(Homebrew) Sonic Z-Treme

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

  1. XL2

    XL2 Active Member

    Joined:
    Jul 20, 2017
    Messages:
    39
    Likes Received:
    96
    I'm already collaborating with Andrew75, he shared with me some levels from AXSX. As for the code, it's useless to me since you just can't make Unreal Engine script work on the Saturn, plus all the optimisation they don't need on a quad-core 3 Ghz CPU vs the Saturn's 28 Mhz dual CPU. The Saturn Sonic X-Treme build is useless as well since it has poor performance. I am considering fisheye lens, but that would pretty much be the last thing on my list. The rotating camera I have is working well and I think most people will prefer it to fisheye. If I find a way to implement it without much impact on the framerate, I might, but that will be much later on.

    For the water not being animated, you can see a previous build on Z-Treme with animated water on my first post here. I haven't implemented it in my last build since I want to auto-generate animated textures using my map converter, but I also want to generate paletted 4 bits sprites to use special effects (mainly the smooth fading effect to hide pop-in/out, which only works on paletted sprites I think).
    As for the Sonic sprite, that's a big no, since I already got the 3d model working, animated and all. I have no reason to downgrade to a 2d sprite.

    I might lower the framerate to 30 fps at one point since I like using gouraud shading and lighting effects and I'm not sure if I can optimize my engine enough for stable 60 fps on project AXSX maps.
     
  2. Anthaemia.

    Anthaemia. The Original VF3 Fangirlâ„¢

    Joined:
    Jun 4, 2004
    Messages:
    1,616
    Likes Received:
    143
    I wasn't aware that you'd already collaborated with Project AXSX, and I certainly wasn't suggesting you try porting elements made in UE to the Saturn - that would definitely be unreal to expect! If anything, I was more referring to the possibility that Andrew75 could provide you with original code from the builds produced by Chris Senn and Ofer Alon that featured animated elements or the fish eye lens effect. However, it seems you're looking to experiment with these later into development, though I do like your own rotating camera system as an alternative. In terms of your work being more faithful to the intention of STI, using Ross Harris' sprites would make this closer than a polygonal model for Sonic. On the other hand, it would be great if someone could extract the mesh from a leaked development kit, as I believe this was the same being used during the Project Condor era. At the very least, it seems to exploit the same hardware rendering trick for generating curves, which Christina Coffin described as a workaround method for drawing rounded surfaces... I wouldn't be surprised if Peter Morawiec employed a similar approach for the abandoned Sonic Pool bonus stage concept along with his own proprietary "Sphere Renderer" technique.
     
  3. XL2

    XL2 Active Member

    Joined:
    Jul 20, 2017
    Messages:
    39
    Likes Received:
    96
    Yeah, I did consider using the SDK model, but it has more quads and vertices than the Sonic R model. I think the Sonic R model also looks better, but in any case Sonic is like 60 pixels tall, so it's hard to notice details, making the lower polycount better.
    I have yet to add gouraud shading on Sonic, depending on the performance I get once everything else is working I might add it.
     
  4. Anthaemia.

    Anthaemia. The Original VF3 Fangirlâ„¢

    Joined:
    Jun 4, 2004
    Messages:
    1,616
    Likes Received:
    143
    Would implementing Gouraud shading have such an impact on performance? I'd have thought the fish eye lens effect would be more taxing on hardware, though I wouldn't complain if you had to reduce the frame rate to 30fps as long as the controls don't take too much of a hit.
     
  5. XL2

    XL2 Active Member

    Joined:
    Jul 20, 2017
    Messages:
    39
    Likes Received:
    96
    The fisheye is taxing on the CPU, while gouraud shading (not realtime) is taxing for GPU. According to Sega's documentation, gouraud shading add something like 300 cycles to draw a quad. A textured 16x16 quad without gouraud takes something like 918 cycles, vs 70 for a flat shaded quad. So it's cheaper to draw a flat shaded polygon than anything else, but an untextured gouraud shaded quad is cheaper than a textured quad.
     
  6. itsthinkingstil

    itsthinkingstil Rapidly Rising Member

    Joined:
    Nov 9, 2014
    Messages:
    77
    Likes Received:
    60
    Just want to say im very sorry for making that new thread, never realized we already had one on here :D (Not sure how you delete a thread when its locked)

    here is the update if anyone is curious

    Running on real hardware


    Emulated
     
    AUSTIN PEYTON likes this.
  7. XL2

    XL2 Active Member

    Joined:
    Jul 20, 2017
    Messages:
    39
    Likes Received:
    96
    So I tried something, but it didn't work out too well so far, so hopefully someone can suggest me something to speed up the whole process before I just move on to another technique (I keep rewriting the collision and rendering part of the game, so I'm getting used to it!) :
    I imported Quake maps in my engine for testing, and I subdivided all the maps in grids and planes (in other words, you have tiles of quads, but these quads all face the same direction and they are all located in the same grid-square from the global map coordinates).
    But this subdivision duplicates several vertices since it's how it works with SGL, to the point where it's be too much for the Saturn and it's too much for the default SGL workarea.
    Long story short, I tried to generate the PDATA (the 3d mesh) on the fly by using essentialy lookup tables to determine if a verticle is already used, and change the quad's vertices reference with that lookup table.
    The number of processed vertices is reduced a lot, but the whole process is much slower (which was expected, but not that bad).
    I guess there might be a way to speed it up by making better use of the CPU cache or find a way to make DMA practical (it's not right now, with nothing larger than 12 bytes).
    Now, I'm considering to revert back to the old technique of just using static PDATA and hope that with better hidden surface determination I can keep everything to managable levels, but I will still try a few more things before fully ditching the current technique.
    Sorry if the code isn't easy to read, I keep rewriting it so I didn't care too much about how readable it is.
    Here is the code :
    Code:
    void COPY_POINT(POINT source, POINT dest)
    {
       dest[X]=source[X];
       dest[Y]=source[Y];
       dest[Z]=source[Z];
    }
    
    void ADD_POINT(unsigned short i)
    {
       COPY_POINT(VDATA.pntbl[i], LevelMesh.pntbl[LevelMesh.nbPoint]);  //Copies the vertices from the global list to the generated PDATA
       VDATA.WRAM_LUT[i]=LevelMesh.nbPoint;  //The indexed value where the vertices are stored
       ++LevelMesh.nbPoint;
    }
    
    void COPY_PDATA(unsigned int i)  //It's called for each plane after culling out those not needed
    {
       register unsigned int T;
       short *WRAM_LUT=VDATA.WRAM_LUT;  //The lookup table for indexing vertices
       _QDATA * curQuad = QDATA[i];  //The quad data, containing the texture id and the quads' 4 points (pointing to the global vertices list)
       POLYGON * curPol;
       unsigned short * curVert;
    
       FIXED curNorm[XYZ];
       curNorm[X] = PLANE[i]->norm[X];  
       curNorm[Y] = PLANE[i]->norm[Y];
       curNorm[Z] = PLANE[i]->norm[Z];   //I keep the normals per plane to reduce RAM usage
    
       for (T=0; T<QDATA[i]->nbPolygon; ++T)
       {
           curVert= curQuad->Vertices[T];
           curPol = &LevelMesh.pltbl[LevelMesh.nbPolygon];
    
           if (WRAM_LUT[curVert[0]]== -1)            ADD_POINT(curVert[0]);
           if (WRAM_LUT[curVert[1]]== -1)            ADD_POINT(curVert[1]);
           if (WRAM_LUT[curVert[2]]== -1)            ADD_POINT(curVert[2]);
           if (WRAM_LUT[curVert[3]]== -1)            ADD_POINT(curVert[3]);
    
           curPol->Vertices[0] = WRAM_LUT[curVert[0]];
           curPol->Vertices[1] = WRAM_LUT[curVert[1]];
           curPol->Vertices[2] = WRAM_LUT[curVert[2]];
           curPol->Vertices[3] = WRAM_LUT[curVert[3]];
    
           curPol->norm[X] = curNorm[X]; curPol->norm[Y] = curNorm[Y]; curPol->norm[Z] = curNorm[Z];
           LevelMesh.attbl[LevelMesh.nbPolygon]=ATTRIBUTE_LIST[QDATA[i]->Texture_ID[T]];
           ++LevelMesh.nbPolygon;
       }
    }
    
     

    Attached Files:

    Last edited: Jan 2, 2018
  8. Saimon69

    Saimon69 Retro Bedroom Musician also known as J.M.D.

    Joined:
    Jan 8, 2018
    Messages:
    5
    Likes Received:
    0
    Hey xl2, i did create an account also here on assemblergames so to have a reliable communication platform with you!
    so couple weeks ago i did left a message on youtube where i was offering to do musics for the game and xl2 told me was planning to use the sound chip rather than redbook audio to save RAM; i did ask him what tools could i use to create music on saturn, since i usually work on mod/xm and if use xm for music was a possibility.
    from another old thread in SegaXtreme i learned that saturn can use up to 512k for music so i think that an xm file with 8 bit samples would be more than fitting, but i still don;t know whether there is a mod/xm replayer code usable on saturn and how processor intensive is.
     
  9. XL2

    XL2 Active Member

    Joined:
    Jul 20, 2017
    Messages:
    39
    Likes Received:
    96
    Hi!
    Sadly I don't know much about the audio on Saturn other than PCM and Redbook audio.
    The Saturn has 512 Kb of audio RAM, but it is my understanding that for PCM it can only be used as a buffer, meaning that the PCM data needs to be transfered (SCU or CPU DMA) each time, which also takes cpu cycles to process when all this could be handled by the audio cpu and RAM, which is why it's a better option.

    You can take a look at the Saturn documentation for more info about audio : https://antime.kapsi.fi/sega/docs.html
    There are also examples with SaturnOrbit for both SGL and SBL, but here again I never went too deep about audio.
    The official Saturn programs for audio were for Mac, which used a PowerPC cpu back then.
    So unless you have an old Mac or some emulator, it won't be possible to use these programs, but it would really be the easiest way.
    I hope this helps a little bit!


     
    Last edited: Jan 8, 2018
  10. Saimon69

    Saimon69 Retro Bedroom Musician also known as J.M.D.

    Joined:
    Jan 8, 2018
    Messages:
    5
    Likes Received:
    0
    I am talking about tracker formats, mod or xm;(works in a similar way to a .mid file but with samples and effects included) is there any replay routine for saturn?
     
  11. XL2

    XL2 Active Member

    Joined:
    Jul 20, 2017
    Messages:
    39
    Likes Received:
    96
    Sadly I don't know and know next to nothing about audio, but try reading this document, you would probably understand it better than I could :
    https://antime.kapsi.fi/sega/files/ST-081-R5-062894.pdf

     
  12. Saimon69

    Saimon69 Retro Bedroom Musician also known as J.M.D.

    Joined:
    Jan 8, 2018
    Messages:
    5
    Likes Received:
    0
    So far i haven't found any practical solution to use the sound chip; i guess i can only provide music as redbook audio unless technical advancements ( a xm/mod replayroutine or deflemask support) comes along :(
     
  13. vbt

    vbt Spirited Member

    Joined:
    Mar 17, 2007
    Messages:
    111
    Likes Received:
    14
    You can play tone, sequence, pcm, adpcm, aiff on saturn and naturally audio tracks.
    You can compose music using the tone editor for mac. I tried to use it to emulate ym2151/ym2203 FM part directly on the SCSP with low success.
    maybe you could help me to use that tool, in that case i can provide a working environement on PC.
    algo.jpg tone_editor.jpg
     
  14. Saimon69

    Saimon69 Retro Bedroom Musician also known as J.M.D.

    Joined:
    Jan 8, 2018
    Messages:
    5
    Likes Received:
    0
    hmm, am usually just a tracker composer so that thing look a bit alien to me; explain me, is that just the instrument definition screen?
     
  15. Saimon69

    Saimon69 Retro Bedroom Musician also known as J.M.D.

    Joined:
    Jan 8, 2018
    Messages:
    5
    Likes Received:
    0
  16. MBMM

    MBMM Powered by Pied Piper

    Joined:
    Aug 19, 2013
    Messages:
    2,432
    Likes Received:
    401
    You definitely have my interest with this project. I'm excited to give it a shot and I'm looking forward to hearing any updates and advancements.
     
  17. XL2

    XL2 Active Member

    Joined:
    Jul 20, 2017
    Messages:
    39
    Likes Received:
    96
    Here is an update on this project - or I should say on the engine since I didn't touch Sonic Z-Treme for a while - to show per-quad collision (I still need to work on it to make everything smoother).
    But maps don't need to be blocky anymore like the Sonic X-Treme maps, which opens up lot of possibilies.
    I almost fully rewrote the engine, I'm now using 4 bits sprites everywhere (except weapons), I added an octree for rendering and collision, wrote a new collision function, wrote an automatic mesh reduction (for LOD on distant objects) and now support the 3D pad (it wasn't even documented anywhere, I found by trial and errors that the dummy1 Uint16 variable is actualy the right trigger). I also switched all the maths functions to SGL FIXED format since they are more precise.
    For the graphics part, I'm using SGL only, while I use Jo Engine for the CD functions and audio.
    I still haven't coded a proper PVS or portal, so the overdraw can be huge, which is bad of course, and I also need to generate textures for LOD objects, which I plan to work on next.

    Here are 2 testing maps :

    Peach Castle from Super Mario 64 DS - I didn't try to fix the geometry other than using Blender's auto triangles-to-quads and subdividing everything once - with an earlier version of the collision and rending code (lot of clipping, I need to ditch the SGL slCheckOnScreen function as it's terribly inaccurate).


    Saturn Quake E1L1, converted with NOESIS to Wavefront .OBJ, then put on Blender to remove the doors (since my engine doesn't support them yet) and then converter with my newer version of my map converter to my engine.
    I'm not done on the updates I want to do - so no source code for now.

    PLEASE TAKE NOTE : The textures seem weird - with poping as they get closer to camera. That's because I haven't coded the texture generation for the merged quads (LOD) yet, so it's just stretching one of the textures from one of the merged quads, and applies it to the whole quad. I will work on that feature within the next few weeks, which will also allow mipmapping (done offline, obviously).
     
    Last edited: Feb 13, 2018
  18. XL2

    XL2 Active Member

    Joined:
    Jul 20, 2017
    Messages:
    39
    Likes Received:
    96
    Small update, showing the results of the texture generation for the low-quality model + mipmapping.
    It still has some issues, but I can confirm that it runs between 20 and 30 fps on real hardware, with slowdowns being CPU related as far as I know (which is fine, since I'm not even using the octree yet for rendering, which will speed things up quite a bit).

     
  19. 8bitplus

    8bitplus Gutsy Member

    Joined:
    Feb 25, 2008
    Messages:
    423
    Likes Received:
    29
    Very good. I love seeing how this engine is developing. Amazing skills you have there.
     
  20. XL2

    XL2 Active Member

    Joined:
    Jul 20, 2017
    Messages:
    39
    Likes Received:
    96
    Here is an update to show the results on real hardware.
    As you can see, it's mostly 30 fps, with some drops to 20.
    I still haven't coded a better view frustum function (I'm using the SGL function, which is terrible for FPS), so lots of quads disappear as you get close.
    I also don't have a proper hidden surface determination, which causes lot of overdraw, so I lower the draw distance for now.

     
    AUSTIN PEYTON and pwl like this.

Share This Page