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

XL2

  • Sr. Member
  • ****
  • Posts: 341
  • Karma: +72/-1
    • View Profile
Re: Sonic Z-Treme
« Reply #135 on: February 12, 2018, 01:40:28 am »
Yes, but for the actual level instead of the entities.

You can check Wipeout which does it too :
https://www.youtube.com/watch?v=x8yLq45tDGc
If you look at the sides, 1 quad turns to 16 (and vise-versa).
It's about the same ratio as I'm doing, but my quads are much larger, so I might have to push the effect a bit to avoid warping on real hardware.
Tomb Raider also does it (starts around the 1 min mark) :
https://www.youtube.com/watch?v=FM3cQt-3kGM


XL2

  • Sr. Member
  • ****
  • Posts: 341
  • Karma: +72/-1
    • View Profile
Re: Sonic Z-Treme
« Reply #136 on: February 12, 2018, 03:47:51 am »
Good news! I only put around 1 hour since the last video, but seems like I got the collision almost right on my first try. I still have to make some adjustments, but a level like a Quake map is fully working now (except for doors).

I still have to write the texture generation to match the merged quads and use another frustum culling technique (I have an octree, but it's not used other than collision since it can't work well with the SGL frustum culling functions).

Here is a Quake map in my engine, with fully working collision : https://youtu.be/uBa6NNM4ZU0

Still no portal or pvs or depth buffer, so it wouldn't work nice on real hardware unless I drop the texture quality (it's 64x64 right now, but with the overdraw it will be slow).

corvusd

  • Jr. Member
  • **
  • Posts: 81
  • Karma: +8/-0
    • View Profile
    • Personal Web Portfolio
Re: Sonic Z-Treme
« Reply #137 on: February 12, 2018, 09:17:59 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!!!

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 according the distance?.

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

Very similar techniques. Two link to wikipedia:
https://en.wikipedia.org/wiki/Level_of_detail
https://en.wikipedia.org/wiki/Tessellation_(computer_graphics)

In the case in this generation of 3D. The improvement of XL2 in your engine is more similar to modern Tessellation. Is a LOD automatic or calculate in real time in function of the variables. To put in screen the optimal number of data geometry.

LOD is a manual technique or static. I mean, you create the levels o detail model for a one specify model. This is used a lot in a lot of game in all catalog in SS. For example FIFA games or similar games. Is easy see the steps in the models. Or in Daytona USA in a cars.

Normally the tessellation is use in the scenario. I one part o in all. In the case of Wipeout or Nascar 98 for the road. In other case like Tomb raider or Courier Crisis for all scenario.

In this age. A lot of games use it. More in PSX for easy to implement. For me one the most aggressive Tesselation + LOD in PSX games us very last games: Terracon (2000)

Good news! I only put around 1 hour since the last video, but seems like I got the collision almost right on my first try. I still have to make some adjustments, but a level like a Quake map is fully working now (except for doors).

I still have to write the texture generation to match the merged quads and use another frustum culling technique (I have an octree, but it's not used other than collision since it can't work well with the SGL frustum culling functions).

Here is a Quake map in my engine, with fully working collision : https://youtu.be/uBa6NNM4ZU0

Still no portal or pvs or depth buffer, so it wouldn't work nice on real hardware unless I drop the texture quality (it's 64x64 right now, but with the overdraw it will be slow).

Again my congratulations!! 1200 quads in screen!! Wohooo!!! :D

I can wait to put in my SS and in yabause to see your work near! ;)

In other hand. I continue my research. I can confirm, that in last SGL (3.0), SEGA implemented the Depth Cueing like PSX SDK. For the side of the use of SCU in SS SDK. Is strange. I can see a lot of function in SBL y SGL to use DMA, access to RAM storages and all stuff tu use it. But not are a code specify implemented in C to call a ASM code or similar. Only in SBL I can find some come to transform or matrix in a folder name MATHS. Is rare, because the very first game of AM2 use it SCU: VF1 and Remix

