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

XL2

  • Sr. Member
  • ****
  • Posts: 341
  • Karma: +72/-1
    • View Profile
Re: Sonic Z-Treme
« Reply #120 on: February 04, 2018, 05:26:26 pm »
Here is a small video (I didn't make it public since many things are removed) just to show what it looks like in terms of performance using LOD models (auto-generated with my map converter).
The effect will be similar to what's in Tomb Raider.

I DIDN'T CODE YET THE MATCHING TEXTURES! Which is why it looks horrible and textures don't fit, but I will code it within a few weeks.
The idea is that if a 4x4 quads wall becomes 1, I will need to generate a texture mixing data from other sprites.
So, 4 times 4 16x16 textures might become a single 32x32 texture, or even a 16x16 texture (I will have to play with different settings)
I removed the collision as I'm working on a per-quad collision and it's not complete.
I also switched to 16 colors sprites, but except for the Quake E1L1 map, all the textures were auto-downgraded with my map converter, which is why they don't look all that great.
Still no PVS/portal, but I might not even need it for Sonic Z-Treme to increase the draw distance thanks to the LOD (we'll see).
I also added analog control in the FPS demo.

https://www.youtube.com/watch?v=crZ7jbSA1SQ&list=UU-U3sMVXNwNkk8Zgs4JPmng&index=1

corvusd

  • Jr. Member
  • **
  • Posts: 81
  • Karma: +8/-0
    • View Profile
    • Personal Web Portfolio
Re: Sonic Z-Treme
« Reply #121 on: February 04, 2018, 08:24:13 pm »
Your progress is really great! AWESOME !!

And also it's a coincidence with me! These days in my research I have added two columns to table data. Now I will update them.

1) If a game has "Tessellation" (you call it LOD) as you say Tomb Raider has it. But there are some more games. The complication is that the game has to have wireframe mode to discover it. Or that the wireframe is implemented in Yabause or other emus to see how many more games are used, surely many! Since it is a trick to gain drawing distance and perfect speed!

* The LOD is the reduction or increase of geometry in an object. Like the FIFA players or the Daytona cars. When it is in the "terrain" or "stage" in the engines they are called Tessellation.

2) I have also added a column of "Table fog" since it was an effect that in PSX also looked a lot. But also in SS!!

I was able to confirm that both effects were fully integrated into the PSX SDK. They are three functions. The "Table fog" is called "Depth Cueing" and the "Tesselation" includes two functions: 1) "Polygon Division" and 2) "Mip-map Function Library". All of them using the GTE.

On the other hand I have searched and not found in the SS SDK any function to do these things. In these cases, programmers create their own code to have these effects in their games or ports. But it is very possible, that each one did it in a different way... and none in the most optimal way. Here perhaps, SEGA failed to detect these needs and integrate them into the SDK.

I think that in this rebirth that you are building, functions like these would be very useful and necessary. I have many concrete ideas for these functions (to optimize the use of memory, VDPs and processes) and proposals in development. But specifically in these cases using the SCU-DSP, would be ideal.

EDIT: I seeing your debugging text I have remembered the polygon limit values (theoretical) in the SS SGL and in the PSX SDK.
SGl talks about:
MAX_POLYGON (number of polygons that can be used): 1800
MAX_VERTICES (number of vertices that can be used): 2500

And in the PSX SDK, in the "Performance Analyzer" manuals you can see analyzes of the game "Motortoon Grand Prix 2": 1200/1040 polygons

It is curious to see how both machines are in very similar numbers.

Greetings and thanks!!!
« Last Edit: February 05, 2018, 07:40:19 am by corvusd »
David Gámiz Jiménez

XL2

  • Sr. Member
  • ****
  • Posts: 341
  • Karma: +72/-1
    • View Profile
Re: Sonic Z-Treme
« Reply #122 on: February 05, 2018, 02:25:45 am »
Thanks!
Just a quick answer :
1) I'm actualy storing the whole lower detail model in memory. But instead of doing it manualy in Blender, it's all automated. So I guess LOD is appropriate, lol. Mipmapping is also a form of LOD, so I do both techniques. Anyway, I will improve memory counsumption by sharing the vertices between the HQ and LQ models. You can find what games use this technique using the vdp1 debugger and looking at the sprites. Far away models will usualy merge 2 textures or more together. Few games that I know are using it : Sonic Jam, Tomb Raider, Quake, Wipeout 2097 and Duke Nukem.
As for the SS SDKs, none of them do it for a good reason : since you need to create a new sprite everytime, it would be a nightmare to manage, without mentionning all the DMA involved. On PS1, since they use texture coordinates, it's super easy. That being said, you could subdivide a quad on Saturn (like 64x64) to 4 times 32x32 without generating a new texture by playing with the memory adresses, width and height.
I don't plan to add that feature as it would be quite complicated to manage, but it could lead to better results with close quads, preventing warping and all.

