XL2
(Sega Saturn homebrew) Improved shadow casting performances!
updated
For obvious legal reasons, I won't port the whole game - I never planned to go beyond the first 3 levels, which were in the demos.
It's in my own engine, so no source code of the original was used and the maps/animation had to be done from scratch. Ponut64 wrote the amazing sound driver while Corvusdeux did most of the 3D models and animations. I coded the tools, the whole game engine and I remade the levels with Trenchbroom - then converted with my own BSP compiler to my own Saturn map format. There are still several glitches and collision issues and the framerate could be improved a lot (it's far from optimized at the moment). The biggest challenge was mostly to make everything fit in RAM. I had to make massive changes to the engine to allow Nyleve falls to work - one week ago it didn't even run without a RAM cart, but the RAM cart is too unreliable, I decided to not use it. I worked on this whole project for around 4 months, with maybe an average of 1 hour per day.
Grab the demo here : segaxtreme.net/resources/irreel.140
Video taken on real hardware. Sadly my capture card interlaces everything and then merge it back, so it's not a smooth as you would expect on a CRT for example. The framerate goes between 10 to 30 fps (it's locked, it could get to 60 otherwise).
///
Voici mon dernier projet, une démo technique d'Unreal sur Saturn, avec mon propre moteur - le même moteur que j'ai fait pour Hellslave, mais avec plusieurs modifications importantes. Le plus gros défi était de tout faire rentrer dans la mémoire limitée de la console. C'est loin d'être optimisé et il y a place à améliorations, mais considérant que la semaine dernière ça ne fonctionnait toujours pas, je suis quand même satisfait.
Malheureusement, je suis mal équipé pour la capture AV, alors c'est loin d'être idéal ici.
Il y a encore plusieurs bugs et problèmes de collision, je vais tenter d'améliorer un peu la démo avant la date limite du 1er janvier.
Cette démo a été réalisée dans le cadre de la compétition annuelle d'homebrew pour Saturn de SegaXtreme : segaxtreme.net/resources/irreel.140
Voici quelque chose que je voulais faire depuis un bout : recréer Lava Giant d'Unreal Tournament sur mon moteur, principalement pour voir jusqu'où je peux pousser la Saturn. Je n'ai pas tenté de recréer tous les chemins et tous les détails, alors c'est plutôt bâclé comme reconstruction, mais comme vous pouvez voir ça fonctionne plutôt bien dans les circonstance (15-30 images par seconde). Le moteur n'est pas encore optimisé alors j'espère gagner quelques images par seconde de plus. Je n'ai pas de mode CTF et mes bots sont trop stupides en ce moment pour que ce soit une option à court terme, alors on verra pour la suite, si suite il y a! J'ai modifié la réflexion sur les armes : La texture est maintenant constituée du framebuffer et une image statique de réflexion. La réflexion en temps réel est plus subtile, mais c'est peut-être pour le mieux? Ou pas. Laissez-moi savoir! Sur cette vidéo le jeu roule sur une réelle console.
**English**
Something I wanted to do for a while now to test how a massive map would look like on the Saturn : remake Unreal Tournament's lava giant map.
It's just a quickly made map, I didn't even bother to make sure the paths are the same (2 paths per side instead of multiple paths...and all these paths lead to a central point) and I don't have any CTF mode and I don't know if I will try to add one (mostly because of the bots). It runs at 15-30 fps, perhaps 20 fps most of the time. I haven't optimized the engine yet, so hopefully I'll gain more frames per second once I do. You can also see that I changed the realtime reflection on the weapons : instead of using the mesh transparency to merge 2 textures, I bake a reflection texture with the image from the framebuffer. The result is that the effect is more subtle now, so you might not even notice it, but it's probably cleaner like this. This is running on real hardware.
Longplay of my entry for the Saturn homebrew competition 2022.
Running on real hardware, you can see it struggles a bit with the bots. I set the default at 3 bots for good performances, but in this longplay I fight against 5 bots then 7.
8 player games are very fun imo, despite the slowdowns!
You can also see my last minute addition (like, litterally a couple of hours before the deadline) : realtime reflections on some of the weapons, with the shotgun being the most obvious one.
Amazing soundtrack by Sergio Enrique Nunez Stroller and Fleshfield, maps by myself, ReyeMe (Gm const remake) and Josh 7774 (Frigate and Forest temple), assets by myself, Ponut64, Anton and many other people from the SegaXtreme community.
Download here to try it yourself : segaxtreme.net/resources/hellslave.58
And check out the other entries, they are well worth your time : segaxtreme.net/threads/sega-saturn-27th-anniversary-game-competition.25009
*Français*
"Longplay" de mon entrée pour la compétition Saturn homebrew 2022.
Le jeu roule ici sur une vraie console, vous pouvez voir que le jeu a un peu de mal avec les bots au niveau du nombre d'images par seconde à certains endroits (ça me rappelle Perfect Dark, mais c'est quand même plus rapide ici, avec 10 ips comme minimum). J'ai réglé la valeur par défaut à 3 bots pour de bonnes performances, mais dans ce longplay je me bats contre 5 bots puis 7 à la toute fin pour montrer à quel point c'est chaotique.
Les parties à 8 joueurs sont très amusantes, malgré les ralentissements !
Vous pouvez aussi voir mon ajout de dernière minute (sans blague, je l'ai ajouté la dernière journée!) : les réflexions sur certaines armes, notamment le fusil de chasse!
Une bande son incroyable par Sergio Enrique Nunez Stroller et Fleshfield, des maps par moi-même, ReyeMe (Gm const remake) et Josh 7774 (Frigate et Forest temple), des assets par moi-même, Ponut64, Anton et beaucoup d'autres personnes de la communauté de SegaXtreme.
Téléchargez ici pour l'essayer vous-même : segaxtreme.net/resources/hellslave.58
Et regardez les autres entrées, elles valent bien votre temps : segaxtreme.net/threads/sega-saturn-27th-anniversary-game-competition.25009
Aperçu du démo pour la compétition homebrew de Saturn 2022. Démonstration de l'effet de réflexion sur certaines armes
Anyone who played Unreal (1998) or Unreal Tournament (1999) will remember just how amazing the skyboxes were, with multiple layers of clouds, nebulas, stars, etc. In this (incomplete) map started by Josh_7774, I show a skybox made using VDP1 (the ocean floor and mountains), paletted sprites to allow sprites to be transparent with the VDP2 layer (sun, moon, nebula) and the 2 cloud layers, including one 3d VDP2 RBG0 plane. As you can see, the Saturn can get pretty close to the best stuff on PC (and expensive GPU!) from 1998-1999, with 3 layers of transparency.
Huge thanks to my patreon btw, I would probably take a huge long break from coding if it wasn't for you guys!
You can also join my Patreon to get the latest updates and some non-public experiments! patreon.com/XL2
///
*Français*
Je voulais tenter de recréer les décors d'Unreal (1998) et Unreal Tournament (1999) sur la vieille Saturn. Les décors d'Unreal étaient exceptionnels, avec des effets de lumière et de transparence. Dans cette carte incomplète commencée par Josh_7774 je montre un décors mélangeant la VDP1 et la VDP2. L'océan est fait avec la VDP1, tout comme les montagnes. Les étoiles et la lune sont aussi faits avec la VDP1, mais en utilisant une palette de couleur pour permettre la transparence. Les nuages (2 couches) sont faits avec la VDP2. Tout ceci permet 3 couches de transparence et un effet qui se rapproche d'Unreal avec un GPU à la fin pointe de la technologie de l'époque...sur une console de 1994.
Merci à ceux qui m'appuient sur Patreon, ça me garde motivé!
patreon.com/XL2
Not much in terms of "gameplay", it's really just a tech demo to show the Gran Turismo-like effect. The track is incomplete, the gameplay is still pretty much Hellslave (you can even kill the cars!), while the floor is made with a huge VDP2 plane that currently has no details. The framerate goes from 20 to 30 fps depending on the scene, so that's another area I would need to improve - Most racing games used LOD models for the cars, while here I only have the high quality model (200+ polygons per car), so that's one easy optimization I could implement. Running on real hardware, my capture card can't get the audio for some reasons... but it's better this way ;)
--
Demo style Gran Turismo, sur une vraie Sega Saturn. Pas vraiment un jeu, juste une démo technique. La carte est incomplète et il n'y a pas de gameplay. La performance n'est pas superbe, 20 à 30 ips, je dois améliorer ça, surtout en utilisant des modèles LOD pour les voitures (200+ polygones par voiture présentement). Vidéo capturée sur une vraie console.
Don't mind the mockup track, it's ugly, straight from Hellslave's engine, which isn't exactly well suited for a racing game.
And no, I am not making a racing game, it's just a quick demo!
//
Suite de mon dernier vidéos, démo de l'effet de réflexion sur une voiture importée de Gran Turismo 2.
La piste est laide, mais je n'ai pas fait d'efforts et c'est sur le moteur d'Hellslave, qui n'est pas idéal pour un jeu de course.
Et non, je ne fais pas de jeu de course, ce n'est qu'un test!
More details here : segaxtreme.net/threads/texture-coordinates-on-the-saturn.25017
And here : segasaturnshiro.com/2021/09/09/xl2-cracks-impossible-saturn-hardware-environment-mapping
///
On disait depuis toujours que c'était impossible, mais voici un rendu matériel d'une texture de réflexion!
Pour plus de détails : segaxtreme.net/threads/texture-coordinates-on-the-saturn.25017
Et ici : segasaturnshiro.com/2021/09/09/xl2-cracks-impossible-saturn-hardware-environment-mapping
//
Petit test fait l'année dernière lors du développement de la démo de Metal Sonic. J'avais ajouté les sprites en 2d de Sonic X-Treme au démo de SAGE 2018 et changé de technique pour cacher les polygons qui apparaissent, utilisant seulement du gouraud shading pour ce test. Il n'y a plus de modèle LOD pour ce test, alors je n'utilise plus la technique de Sonic R. Les sprites 2d prennent beaucoup de mémoire, ce qui a brisé ma routine de chargement des cartes, ce qui fait en sorte que seules Jade Gully et Galaxy fortress fonctionnaient. Il aurait fallu apporter des modifications au code de chargement des cartes pour faires fonctionner les autres cartes. Je préfère de loin les modèles en 3d, ça l'aide beaucoup pour la perception des distances...
J'utilise Mednafen pour cette vidéo.
That Sonic 3d model was meant to be used in Sonic X-Treme and it makes good use of the Saturn's unique rendering technique (quads instead of triangles) to create curves, like around the eyes here. The terrain model in the SDK is also a heightmap, with the X and Z coordinates for each vertex being implicit as it's a uniform grid. So it's very easy to interpolate and do some basic collision detection on it as seen here, or to animate it by moving vertices around. The official game had cooler terrain deformation, I am only moving one vertex.
//
Voici les modèles officiels utilisés par Sega pour vraisemblablement Sonic X-Treme. Ils sont tous compris avec SGL, donc rien de nouveau ici. Le modèle de Sonic utilise bien la Saturn pour créer des courbes grâce aux quads (vs triangles). Le terrain est aussi une grille uniforme avec seule la hauteur qui change, ce qui permet de facilement modifier le terrain pour la collision et le rendu.
With no bots the map runs at around 20-30 fps on real hardware.
I also joined the dark side and started a Patreon, if you guys want to contribute to this project, here is the link : patreon.com/XL2
Thanks for those who are already supporting me!
Original music by the talented Sergio Enrique Nunez Stolles!
//
Match à mort contre 5 bots dans la nouvelle carte, Oasis temple. Carte ouverte avec des réflexions, effets de lentille, etc. Les performances sont basses à cause des bots qui ne sont pas encore optimisés. 20-30 images par secondes sur une vraie console.
J'ai aussi ouvert un compte Patreon, si vous voulez contribuer au projet, voici le lien : patreon.com/XL2
Merci à ceux qui me supportent déjà!
Musique par le talentueux Sergio Enrique Nunez Stolles!
Running in the Mednafen emulator as my capture hardware still doesn't work well, but the map runs at 20-30 fps on a real Saturn with 3 bots.
I also joined the dark side and started a Patreon, if you guys want to contribute to this project, here is the link : patreon.com/XL2
//
Nouvelle carte, "Hellstation" pour 2 à 4 joueurs.
Démonstration utilisant Mednafen car mon équipement de capture AV ne fonctionne pas, mais ça roule à 20-30 images par seconde sur une vraie console avec 3 bots.
J'ai aussi ouvert un compte Patreon, si vous voulez contribuer au projet, voici le lien : patreon.com/XL2
It gets chaotic enough with 4 players!
My capture hardware doesn't capture the audio anymore, so this is running in an emulator instead of real hardware.
With 3 other bots, this map runs at around 20 fps in average.
I'll try to reach a more stable 30 by making some small changes.
You can also see the near flare fading effects, heavily inspired by Unreal/Unreal Tournament!
I hope to release a demo near the end of the summer - but I'll focus only on the multiplayer portion as I won't have time add anything new for the single player portion.
//
Démonstration du mode multi-joueurs contre 3 bots.
C'est assez chaotique!
Mon équipement de capture est brisé - l'image fonctionne mais il n'y a pas de son - alors je roule le jeu ici sous Mednafen.
Sur une vraie Saturn le jeu roule à 20 images par seconde en moyenne, j'espère me rendre à 30 images par seconde en apportant des petits changements.
Vous pouvez aussi voir un nouvel effet de lumière, largement inspiré par Unreal / Unreal Tournament (1998 / 1999).
Je vais tenter de diffuser une nouvelle démo vers la fin de l'été, mais je n'aurai pas le temps de toucher au mode solo, alors ce sera multi-joueurs (incluant bots) seulement!
The bots were coded fairly quickly (roughly one hour), so they won't win any awards for intelligence, but their basic behaviour makes them challenging and fun enough.
They also work in splitscreen obviously, so in theory 4 local players could play with 4 bots.
Oh, and also, in the WIP forest map, made by a user named Josh_7774, you can see my new volumetric fog in action, where the fog affects the "fogged" sector and those seen from it, with the fog getting less and less dense as you move out of it, which is quite nice.
Running in Mednafen instead of real hardware, my capture equipment can't get audio for some reasons
--
Partie de match à mort contre 7 autres bots.
J'ai codé l'IA des bots en environ une heure, alors ils ne sont pas brillants, mais c'est suffisant pour s'amuser.
Ils fonctionnent aussi en écran partagé, avec 4 joueurs "humains" et 4 bots.
Je montre aussi la brume volumétrique dans le niveau (incomplet) de la forêt. La densité de la brume diminue lorsque vous quittez la zone affectée, ce qui est plutôt bien!
J'ai des problèmes avec mon équipement de capture, alors le jeu roule ici sous l'émulateur Mednafen.
Download the game here :
sonicfangameshq.com/forums/showcase/sonic-z-treme-metal-sonic.851
Running on a real Saturn. The actual track included is Lost Boss from Sonic X-Treme, but as I run the game using my USB dev cart it's reading the disc in my Saturn (Hellslave), so the music here is Flesh Field.
I die on the second map, but you can also simply rush the exit to finish the level, I just wanted to try my luck against 20 enemies ;)
You can grab the game here : sonicfangameshq.com/forums/showcase/hellslave-project-z-treme.724
----------------
Voici une démo de mon jeu, Hellslave - Project Z-Treme.
La fin du deuxième niveau est un peu brutale, mais c'est possible de la terminer en fonçant vers la sortie tout simplement. Je voulais tenter ma chance en tirant dans le tas, 1 contre 20...
Il y a présentement 2 vrais niveaux, les autres sont surtout des tests que j'ai gardés pour prolonger un peu la durée de vie du jeu.
Lien vers le jeu : sonicfangameshq.com/forums/showcase/hellslave-project-z-treme.724
Song : Dreams Untrue by Alexander Brandon (Unreal 1998)
Running on stock Sega Saturn hardware with my own engine, the Z-Treme Engine.
I didn't bother with transitions as I really wanted to show the cool flare effect around the 13 seconds mark.
The trailer won't have sound, so don't mind the audio here.
I just felt like adding some effects I didn't have time to add to the Sage 2018 demo, such as RBG0 layers, snow, etc.
Here is what it looks like.
While I did have later versions, I experimented so much that it killed several effects (gouraud shading vs fade in).
Unlike what my engine is now at, this version still uses SGL for rendering, which is kind of slow in comparison and creates several memory management issue (it wastes ram in other words).
I also just put my frustum culling code from Project Z-Treme, which is way more accurate, but it also means less stuff gets culled out, so it impacts the framerate a little bit in some maps.
Getting rid of SGL should be enough
Before anyone asks, I don't intend to do much more with this, it was mainly for fun. My main project is still Project Z-Treme, which is obviously much more advanced than what's here.
----
Nouveautés ici : multijoueur à 4 (je n'ai pas de multitap, donc je peux seulement contrôler 2 joueurs), nouvelles techniques de rendu (soleil et polygones générés en temps réel pour sauver de la mémoire) et puis un peu de nouveautés côté jeu. La dernière pièce avec 20+ ennemis roule à 12-15 fps, mais c'est seulement pour les niveaux de difficultés plus bas. En mode facile/normal ça roule plutôt à 20-30 images/secondes (environ 12 ennemis). En multijoueur à 4, le jeu roule à 12-30 images/secondes, mais c'est surtout un problème de processeurs plutôt que du VDP1.
I haven't made updates for a while as I was very busy with work, but there are several new things I've been working on :
-I am now using the SCU DSP for the entities (enemys, weapons, etc.). It doesn't lead to any noticable increased performances as, quite honestly, the SH2 cpus are quite good for 3d maths (built-in math units) while the SCU DSP is just poorly designed.
-My model converter (enemys and more) allows support for texture coordinates, generating Saturn-friendly predistorted textures. You can see it on the enemy models from Quake!
-I added support for doors, switches, locked doors, switches to turn on lights, elevators (not seen here) and more.
-And yeah, the dog model isn't animated at the moment!
-More stuff not seen here (new weapons and all)
I will probably not make other updates for the next couple of weeks, but the engine is getting near to a point where I can now consider creating interesting levels and focus more on the gameplay.
----
Nouvelle mise-à-jour, j'utilise maintenant le SCU DSP pour les modèles 3d (mais ça ne donne pas de meilleures performances malheureusement), les modèles 3d peuvent maintenant être convertis en utilisant des coordonnées pour les textures et j'ai ajouté des portes, des interrupteurs, des nouveaux effets de lumière et plus encore.
It's trickier to make it all work together than what it seems as the VDP2 is a pain in the butt to get working well, with 1000+ restrictions.
I also added a gradation effect on the NBG1 layer, which simply creates a more intense alpha blending coloring.
Sorry for the abrupt ending, I had a phone call ;)
The assets, sound effects and music are almost all temporary.
So you can now have up to 9 light sources affecting a vertex, giving way better lighting than before.
I also changed the lighting for the weapons, now taking the dynamic light + static light into account.
You can also see the new intro map (difficulty select, main menu screen where everybody is just fighting to death) and some transparency features (light halos, flames, player's shadow, water, etc.).
The transparencies are using a mix of VDP1 half-transparency and VDP2 transparency (single player only, I use the dithering effect in splitscreen).
The game runs at 30 fps, with drops to 20 fps when it gets more busy, but as you can see it's smooth overall even with multiple ennemies and light sources on screen.
This is running on my own engine (using a BSP), with 100% original rendering code, collision, AI, map compiler, etc.
My game is still untitled and I still need to change some textures/assets/sounds (like the flamethrower's sound and the Quake 2 weapon!)
You can see here a technique really similar to what Burning Rangers did to achieve proper transparency on the Saturn.
How it works : I render the transparent sprites outside the framebuffer, in an unused area (from x:352 to 511 and y:0 to 112).
That gives me a 160x112 resolution to work with, which isn't great, but that's good enough.
I then transfer that portion of the framebuffer to vdp2 ram into a NBG0 layer at 16 bpp.
Unlike Burning Rangers, I only need to clear that portion of the framebuffer once per frame, but I do lose 16 pixels compared to BR.
Since the VDP2 NBG0 layer used here comes on top of the framebuffer, I also need to draw transparent polygons to mask the columns and weapons.
This scene runs at 20-30 fps.
I hope to get a small speed boost by using VDP2 CRAM for the weapons, with priorities to prevent having to mask the weapons (which will also look better).
I have yet to mask the entities, and in multiplayer I will simply use the mesh/dithering transparency effect to try to keep the framerate up.
Also, when there are no transparent elements, I don't transfer the framebuffer nor draw the masks, so I can save ressources there.
The transparent sprite shown here is simply an untextured polygon, but it also works with textures.
---
Petite mise-à-jour avec armes en 3d. Elles ont encore besoin de travail. Côté performances, j'ai fait quelques gains...que j'ai perdu en ajoutant les armes 3d. Vers la fin du vidéo il y a une pièce où le nombre d'image/seconde descend à 15-20 images/s, mais la console affiche plus de 1500 polygones! On voit aussi ici les nouvelles cartes et zombies.
I also manually added some portals for extra culling.
I placed them in a couple of doorways to help both the slave cpu (less polygons to create) and the VDP1 (it can reduce the number of drawn polygons by 25% or more).
Running on a real Sega Saturn on my own engine (Z-Treme engine). Assets mainly from Quake, Powerslave and Freedoom.
------
Petit test avec une grande salle. Je voulais voir le niveau de performance en mode écran partagé dans une grande pièce. Le résultat est assez bon, 30 à 15 images/seconde. En mode 1 joueur, le jeu ne semble pas descendre sous la barre des 20 images/secondes, même avec 6-7 ennemis à l'écran, ce qui est assez bon pour la console considérant que presque tout est en 3D.
J'ai aussi ajouté manuellement des "portals" à certains endroits pour éliminer plus de polygones, ce qui aide aussi à maintenir de bonnes performances.
La démo ici fonctionne sur une vraie console (NTSC). Le moteur 3D est le mien. Les textures et armes proviennent principalement de Quake, Powerslave/Exhumed et Freedoom.
New stuff seen here : I wrote a new map converter, so now I can use brushes with CSG operations to a BSP tree. It works with Quake map editors, so that speeds up map making quite a bit! Of course, my engine has its restrictions, so a simple convertion of PC Quake maps won't work asis (mainly about RAM).
Near the end of the video I'm also showcasing the new realtime lighting that now affects entities too!
Every single entity (including healthpacks and body parts) are now affected by the realtime lights.
And it comes a very little cost!
The new map seen here is a bit huge and I didn't bother too much with textures, so it's not optimal, but you can see that I can now create way more complex maps than before thanks to the new version of the compiler.
Running on stock hardware using my own 3d/game engine.
The assets are mainly from Quake, Powerslave and Freedoom.
Running on stock Sega Saturn from a CD.
This is running on my own BSP based 3D engine, with my own rendering code, collision code, physics, etc. etc.
Music : Voyager by Jasper Byrne, Quake 2 title screen by Sonic Mayhem, Organic (Unreal Tournament 99) by Alexander Brandon.
Assets (almost all temporary) mainly from Saturn Quake, Powerslave and Freedom
Demo here :
sonicfangameshq.com/forums/showcase/project-z-treme-sega-saturn-sage-2019-tech-demo.323
I have been super busy in the past few weeks, so this project went to the backburner.
I still need to improve how the flare looks and make it fade in/out in a smoother fashion, but here is what it looks like with torches I quickly made in Blender and "proper" light sources.
I'm using the offscreen area of the framebuffer (512x256, so from 352 to 512 and 0 to 112) to draw the transparent sprites, I then DMA everything to VDP2 ram and have the NBG0 layer display it using additive transparency.
It looks really nice and the impact on the framerate isn't too huge.
Very complicated just to get such a "minor" effect, but I think it looks great.
Let me know in the comments what you think.
Running on stock Sega Saturn. It's my own engine, coded mostly in C. Assets are mostly from Quake/Freedoom/Powerslave.
Still buggy and I only use one light source at 0,0,0.
The effect is similar to the Burning Rangers VDP2 trick.
It's running on real hardware.
Running on a stock SEGA Saturn.
New things seen here : dynamic lighting!
Demo here :
sonicfangameshq.com/forums/showcase/project-z-treme-sega-saturn-sage-2019-tech-demo.323
A small word on my engine :
It's a BSP based engine using a PVS for occlusion culling.
It doesn't eliminate overdraw, but reduces it enough for the VDP1 to be able to display it all at 30 fps.
But that overdraw causes a heavy burden on the cpus, mainly the poor slave Cpu which is currently doing 100% of the T&L work (but the main is busy with everything else, which is also a lot).
I am currently rewriting huge chunks of the engine to turn it into a portal based engine instead, but I thought I should release the current version since, well, why not?
The engine isn't optimized yet, so please keep that in mind when the framerate drops in some busy areas.
I plan to make a game like a terrorist hunt mode from R6 with a focus on multiplayer/deathmatch. And, if I really stick to it long enough, I would like to make a full campaign à la Powerslave, but I won't promise anything now as it's a lot of work obviously.
ALL THE ASSETS ARE TEMPORARY!
Included in the demo : 4 weapons, 1 map (+ 1 hidden map), 3 gameplay modes : single player, splitscreen coop and splitscreen deathmatch.
The map isn't really designed for my engine, so it doesn't work perfectly.
Also shown here is the monsters' infighting.
I haven't decided the name of the game yet.
Again, my stupid capture card interlaces everything, so sorry about that!
Gameplay wise, image Rainbow Six's terrorist hunt mode, but with monsters, zombies, creatures, whatever you want to call them. I guess that's the kind of game I will be going for since it's easy enough for a single person, unlike something more ambitious like Powerslave.
The framerate while in multiplayer is mostly 15-30, except the room upstairs (7x 3D enemies, x2 since it's splitscreen). The game isn't fully optimized (the slave is doing 100% of the vertex/polygon transformations), so the bottleneck is the CPU. I think the VDP1 could hit 60 FPS most of the time if the CPU wouldn't be holding it back. And I still know several VDP1 optimizations that I haven't tried yet, so the VDP1 more powerful than I thought.
I will add a couple of enemies such as dogs and things like that, with different attacks. And the soldiers will shoot "slow" projectiles that you can dodge to allow a fast gameplay instead of camping in the corner.
About the engine itself, I am still using a BSP + PVS, but I will try to move to a portal-based sollution.
There are also collision issues I haven't been able to fix using the BSP tree, so hopefully with a portal based engine I should be fine.
Running on stock Sega Saturn, using a cheap USB capture card (which interlaces everything...) on my own engine.
I added a basic AI (stuck in a walking animation for now, I haven't implemented proper animation selection yet), it detects when you fire, when idle it turns around (for now) until it finds a target and when it finds a target it will hunt it until the target dies.
Monster infighting also works, but they won't shoot a friendly on purpose (it will work mostly with slower projectiles which will hit another target than the intended target at times).
The AI more or less randomly shoot and walk in different directions (but still about the player's position) to keep things interesting. It's good enough for them to follow you in other rooms, but of course it's not a very advanced AI.
I don't plan on using hitscanners as I just hate it, but that was mainly for testing.
And as you can see, it works rather fine in split screen, even with 7 ennemies on screen (the flashing room upstairs) the framerate doesn't seem to go under 15 FPS. In average it runs at 30 FPS in single player and 20-30 in split screen mode.
All the audio sfx are still from Sonic Z-Treme's tone file, so yeah, it sounds out of place. And I need to work on animations/decals, etc.
I am just testing bullets collision detection. It's still running with my bsp/pvs engine, but I will probably move to a portal based solution in the near future.
I still have many things to work on, like pickups, ennemies and AI, switches and doors, etc.
I will focus on multiplayer for now since it's a bit easier.
It won't beat GoldenEye 64 anytime soon, but it's still the only splitscreen fps action you ever played on the Saturn!
I only use my own code for rendering, but SGL is still used to boot the system and control the vblank and commands final sorting. I use SBL for audio and cd control.
The poor slave CPU is still doing 100% of the vertex transformation and polygon creation, I will start working on a system to share the burden soon.
The Z-Treme engine is coded in C, this demo is running on stock Saturn with a usb dev cart. It runs at 20-30 fps while in splitscreen and 30 fps in single player, all the quads are 64x64 gouraud shaded textures (plus a LOD system).
I am testing bullets here and overall collision detection.
It's not 100% perfect and I am not sure if I will be keeping the current version of the engine (BSP based).
The BSP based engine is causing me a TON of frustrations/problems (like the BSP ray tracing failing like you shoot at an invisible wall), so I am starting to look at already available map editors (Tomb Raider maybe) and fully change the engine...again.
Something like the Tomb Raider format sounds nice on paper (so did BSP...), with heightmaps, rooms and portals.
It's VERY frustrating : I felt close to start working on gameplay and 3d models!
BSP is nice since it's easy to find your current position using it, have portals autogenerated (and then just use a PVS to cull out geometry) you can do raytracing and many useful things. But it requires many divisions and other things the Saturn isn't that good with, so it's not optimal. It seems that the divisions cause rounding errors too and make the BSP fail.
Anyway, with portals I can cull out even more polygons, so it's not all bad.
Unless someone can give me a hand with BSP based collision (and again it's not optimal, a portal based engine would be better), I'll just change the technique...some 4-5 months down the drain...again!
Oh, and before you ask : No, Vasectomy Software is not a real thing
I also only had 1 pad for this test... so only player 2 is moving around.
The textures are now 64x64 (vs 32x32 in other videos) and I don't use SGL anymore for rendering, only my own code.
This allows way better shading and much faster rendering (preclipping disable trick, that only few games used, such as Sonic R and Burning Rangers, even if it's clearly stated in Sega's documentation that it's much faster to flip it on/off depending on if your sprite is partially offscreen or not).
I am using ONLY the slave CPU for vertices transformation and polygon creation, so the main CPU doesn't do much (you can see the rendering cpu time, which is the main CPU's part...it doesn't do much compared to the slave cpu).
It runs mostly at 20 fps, which is great considering I am almost only using 1 cpu.
I also only use C for the transformation, so I could get a big boost by using assembly.
For the shading/lighting, I have static light precalculated using my BSP tree, depth shading calculated in realtime and I have "dynamic" light effects (red and green, which is just a color table getting updated to change the intensity).
So in terms of graphics (if we forget the artistic choices), it's more or less on par with the Slavedriver : Both engines use 64x64 textures with gouraud shading lighting on each quad. I have a higher resolution (352x224 vs 320x240), but still no "real" realtime lighting effects. The slavedriver used portals, while I use precalculated visibility (PVS), so the slavedriver engine would cull out more geometry, but thanks to the preclipping trick I'm not that much at disadvantage as overdraw becomes more acceptable. Right now my bottleneck is the CPU, so I'll have to improve my code and (maybe) share the rendering burden between the main and slave cpus.
Running on real hardware. Visit the Segaxtreme forums for more info. segaxtreme.net
First, sorry for the video quality and for how dark the map is, I didn't spend much time on it as it's just a test map, but other textures would make it way better as the current ones are dark.
The new engine uses a compressed potentially visible set (PVS) for occlusion culling. The compiler creates portals and these portals are used offline to calculate the visibility. It reduces overdraw a lot, and it also means that I am not using any draw distance limit anymore.
The bsp-base engine also has a huge benefit : it's now very easy to calculate lighting. Each polygon has gouraud shading on it, using 32x32 textures (Sonic Z-Treme used 16x16, Nights into Dreams often used 24x24, Sonic R used 32x32, while the king of the Sega Saturn engine, the Slavedriver engine, used 64x64 textures). The higher the res, the slower they are to render, so 32x32 is a good compromise.
I'm also not clearing the framebuffer to gain some rendering speed. Right now, from my tests, the engine can draw around 700-800 polygons at 30 fps and up to 1400 at 20 fps. I'm looking for ways to improve it, such as adding some manual portals to be used in game and flipping on and off preclipping disable to speed up a bit the VDP1 rendering in some cases.
I'm also showing here the Burning Rangers-style transparency, which I had for a couple of months now. Unlike Burning Rangers, I'm simply rendering these polygons offscreen (the framebuffer is 512x256, but the screen is only seeing 352x224, so I have access to 160x256 fully unused pixels on the side). I'm using 160x112. I then just send that offscreen area to VDP2 memory and display it as a NBG0 layer, that I zoom. in . It means that it's pixelated, but for close enough polygons it works well. The main issue with BR-style transparency? SORTING! I haven't found a fast solution to it yet. Since the Saturn can't clip other than with user clip commands (rectangles), thanks to the lack of texture coordinates, the only other option is to use some masking polygons, but I don't like this solution. Another solution might be to disable gouraud shading and use lightmaps at that offscreen area (which also means I would render 2x more polygons, but smaller, and the main area wouldn't need to use gouraud shading, so it might work).
You can also see collision detection, including bullets (the star-thing acts as a collision tester for bullets).
So, what's next? I'm working on importing another map format (.MAP) to my compiler, using brushes instead as polygonal soups aren't too friendly with a BSP compiler. I'm also on the fence about aiming for zero overdraw. 64x64 textures would probably reduce the framerate, so I stick with 32x32...for now. The solution would be to use a portal based engine like the Slavedriver engine, but making it fast is another story. The PVS solution is good enough, but it's not perfect and in some cases you could still get a ton of overdraw.
Another huge thing is dynamic lighting, but I couldn't think of a way to make it fast yet. And, of course, AI, gameplay, multiplayer, etc.
All in all, the Saturn is a super complicated console and poorly designed...but it's fun to mess with it trying to find super-complex solutions to problems that don't even exist on the PS1!
Visit http://segaxtreme.net for the latest news on this project, or join the Discord channel if you are interested in Saturn homebrewing!
Made in C, using the Sega Libraries (SGL/SBL) and my own engine.
Here is a SAGE 2018 preview of the demo I will submit in 2 weeks.
I will still tweek a couple of things like physics and maybe try to fix some of the quads being in the wrong orientation (long and boring work!)
I toyed with the idea of adding gouraud shading lightning to the level, but that will have to wait for another demo as I will focus on making the code faster.
It runs at a pretty stable 30 fps on real hardware, while splitscreen works mostly at 30 with some drops to 20 (because of v-sync).
The draw distance is impressing even myself, as you can see the whole level in Jade Gully when you're at the top!
About the water/fire animation : the Saturn doesn't support texture coordinates, and since I'm using 2 different color systems (16 colors LUT for meshes close to the camera and 256 color banks for the merged LOD meshes further away), with different levels of luminance, storing different textures would be hell.
So I found a solution that I'm quite happy with : double the texture's height, change the texture's starting address in vram and just increase it to scroll the texture. The results are that it's now possible to have ultra smooth animations (like 32 frames for a 32x32 texture) with low memory overhead and low cpu overhead (no DMA, just swapping some pointers) for any texture size (some merged textures are 8x8, others are 48x16, others are 128x64, etc.).
I just need to setup the texture flag and my converter will take care of the rest.
Running here in SSF emulator (on a keyboard, which is a bit hard!).
Maps are from Project AXSX with some modifications by me.
EDIT : In case you are wondering - yes, multiplayer will be in the demo. It's not shown here because it doesn't display properly in SSF. It's playable in Yabause in software mode, but has some glitches too.
//
Petit aperçu du démo de Sonic Z-Treme que je vais présenter lors du SAGE 2018.
J'ai encore du travail pour la physique et la présentation de certains niveaux, mais dans l'ensemble ça devrait ressembler à ça.
J'ai pensé ajouté de la lumière gouraud pour l'ensemble des niveaux, mais ça ira à une prochaine fois, je vais prioriser l'optimisation de mon code.
Le jeu fonctionne de manière assez stable à 30 images/seconde sur Saturn en mode 1 joueur alors qu'en multijoueurs ça peut descendre à 20 images/seconde (à cause du v-sync).
Le démo montré ici roule dans l'émulateur SSF.
Les maps proviennent du jeu "Project AXSX" avec quelques modifications.
I've added back entities, so now there are rings and ennemies all over.
I also quickly coded a global static lightning function in my converter using palettes.
It looks good enough, but it's free to render compared to gouraud lightning.
Also seen here is the new "Metal" shading : I'm actualy using a hardware bug to use gouraud shading on paletted sprites, which should be impossible according to official Saturn documentation.
I'm using red gouraud (LSB, so bits 0 to 4) and green gouraud (bits 5 to 9) to shift the palette.
By having non-linear increase in colors, you can create bump mapping and metallic effects.
This bug doesn't work well on emulators, only on real hardware.
The code isn't optmized yet, so there are some framerate drops. Also, I have some glitches with my view frustum that I will need to fix, and my collision code isn't spot on yet.
All the maps seen here were shared by Andrew75 and are straight from Project AXSX with some minor modifications by me to fit my own engine.
Coded in C using the Sega Graphic Libraries, running on stock Sega Saturn.
Ps : sorry for the bad filming, I didn't notice until it was too late!
I didn't have time to animate another model, so I'm using 2 Sonics for multiplayer.
Running on stock Sega Saturn hardware.
Vertex animation is super expensive in terms of memory, but thanks to a couple of tricks I made it quite low.
The vertices are compressed from 12 bytes to 6 bytes each, while the normals are compressed from 12 bytes each to 1 byte.
And I use linear interpolation to reduce even more the size.
Take the idle animation : it's actualy only 2 frames!
The interpolation is good enough that it gives the impression of smooth motion.
So all the animations seen here take a total of about 35 kilobytes, while they would take maybe over 1000 KB without compression and interpolation.
Vertex animation allows super complex animations without the hassle of having to decompose your model in multiple meshes and playing with matrixes.
So for a 1-man project like Sonic Z-Treme, it should allow good animation in little time, which is what I need!
The compressed normals do have a side effect that when you get near the side of a quad it might get culled away, but it's not that bad.
I might play with a few settings to improve it.
I'm still using per-vertex gouraud shading for realtime lightning as well.
This demo is running in Yabause emulator.
The Saturn got a pretty nice gouraud shading implementation.
I'm showing here a realtime gouraud shading test I did.
I tested it on real hardware too and the VDP1 could keep up with 7 models onscreen at 60 fps (more than 650 drawn quads), while the CPU struggled a bit (but it ran fine at 30 fps). I think I will aim for 30 fps in Sonic Z-Treme and add nice effects (I'm not satisfied with the look of the older builds, even if it does run really smoothly).
I still hope to make it out in time for SAGE 2018 with a new Sonic Z-Treme demo, but I still have so much to do that I start to think I won't have enough time. I might only make a really simple tech demo (kind of like what Sega did in 1996 with the boss engine demo).
Running on SSF, using SGL/SBL and my own Z-TREME engine SDK. The models are all from Sonic R PC version, but I didn't fully texture map them (Tails' tails aren't texture mapped and Metal Sonic's shoes use one color only). There are also some issues with Tails' hair as it's only using 6 quads with no backface culling, so the normals on one side are pointing in the wrong direction (the only alternative is to put backface culling and make it 12 quads instead, but I won't do it for such a small detail).
It runs mostly at 20 fps during splitscreen, with the same draw distance as in single player (which stays at 30 fps most of the time).
I'm quite satisfied with the performance, as I could just reduce the draw distance or stick to 20 fps (which is smooth enough since it's not interlaced).
The code also isn't optimized yet, so it can improve quite a lot in the future.
Don't mind the cheap sky, it's just a placeholder, I would need to have 2 sky effects (one for each player), which requires 2 VDP2 layers.
I show Galaxy Fortress mainly to show how the transparency effect looks when the background "fits" the level.
That transparency effect is "free" in terms of GPU power since the VDP2 is way faster than the VDP1, so the Saturn has no problem handling transparency on everything.
I had most of these features for a while, but I thought I could show them. I'm currently working on Sonic Z-Treme, making the engine more modular and putting new features. The Z-Treme engine's newer versions allow for better/easier use of the VDP2 and the Saturn sound CPUs (not seen here as it's an older version).
I'm coding the Z-Treme engine using the Sega Graphic Library, Sega Basic Library and of course my own functions.
This build seen here shows Sonic R-style transparency for fade-in/out. SGL doesn't support this, so I had to code my own functions.
I also coded splitscreen multiplayer about one month ago, I thought I could show it here.
Of course, the players' models are just a placeholder, untextured and without animations.
I had problems with SSF, so I'm using Yabause, which doesn't work that well (split screen just doesn't work with it in hardware rendering, so I'm using the software rendering, which is slower.
On real hardware, it should run between 20 and 30 fps with split screen multiplayer.
//
Nouvelle-vieille version de ma démo FPS pour Saturn.
Les modèles sont temporaires, le ciel aussi!
Je voulais seulement tester la transparence avec la VDP2.
C'est une vieille version de mon moteur, j'ai depuis commencé à tout porter vers une nouvelle version pour mettre à jour Sonic Z-Treme, mais je n'ai rien de "jouable" à montrer pour l'instant.
Ça fait environ un mois que j'ai le mode multijoueur, j'ai récemment ajouté un effet à la Sonic R pour la transparence.
Codé en utilisant SGL, SBL et bien entendu mes propres fonctions. SGL ne supporte pas l'effet fade-in/out avec la VDP2, alors j'ai dû me débrouiller autrement.
Je n'ai pas testé cette version sur une vraie Saturn, mais j'estime que ça devrait rouler entre 20 et 30 FPS.
As you can see, I got Saturn Quake maps running on stock hardware at 30 fps, with some small dips to 20 fps.
I still haven't coded a better view frustum culling function (so lot of polygons disappearing while on screen while a lot get processed for nothing) and there is a lot of overdraw (no hidden surface determination), which is bad.
Once I sort those, it might get close to 60 fps on stock hardware.
I'll stick to 30 fps, but advanced lightning effects might be possible.
Now, I'm NOT pretending my engine is better than the Slavedriver.
The real secret here is the mipmapping I'm using : while Lobotomy used 64x64 textures, I use 32x32 (except for the Saturn Quake intro level, where it's 64x64) and mipmap everything further than 512 units to 16x16 + merge quads (so some textures might be 64x16, some might be 128x64, etc.). I generate a whole lot of textures (600 to 1000) that I can keep in VRAM since I'm using 16 colors sprites (4 bits per pixel).
I also don't have as much going on (no AI, only 1 caracter to look for collision, etc.) and only depth gouraud shading for lightning, which makes it easier on the CPU.
Coded in C using the Sega Graphic Libraries 3.0 and Sega Basic Library, running on stock Sega Saturn using the 3D controller.
I upped the mipmapped textures' quality, which looks better.
There are glitches, such as quads dissapearing : that's because when the number of vertices gets close to 2500 (the SGL limit), it just stop processing everything.
The solution will just be to walk the octree from near to far, so only far objects will disappear.
Another solution, of course, is simply to use a portal or pvs system and only display what needs to be displayed.
On real hardware, currently the framerate is 30 fps most of the time, with dips to 20 fps, but these seem to be CPU related, which is fine since it's currently not optimized at all.
There is also an issue with some quads not being displayed when using the low-quality mesh. I've no idea what's creating this bug as the textures are fine, so it might take a while to find the problem and solve this.
The ingame resolution is 352x224, but I will switch to 352x240 later on (Quake on Saturn used 320x240)
I did a lot of stuff since my last public update.
Here is a short list of what is seen here :
-Octree for rendering and collision
-Per-quad collision (allowing levels such as Mario 64 Peach Castle to work, but I still need to fine tune it to make it smoother).
-Mipmapping (it doesn't look that great now, I might switch to 8 bpp or better hide it with gouraud shading, but it's all done in automatic).
-Level of Detail map auto-generation : it reduces the geometry quite a bit, especially in the Sonic X-Treme maps.
-4 bits per pixel images (using VPD1 Lookup table).
-Analog control support (as seen here).
-I'm now using the SGL math FIXED functions for more precision.
-And many other things...
It's running here on Yabause emulator. The 3D rendering and math functions are using the SGL library, while the audio (not heard here), CD functions and sprite memory management functions are done using Jo Engine.
For more info on this project : http://jo-engine.org
I also had to code special interactions using the map converter I coded. The 2 maps seen here are from Project AXSX, shared by Andrew75. I had to cut lot of stuff out to make it to 60 FPS, so the maps themselves don't look as great as they did in Project AXSX. I will continue to improve my engine to allow better drawing distance and more detailled maps. I also had to remove the previous RBG0 "ocean" because I didn't have time to code paletted sprites/images in my map converter to binary and I just didn't have enough RAM left for hardcoded images.
Anyway, here is the demo I sent to the Retro Barcelona . I also modified the diagonal code, which loses some momentum as you turn, but makes it more reliable than previous build when you would sometimes slow down and other times turn at full speed. I will play with Sonic's acceleration later on until I find the right balance between Classic Sonic movements and 3D requirements.
Running on SSF, for real hardware test (v. 0.32, which is a bit slower than the current build : youtube.com/watch?v=x7cW9wgIW00 ).
For the latest news on the project : jo-engine.org