Finally! I can read in youtube a user said it, about port Quake 2 to SS in your engine. I can help you whit the graphics part. If some day this project start. ;) One of my dreams is make a very good port of Doom. Best that PSX, I believe it possible. And because no! a Quake 2. But Sonic Z-treme is good start to put to limit a our lovely machine!! I want see more transparencies in SS, like PSX... real lens flares for example. I try to design some trick or way to do it!!

Stay in touch! See ya!! :)
David Gámiz Jiménez

XL2

  • Sr. Member
  • ****
  • Posts: 341
  • Karma: +72/-1
    • View Profile
Re: Sonic Z-Treme
« Reply #138 on: February 12, 2018, 11:13:40 pm »
For the depth cueing, it's what I'm using for the gouraud shading.
For the LOD/tessalation, the thing is that all the work is done offline, so there are really 2 full maps in memory, I display one or the other depending on the distance from camera for each node. It could be done manually for better results, but I don't have time for that so it's all automated during conversion.
Nothing is built in realtime.
While it would be possible to subdivide a quad in realtime, the other way around can't be done since we are dealing with distorted sprites only.
I could choose to just use the low quality model if I wanted, but the results would be bad.
About the 1200 quads on screen, SGL transforms the vertices, then does backface culling, so only half those quads reach the VDP1. Using a BSP tree could reject them earlier, but walking the tree would be slower than what could be gained (and it uses more memory).

The SCU DSP is in assembly only, and SGL doesn't have functions using it, while the SBL functions are useless : they transform vertices from a different matrix format and it is not compatible with the SGL quad processing (buffers and all).
The DSP RAM is also too limited, so I can't really use it for a depth buffer or something like that, while SGL already has a strong lightning support built in, so I wouldn't gain anything from replacing it.
It's hard to find a good use for it in these circonstances.

For Quake 2, I could just show 1 or 2 maps in my engine, but I wouldn't want to port the whole game since there are much better ways to play it already.

corvusd

  • Jr. Member
  • **
  • Posts: 81
  • Karma: +8/-0
    • View Profile
    • Personal Web Portfolio
Re: Sonic Z-Treme
« Reply #139 on: February 13, 2018, 07:25:24 pm »
For the depth cueing, it's what I'm using for the gouraud shading.
For the LOD/tessalation, the thing is that all the work is done offline, so there are really 2 full maps in memory, I display one or the other depending on the distance from camera for each node. It could be done manually for better results, but I don't have time for that so it's all automated during conversion.
Nothing is built in realtime.
While it would be possible to subdivide a quad in realtime, the other way around can't be done since we are dealing with distorted sprites only.
I could choose to just use the low quality model if I wanted, but the results would be bad.
About the 1200 quads on screen, SGL transforms the vertices, then does backface culling, so only half those quads reach the VDP1. Using a BSP tree could reject them earlier, but walking the tree would be slower than what could be gained (and it uses more memory).

The SCU DSP is in assembly only, and SGL doesn't have functions using it, while the SBL functions are useless : they transform vertices from a different matrix format and it is not compatible with the SGL quad processing (buffers and all).
The DSP RAM is also too limited, so I can't really use it for a depth buffer or something like that, while SGL already has a strong lightning support built in, so I wouldn't gain anything from replacing it.
It's hard to find a good use for it in these circonstances.

For Quake 2, I could just show 1 or 2 maps in my engine, but I wouldn't want to port the whole game since there are much better ways to play it already.


OK! Now I understand you. Yeah, you are implemented LOD for the scenery. But is a absolutely great achievement. And is a good opportunity to design great levels to fit in memory. :)

This sentence I don't understand: "I could choose to just use the low quality model if I wanted, but the results would be bad."

I think that, in Tomb Raider and Wipeout 2097 is realtime. Because both games full the memory and both are been port to PSX whit the same memory. The Wipeout 2097 is a port from PSX, that have this feature implemented in SDK.

