Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - corvusd

Pages: [1] 2 3 4
Thanks for the update.
Have you seen a single game doing paletted gouraud?
Also, have you seen a game using RBG1?

Sorry I see the post today.

Have you seen a single game doing paletted gouraud?
Yes, but only for Normal Sprite, Polygons or Line. Not for distorted sprite or scaled sprite.
Also, have you seen a game using RBG1?
Yes, not are analysed deeply all games. And are possible that I confused RBG1 whit RBG0 or named RBG2. But are sure in this two example: Street Racer and Mechwarrior 2


Share your code / Re: Model converter (.ZTP) -0.05 - WIP
« on: June 11, 2018, 10:35:06 pm »
Ok, scratch that last one, I just did minimal clean up of the code.

Just remember : you need to have 1 base model, the other models will use that name +  "_000001" to whatever amount of frames you want.
The base model needs to write the material data, but not the animation.
Just make sure you keep the vertices order (I think it does it by default in Blender).

I'm also sharing the source code for the converter, it should be cleaner than last time...but I did make a mess while adding animation support!


Absolutely amazing! :D

Share your code / Re: Model converter (.ZTP) -0.05 - WIP
« on: June 07, 2018, 08:37:49 pm »
Fantastic news! Really making projects like mine possible. One thing though excuse my lack of concept but in my Katamari project I ported the PSP level and decimated it and made it quads. When loading the ZTE it missing a few select faces even some simple 4 vertex quad with correct normals, but will let me add more complex things like the plate of snails.

I fixed a lot of the levels glitches by merging the vertices of the separate objects and making sure there isn't a face underneath another. But having a hard time making any more 3d objects show up without being clipped out by the floor or whatever. .

For example of a simple quad clipped: the shopping bag that goes up to the table here

Is clipped on the saturn build but let me add the plate of all this stuff on it, if merged the plates vertices to the ground.

Can I make a level this way if I clean it up more or is the Zsorting(?) too much with all the stuff and need a proper map?

Amazing project!! Katamari Damacy in SS whit RT Gouraud Shading!!! OOOOOHHHH!!! :D

Project announcement / Re: Sonic Z-Treme
« on: May 28, 2018, 09:58:42 pm »
I think I found a solution!
By using gouraud shading on 8 bits paletted sprites, I could simply register 8x 256 color banks with different light intensity. By using gouraud changing the color value of bits 9 to 12, it would just switch the color banks!
That means I could get gouraud lightning AND transparency.
Of course, only 8 intensities is a bit of a bummer, but it's better than none and it should look smooth enough.
I'm not 100% sure that it could work with realtime gouraud as it would require to register the 8 values and tell SGL to onpy choose among those.
Another benefit is that if your quad has flat lightning, you don't need to use gouraud, saving VDP1 rendering time.
I think it's a much better solution than what Sonic R does, but fitting all my colors in 256 values isn't that easy and it might not look that great and it prevents differently colored lightning (so you only have 8 intensities for any given levels), but we'll see I guess.
Of course, if I could somehow fit all my colors in 128 values, I could get 16 intensities, and full 32 intensities if I make it fit in 64, but I doubt it.

Edit : Ok, so the answer is that it wouldn't work for full gouraud (only flat lightning). I'm now looking at other solutions with 32 colors and green gouraud or 256 with red gouraud.
You are great, that you fight for put more at limit the machine. Bravo!!!
I hope, soonly share it with you a little draft of my render pipeline idea.
See you soon! :)

UPDATED: 28-05-2018 80% Complete:
- Complete analysis of: SEGA GAME SAMPLE 1 for SBL 1.1 (1994-08-01)
- Complete Dragon Ball Z Games.
- Improve description and data analysis of "Lighting" and "Layers / Color BPP and Type" columns.

UPDATED: 23-05-2018 79% Complete:
- New games. Up to 257. No comment.  ::)
- Improve a lot of games, in various columns.
- Improve title columns.
- Improve some most important SEGA games.
- Complete more games.
- Add more credits games.
- Improve Lighting column data.
- Basis Analysis to Altron games.

