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

corvusd

  • Jr. Member
  • **
  • Posts: 81
  • Karma: +8/-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

  • Sr. Member
  • ****
  • Posts: 341
  • Karma: +72/-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: 81
  • Karma: +8/-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

  • Sr. Member
  • ****
  • Posts: 341
  • Karma: +72/-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: 81
  • Karma: +8/-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

  • Sr. Member
  • ****
  • Posts: 341
  • Karma: +72/-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

  • Sr. Member
  • ****
  • Posts: 341
  • Karma: +72/-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

  • Full Member
  • ***
  • Posts: 175
  • Karma: +13/-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

mindslight

  • Administrator
  • Full Member
  • *****
  • Posts: 157
  • Karma: +6/-1
    • View Profile
    • Jo Engine
Re: Sonic Z-Treme
« Reply #233 on: July 10, 2018, 09:07:59 am »
Very impressive. Homebrews reached a new level

XL2

  • Sr. Member
  • ****
  • Posts: 341
  • Karma: +72/-1
    • View Profile
Re: Sonic Z-Treme
« Reply #234 on: July 10, 2018, 10:20:52 pm »
Thanks.
Good news : SAGE as been pushed back one month, which should help me quite a bit to get a demo out in time.
I've also added support for very basic paletted light sources (per face instead of per vertex, so no gouraud for now).
I will have to improve my support for light sources, but it doesn't look bad and comes at no costs since it's just precomputed.

I might stick with this technique and maybe use gouraud shading on special objects to allow bump mapping (see third and fourth images for the SGL tech demos).

20EnderDude20

  • Full Member
  • ***
  • Posts: 115
  • Karma: +6/-0
  • I'm also known as "The Blender Fiddler" on Youtube
    • View Profile
    • Youtube Channel
Re: Sonic Z-Treme
« Reply #235 on: July 12, 2018, 06:18:21 pm »
For the water, what if you set the name of the material of the water in the .mtl file to, for instance, "__WATER__" and your converter can detect and assign every face with that material to have all of the scripted behaviors and textures on those faces?

XL2

  • Sr. Member
  • ****
  • Posts: 341
  • Karma: +72/-1
    • View Profile
Re: Sonic Z-Treme
« Reply #236 on: July 12, 2018, 06:50:53 pm »
I'm doing something similar, but I'm not reading the mtl file so I just use the texture name.
I will expand that system in the future to try to allow bump mapping.

20EnderDude20

  • Full Member
  • ***
  • Posts: 115
  • Karma: +6/-0
  • I'm also known as "The Blender Fiddler" on Youtube
    • View Profile
    • Youtube Channel
Re: Sonic Z-Treme
« Reply #237 on: July 12, 2018, 10:13:53 pm »
In one point, are you planning to add a power-up, or character that will utilize environment mapping?

XL2

  • Sr. Member
  • ****
  • Posts: 341
  • Karma: +72/-1
    • View Profile
Re: Sonic Z-Treme
« Reply #238 on: July 12, 2018, 10:52:46 pm »
Environment mapping is a sure no, it's super slow to read from the framebuffer and there are no texture coordinates.
I am considering power ups but I have many other things to do first.


20EnderDude20

  • Full Member
  • ***
  • Posts: 115
  • Karma: +6/-0
  • I'm also known as "The Blender Fiddler" on Youtube
    • View Profile
    • Youtube Channel
Re: Sonic Z-Treme
« Reply #239 on: July 13, 2018, 01:09:15 am »
I thought you could've used the slave CPU to accomplish the task, like in Sonic r,  but what do I know? I'm sure that you've thought of that, but it just wasn't efficient enough to accomplish everything else in a 30th of a second, with environment texturing. Am I right?

 

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