Whit the data recompiled in Yabause. 1200 quads in screen not is are impossible situation. Sonic R(2x SH2 + SCU use) or Burning Rangers(2xSH2 no SCU use) have more than this quantity and run whiteout problem at 30FPS. 4x4 Hardcore(1500) or Tomb Raider(1300) whit slowdown to 15FPS o less in the 4x4 case. Yabause only list the elements in the screen, not the calculated or back face clipped... Maybe more really.

Is true the SBL an SGL, are a two different approach to build a "engine" or conjunction of library to arm a SDK. In some form the structure of libraries SBL is similar to PSX SDK. But SGL is more similar to PSX SDK in the name of the specify 3D functions and variables in it. I think in last version SEGA tried to fusion both... but not is perfect SDK to exploit to maximum SS.

This days I think about the fantasy, of the in time, fusion of the Tantalus/Perfect engine(Yes I think in some aspect are good features) + Argonaut Engine + Sonic Team Engine + Sonic R Engine + Slave(Lobotomy) Engine + Game Arts FMV codec... for put some of the best devs engines of the time. If SEGA would have invested in all this GREAT code, the SDK enriched greatly.

Anyway. Your work, the Johannes work and the other awesome people of the SS community homebrew, this days make true my dreams. Thank you!

GO GO GO! Greetings! :)
« Last Edit: February 13, 2018, 08:41:46 pm by corvusd »
David Gámiz Jiménez

XL2

  • Sr. Member
  • ****
  • Posts: 341
  • Karma: +72/-1
    • View Profile
Re: Sonic Z-Treme
« Reply #140 on: February 13, 2018, 07:47:44 pm »
About the low quality model, I just meant that by changing one line of code I could choose to display the low quality or high quality model.
About 1200 quads on screen, it's totally possible even at 30 fps. But for a FPS, that means many many pixels that keep getting rewritten over since the walls - if you don't have proper occlusion culling - can take the whole screen.
About Burning Rangers, there is a SCU DSP program in memory, so are you sure it's not used?
I don't know if Wipeout and Tomb Raider do the quad subdivision in realtime, but one way to see is to check the texture memory address : if 1 quad turns to 4, look at the top left quad. If the address is the same as the lone quad texture address, with different width/height, then you know it's probably done in realtime.
But they could also store it in memory since the low quality map should take maybe as little as 1/4 the size of the high quality map.
About SBL and SGL, both are really interconnected. For graphics, it's SGL, for almost everything else it's SBL or SBL wrappers.

corvusd

  • Jr. Member
  • **
  • Posts: 81
  • Karma: +8/-0
    • View Profile
    • Personal Web Portfolio
Re: Sonic Z-Treme
« Reply #141 on: February 13, 2018, 08:49:50 pm »
About the low quality model, I just meant that by changing one line of code I could choose to display the low quality or high quality model.
About 1200 quads on screen, it's totally possible even at 30 fps. But for a FPS, that means many many pixels that keep getting rewritten over since the walls - if you don't have proper occlusion culling - can take the whole screen.
About Burning Rangers, there is a SCU DSP program in memory, so are you sure it's not used?
I don't know if Wipeout and Tomb Raider do the quad subdivision in realtime, but one way to see is to check the texture memory address : if 1 quad turns to 4, look at the top left quad. If the address is the same as the lone quad texture address, with different width/height, then you know it's probably done in realtime.
But they could also store it in memory since the low quality map should take maybe as little as 1/4 the size of the high quality map.
About SBL and SGL, both are really interconnected. For graphics, it's SGL, for almost everything else it's SBL or SBL wrappers.

Perfect thanks, now I understand.

It is true, in a FPS the probability of covering other objects and many of them is greater ... I think now about how the Slave engine does it. It's really complex, using Clipping user and system every "X" elements ... it's almost the only game I've seen that does that. Even with the sky drawn he does it in case of the Quake.

