FPS-demo + source code

[XL2]

Yes, I've just updated the FPS demo with 2 maps and map loading.
Press L/R+START to load the other map.
I really didn't put much time in the FPS demo, the controls are "weird", the "pop-up" effect when you are under a tile isn't smooth at all, etc.
I might revisit it all at a later date to make it better.
For the clipping, just removing UseNearClip fixes it, but it doesn't do a good job hiding the polygons that aren't in your field of view.
There might be other ways to improve this other than UseNearClip, I know there is a WindowIn option, but I never used it.
The problem without UseNearClip is that the polygon count goes way too high for the Saturn, so it will create problems.
Another solution might be to push the camera back, but I'm not sure how well it will work with FPS game.
In Sonic Z-Treme, the camera is far, so all this isn't a problem, and polygon disappearing is good since they would otherwise hide the camera, but for first person games it's problematic.

Good news : the .Obj converter seems to work nicely (I used it to generate the second map). I didn't update the slopes code, so some of them don't even work, you would have to edit the BB file manualy to fix them.

 

[cafe-alpha]

Guys, you are awesome!!
You were both right.

Iya~ sore hodo demo 😀

Basically, if your (unsigned) short data are two bytes aligned, and (unsigned) long data are 4 bytes aligned, problem shouldn't happen. If you're accessing (unsigned) char then any alignment is OK.

 

[XL2]

I updated the tool and the demo.
There was a bug that made .OBJ files with multiple meshes not being converted properly.
Now there is still an issue with memory allocation as the memory "gaps" between the meshes are really huge, wasting a lot of ram. (EDIT 2017-08-16) Problem fixed, try map 3 for a bigger file.

I also added frustum culling.