2) for the fog effect, it's supported by SS hardware thanks to the vdp2 transparency.  That's a feature I want to implement. One way I plan to do is to use color bank for far away objects, and normal vdp1 lut for close objects and put vdp2 transparency on CRAM sprites. I'm just not sure if there is a way to use automatic color calc ratio or if I need to calculate it myself. Worst case scenario if all fails is normal depth gouraud, but it doesn't play nice with some colors (white, blue, yellow, etc.).

Edit : About the limits, it's only the default SGL buffer memory allocation, you can increase it. But with a portal system or pvs the default values should be fine.
« Last Edit: February 05, 2018, 02:45:43 am by XL2 »

itsstillthinking1999

  • Jr. Member
  • **
  • Posts: 84
  • Karma: +5/-0
    • View Profile
Re: Sonic Z-Treme
« Reply #123 on: February 05, 2018, 04:43:03 am »
Loving that Gouraud shading!

itsstillthinking1999

  • Jr. Member
  • **
  • Posts: 84
  • Karma: +5/-0
    • View Profile
Re: Sonic Z-Treme
« Reply #124 on: February 07, 2018, 05:10:14 pm »
Hey XL2 you should show build 34 or 33 to SAGE this year! ;)
http://forums.sonicretro.org/index.php?showtopic=37809&st=0&gopid=921577&#entry921577

XL2

  • Sr. Member
  • ****
  • Posts: 341
  • Karma: +72/-1
    • View Profile
Re: Sonic Z-Treme
« Reply #125 on: February 07, 2018, 06:45:27 pm »
I still have 6 months, so I will have a new version ready by then, I think I can push the draw distance much further, so no rush for now.

corvusd

  • Jr. Member
  • **
  • Posts: 81
  • Karma: +8/-0
    • View Profile
    • Personal Web Portfolio
Re: Sonic Z-Treme
« Reply #126 on: February 08, 2018, 09:01:56 pm »
Hi XL2 !!!

I discover new game that use "tessellation" or LOD like you say in Scenary generation. Is Courier Crisis. This game has wireframe cheat to activate. This game in SS version have more draw distance and FPS that the PSX version !!! Use "Color Calc. Mode: Gouraud Shading + Half-luminance" to far "quads/distorted sprite" and also change for 3D objets and something quads to flat polygon whit base color also. Is a good example to add trick to engine.

The key I think, and the complicate is a good clipping algorithm. Is it possible to write to a simple algorithm for the engine to know when to cover the object / s behind and are to more distance to not draw them??

Greetings!!
David Gámiz Jiménez

XL2

  • Sr. Member
  • ****
  • Posts: 341
  • Karma: +72/-1
    • View Profile