It is true that there is a program. But SSF does not detect the use of the SCU ... and seeing the registers ON, they are only 3% ... I really have doubts in this case.

I will investigate more deeply Wipeout, Tomb Raider, Nascar 98 and Courier Crisis, which are the games that until now I am sure do this.

With respect to SBL and SGL ... I understand, but they seem very separate "projects" ... And the logic should be that these should be closer still ... I do not know.

Thanks again for the quick replies!
« Last Edit: February 13, 2018, 09:11:36 pm by corvusd »
David Gámiz Jiménez

Joeveno

  • Newbie
  • *
  • Posts: 9
  • Karma: +0/-0
    • View Profile
Re: Sonic Z-Treme
« Reply #142 on: February 15, 2018, 10:24:18 pm »
Hello! I'm a huge fan of this project! It's bringing the Blue Hedgehog fully fleshed out to the Saturn! congratulations!
I was just wondering something, it is possible to convert some of the Sonic Robo Blast 2 maps to Z-Treme? or it would be too heavy for the Saturn? and about the loops, they're gonna be in the game?
Would be nice to see those maps in this amazing project! cheers!

XL2

  • Sr. Member
  • ****
  • Posts: 341
  • Karma: +72/-1
    • View Profile
Re: Sonic Z-Treme
« Reply #143 on: February 15, 2018, 10:48:57 pm »
Thanks!
For porting the maps, it could be done using something like Noesis, but lot of work would need to be put to make them suitable for the Saturn.
The Doom engine has large open space, which isn't too great on the Saturn.
That being said,  I don't intend to do it.
For the loop, it will come back at a later time, once I fully settle on the collision functions, as I'm still experimenting.

XL2

  • Sr. Member
  • ****
  • Posts: 341
  • Karma: +72/-1
    • View Profile
Re: Sonic Z-Treme
« Reply #144 on: February 16, 2018, 10:44:56 pm »
It's not perfect, but still not terrible either :
https://youtu.be/lLiq5V_nlsg

 
I might just push the LOD draw distance to hide it better or play more with the mipmapping or even hide it with gouraud shading, but it now generates textures to fit the merged quads.
One huge issue is that the quads can have different width/height, so the generated textures doesn't fit perfectly.
It's even more obvious on Quake maps, but anyway I think it can be improved.

corvusd

  • Jr. Member
  • **
  • Posts: 81
  • Karma: +8/-0
    • View Profile
    • Personal Web Portfolio
Re: Sonic Z-Treme
« Reply #145 on: February 17, 2018, 12:58:11 am »
It's not perfect, but still not terrible either :
https://youtu.be/lLiq5V_nlsg
 
I might just push the LOD draw distance to hide it better or play more with the mipmapping or even hide it with gouraud shading, but it now generates textures to fit the merged quads.
One huge issue is that the quads can have different width/height, so the generated textures doesn't fit perfectly.
It's even more obvious on Quake maps, but anyway I think it can be improved.

Another awesome step! Are mip mapped manually the textures?? How many levels? Max/min resolution?

The fit problem is normal, in auto convert geometry. Whit a manually clean and adjust this problem fix it almost all cases.

A very little doubt? Is possible adjust to the max peak(1000/1200) of the showed quad geometry, to show the max or near to the max, for all most time to increase farclip??

And last. It possible adjust the levels of shades to farclip. To have more equal color fade to far. To soft the poping??

Amazing work!!

The Doom engine has large open space, which isn't too great on the Saturn.

I understand well the sentence? The open space in Doom not capable for SS?? I mean, Exhumed or Duke3D had have open space and SS had been capable to move whiteout problem. ;) I hope in the future, We give a definitive port of Doom to SS. :)
« Last Edit: February 17, 2018, 01:01:25 am by corvusd »
David Gámiz Jiménez

XL2

  • Sr. Member
  • ****
  • Posts: 341
  • Karma: +72/-1
    • View Profile
