Attention : I couldn't test the game on a PAL console, so it might not work correctly! Be aware of that!
For PAL users (Europe and other areas), burn the PAL version. For all the others, burn the NTSC version (North America, Japan, etc.). For emulators, choose the NTSC version.
Sonic Z-Treme is a new game for the Sega Saturn inspired by the ill-fated Sonic X-Treme.
While Sonic X-Treme relied on sprites and the fisheye view camera and worked correctly only on pc, this game relies heavily on 3D, including the player's model and enemy models, while also aiming for a stable 30 FPS on the Sega Saturn.
This game also includes a splitscreen multiplayer mode where you can either play the full game versus or coop!
Keep in mind that little time was put on the gameplay/controls/physics since most of the time was put on the engine itself and all the different tools I needed (SDK...) to create the game and making it work on Saturn. As such, the SAGE 2018 demo is more a tech demo than a full game, but as the engine becomes more mature I will focus more on the gameplay and levels. Also, the game is supposed to be played as a sidescroller (d-pad friendly), unlike a game like Super Mario 64. The whole control system is designed to keep momentum, so it's normal you can't turn 90 degrees right away when you're running at full speed and you're not supposed to rotate the camera all the time to keep it behind you!
Q : Is the game using the Sonic X-Treme prototypes' code?
A : No, it's all original code. The engine - that I just named the Z-Treme engine - is using the Sega Graphic Libraries (kind of OpenGL for the Saturn) and the Sega Basic Libraries (for accessing the hardware for things like audio, cd access, etc.) , while the rest of the engine (rendering, collision detection, loading functions, 3d animations, controls, etc.) is coded from scratch. Same thing for all the tools needed (converting models, map partition, image conversion, auto-LOD generation, texture generation, 3d animation generation, etc.). It is still a work in progress engine.
A few words on the engine. The levels were shared by Andew75 (best known for Project AXSX). I wrote a converter to take Wavefront .OBJ files, convert them to my custom binary file format, generate the distant low-quality models automaticaly (which is also the collision model), generate mipmaps for textures and generate the merged quads' textures, generate flat lightning (using 2 different techniques...more on that later), the collision, the octree (for rendering and collision on the Saturn) and places the entities based on the texture's name. All this allows importing levels to the engine very quickly, as long as the geometry is Saturn-friendly (small quads as much as possible with as few triangles as possible).
I also had to create a custom converter for the 3d entity models (Sonic, badniks, etc.) as the .OBJ files don't support animation and other files formats (DAE comes to mind) are quite complicated to work with. The model converter takes the Blender solution for .OBJ animation (a serie of files with different vertices positions) and then does the following : reads the files (obviously), compresses the keyframes (from 12 bytes per vertex to 6 bytes and from 12 bytes per normal to 1 byte) and outputs a binary file format. On the Saturn side of things, to keep the ram usage low, the animations are played with linear interpolation. The Sonic's idle animation, as an example, only has 2 keyframes, but with interpolation it looks smooth enough. Different interpolation factors can be selected, allowing different playback speeds and allowing good scaling with the framerate - all that without using any divisions to keep the game fast. All this allows ultra-smooth animations per-vertex at low-RAM usage. The only thing preventing the animations from being better are my own limited skills!
Another crazy thing I had to do is to import audio. Sounds easy, right? Well the Saturn audio tools were released around 1994-1997 for Mac computers. Mac computers back then used a very different cpu architecture, a Motorola 68k cpu and then a Power PC cpu, while the modern computers use the usual x86 cpu. So the only way (that I know of at least) to use the sound ram to store audio without the proper hardware was to use an emulator for the Mac OS 7.5, run the Saturn sound tools within the emulator and create my sound maps and tone data there.
That saves me quite a bit of ram as I would have otherwise used the main ram to transfer pcm audio (way easier). Some features also don't seem to work in the Mac emulator without the proper hardware (sound box), so I couldn't convert midi audio, but it might still be possible.
Many more things had to be done to make it work on Saturn.
Q : Where is the fisheye lens? Why is there no fisheye? Just give us the fisheye!!!!
A : Won't happen. It's super CPU-intensive, plus SGL controls the matrix transformations, so adding that on top of SGL's own calculations would just make everything terribly slow. You can rotate the camera around and the field of view is large, so it shouldn't affect the gameplay. You can also try the pseudo fisheye in the options. If you truly want fisheye view, try the leaked Sonic X-Treme v.40 demo and tell me seriously that's what you want!
Q : Why Sonic X-Treme? Why not ... insert another game ... instead?
A : Because the assets exist and the axis-aligned nature of the game make it simple enough for a single person. That auto-generated LOD model needs polygons on the same plane to work well, so maps like Sonic X-Treme or even Quake are perfect for it, while maps such as these in Nights or Mario 64 wouldn't work well. Manually modeling different quality models would just be impossible for a single person, so it has to be automated. Sonic X-Treme is just perfect for that.
Q : Ok, but can you make the maps more like Sonic Jam / Project Condor?
A : I'm working on better collisions and physics and to add VDP2 tile planes (I used to have them, but they were hardcoded), but that will take a while since I need to write new tools for better VDP2 support (right now it's limited to bitmaps layers only).
Q : Is this game the same as Project AXSX?
A : No, both are separate projects with different "teams" and aiming different platforms. The only comon things they have are the maps, which were shared to me by Andrew75, who faithfully recreated these maps from scratch. Some modifications were done to better fit the engine.
Q : How does the metal effect on the metal Sonic works?
A : It uses a hardware bug. According to all the Saturn official documentation, the Saturn doesn't support gouraud shading on paletted sprites (the textured polygons on the Saturn) or paletted polygons. The gouraud shading works by modifying the pixel's color directly, so with RGB sprites, if you increase red by 1, it will just increase that pixel's red value by one. On paletted sprites, the data sent to the framebuffer is actualy the index of the color in the color RAM. But the hardware still processes the gouraud and send the data to the framebuffer. So by using red (bit 0), you increase the index by 1, which means that if you carefully map your color palette, you can create pseudo-bump mapping effects or metallic effects. So the metallic Sonic uses that red gouraud shading trick. The 2 drill/badniks use the same trick, but without realtime lightning.
But that's not all. By increasing the green gouraud value (bit 5), you increase your color bank index by 32. So you can actually even put different banks entirely and easily swap between them. This is what I use when the metal Sonic is invincible, in addition to the red gouraud trick. The green gouraud trick doesn't work in any emulator as far as I know.
Q : What's the point of the multiplayer mode?
A : You decide. Coop, racing, deathmatch, it's all up to you. The entities reset only when player 1 dies and if player 1 loses all its lives it's game over. Player 2 can also "steal" these lives. I suggest vs gameplay.
Q : How does the transparency works?
A : The polygons close to the screen use RGB code (16 colors look-up tables), while the further away polygons use 256 color banks (VDP2 palette). The VDP2 has no problem with transparency, so all I need to do is send the color calculation ratio based on distance to create a smooth fade-in/fade-out. And since the VDP2 takes care of it and the VDP2 is really overpowered compared to the VDP1, it comes at no cost at all. Take that PS1! The metal Sonic also uses some VDP2 transparency (a low ratio) + gouraud shading for a pseudo-environment mapping (the color will change with the background). The player's shadow is using a VDP1 function, sprite shadow, which works fine since the shadow itself is just a scaled sprite.
Q : How many people worked on this game?
A : That's mainly a solo work.
But I do want to give credit to the following persons : Andrew75 for sharing the Project AXSX maps, Dany for the development environment and coding tips, Jollyrodger for his tips and for answering my numerous questions, Johannes Fetz (the maker of Jo Engine) for bringing me in Saturn development (the project started on Jo Engine after watching a video of his work!) and for his cue maker! Oh, and thanks to whoever from Assemblergames who did that cool cover art for the leaked Sonic X-Treme prototype, I couldn't find you but thanks! Also, of course, huge thanks to SEGA (who, of course, are in no way affiliated with this project) and the Sega Technical Institute team who worked so hard on the original game!
(continued at tab 2)
Maxime, AKA XL2.
View attachment 1372
Sonic Fan Games HQ is the largest resource for Sonic the Hedgehog fan gaming on the web and home to SAGE, the annual Sonic Amatuer Games Expo! We specialize in engines, sprites, music, gameplay, levels, gimmicks, the whole eight yards! Got a project you want to show off? Need some help with your game? Or maybe you just want to connect with creators and fans alike! No matter why you're here, hit that register button below to join the fun and start creating today!
We just updated our SFGHQ Rules & Guidelines. Give them a read, it might just save your life!
Our pals from the SHC are going to be running the Sonic Hacking Contest a little later this year, a bit after SAGE! You should totally check it out by clicking here!
Sonic Z-Treme (Saturn) - SAGE 2018 demo
- Average User Rating:
Q : Why do the textures change when I get close to them? Why does the lightning change as well?
A : It's the LOD system and mipmaping system (see wireframe mode). In order to display more polygons, there is a LOD model (see the earlier answer) which creates uber-walls by merging as many quads as possible together and generate (offline) a new texture to fit. So some 16 polygons sometimes become just 1 - with the only limitation being the octree preventing even more immense quads. So it's fast to render, fast for the CPU, and it doesn't look that bad when the base texture is good (the Red sands map is a good example, while Crystal Frost is a bad one). The gouraud shading should hopefully make it look better in the future.
The lightning changes for the same reasons, since I'm currently using paletted flat lightning for the map, the LOD model has huge polygons, so the lightning can't be as smooth as the polygons closer to the screen. Again, gouraud shading should help to hide it. Increasing the draw distance and the transition distance would help too.
Q : The game doesn't display properly. Some polygons are invisible or not shaded correctly. Why?
A : Play on a real Saturn.
Q : Why are some textures in the wrong orientation?
A : The Saturn doesn't support texture coordinates since it's using distorted sprites for 3D instead of normal polygons with UV maps. So the texture's coordinates are implicit, with vertex 0 being the starting "coordinate". The way around this is to manually rotate all the polygons in the wrong orientation, which is a long and tedious work. Another workaround is just to flip the texture' file in photoshop or gimp. It takes forever, so I didn't finish it.
Q : The game slows down at time. Do I really need to turn off dynamic lightning?
A : No! The game is in dynamic framerate mode to prevent glitches and crashes, mainly in multiplayer mode. But you can put it in fixed framerate mode so that the Saturn A) Doesn't need to manualy clear the framebuffer with a sprite each frame (faster to render) and B) Enters pseudo-end draw mode when it sees it won't complete the drawing, usualy conveniently clipping polygons right in your face and hiding your view...but also the HUD which is currently just 2 sprites. DO NOT USE THAT MODE IN MULTIPLAYER! It will crash!
In game : Press Left+START for fixed mode.
Right+Start for dynamic mode (default)
Up+Start to skip the current level
Down+Start to switch between 60, 30 and 20 FPS targets (it's mainly for testing collision/physics, but 60 fps might work well in some emulators).
B+Start for the debug text.
In options : L+R and press UP to cycle between wireframe, sprite and normal modes.
Q : Why are all enemies static? Why aren't the platforms moving?
A : I haven't had time to implement dynamic entities yet, and I will need to think of a way to update them without slowing the game and work on dynamic memory management to insert/extract them from the nodes.
Q : How is the collision system working?
A : The LOD model is the collision model (check the wireframe mode), so you have per-quad collision detection. The engine first detects if you cross that quad's normal. If you do, it checks to see if at your previous position you were in front. If yes, it checks with a bounding box and reprojects Sonic according to the normal. If there is a collision, the normal will determine the reprojected position and the speed vector's values. In some areas, the "triangles" will have an average middle point different from the polygon you see, so it might block you a little. Just jump a bit higher to pass.
Q : I can see polygons that should be behind another polygon. Why is it this way?
A : The Saturn doesn't have a z-buffer (neither did the PS1). So SGL uses a technique called Z-sort, where it just looks at the z-position, put it in a buffer and send the commands to the VDP1 in this sorted order. Now, especially with the huge uber-walls, the quad is sometimes so big that it's z-distance (average or max, both will have the same problem) is further away than a smaller polygon behind, creating wrong sorting. The solution is to use a BSP tree, but since SGL forces you to use z-sort, I haven't found a workaround yet.
Q : Is it possible to increase the polygon count and the draw distance?
A : Yes. Right now, I still don't have a hidden surface determination, so all the polygons in the view frustum and not facing away just get displayed. While it sounds terrible on paper, thanks to the LOD model and mipmapping, it's still fast enough. It could be improved by a) not displaying the hidden polygons (easier said than done) and b) using more untextured polygons (with gouraud shading it can look better than textured polygons in fact). Right now, depending on many factors, in single player the game can reach up to something like 700-800 polygons at 30 fps, while multiplayer can reach around 1000 polygons at 30 fps in some areas. Why is the polycount higher in multiplayer? Because the players' model get displayed up to 4 times (2 player models on each screen) and these models are mainly untextured. That's around 400 displayed polygons, which are super cheap to render.
Q : Is the code optimized? Are you using the SCU DSP and the sound CPU/DSP?
A : No, no, and not really. The code is still a mess as I didn't have time to clean it and optimize it. I don't know assembly language, so I haven't coded anything for the SCU DSP, but realtime lightning on the whole level might be possible with it (I've got an idea to make it cheap enough). As for the sound CPU/DSP, it's only used right now for tone (sound effects), which really isn't pushing it. It might be possible to do something with it other than sound related stuff.
Q : When did the project start?
A : It started - or at least I started coding for the Saturn - around march 2017 after I saw a video of a demo of a 2D Sonic game running on Saturn, by Johannes Fetz, maker of Jo Engine. I started fooling with Jo Engine and adding 3D stuff, until the idea to make Sonic Z-Treme took roots. I've since moved on to fully create my own engine by coding all my own functions to better fit my needs since Jo Engine is mostly a 2d engine while my game is only 3d. The idea to remake Sonic X-Treme just happened by itself since I used a very basic bounding box collision system and needed "blocky" levels. It as then evolved after Andrew75 shared with me some of his maps from Project AXSX. This is my first game and I use it to learn coding on my own (I had some VB experience in high school, but that wasn't very helpful).
Q : What are advantages in coding for the Saturn in 2018? Disadvantages?
A : In my opinion : For the advantages, I'm using a more modern SH2 compiler (still quite old) than what was available in 1996, which allows code in C to be more optimized when compiled, so I don't need to write huge portions of the code in assembly to keep good performance. Having emulators also allows debugging much faster. Compiling times are also obviously faster, and converting the maps takes seconds instead of minutes/hours.
As for the disadvantages, well the Saturn is long dead so there is only a few active people who know the console, so finding answers is nearly impossible outside of reading the (very) old technical documentation and trying to figure it all out. SGL's documentation is really poor, which makes it really hard and tedious to find some settings or finding how the functions work. Also, all of the official SDK tools are just useless now. As an example, there were some plugins for SoftImage to export your 3d models/animations, but obviously it won't work on newer version, so I had to code my own tools from scratch, which takes a very long time obviously.
Q : The "skull switch" is trying to kill me, why?
A : It's a skull. Skulls are bad.
Q : Will the load times be improved?
A : Yes.
Q : Why was version 0.034 running at 60 fps, but this one is running at 30?
A : I more than doubled the draw distance, added tons of rings and ennemies, added fade in/out effect, gouraud shading, realtime light, more solid collision system, etc, so the framerate took a hit. With more optmized code and hidden surface removal I might get close to 60 again. On PAL consoles it can hit 50 fps quite often.
Known bugs :
-The sound effects sometimes aren't playing correctly.
->Possibly a DMA issue. Could also be because of the way I converted the audio files (with an old mac emulator), the sound's end code seems to be wrong, so I need to manualy clear the sound channels, which seems to cause conflicts sometimes.
-The loops can be glitchy and when the framerate drops you sometimes clip right throught the floor/ceiling
->I will need to play with these settings as it's really hard to do collision detection at low framerate since you need to cover more distance, and with Sonic being so fast and having so many physics requirements making your change directions, it can break the collision detection routine.
-In Jade Gully, some weird polygons appear on screen sometimes during multiplayer.
->Possibly a DMA issue. I'm not sure what causes that.
-The physics/controls seem a bit off.
->I spent very very very little time on the gameplay. I will spend more time on these once the engine is more mature (ie less overdraw).
-Some polygons are clipping when they should be displayed.
->Z-sort issues and/or view frustum issues. I need to improve my view frustum culling code (which is just bad to be very honest). As for the z-sort issues, it might be possible to resolve them using a BSP tree and better hidden surface determination, but it might take a while to fix it.
-The game crashes when I'm using the fixed framerate mode while in multiplayer.
->Use the dynamic framerate mode.
-Some objects (rings) disappear right in front of me.
->I need to improve my view frustum and entity insertion code in the octree's nodes.
So, what's next?
I need to address the hidden surfaces problem. I would also like to subdivide the map when the polygons are close to the camera to reduce warping, which unlike the PS1 SDK isn't supported by Sega's library (I'm trying to play with the textures' address in vram to avoid storing new textures). I also want to improve the draw distance and add gouraud shading and maybe dynamic lights. If all works, the game should run at a stable 30 fps or maybe even 60.
Sonic Z-Treme for the Sega Saturn game system, coming to stores near you, Christmas 1996! Or 2018...
Mario has a big problem!
EDIT : 2018-08-20. Updated to version 0.081, which adds particles effects and some small optimizations.
EDIT : 2018-08-21. Small collision improvements - Sonic gets pushed back one extra unit when hitting a wall to avoid being blocked by another wall.
EDIT : 2018-08-22. Added a wireframe mode for debugging and to show how the LOD/collision/transparency systems work and to check the overdraw in prevision for future updates. In options, hold L+R, then press UP to cycle between wireframe, sprite and normal modes. Sprite is just to showcase what the Saturn is really rendering (but instead of 2 points sprites, for 3d it renders 4 points sprites and distort them). The polygon mode is to turn all textured polygons into untextured polygons, again just to test the framerate. If it slows down, that means the CPU is probably the bottleneck. The transparency mode turns all the quads into half-transparent quads just to showcase the corruption that happens and why no devs used it on Saturn and used the mesh effect (faster and still looks about the same because of the corruption). Try the transparent mode at your own risk as it will break the game on real hardware!
As you can see with the wireframe mode, there is quite a bit of overdraw, which is why I didn't add gouraud shading on the whole map (in options, press L+R+Start to turn on gouraud shading, but it was just a quick test so it won't look great, it's mainly for testing the impact).
I hope to solve the overdraw issue soon to increase the polygon count and add gouraud shading on the whole map or parts of it (palette lightning is also fine on some quads).
Game, SDK and coding by XL2. Maps imported from Project AXSX, shared by Andrew75. Textures, Sonic 3D model, music and other assets from Sega and the now defunct Sega Technical Institute. Thanks also to those who playtested the game on real hardware. The badniks are based on the sprites from Sonic X-Treme, but I recreated them myself.
- File size:
- 157 MB
Share this Item
Recent User Reviews
"Well Done Can't Wait For More"
Though the game is short (obviously) I can see that this has so much potential. I've played through the game about 5 times now just exploring and getting use to the physics. A full game would be insane. Found sonic to be a little stiff but for whatever reason also fluid and enjoyed playing with the game and the physics. Great job make more ;D