(Homebrew) Sonic Z-Treme

Discussion in 'Sega Saturn Programming and Development' started by XL2, Jul 20, 2017.

  1. XL2

    XL2 Rising Member

    Joined:
    Jul 20, 2017
    Messages:
    52
    Likes Received:
    112
    Good day!

    I've been creating a game for the Sega Saturn since the end of march of this year. I simply named my project Sonic Z-Treme, which is a game that takes inspiration from Sonic X-Treme, but doesn't attempt to be a 1:1 conversion.
    The game is coded using C language, Jo Engine SDK and SGL.
    I've been coding pretty much the whole engine from scratch, such as the collision detection engine, the BSP, the physics, collision BB precomputing, etc.
    It runs at 60 FPS on stock Saturn and right now I'm only using 1 CPU and, according to Yabause, only the HWRAM (1 MB out of 2).

    I'm not 100% sure I'll complete this project since I have several problems ahead and the Saturn homebrew scene being so small, it's really hard to find answers.
    The other huge problem is that Jo Engine is incomplete and will ditch SGL and I have no idea what the new 3D implementation will be, so I don't feel like creating conversion tools that might not even work in future versions. So I'm pretty much left with 3 options at the moment : wait, go full-SGL or go Jo-Engine for the moment but risk wasting my time.

    EDIT : Latest version with the new 3d implementation, auto-collision generation, auto-map subdivision, import of .OBJ Wavefront files for the map including textures, 3d ennemies, few more gimmicks, etc. Running in SSF emulator :


    You can see the game here (older version), running on stock Saturn :
     
    Last edited: Sep 21, 2017
  2. ActSean

    ActSean Member

    Joined:
    Feb 18, 2014
    Messages:
    22
    Likes Received:
    21
    Wow! Great job, XL2! This very impressive! Any chance you will be sharing the source so others can help with development?
     
    DSwizzy145 and XL2 like this.
  3. XL2

    XL2 Rising Member

    Joined:
    Jul 20, 2017
    Messages:
    52
    Likes Received:
    112
    Thanks. Right now my code is a total mess as I'm in the middle of a transition, so I would need to do a massive clean up first. That being said, I don't mind sharing my code at all, but I wouldn't do it all large at the moment and would keep it more private.
     
  4. Greg2600

    Greg2600 Fiery Member

    Joined:
    Jun 23, 2010
    Messages:
    895
    Likes Received:
    80
    Wow, very cool project to hear about.
     
    XL2 likes this.
  5. Yakumo

    Yakumo Pillar of the Community *****

    Joined:
    Mar 14, 2004
    Messages:
    20,402
    Likes Received:
    958
    Now this is very impressive! Full 60fps target is amazing and only using 1 CPU. I take my hat off to you, sir.
    I honestly do hope you can continue development with extra hands if needed as this is some impressive homebrew for the Saturn.
     
    DSwizzy145 and XL2 like this.
  6. OOQQ

    OOQQ Newly Registered

    Joined:
    Jul 22, 2017
    Messages:
    3
    Likes Received:
    1
    I still follow your progress here and Youtube. Dude I'm on the middle of learning C myself, if you wish add me to the dev team :D , I'll help on whatever I could.
     
    Last edited: Jul 22, 2017
    Anthony817 likes this.
  7. jollyroger

    jollyroger Peppy Member

    Joined:
    Oct 18, 2008
    Messages:
    397
    Likes Received:
    221
    Jo engine is a very reasonable 3D engine for Saturn, it is a perfect choice for a project like this.
     
  8. XL2

    XL2 Rising Member

    Joined:
    Jul 20, 2017
    Messages:
    52
    Likes Received:
    112
    Yes, Jo Engine is amazing, it makes everything so much easier. But as far as 3D is concerned, it's using SGL functions, so it's really just wrapping SGL functions with Jo Engine functions. So there isn't really a 3D "Jo Engine" yet, but I know Johannes is hardworking to get there. The problem I have is that the tools I'm creating are using SGL, so depending on future 3d implementation they might not work at all. But since Jo Engine is open source, I could also consider updating the functions I need with future versions and keep SGL as well, but that wouldn't be the most efficient way to go.
     
  9. Sp33dFr34k

    Sp33dFr34k Spirited Member

    Joined:
    Jul 13, 2015
    Messages:
    141
    Likes Received:
    31
    Wow, very impressive, great work! Love to follow your progress here :)
     
  10. XL2

    XL2 Rising Member

    Joined:
    Jul 20, 2017
    Messages:
    52
    Likes Received:
    112
    For ActSean and others: I did a quick FPS-style demo (with source code, done in a few hours only so don't expect Half-Life on the Saturn) with working collision detection (still buggy) and a tool to generate the bounding boxes and slopes (buggy as well, but works nicely for axis-aligned polygons). Not directly related to Sonic Z-Treme, but I will continue to update the tool I created for the bounding boxes and hopefully it will help someone with his project.

    There are currently several limitations and the tool isn't complete (I'm in the middle of adding features such as writing to binary), but I guess maybe that could be interresting for some of you here since I included the code. It works better for a game like Sonic X-Treme/Z-Treme or corridor shooters like Doom/Quake. It wouldn't work too well for a game like Mario 64 since it won't play nice with things like hills and rocks with multiple faces. It works better with axis-aligned quads (or slope on one axis). You could also just use a complex heigth mask for hills and rocks, but right now for memory constraints I use small arrays (more on that later).

    Hopefully it will help someone start his/her own 3D game project on the Saturn.

    Video of the short demo (I say again, I quickly coded it, so it's nothing impressive!) :



    For the tool, first I want to apologize, the code is full of commented code that I didn't fully remove since I might use some in the future, and it's not user friendly. It shouldn't be that hard to use, but it requires a few things.

    First, make sure you link it up with the SGL library (SGL.h) as I'm using that to read the polygons
    (EDIT : I removed the need to link to SGL.h, so one less step for you! But I didn't do much testing, so tell me if it causes issues!).
    Then include your level's .h file (just convert it with the Jo Engine map editor - without the textures for now)
    (EDIT : The tool now supports .OBJ files that you can load. It will output both collision data and a custom binary map format - ZTM as Z-Treme map - that can be read by the Saturn to allow changing maps). Call the display command (it won't display anything, I just use that to initialize the polygon list - it avoids having to modify the .h file and removes one step for you).
    The tool needs to be compiled. It outputs a collision file and a map file. The collision file's name is just TESTPOLY2BB.txt for now, with examples of the struct I use. The map binary file is using the extension .ZTM as it's a custom file format.

    Look at the FPS demo, in MESHES/LVL_BB.h, Collision.c and Display.c to see how it all works. I use Code::Blocks to compile, but it should work with anything. The tool is using C++.

    The tool works by reading the polygons, creating bounding boxes and then merging the boxes with neighbours to reduce the amount the Saturn needs to go throught. It also reads the normals to determine if it's a slope, then calculates the slope (still buggy, I will have to improve it). It also adds "depth" to the polygon to avoid going throught it if you go too fast.
    I will have to improve my slope generation code as it's hit and miss but I didn't put much time in it yet. It also doesn't generate heigth masks yet, but I've included examples in the FPS demo on how to use masks, so it shouldn't be too hard.

    For the FPS demo and code, just put it in your Jo Engine Src folder next to the demos, from there you should be able to open the code and modify it and compile it. And once more : it's quickly coded, so some things are probably wrong/stupid, if I update it I will share with you guys.

    Again, sorry for the not-so-user-friendly-hackjob of a code!

    EDIT (2017-08-14) : Many bugs fixed involving OBJ to binary. Also added view frustum culling, auto-crouch function (buggy), basic HUD (ugly, also since it's using JO Engine functions it causes issues with SGL VDP2 addresses, just uncomment in the Display.c to revert back to NBG2 and RBG0 layers).

    EDIT (2017-08-16) : Upgraded to Jo Engine 9.0 (make sure you upgrade also). I also fixed the memory allocation, so you should be able to load much bigger files now (try map 3 to see an example of this).

    EDIT (2017-08-25) : You can now write textures directly in the binary file. The map program will read TGA textures (uncompressed only) and write them. Also added auto-subdivision of the map for culling, you just need to specify how many "cuts" you want (there is a bug that will sometimes "lose" polygons, so just try different values for "cuts" (x, y, z axis) if one setting doesn't work well). I also changed the FPS demo's collision code to reduce CPU usage.
     

    Attached Files:

    Last edited: Aug 25, 2017
  11. ActSean

    ActSean Member

    Joined:
    Feb 18, 2014
    Messages:
    22
    Likes Received:
    21
    Thanks XL2! Can't wait to play around with this!
     
  12. XL2

    XL2 Rising Member

    Joined:
    Jul 20, 2017
    Messages:
    52
    Likes Received:
    112
    Made some more modifications to show how to use the VDP2 plane (+ transparancy), NBG2, color offset, and I put a sprite instead of the 3D model (much better, honestly! But a VDP2 layer would be better).

    File in previous post
     
    Last edited: Jul 31, 2017
    DSwizzy145, OOQQ, ActSean and 2 others like this.
  13. XL2

    XL2 Rising Member

    Joined:
    Jul 20, 2017
    Messages:
    52
    Likes Received:
    112
    I did a small update to the tool by removing the need to link SGL.h with your project, so that should be one less step for you. Make sure you tell me if you encounter problems because of this! I still need to clean the code (it's a real mess right now), so again, sorry about that! Include your model's header file, put the display command in the main function, compile and just use the POLY2BB.txt file (see the FPS demo for how to use it). I haven't fixed the issues with slopes yet.
     
  14. irvgotti452

    irvgotti452 Rising Member

    Joined:
    Jan 30, 2014
    Messages:
    60
    Likes Received:
    18
    Man this is exciting to see. Hopefully you get far with this project. I actually like that 3D sonic VS 2D enemies, even if it is mean as a placeholder. Looks great!
     
  15. XL2

    XL2 Rising Member

    Joined:
    Jul 20, 2017
    Messages:
    52
    Likes Received:
    112
    I just posted a new update. I didn't improve the collision generation code, but the tool now reads .OBJ 3d model files and outputs both the collision data and a binary file format (.ZTM) to be used to load the map from the disk. The FPS demo contains the loading function in Display.c, you can switch maps ingame by pressing L/R + Start.
    The second map is 100% using the .OBJ loading, but I didn't do much testing so it might not always work so well and might contain bugs.
    I haven't tested it on real hardware, only emulators for now.
    If you find bugs that aren't noted in the code, make sure to tell me!
    Thanks!
     
    Last edited: Aug 15, 2017
  16. XL2

    XL2 Rising Member

    Joined:
    Jul 20, 2017
    Messages:
    52
    Likes Received:
    112
    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.
    I also added frustum culling to reduce CPU usage.

    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 30 FPS option 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.
     
  17. XL2

    XL2 Rising Member

    Joined:
    Jul 20, 2017
    Messages:
    52
    Likes Received:
    112
    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 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.
     
    Zeigren, Piratero and takeshi385 like this.
  18. XL2

    XL2 Rising Member

    Joined:
    Jul 20, 2017
    Messages:
    52
    Likes Received:
    112
    I made a small update in Sonic Z-Treme using some things I made for the FPS demo, but I haven't implemented everything I need yet so it plays from 30 fps to 60 fps on real hardware. Video here :
     
    takeshi385 and Anthony817 like this.
  19. XL2

    XL2 Rising Member

    Joined:
    Jul 20, 2017
    Messages:
    52
    Likes Received:
    112
    Hi all!
    I'd like your input on the 3d implementation.
    I will soon integrate a grid hashing or octree both for collision and 3d data.
    I want to modify my map tool to also precompute visibility from any nodes (nothing too fancy : from position x:3,y:2,z:4, you can potentially see mesh no. 3, 5, 8, 9, 10, then I will just add culling on realtime).
    My problem is that by splitting the mesh, the number of vertices keeps increasing (like, take a cube, divide it in 6 faces, you end up with 24 points instead of 8).
    The Saturn processes the vertices first, no matter what polygons you send it to draw, so I can't just have a huge vertices list and just tell the system which quad to draw.

    More vertices = high cpu usage, but obviously it's wasting ressources that could be used for something else, like depth gouraud shading or maybe even realtime lighting and gouraud shading.

    One solution I'm considering involves DMA the polygons and vertices in a temporary mesh, but I'm not sure if it's possible or fast enough. Storing different meshes for all the potential viewpoints isn't practical as I would run out of ram quickly on bigger maps, unless I can find a way to compress everything.

    What would you suggest? Has anyone even bothered to solve this issue in the past? My game runs fine at 30 fps, but since I'm aiming for 60 fps I need to do a lot more work. Thanks!
     
    takeshi385 likes this.
  20. Anthaemia.

    Anthaemia. The Original VF3 Fangirlâ„¢

    Joined:
    Jun 4, 2004
    Messages:
    1,626
    Likes Received:
    156
    Have you thought about reaching out to the makers of Project AXSX for a collaboration? Your engine looks impressive (especially when you consider how little it's taken to reach such an advanced stage), and I feel you might be able to help them out. On the other hand, they've got access to original development materials - since your work has so much overhead in terms of frame rate compared with the official code, maybe it would be possible to implement the fish eye lens effect without this causing the same pacing issues Sega Technical Institute and Point Of View had to endure? Also, the main programmers behind AXSX will probably know how to add the animated elements such as Sonic's proper sprite and the flowing water. I'd definitely love to see the best version of Sonic Xtreme that can be produced by fans, similar to the ongoing "restoration" of the Resident Evil 2 prototype by Team IGAS, which has since enlisted the Squeeze Bomb technology of Gemini from Loboto 3...
     

Share This Page