Re: Sonic Z-Treme
« Reply #146 on: February 17, 2018, 03:29:29 am »
Everything is automated, which is why the textures don't look all that great, but my pushing them further I might be able to hide it. About the open space, my engine doesn't support proper occlusion culling (pvs or portals), so I need to limit the draw distance.

corvusd

  • Jr. Member
  • **
  • Posts: 81
  • Karma: +8/-0
    • View Profile
    • Personal Web Portfolio
Re: Sonic Z-Treme
« Reply #147 on: February 17, 2018, 07:18:20 pm »
Everything is automated, which is why the textures don't look all that great, but my pushing them further I might be able to hide it. About the open space, my engine doesn't support proper occlusion culling (pvs or portals), so I need to limit the draw distance.
When you said  "Everything is automated"... is in realtime or automated in a script when you create the scenary??
I answer myself: Script map tool make it the automated features. XD

Anyway. A great job again.

I've been reviewing forum threads. And I've seen that you were investigating the clipping user of slave engine. Finally you concluded that it helped to improve the bottleneck of the VDP1 itself. But not the DSP calculation of the SH2 or SCU.

Combine both techniques to optimize both side of the VDP1 blitter and side of the 3D transformations for loading the processors (SH2 or SCU). It would be the ideal scenario to take advantage of the SS, right?

Maybe you're doing it already.

Finally, I think I understand you right now perfectly regarding the issue of open areas. With a pvs or portals algorithm. You can discriminate rooms by size or distance and so you can stop processing or drawing before said geometries. Or even apply a more aggressive LOD more selectively, no?

On the other hand. I have been looking at the use of SCU in Burning Rangers and other games. I said that I used 3% of registers and I was wrong. Out of a maximum of 23 registers, use 3. Which are actually 13% and 70% code. Against Sonic R 53% registers and 80% code. Or cases such as Wipeout 1 (Registries 60% Code 33%) or Assault Rigs (39% Registries 60% Code) where they also use the DMA. Something must be doing this code in BR. Is it possible to help decompress the Audio ADX??

Which brings me to another question. What I see also you have been researching in the forums. Using PCM for sound takes up a lot of memory. SDK SS there are libraries to compress/decompress ADPCM, which in essence is very similar to ADX. You will save a lot of space and decompress whit the M68000 sound proccesor.

Which leads me to another question that surrounds me these days and I do not understand. The SS sound chip is a beast. That has programmable DSP. It is possible to do things with him. Because I have not seen any game with reverb. Something that is seen in many PSX games. And it is supposed SS could do. I know that for this I had to buy another sound development SDK. And that's the reason for not seeing more things like that in games.

It is also a question to Johannes. Is it possible to implement this effect in the Jo-Engine library? Reverb and / or echo effect for sound or sound channels.

Greetings! :)
« Last Edit: February 19, 2018, 12:37:11 am by corvusd »
David Gámiz Jiménez

mindslight

  • Administrator
  • Full Member
  • *****
  • Posts: 157
  • Karma: +6/-1
    • View Profile
    • Jo Engine
Re: Sonic Z-Treme
« Reply #148 on: February 18, 2018, 09:28:36 am »
It's possible, but first I need to fix Linux compilation with custom GCC and continue the 3D implementation  :)

corvusd

  • Jr. Member
  • **
  • Posts: 81
  • Karma: +8/-0
    • View Profile
    • Personal Web Portfolio
Re: Sonic Z-Treme
« Reply #149 on: February 18, 2018, 12:35:39 pm »
It's possible, but first I need to fix Linux compilation with custom GCC and continue the 3D implementation  :)
Only with read this: "fix Linux compilation with custom GCC" you are GOD!

And is normal. 3D implementation is priority feature.

But read that is possible, for me is dream! Reverb in SS! :)
« Last Edit: February 18, 2018, 03:13:09 pm by corvusd »
David Gámiz Jiménez

 

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