(Saturn homebrew) Sonic Z-Treme
- Thread starter XL2
- Start date
-
- Tags
- homebrew saturn sonic z-treme
Hi, I just signed up the other day. This amazing! Can you enable support for the 1MB or 4MB ram carts to give yourself more to work with? Or have you already? Just because you can't make money off the game doesn't mean it can't get you a good job. This is pretty impressive.
I'm not a programmer, but I found an article on dreamcastlive.net that blew me away. I think this could work well for you if you put the game to disc. I posted a quote and a link to the full interview over at https://www.dreamcast-talk.com/forum/viewtopic.php?f=5&t=10619
Check out this thread over here as well (it's not my thread), I am trying to get people with the know-how to test the limits of what the Saturn can do. Appreciate help or feedback: https://segaxtreme.net/threads/screeen-resolution-hacks.24034/page-3#post-174748
XL2
Established Member
Thanks. Memory fragmentation isn't really an issue for me since I don't use malloc, I just point out which addresses to use in the LWRAM while loading maps. The rest of the engine is in HWRAM and stays there (permanent assets). I don't use the RAM cart and don't really plan to use it. I am a bit short on RAM, but I have lot of room for improvements.
About the screen resolution, switching to a higher res such as 352x240 comes at no cost AFAIK since the VDP1 switches from 26 mhz to 28 mhz. I will play more with different resolutions and FOV later on. I've got the pseudo fisheye lens working (120 degrees), but it's a bit too much for the gpu, so I stick with 90 degrees FOV for now.
About the screen resolution, switching to a higher res such as 352x240 comes at no cost AFAIK since the VDP1 switches from 26 mhz to 28 mhz. I will play more with different resolutions and FOV later on. I've got the pseudo fisheye lens working (120 degrees), but it's a bit too much for the gpu, so I stick with 90 degrees FOV for now.
Does the VDP1 switch speed automatically when you set the higher resolution? Or do you have to force it to the higher frequency also?
And any news on feedback from Retro Barcelona?
EDIT: I was mostly talking about striping the map data out into sequential files for faster loading and less seek. Since you keep everything in memory it would only work on the initial startup (which might still be nice)
And any news on feedback from Retro Barcelona?
EDIT: I was mostly talking about striping the map data out into sequential files for faster loading and less seek. Since you keep everything in memory it would only work on the initial startup (which might still be nice)
Apparently RB went very well! im trying to get in contact with the Sonic & Sega Fan Jam to see if we can send a demo there
XL2
Established Member
AFAIK it's automatic. For Retro Barcelona, I didn't get much feedback, so I guess it wasn't that huge, but it's hard to know.
hi ! thank you very much for the link
XL2
Established Member
Np! That version is very old (0.02), there is a newer version floating around (0.034), you could try it instead : http://www.seganerds.com/2017/11/30/the-sega-saturn-is-finally-getting-a-3d-sonic-game/
I will try to have a new version ready for Sage 2018, with a new engine, new maps and splitscreen multiplayer. I'm still not done porting to my new engine, so I hope to make it on time!
EDIT : Just to show what split screen looks like within the FPS demo. I'm now using 16 color banks for everything except the weapons, so I can't put gouraud shading and I don't have enough CRAM left for pseudo-gouraud (like the Chrome SGL demo). But using color banks mean that I can use VDP2 color calculation effects on sprites, such as transparency, so I could just use the transparency to do depth gouraud, which would be much cheaper than using actual gouraud shading since it's offloaded from the VDP1 to the VDP2.
Last edited:
XL2
Established Member
I made a short video of the (still incomplete) splitscreen mode.
It works rather well (just don't mind the lack of animation or textures on the players)!
I just wish someone had the Netlink library files and documentation somewhere, I could make sure I design the game for compatibility with online multiplayer!
EDIT : Btw, does anyone know how to set different sprite priority in SGL (for VDP2 color calculation)? I see in the sl_def.h file that there are several options, but I can't find a single one to do a per-quad priority (again for color calculation, not for the z sort). It can only switch once per screen. The SGL documentation is totally useless for that, but reading the VDP1 manual it seems you can put a different priority for each quad. The idea here is to replace the depth gouraud shading with color calculation on the backscreen, which will be faster. I don't know if there is a better built-in function, but the solution I found is to manually change the "colno" attribute (depends on the sprite type, but for sprite type 0 it's starting at bit 11) and set bit 14 to 1. It only works with color banks, while with look up table if you set your color calc condition to MSB and your pixel colors have the MSB set to 0, you can do it. I will have to play more with it to see if you can change the color calc ratio using CLUT sprites as the CRAM is super limited (2048 colors max).
It works rather well (just don't mind the lack of animation or textures on the players)!
I just wish someone had the Netlink library files and documentation somewhere, I could make sure I design the game for compatibility with online multiplayer!
Last edited:
XL2
Established Member
Slowly getting there!
I still haven't put back the gameplay in the new version of the engine and I want to add some graphical effects, but I think the draw distance is pretty good so far.
I got the audio part OK (I think), graphics are getting close to be done, so I still need to put gameplay back in and work on the collision system and entities management.
If all goes well I'll have a demo in 2 months ready for SAGE 2018.
I still haven't put back the gameplay in the new version of the engine and I want to add some graphical effects, but I think the draw distance is pretty good so far.
I got the audio part OK (I think), graphics are getting close to be done, so I still need to put gameplay back in and work on the collision system and entities management.
If all goes well I'll have a demo in 2 months ready for SAGE 2018.
XL2
Established Member
I'm not 100% sure what you mean.
I use 16 colors LUT for quads close to the screen (it allows gouraud shading) and use CBank for quads further away (for transparency ).
The main issue with using CLUT as color bank code is that I can't select different ratios, so it doesn't work well for what I'm doing.
I now have 8 levels of transparency, so it looks quite smooth .
Last edited:
XL2
Established Member
No, I tried and I can't set different ratios, so you are stuck with Sprite 0 or 1 ratio (so you can't do a smooth fade in). The alternative is to use gouraud shading on paletted sprites, but it's VERY tricky.
You only have access to 2048 colors and for memory reasons you probably want 4 or 8 bpp, but with gouraud shading on paletted sprites the gouraud shading will change the index of the palette instead of the actual RGB code, so you need to put all the gradiants you want in your palette.
You must also be very careful with your palette's values as you don't want to overflow it (like, your texture's first index should be at 16 since if you remove 16 with the gouraud you don't want to end at < 0)
You also only want to use red gouraud (since it will offset one index - at the LSB).
It can look more impressive than RGB gouraud shading (for things like metalic or wet rock effects) since you aren't limited to a gradiant from 4 corner colors and the shading can "penetrate" the texture.
I considered using it on crystal frost (the ice level from Sonic X-Treme) for the ice, but it might be a bit too much as it would require to hold per vertex normals (takes quite a lot of memory) and do one dot product per quad (it would impact the CPU) - and that's without saying that the color RAM would still be way too limited.
XL2
Established Member
I'm trying to play with palettes to fit them in 32 colors palettes and allowing me to use gouraud shading with 8 lightning values (32x8=256) by having only green gouraud (it would increase the color value by 32 since green starts at bit 5) and 8 bpp sprites. It would also have the benefit of allowing me to not use gouraud shading when the lightning is flat (4 vertices have the same normals) for faster rendering. It would allow both gouraud shading with transparency and flat lightning without gouraud.
I have yet to try it as I must find a way to cram the colors in 32 colors palettes and keep the number of palettes low (6 max to keep background palettes), but hopefully I'll make it work.
XL2
Established Member
I added vertex animation support to my engine.
The vertices are compressed from 12 bytes to 6 each while the normals are compressed from 12 bytes to 1 byte.
The animations are interpolated to give a smooth result with few frames.
The idle animation is only 2 frames in fact!
All the Sonic animations seen here take a grand total of 35 kilobytes, which is quite low for rather smooth animations!
The vertices are compressed from 12 bytes to 6 each while the normals are compressed from 12 bytes to 1 byte.
The animations are interpolated to give a smooth result with few frames.
The idle animation is only 2 frames in fact!
All the Sonic animations seen here take a grand total of 35 kilobytes, which is quite low for rather smooth animations!
