Messages

226

Project announcement / Re: Sonic Z-Treme

« 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.

227

Project announcement / Re: Sonic Z-Treme

« 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.

228

Project announcement / Re: Sonic Z-Treme

« 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.

229

Project announcement / Re: Sonic Z-Treme

« 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.

230

Project announcement / Re: Sonic Z-Treme

« 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).

231

Project announcement / Re: Sonic Z-Treme

« 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

232

Project announcement / Re: Sonic Z-Treme

« 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!

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.

233

Project announcement / Re: Sonic Z-Treme

« 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

234

Project announcement / Re: Sonic Z-Treme

« 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.

235

General Jo Engine Help / Re: TGA not found

« on: February 08, 2018, 02:49:07 pm »

Make sure you have no RLE compression and that your TGA files are in the "cd" folder. For binary, just use the Jo Engine editor.

236

Project announcement / Re: Sonic Z-Treme

« 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.

237

Project announcement / Re: Sonic Z-Treme

« 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.

238

Project announcement / Re: Sonic Z-Treme

« 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

239

Project announcement / Re: Sonic Z-Treme

« on: January 24, 2018, 07:34:38 am »

Right now I put Sonic Z-Treme on hold to focus on occlusion culling using the FPS demo for testing.
I got the auto-LOD model generation working (but I haven't implemented texture generation yet) which should help with better draw distance.
I also got the 4 bits per pixel textures working, saving me some VRAM that I'll use for LOD textures.
I added analog control (not even properly documented in the official documentation) in the FPS demo.
I implemented a KD tree... then tried a BSP tree... now I'm going for an octree...but feel like going back to a BSP tree...
I also wasted a couple of weeks trying to implement a mesh buffer to save RAM and reduce vertices transformation, but the memory access made it slower so I flushed it.
I still need to find a way to generate PVS and cram it in the little bit of RAM left... or go for the BSP tree and use a low-res depth buffer (should be slower, meaning 60 FPS would be impossible).

I'm working on a new collision detection code and PVS, and I need to find a way to use the audio RAM to free some work RAM.
Quake maps are loading, maybe I'll be able to show the new FPS demo within 2 months, but I'm confident that I'll hit 30 fps with gouraud shading.

Long story short, occlusion culling is really hard and there is no perfect solution.

As for the VDP2, it's used for the text (NBG0), the "ocean" (RBG0) and the background mountain (NBG2). I added extra clouds with NBG3, but removed them as I was running out of high work RAM.

240

Share your code / Re: 4 bits per pixel image converter app

« on: January 07, 2018, 04:49:35 am »

I did a small update : I fixed a bug with the sprite's orientation and also added auto-compression of the palette data if the image contains more than 16 colors (it's just removing the LSB until it fits, so the results aren't ideal compared to what you can get with something like Photoshop).