Re: Sonic Z-Treme
« Reply #127 on: February 09, 2018, 01:37:55 am »
For using untextured quads for far away objects, I won't need it to improve the framerate as I think I'm on the right track with the current technique (the per-quad collision might cause some issues thought if it's not fully optimized for early rejection).

For the clipping, my plan is still the per-octree node pvs, the main issue will be the compression used to store the data, but I'm not there yet as the new collision technique might take a while to get it right.

XL2

  • Sr. Member
  • ****
  • Posts: 341
  • Karma: +72/-1
    • View Profile
Re: Sonic Z-Treme
« Reply #128 on: February 09, 2018, 07:11:48 pm »
Still lot of work to be done on the per-quad collision, the view frustum culling and the LOD (or tessalation) texture generation, but here is, just to show my newer version of the engine, an old "map" revisited with the map converter (I didn't try to fix the geometry for the Saturn other than turning triangles to quads and subdividing everything once).

The intro level isn't the biggest level, but it shows that Mario 64 could have worked on the Saturn (with perhaps some compromises of course).

Video here : https://youtu.be/ScGVHMFB58M
« Last Edit: February 09, 2018, 08:55:41 pm by XL2 »

mindslight

  • Administrator
  • Full Member
  • *****
  • Posts: 157
  • Karma: +6/-1
    • View Profile
    • Jo Engine
Re: Sonic Z-Treme
« Reply #129 on: February 10, 2018, 09:19:57 am »
Very impressive  :)

corvusd

  • Jr. Member
  • **
  • Posts: 81
  • Karma: +8/-0
    • View Profile
    • Personal Web Portfolio
Re: Sonic Z-Treme
« Reply #130 on: February 10, 2018, 08:13:26 pm »
For using untextured quads for far away objects, I won't need it to improve the framerate as I think I'm on the right track with the current technique (the per-quad collision might cause some issues thought if it's not fully optimized for early rejection).

For the clipping, my plan is still the per-octree node pvs, the main issue will be the compression used to store the data, but I'm not there yet as the new collision technique might take a while to get it right.

Sorry for not answer sooner... Absolutely you are in the right path. Your actual work and improvement in the engine talk about the quality work it for you.

My only intention is try to add something possible ideas to get new paths to improve the use of the machine.

In other hand your goals are impressive: Clipping with per-octree node pvs, the compression for store the data(in SDK SS can see the RLE compression are been implemented) and finally a new collision technique. All goal are important and impressive to build a strong engine for a "SS Sonic 3D" game ;)

Still lot of work to be done on the per-quad collision, the view frustum culling and the LOD (or tessalation) texture generation, but here is, just to show my newer version of the engine, an old "map" revisited with the map converter (I didn't try to fix the geometry for the Saturn other than turning triangles to quads and subdividing everything once).

The intro level isn't the biggest level, but it shows that Mario 64 could have worked on the Saturn (with perhaps some compromises of course).

Video here : https://youtu.be/ScGVHMFB58M

Is a outstanding work! Really! You are use the two SH2?? Because is possible will go more far... and If you could use de DSP of SCU it be a crazy improvement! :D

In the video is possible see a peak of near 1000 quads in screen at 30FPS!!! is a madness!! XD Is possiible that you cap the limit FPS to 30, is possible that you rendering at more FPS, near 60FPS??

Thanks and encourage!!!! GO GO GO!
« Last Edit: February 10, 2018, 08:25:53 pm by corvusd »
David Gámiz Jiménez

itsstillthinking1999

  • Jr. Member
  • **
  • Posts: 84
  • Karma: +5/-0
    • View Profile
Re: Sonic Z-Treme
« Reply #131 on: February 11, 2018, 02:28:53 am »
Face it Pretendo, you are not worthy

XL2

  • Sr. Member
  • ****
  • Posts: 341
  • Karma: +72/-1
    • View Profile
Re: Sonic Z-Treme
« Reply #132 on: February 11, 2018, 03:12:00 am »
For using untextured quads for far away objects, I won't need it to improve the framerate as I think I'm on the right track with the current technique (the per-quad collision might cause some issues thought if it's not fully optimized for early rejection).

For the clipping, my plan is still the per-octree node pvs, the main issue will be the compression used to store the data, but I'm not there yet as the new collision technique might take a while to get it right.

Sorry for not answer sooner... Absolutely you are in the right path. Your actual work and improvement in the engine talk about the quality work it for you.

My only intention is try to add something possible ideas to get new paths to improve the use of the machine.

In other hand your goals are impressive: Clipping with per-octree node pvs, the compression for store the data(in SDK SS can see the RLE compression are been implemented) and finally a new collision technique. All goal are important and impressive to build a strong engine for a "SS Sonic 3D" game ;)

Still lot of work to be done on the per-quad collision, the view frustum culling and the LOD (or tessalation) texture generation, but here is, just to show my newer version of the engine, an old "map" revisited with the map converter (I didn't try to fix the geometry for the Saturn other than turning triangles to quads and subdividing everything once).

The intro level isn't the biggest level, but it shows that Mario 64 could have worked on the Saturn (with perhaps some compromises of course).

Video here : https://youtu.be/ScGVHMFB58M

Is a outstanding work! Really! You are use the two SH2?? Because is possible will go more far... and If you could use de DSP of SCU it be a crazy improvement! :D

In the video is possible see a peak of near 1000 quads in screen at 30FPS!!! is a madness!! XD Is possiible that you cap the limit FPS to 30, is possible that you rendering at more FPS, near 60FPS??

Thanks and encourage!!!! GO GO GO!

For RLE, you mean using SBL?
I thought of something else, but everything is on the table.
It might take a few months before I truly focus on pvs.

I am using both SH2, but not the SCU DSP. The problem with the SCU DSP is that it needs to be coded in assembly (I haven't learnt it yet) and there is some overhead since you need to DMA transfer data, start the DSP program, wait for it to complete the processing, stop the program and then fetch the data. Unless you are dealing with complex maths in parallel, it's not really worth it. Most people used it for lightning calculations, but SGL for some reasons didn't use it.
It also has really limited RAM and can't do divisions, so you can't do that much with it.

For 60 fps, it would work with around 450 quads on screen, no gouraud shading, low res textures and/or no overdraw, so it's not really a solution for now with complex levels.
But it works nice with Sonic X-Treme levels.

corvusd

  • Jr. Member
  • **
  • Posts: 81
  • Karma: +8/-0
    • View Profile
    • Personal Web Portfolio
Re: Sonic Z-Treme
« Reply #133 on: February 11, 2018, 01:06:04 pm »
For RLE, you mean using SBL?
I thought of something else, but everything is on the table.
It might take a few months before I truly focus on pvs.

I am using both SH2, but not the SCU DSP. The problem with the SCU DSP is that it needs to be coded in assembly (I haven't learnt it yet) and there is some overhead since you need to DMA transfer data, start the DSP program, wait for it to complete the processing, stop the program and then fetch the data. Unless you are dealing with complex maths in parallel, it's not really worth it. Most people used it for lightning calculations, but SGL for some reasons didn't use it.
It also has really limited RAM and can't do divisions, so you can't do that much with it.

For 60 fps, it would work with around 450 quads on screen, no gouraud shading, low res textures and/or no overdraw, so it's not really a solution for now with complex levels.
But it works nice with Sonic X-Treme levels.

Yes, I remember some library for that. Is a CMP LIB. In the "ST-135-R4-092295 Program Library User's Guide 3" is explain.

Are great if you are using right now the two SH2. SCU DSP is truly powerful but is high complex to use it, I know... but the memory I don't think is the problem here. First the ASM language. Second design that task make and design the process thread carefully. It is possible to tessellation(LOD) use the SH2, and for lightning or transformation use SCU to speed up. Is only intuition for my part, I not a programmer...

SGL is created mainly for AM2 team... I think in its games, the use of lighting is very limited... and not need it more speed in this area. This reason it possible to not use SCU DSP at all.

Other case is Sonic Team, whit Burning Rangers... Is are a truly lighting system... but not use SCU... is rare.

The 500 quad at 60FPS is real numbers... because in the games whit this FPS the numbers and shading used are it you said Two examples: VF2, Mass Destruction... etc...

Thanks for the feedback!! :)
David Gámiz Jiménez

Cerv3ro

  • Newbie
  • *
  • Posts: 7
  • Karma: +1/-0
    • View Profile
Re: Sonic Z-Treme
« Reply #134 on: February 12, 2018, 01:29:47 am »
Your progress is really great! AWESOME !!

And also it's a coincidence with me! These days in my research I have added two columns to table data. Now I will update them.

1) If a game has "Tessellation" (you call it LOD) as you say Tomb Raider has it. But there are some more games. The complication is that the game has to have wireframe mode to discover it. Or that the wireframe is implemented in Yabause or other emus to see how many more games are used, surely many! Since it is a trick to gain drawing distance and perfect speed!

* The LOD is the reduction or increase of geometry in an object. Like the FIFA players or the Daytona cars. When it is in the "terrain" or "stage" in the engines they are called Tessellation.

2) I have also added a column of "Table fog" since it was an effect that in PSX also looked a lot. But also in SS!!

I was able to confirm that both effects were fully integrated into the PSX SDK. They are three functions. The "Table fog" is called "Depth Cueing" and the "Tesselation" includes two functions: 1) "Polygon Division" and 2) "Mip-map Function Library". All of them using the GTE.