Project announcement / Re: Sonic Z-Treme
« on: May 23, 2018, 09:22:47 pm »
Yeah, I think it would make more sense to use textured lightmaps instead of gouraud for speed reasons, but it takes a lot of VRAM.
And the Color RAM is super limited, so I don't know.
If I had more color RAM I would just pick gouraud on everything.
Maybe I will use a technique similar to John in the end, or maybe I'll just not care about the transition between gouraud/no gouraud...
Yes, texture with the light "painted" is the most cheap and nice solution. The cost is it need more space data in VDP1 VRAM in pattern, and color data in VDP1 or VDP2 area VRAM. And more, if you need 4 or more variant color grades for ratio CC function for fade over VDP2 foreground, more data. In this case direcly in VDP2 color VRAM.

For Gouraud with texture, distorted sprite, only you can use color of the VDP1 RAM. The Gouraud tables store in specify boundary in VDP1 VRAM. John for Sonic-R seem convert in the fly the color palettes to Color Bank for the pattern in far clipping to fade area. Maybe the transition area is for this reason... I think.

In other hand, this issue is a good reason to gain speed. Because in some Z value in far clipping, the game not draw Gouraud distorted sprite, more expensive that distorted flat quad.

For me the ideal situation is a system lighting with a base ambient color , with at 3 lights parallel lights sourced color to affect a 3D model in real time. Very nice effect, and pretty usual in PSX games. And in other hand totally possible in SS. For the scenery, pre calculated Gouraud table lighting in some point in the scenery, is are a nigh or point lighting in the design. This point are at the 3 Light parallel that can affect at 3D models, not all models, only a controlled quantity, for not recharged the CPU lighting calculate. In someway Burning Ranger, Loaded(Point Lights) and Lobotomy Slave(Point Lights) engine archive this type of final render in SS.

The problem of use Gouraud with your LOD scenery system is we can see the change in the geometry shading, but for me is a low cost, to have lighting shading 3D real time game, and with a good compromise with the final speed.

Only share with you, my ideas, not are that I want say that need it your project. Right now, I think is a wonderful gift for the lovers SS, and possible the most advanced homebrew realtime engine for the system.


Project announcement / Re: Sonic Z-Treme
« on: May 23, 2018, 07:45:15 am »
Nice, I didn't see it.
I use the same technique for CBANK sprites, but I admit that his solution for CLUT sprites could work, but then why even put gouraud shading if it's so limited? I could just write the lightning value directly on the textures and it would be faster for rendering.
Of course it would take way more VRAM, but it might work.
Another solution is to use the gouraud on CRAM sprites bug to produce pseudo bump mapping.
Your current implementation is very good.
I think that John's implementation is a bit more complex than yours.
In this way you have the scenarios with the same illuminated light, already pre-calculated. And characters with light Source Gouraud plus the stage static lighted looks very good.
Obviously he does not use Gouraud with Color bank in distorted sprites for the final Fade on the VDP2, because of the bug there is. At least that's what I think.

Anyway, I think that even we can get more with SS. Have a Depth cueing with fade like the one you have implemented, and use the transparencies of VDP1 plus the VDP2. As soon as I have a little time, after advancing the game analysis. I will start to design my idea to share it with the community.

Let's see if for future homebrew games we put the limit even more to the SS.


Project announcement / Re: Sonic Z-Treme
« on: May 22, 2018, 11:47:26 pm »
I do plan on having static lights (the quads closer to screen use CLUT while the quads with CC use CRAM banks), but I'm quickly running out of time.
But if I think I can implement it in 1 or 2 hours I will sure try it!

Project announcement / Re: Sonic Z-Treme
« on: May 18, 2018, 09:35:17 pm »
Still a very long way to go : I'm not done with the rendering part and I haven't started to put gameplay back in (you can just move the camera around now), but I think it looks rather good so far.
You can see the draw distance is quite good!
I might have to reduce it a little bit, but it shouldn't impact too much the visual as the draw distance is a bit too far now (it should still be fine at 30 fps).
Plus with the transparency effect, I think most people won't mind and will instead appreciate the effects ;)
Absolutely great improve.
Your new build whit the far fade clipping whit the VDP2 CC ratio and priority is great, same that Sonic-R or very similar. Sonic-R use static source Gouraud in all the rest scenery before fade.
And the Sonic and Tails whit Real Time Gouraud Light is amazing! :) All together look very nice an promising! Go Go! :D
You can see that me, are capable to appreciate all this effects and your GREAT efforts!! Thanks!! :D

