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

Quake maps do work with OKish draw distance, but have a very high poly count and vertices count. Still, 30 fps with Sonic and some 920 drawn polygons on screen isn't too bad considering all the overdraw.I made some little progress on the bsp tree, but there are many problems to solve as nothing found online mentions quads or small polygons, so it might take a while to make it all work.

Quake maps do work with OKish draw distance, but have a very high poly count and vertices count. Still, 30 fps with Sonic and some 920 drawn polygons on screen isn't too bad considering all the overdraw.I made some little progress on the bsp tree, but there are many problems to solve as nothing found online mentions quads or small polygons, so it might take a while to make it all work.

Again great job XL2!

It is getting closer and closer to the nearly 1300 of Sonic-R at 30FPS. Definitely, you are putting more and more to the limit the possibilities of the DSP (transformation and lighting) of the two SH2, along with the management of calls to the VDP1 and VRAM of VDP1 and sound system. Not to mention physics, collisions or AI. That is to say all that traffic by BUS-B passing through the SCU. Amazing!

I am increasingly aware that this is one of the keys to the REAL optimization of the SS. In fact, in his reflection with PSX, this is also part of the key to his good performance. And having a Profile system made it really easy to expose all the bottlenecks in an engine or program.

Here is a shot of Jade Gully in OpenGL (PC, for testing) after the BSP subdivision.I just simulate the Saturn behaviour in OpenGL for faster testing.I'm using a solid leaf bsp tree from the MrGamemaker famous bsp tutorial.

You can see, just like Saturn Quake and Saturn Duke Nukem 3D, how it creates some issues with textures because of the lack of texture coordinates.The way around this is to declare some quads as entities instead of parts of the map to avoid diagonal subdivisions.Some maps just don't work with it, such as Super Mario 64's peach castle.

I still have no portals and pvs, so I don't know if the maps that currently work will still work after, but it should help reducing the overdraw and speed up collision detection a lot, maybe allowing proper collision detection against the map for ennemies too.

From what I see of the image that you have shared, and the theory of the tutorial. It is a technique very oriented to closed scenarios, with rooms and with the basic primitive of the triangle.

I understand that it may be difficult for you to implement the BSP tree for both SS, primitive and open levels by levels like this of the Sonic.

I can think of a few suggestions, to see what you think:1) Try to create, or force, the triangle to a quad of the SS. In order to facilitate a replacement with a predefined texture, it works better. And avoid the overdraw of using forced triangles in SS.

2) Search that the geometry designs are designed to create more square divisions. For example, the plant in X, which is 45º above the quad of the ground, are divisions that seek to follow this angle. If this plant were at 90 degrees, the divisions would be more square.

3) For the theme of textures that look bad. I see complicated that you can automate this. That is, automatically cut the textures, so that new textures are created small, more adjusted to the division. Of course all this results in using more space of VDP1 VRAM.

4) I do not know if it would be possible to use RockinB's UV flat mapping code, which I found from my tests quite quickly. On these triangular primitives, to avoid generating new textures, although you will still have the problem of redrawing by deformation.

5) Use the triangle with a mask as an alternative to forcing triangles. But I do not know how you can translate the coordinates of the vertices to this "triangle", so as not to load the transformations engine or the BSP motor itself.

6) Finally, I do not know if you would use the LOD by distance. Perhaps these zones divided into more "ugly" triangles are not seen with the closest LOD.

Great work and encourage!

I continue with my research and analysis work for my entries. On the other hand I hope to finish my 3D engine proposal soon and share it with everyone.

I already create quads, but sometimes it's impossible (like the area next to the flowers).My solution will be to flag these objects as entities instead to avoid subdividing the map.It should lead to very few subdivisions.I also have a scoring system where subdivisions are to be avoided when selecting splitting planes.About open maps, it's a huge concern and the portals might not even work.I don't care that much since I want to focus on my fps game instead, so maps such as Quake maps should work fine.But it's still a long way to go before I can test it on real hardware.

So I got the BSP tree, portal generation and PVS all working.Using a BSP is really a game changer, it's 10000% better than any previous solutions I used.The only cost is extra geometry after splitting and a requirement that the levels need to be "closed off".

I would be possibly to use an octree for rendering and a BSP for collision/line of sight/raytracing, but so far I really like the BSP tree and it's perfect for corridor shooters.

Here are screenshots (in OpenGL, but I try to micmic the way the Saturn renders everything, with no texture coordinates and per vertex lighting).

Thanks to the BSP tree, adding lighting took only 1 hour or so.It's just that great.Since I am now using a PVS, I won't need the smooth fade-in/out anymore as I won't have a draw distance limit, so I can use RGB 4 bpp and gouraud shading on everything with no issues...so colored lighting works perfectly.