On the other hand I have searched and not found in the SS SDK any function to do these things. In these cases, programmers create their own code to have these effects in their games or ports. But it is very possible, that each one did it in a different way... and none in the most optimal way. Here perhaps, SEGA failed to detect these needs and integrate them into the SDK.

I think that in this rebirth that you are building, functions like these would be very useful and necessary. I have many concrete ideas for these functions (to optimize the use of memory, VDPs and processes) and proposals in development. But specifically in these cases using the SCU-DSP, would be ideal.

EDIT: I seeing your debugging text I have remembered the polygon limit values (theoretical) in the SS SGL and in the PSX SDK.
SGl talks about:
MAX_POLYGON (number of polygons that can be used): 1800
MAX_VERTICES (number of vertices that can be used): 2500

And in the PSX SDK, in the "Performance Analyzer" manuals you can see analyzes of the game "Motortoon Grand Prix 2": 1200/1040 polygons

It is curious to see how both machines are in very similar numbers.

Greetings and thanks!!!

Hei guys, when you talk about "Tessellation" or "LOD" you mean something like this? (Go to minute 05:00).
https://www.youtube.com/watch?v=ME7Dkpgd_-k&t=175s

Different levels of detail acording the distance?.

Very impresive work XL2, thank you very much for doing this.

 

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