Project announcement / Re: Virtua Skimmer
« on: May 18, 2018, 09:30:41 pm »
You can easily put one light source per model, but not more.
SGL can only register one source.
The way around this would be to not use SGL, or maybe it's possible to use offsets, but I don't know.
I might compute lights offline for static lights, which should allow much better colors.
Maybe you could then use the SCU DSP to calculate the additions/substraction on top of static lights, but I think it would be slow.

I already tried with colors, it's super easy.
For this demo, I'm using "semi white", but you can put any color you want.

It's already using the 2 CPUs. As soon as you call slPutPolygon, it will look to see if the slave is busy, and if not it will transfer the command so that the slave handles everything.

I know for you, the easy way right now is use the SGL. For 1 Light Dynamic the SGL is very well implemented.

But my questions was for this data extract from, for the theoretical maximum capacity for SS in this type of process:

DSP geometry processing: 188 MIPS (million instructions per second)

    Fixed-point operations: 114 MOPS (million operations per second)
    Additions: 85 million adds/sec
    Multiplications: 85 million multiplies/sec
    16-bit divisions: 5 million divides/sec

Geometry calculations: 114 MOPS fixed-point calculations

    Vertex transformations: 2,400,000 vertices/sec
    Polygon transformations: 1,800,000 polygons/sec
    T&L flat lighting: 800,000 polygons/sec
    T&L Gouraud lighting: 700,000 polygons/sec

Polygon rendering performance: Lighting

    800,000 polygons/s: Flat shading, 32-pixel polygons
    500,000 polygons/s: Flat shading, 50-pixel polygons
    200,000 polygons/s: Gouraud shading, 32-pixel polygons

Texture mapping performance: Lighting

    300,000 polygons/s: 32-texel textures
    200,000 polygons/s: 70-texel textures
    140,000 polygons/s: Gouraud shading, 32-texel textures

Project announcement / Re: Virtua Skimmer
« on: May 17, 2018, 08:57:51 pm »
I tested it on real hardware, I tried with 7 models (around 180 quads per model) and the results are rather good, with 60 fps with 4 models, then the VDP1 can keep up, but the CPU doesn't. By not updating each frame, it might be possible to keep 60.

Very interesting implementation XL2. You are using one light Dynamic source for all models. 1200 quads lighted whit source. Really nice. You think if is possible improve the performance or use of the CPUs? More Lights and whit color? Thanks! :)

Project announcement / Re: Sonic Z-Treme
« on: April 22, 2018, 10:58:16 pm »
Maybe is to soon to say something. XL now are learning and improve your engine, to put at limit SS. All your ideas are great and maybe possible. But, now not is the time to this. And this type of design, maybe, is too big for the machine or the actual technical resources. Thanks for your apports. 👍

Project announcement / Re: Sonic Z-Treme
« on: April 14, 2018, 10:42:01 pm »
The flat shaded quads in SGL can use flat lightning both in RGB and palette format.
Perfect! :D

I'm not using the SCU DSP yet, so it's SH2 only.
Not mention SCU in the next two years. I promise XD

I can't do realtime light with color bank sprites, but I'm now doing like in Sonic R and Bulk Slash.
Why not? What refer exatly that doing like this games?

I can't use the high res mode, it's super hard to setup, so I don't want to waste time on it.
It is possible, the requirements are many and both VDPs. It is normal that you choose not to get involved in this. But is very attractive, have it full resolution SS in a Sonic game. :)

Project announcement / Re: Sonic Z-Treme
« on: April 14, 2018, 10:52:32 am »
I just did a small video (it's not public as there isn't much to show) for the split screen mode and the removal of gouraud shading/use of CRAM sprites.

Really nice improvements!! Congratulations.

We can see source lighting in models no? Yo are calculate level of luminance or brightness, by VDP1 CC or change color palette for this face??

For calculate lighting use SH2 or SCU-DSP?

And finally. You can apply this lighting to scenery faces?

If you can all this without use CC, is possible you can use Full HiRes mode in VDP1 and VDP2.


Pages: [1] 2 3 4
SMF spam blocked by CleanTalk