I also tried the demo on real hardware, and had to reduce the draw distance as the hardware was struggling on map 2. The gouraud shading doesn't help, but also the collision code isn't optimized yet since I haven't implemented proper BSP (the collision tool does it, I just haven't decided how to implement it yet) and the animation code isn't as fast as it could be. I also suggest using low-quality map models for collision as it can reduce the amount of bounding boxes. Once I fix the memory issues, I plan to load a "high quality" map and a low quality one, and display one or the other depending on the distance from camera to improve framerate. Of course, it means less RAM available. The Jo Engine option for 30 FPS doesn't seem to work (or I'm doing something wrong) as it gives me the same results as 60 FPS, so I just left it at 60 for now.

 

[mrkotfw]

What was the polygon count for when the Saturn was struggling with?

 

[XL2]

What was the polygon count for when the Saturn was struggling with?

For the GPU : Around 250 quads, mostly 16x16 with depth gouraud shading, at 60 FPS.
For the CPU : Around 750 vertices, also 60 FPS.
CPU slow down is more problematic than GPU, but there is a lot of room to improve so I'm not worried.

In Sonic Z-Treme I can reach around 1100 vertices before it slows down, with 450 quads onscreen (but no gouraud and Sonic is mostly flat shaded), also mostly 16x16.
I never played with textures lower than 15 bits, so I don't know if it gives better results, but it is my understanding that it should not.

 

[XL2]

I made a big update, the map tool now reads TGA files and writes to the binary custom file for texture mapped levels.
I also added a function to auto-subdivide the map for view frustum culling.
I'm still using SGL culling function, which isn't great.
I also changed the collision code to reduce CPU usage (I didn't do much testing, so it's possible that it's buggy now).

I succesfully imported levels from Project AXSX, but performance isn't that great for now as you can see in the video.

I still have to fix bugs, do more testing and find a way to precompute visibility (suggestions are welcome!) in order to improve performance further.

 

[XL2]

I should be able to release a new version of both the FPS demo and the map converter within a few weeks. I almost fully rewrote the engine, which should allow much more flexibility (no more per-bounding box collision or 1-axis slopes only, which will allow all sorts of games).
Here is a little teaser (I generate a LOD for distant object, but I didn't code the fitting texture generation yet, which is why it's so glitchy. I also need to fully rewrite the view frustum culling as it's clipping heavily as you can see.)

Also take note : The map really wasn't designed for the Saturn, so the results aren't optimal, with way too many triangles. Of course, someone could just manualy fix it by removing all the triangles and rotate the vertices to get the proper texture orientation, but I don't plan to do it.

 

[XL2]

Another small update to show the fully working per-quad collision (I still need to work on it to make everything smoother).
Maps don't need to be "blocky" anymore like in Sonic X-Treme, which opens up lot of possibilities.
Here is Saturn Quake E1L1, converted with NOESIS to Wavefront .OBJ, then put on Blender to remove the doors (since my engine doesn't support them yet), and then converter with my newer map converter to my engine.
I'm still a few weeks from being able to release the code (I can only put like 1 hour max per day on this project, so it's slow).
NOTE : The textures on further away quads are weird and become normal closer to camera. That's because I coded automatic quad merging for LOD objects in order to reduce the number of quads on screen, but I didn't code yet the textures that should fit these large quads, which is why I'm not making the video public other than on forums.

 

[mrkotfw]

Absolutely amazing work.

I'll need to read up on the thread to catch up how you've been handling collision so far.

Since the Saturn doesn't allow you to specify UV points, did you have to do anything with the textures when clipping?

 

[XL2]

Absolutely amazing work.

I'll need to read up on the thread to catch up how you've been handling collision so far.

Since the Saturn doesn't allow you to specify UV points, did you have to do anything with the textures when clipping?

I was only using bounding boxes and used height masks for slopes. It was fine for Sonic X-Treme maps, but it wasn't flexible enough for other kind of games. I'm now using a mix of bounding boxes (for general testing) and then dot products using the normals and center points. It's quite accurate as you can see in the videos, but of course it could be improved to make it smoother.

For the textures, I now generate new textures to fit the merged geometry. They can't fit 100% right since the quads aren't exactly the same size, but I'm afraid there is no way around it other than hiding the transition better. For clipping, I'm currently just using the painter's algorithm, so there is a lot of overdraw (which is bad). I sadly couldn't solve this issue yet, but reading past acticles everybody also seemed to struggle with that back in the day.

Here is another video with the fixed textures (I still need to improve the colors as selection of the 16 colors to make it in the merged textures isn't optimal) :

 

[mrkotfw]

Which documents are you referring to?

 

[XL2]

Which documents are you referring to?

For occlusion ?
Pretty much every interview with devs back in the day mention it to be one of the main issue.

 

[mrkotfw]

For occlusion ?
Pretty much every interview with devs back in the day mention it to be one of the main issue.

Occlusion and clipping. Are there any sources you can link?

 

[XL2]

Occlusion and clipping. Are there any sources you can link?

I've read so many articles, I can't remember which one mentionned it.

 

[XL2]

Here is an update showing what it looks like on real hardware.
Mostly 30 fps, with some drops to 20 (there is no hidden surface determination, so there is a lot of overdraw which causes slowdowns).

 

[mrkotfw]

I can't wait until the source is released.

 

[XL2]

I can't wait until the source is released.

I should be able to release it within a few weeks.
The main issue now is that I'm pretty much using SGL and SBL only, but I'm still on Jo Engine for things like HWRAM memory allocation and sprite memory management - but I made many modifications to the way it works internally to allow more sprites/vertices and changing the resolution.
So someone taking my code and trying to compile on Jo Engine wouldn't work right now, nor would it work with SGL only.
I would have to clean everything up and release the code as a standalone version that you can compile regarless of Jo Engine, so it might take a while as I'm doing the transition slowly.

 

[XL2]

I'm still rewriting my own functions for everything, but I've since moved to tone audio instead of PCM streaming, wrote my own sprite loading and VDP2 managing functions, so I'm still not ready to share the code. As I replaced many functions, I just noticed that I wasn't using Jo Engine functions anymore except for sprite loading and CD audio - and in fact I was reinitializing most functions for different effects - so I didn't make sense to keep it. So I've since moved 100% to SBL/SGL only, using only the Jo Engine compiler/cue maker.

The following demo is from the older version of the engine (still using Jo Engine's sprite loading and CD audio functions) to show VDP2 transparency for a fade-in/out effect (like in Sonic R), plus multiplayer. The sky is just for a quick test, an actual background rotating with the camera would look beter. Managing the backgrounds in splitscreen is a bit of an headache since I've got one layer for text (NBG3), 1 layer for player 1 weapons, 1 layer for player 2 weapons, which leaves me with 1 normal background layer and one rotating background layer for the backgrounds, which both have different behaviors. I guess it's possible to use interupts and share 1 layer across 2 windows with offsets, but I'm not there yet.

Edit : I tested it on real hardware (@ 352x240) and I can confirm that with splitscreen I get a pretty stable 20-30 fps. I will try 352x224 instead to see if I can get closer to a stable 30 fps.

 

[XL2]

Same version running on real hardware this time .

 

[mrkotfw]

Was there more of a performance gain when removing calls to Jo?