Author Topic: Sonic Z-Treme  (Read 14129 times)

corvusd

  • Jr. Member
  • **
  • Posts: 57
  • Karma: +5/-0
    • View Profile
    • Personal Web Portfolio
Re: Sonic Z-Treme
« Reply #225 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.

Regards!
« Last Edit: May 23, 2018, 08:49:52 pm by corvusd »
David Gámiz Jiménez

XL2

  • Full Member
  • ***
  • Posts: 242
  • Karma: +56/-1
    • View Profile
Re: Sonic Z-Treme
« Reply #226 on: May 23, 2018, 04:30:07 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...

corvusd

  • Jr. Member
  • **
  • Posts: 57
  • Karma: +5/-0
    • View Profile
    • Personal Web Portfolio
Re: Sonic Z-Treme
« Reply #227 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.

Regards!
« Last Edit: May 24, 2018, 06:49:41 pm by corvusd »
David Gámiz Jiménez

XL2

  • Full Member
  • ***
  • Posts: 242
  • Karma: +56/-1
    • View Profile
Re: Sonic Z-Treme
« Reply #228 on: May 25, 2018, 12:17:06 am »
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.
« Last Edit: May 25, 2018, 06:27:56 am by XL2 »

corvusd

  • Jr. Member
  • **
  • Posts: 57
  • Karma: +5/-0
    • View Profile
    • Personal Web Portfolio
Re: Sonic Z-Treme
« Reply #229 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! :)
David Gámiz Jiménez

XL2

  • Full Member
  • ***
  • Posts: 242
  • Karma: +56/-1
    • View Profile
Re: Sonic Z-Treme
« Reply #230 on: June 16, 2018, 05:47:57 pm »
Here is a new update on my new engine (WIP!) on real hardware.
I didn't implement back the physics/controls, so don't pay attention to that.
What's new : compressed per-vertex animation with interpolation (a bit like Crash Bandicoot and Quake 2), VDP2 transparency fade in, per-vertex realtime lightning (on Sonic only), audio using tones, splitscreen (not seen here), octree instead of an uniform grid for culling/collision, paletted/CLUT sprites, LOD model autogenerated for distant quads and probably many other things I forgot to mention.
Splitscreen works at a stable 30 fps from what I tested.

It's not optimized yet, so there is room for lot of improvement.

https://www.youtube.com/watch?v=J51wKAvJL7g

XL2

  • Full Member
  • ***
  • Posts: 242
  • Karma: +56/-1
    • View Profile
Re: Sonic Z-Treme
« Reply #231 on: June 23, 2018, 03:04:20 pm »
Here is splitscreen in action (real hardware) : https://youtu.be/A3ClV-6aLdQ

ponut64

  • Jr. Member
  • **
  • Posts: 86
  • Karma: +8/-0
    • View Profile
Re: Sonic Z-Treme
« Reply #232 on: June 23, 2018, 11:04:18 pm »
These improvements are hitting pretty rapidly, great work

 

Sitemap 1 2 3 4 5 6 7 8 9 10 
SMF spam blocked by CleanTalk