(Saturn homebrew) Sonic Z-Treme

XL2

Established Member
Hi all!

I'm currently learning c language on my own and game developpment as an hobby.
I decided to start with the Sega Saturn (yes, I didn't start with the easiest machine!) and a 3D game (yes...).

I've been working part-time on my project, that I named Sonic Z-Treme, since the end of march. The game is a remake of Sonic X-Treme, but I'm not aiming for a 1:1 reproduction. And unlike Sega's game, it runs fine on the Saturn!

You can take a look at the game running on emulator here :


EDIT : I attached the demo from october 2017, it's not the latest version (which is half-working now since I'm rewriting a lot of code) and contains bugs, but if you feel like trying it, be my guest!
 

Attachments

  • SONIC Z_TREME 0.034 (Custom Music).zip
    14.2 MB · Views: 1,695
Last edited:
Thank you!
The Saturn homebrew scene is quite dead, so I guess this forum is one of the only places where people have technical knowledge about the console.
I'm now struggling trying to decide where to go next : I need some sorts of level loader to load other maps, which means I need to write the files in .bin format. Jo Engine doesn't support that yet and has no ETA, so the alternative is the official Sega 3D editor tool, which is really dated and hard to use.
Anyone got a suggestion for that?
And if I do use the official tool and export the files in SG3 (which I guess is a binary file), how do I even load it?
Thanks!
 
well, you have multiple choices, you can try the blender plugins from rockin'-b or those by mrkotfw. there was another way by using a dxf converter.
 
Thanks for the reply. I figured that I should just invest time in creating my own tools since it would take a while trying to understand someone else's code and adapting it. I succesfully created a collision detection generator tool and have made some progress with converting Obj files to Jo Engine files and binary files. I will try to implement an automatic mesh subdivision (BSP) for better performance as well.
 
Demo attached to the first post (july 7th version, I didn't even test it on real hardware but it should be fine), if someone wants to give it a try...
 
I may have understand your other posts, but are you refactoring the Jo Engine to no longer use SGL? Could you elaborate?
 
I may have understand your other posts, but are you refactoring the Jo Engine to no longer use SGL? Could you elaborate?
Johannes Fetz, the maker of Jo Engine, is aiming to fully remove SGL.
But it's currently using it since Jo Engine uses functions wrapping SGL for the 3D part.
Since my game is a bit far in development, depending on the future implementation, I might keep SGL if it's not worth the effort of changing everything (tools, 3d models, animation, etc.).
I think if I do keep SGL, I might simply "fork" Jo Engine by adding functions from newer versions but keeping SGL 3d implementation, which might not be super efficient, but is sure easier.
Since I'm using Sega's IP, I will never make any money out of this game, so I don't mind keeping SGL, but future versions of Jo Engine will allow homebrew games to be sold.
 
I'll give the demo a go on my hard-modded Saturn when I get a chance. I'll be away for a couple of days, but when I get back, I'll burn it to a disc and make a quick video for you :)
 
  • Like
Reactions: XL2
Recorded some gameplay in crappy composite, this is amazing work! the only bug i found (which you probably fixed in the newer version) is that Sonic gets stuck on the loop, again you fixed it i bet. Keep up the good work!
 
Recorded some gameplay in crappy composite, this is amazing work! the only bug i found (which you probably fixed in the newer version) is that Sonic gets stuck on the loop, again you fixed it i bet. Keep up the good work!

Yeah, the new collision implementation broke the loops, I haven't bothered to put it back yet since it's a bit complicated and turns the code into a total mess, making debugging harder. Someone on the Jo Engine forum showed me a way to load maps from the CD without binary files and to load it to specific RAM areas.
Right now I'm only using 1 MB of RAM (High Work RAM), but I'll be able to load bigger maps... but I must write a tool allowing me to convert the current .h/MDL files to the new format... fun times ahead!
I still don't know how different the speeds are for the LWRAM and HRRAM, so I'm not sure putting the map in the LWRAM is the most efficient way to go.
I guess we'll see!
 
Sorry for the delay. I will make the video today after work :)

EDIT: Also a side note to anyone that wants to run this on real hardware. XL2 packed the audio tracks with this as .mp3 files, however the .cue file refers to them as .wav files instead. You must convert the audio files to .wav before burning this otherwise the audio tracks won't work. This was common practice for distributing saturn games back in the day when people had slower connections (so I decided to check it before burning haha)

UPDATE 7/31/17: I did actually make the video. Did some basic editing on it as well. Now I'm just waiting for it to upload over my crappy internet connection XD. Will post a link here once its good to go

UPDATE 2 7/31/17: As promised here's the video:
 
Last edited:
  • Like
Reactions: XL2
Sorry for the delay. I will make the video today after work :)

EDIT: Also a side note to anyone that wants to run this on real hardware. XL2 packed the audio tracks with this as .mp3 files, however the .cue file refers to them as .wav files instead. You must convert the audio files to .wav before burning this otherwise the audio tracks won't work. This was common practice for distributing saturn games back in the day when people had slower connections (so I decided to check it before burning haha)

UPDATE 7/31/17: I did actually make the video. Did some basic editing on it as well. Now I'm just waiting for it to upload over my crappy internet connection XD. Will post a link here once its good to go

UPDATE 2 7/31/17: As promised here's the video:


It's nice to see it working nicely on other people's consoles! So far the demo as been pretty stable except for some small glitches, which is great! Hopefully I will have something nice to show before next month!
 
Thanks!
I tested it on a real Saturn, the framerate goes between 30 and 60 fps (while using SGL culling solution, which is slow). I've coded my own culling function, I'm pretty sure it will be faster, but I doubt I'll get a solid 60 fps.
That being said, I need some advises on a problem I'm currently facing.
I'm currently starting to work on a proper octree for both collision and 3d drawing.
One issue I have is that subdividing a map for culling increases the vertices count, slowing down the Saturn.
Like, if you take a cube (8 vertices), subdivide it in 6 objects, you end up with 24 vertices (just an example of this effect, but applied to a whole map you see the problem ).
I noticed there is an Object struct in SGL 3.0 which contains child/parents data and polygon data.
I never saw any SGL 3.0 documentation, so sadly I can't find answers there, and I've seen no examples.
Anyone knows how to use it and if it would help?
Another option I guess could be to store polygon data in the octree's leaf and all vertices in one list, then just DMA the polygons to one single temporary mesh, but I'm not sure if it would be a pratical solution and fast enough (and if it would even work).
Any ideas to solve that issue?
Thanks !
 
Back
Top