Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - XL2

Pages: [1] 2 3 ... 12
Project announcement / Re: Sonic Z-Treme
« on: April 20, 2018, 05:14:51 pm »
Just a small update to show the Sonic R-style fade in/out.

Jo Engine Wish List / Re: 3D Textured Mesh Sample
« on: April 16, 2018, 10:50:24 pm »
No demo yet, so make sure you follow the explanations (text I posted earlier today at Segaxtreme) :

I got the model converter I promised you working at pretty much 70-80%, but I didn't have time to test it nor write a demo.
It seems to be ok, but since I didn't test it, I can't guarantee it.
IT'S ALSO REALLY QUICKLY CODED! I made it in like 2 hours and only did small tests, so it might not work properly.

I'm sharing it with you now, but I guess without a demo it might be a bit hard to use.
The file starts with a header portion of 36 bytes, then writes the texture data, then the polygon data.
I added the header and the code to know how I write to the binary file so that you know what to load.
You can use the image converter I posted elsewhere to know how to load the paletted textures.
The program also outputs a text file including all the PDATA, but no textures, so you can also play with that.
Please note that it only supports textures, so if you want to load a flat shaded polygon, you can use something such as a 8x1 texture with 1 color. I guess it would be a bit slower than using a real flat shaded quad, but I don't think I will have time to modify my code to allow it for now.

Code: [Select]
typedef struct
    unsigned short  TOTAL_MESH; //total amount of PDATA
    short            TOT_TEXT;  //total amount of textures
    unsigned int    TEXT_SIZE;  //to quickly load from disk, that's the size of the textures in bytes
    unsigned int    PDATA_SIZE; //to quickly load from disk, total size of pdata in bytes
    vector3 Origin; //Origin point used to "center" the culling/collision data and your model's position. Should be 0,0,0 unless you have an offset
    vector3 Length;  //Lenght along the x,y z axis. Together with the origin, that gives you the bounding box for quick broad collision testing

unsigned short convert_to_4bpp(unsigned short a, unsigned short b){    return (((a&0xffff)<<4) | (b));}

void WRITES_TEXTURES(ofstream * binFile)
    cout << "Writing the textures to binary file...\n\n";
    unsigned short buf16;

    for (short i=0; i<MODEL_DATA.TOT_TEXT; i++)
        unsigned short w = swap_endian_ushort(pimg[i].width);  //pimg == paletted image
        unsigned short h = swap_endian_ushort(pimg[i].height);
        binFile->write((char*)&w, sizeof(unsigned short));
        binFile->write((char*)&h, sizeof(unsigned short));
        binFile->write((char*)&MODEL_DATA.TEXT_SIZE, sizeof(int));

        for (short ii=0; ii< (pimg[i].width * pimg[i].height);)
            unsigned char buf = 0;
            buf =  (unsigned char) convert_to_4bpp(pimg[i].palette_id[ii], pimg[i].palette_id[ii+1]);
            binFile->write((char*)&buf, sizeof(unsigned char));

    for (short i=0; i<MODEL_DATA.TOT_TEXT; i++)
        for (unsigned int ii=0; ii<16; ii++)
           buf16 = swap_endian_ushort(pimg[i].palette[ii]);
           binFile->write((char*)(&buf16), sizeof(unsigned short));

This writes all the PDATA in a sequential order
void WRITE_PDATA(ofstream * file)
    unsigned short bUint16;
    unsigned int bUint32;
    int bSint32;

    for (unsigned int i=0; i<MODEL_DATA.TOTAL_MESH; i++)
        //PDATA, including buffers for the pointers
        bUint32 = 0;
            file->write((char*)&bUint32, sizeof(unsigned int));
        bUint32 = swap_endian_uint(mesh_array[i].nbPoint);
            file->write((char*)&bUint32, sizeof(unsigned int));
        bUint32 = 0;
            file->write((char*)&bUint32, sizeof(unsigned int));
        bUint32 = swap_endian_uint(mesh_array[i].nbPolygon);
            file->write((char*)&bUint32, sizeof(unsigned int));
        bUint32 = 0;
            file->write((char*)&bUint32, sizeof(unsigned int));

        //POINT (vertices), 12 bytes each
        for (unsigned int ii=0; ii<mesh_array[i].nbPoint; ii++)
            for (unsigned int j=0; j<3; j++)
                bSint32 = swap_endian_sint(mesh_array[i].pntbl[ii][j]);
                file->write((char*)&bSint32, sizeof(int));
        //POLYGON, 12 bytes for normals and 8 bytes for vertices
        for (unsigned int ii=0; ii<mesh_array[i].nbPolygon; ii++)
            for (unsigned int j=0; j<3; j++)
                bSint32 = swap_endian_sint(mesh_array[i].pltbl[ii].norm[j]);
                file->write((char*)&bSint32, sizeof(int));
            for (unsigned int j=0; j<4; j++)
                bUint16 = swap_endian_ushort(mesh_array[i].pltbl[ii].Vertices[j]);
                file->write((char*)&bUint16, sizeof(unsigned short));
        //ATTRIBUTES, 12 bytes each
        for (unsigned int ii=0; ii<mesh_array[i].nbPolygon; ii++)
            file->write((char*)&TextureAttributeArray[mesh_array[i].attbl[ii].texno].flag, sizeof(unsigned char));
            file->write((char*)&TextureAttributeArray[mesh_array[i].attbl[ii].texno].sorting, sizeof(unsigned char));
                file->write((char*)&bUint16, sizeof(unsigned short));
                file->write((char*)&bUint16, sizeof(unsigned short));
                file->write((char*)&bUint16, sizeof(unsigned short));
                file->write((char*)&bUint16, sizeof(unsigned short));
                file->write((char*)&bUint16, sizeof(unsigned short));

So, you can use something such as GFS_LOAD starting with 36 bytes to know what the file contains, then read the textures (just put it in low-work RAM), DMA everything to VRAM where it belongs and then overwrite the data in low-work RAM with the PDATA (since the textures are transfered, you don't need them in work-RAM, so just overwrite them).
For the textures, make sure you do it per face instead of using texture coordinates.
The converter I wrote only supports 16 colors per texture, but save your TGA files as 32 bits files. The alpha channel is treated as transparent.
I'll see what I can do for the demo, but I'm a bit busy with work so I might not have time. Let me know if you encounter bugs!
I added the title map from Quake as a demo, but this tool isn't meant for maps since it doesn't do map partition nor does it hold data for culling!

Project announcement / Re: Sonic Z-Treme
« on: April 14, 2018, 10:56:08 pm »
These games use the color calculation  (with ratios) to make a smooth fade in and fade out. It's what I'm doing now. It might be possible with CLUT sprites too, but I have to try a few more things first. But the only way to do actual gouraud shading on color bank sprites requires a ton of color RAM, but you only have 4 KB shared for all the background layers and the color bank sprites.
High res mode is attractive, but you can't simply flip a switch and make it work. You really need to setup everything in a specific way and there are many limitations.
I could try it for menus and such, but even for that I don't want to waste time on it.

Project announcement / Re: Sonic Z-Treme
« on: April 14, 2018, 05:24:09 pm »
The flat shaded quads in SGL can use flat lightning both in RGB and palette format.
I'm not using the SCU DSP yet, so it's SH2 only.
I can't do realtime light with color bank sprites, but I'm now doing like in Sonic R and Bulk Slash.

I can't use the high res mode, it's super hard to setup, so I don't want to waste time on it.

Project announcement / Re: Sonic Z-Treme
« on: April 12, 2018, 03:12:18 pm »
I just did a small video (it's not public as there isn't much to show) for the split screen mode and the removal of gouraud shading/use of CRAM sprites.

Project announcement / Re: Sonic Z-Treme
« on: April 11, 2018, 03:08:26 pm »
The way they did it in the Chrome demo is that they use a palette of different luminances.
The VDP1 does the gouraud shading processing, but when it's using paletted sprites it just offsets an index instead of the actual RGB color.
So the result is that by using only red gouraud processing you will exactly offset +- 1 to 16 in each direction for each verticle.
You could do it with 16 colors banks, but then you could only do it with one color and only 7-8 different luminances, else it will overflow.

I could do like Sonic R, but I could also just put static lightning on the textures.
The issue with Sonic R is that you have gouraud on quads close to the camera, then you lose that luminance as it starts disappearing.
I have enough VRAM left to generate other textures for luminance.
From the videos of Saturn Shenmue, it seems to be what they did.
Speaking of Saturn Shenmue video, I noticed lots of triangles in the background (they get clipped out). So I'm not sure if it's running on a real Saturn or if it's using software rendering for backgrounds.

Project announcement / Re: Sonic Z-Treme
« on: April 10, 2018, 11:55:57 pm »
Haha, just using the SCU DSP would be a great start!
It has really limited memory, so it can't do that much.

Update on the project, I've now moved from 16 colors Lookup tables to 16 color bank (CRAM). That means no more gouraud shading...but I will be able to use transparency, which is better.
I'm not sure if you can do color calculation over the back screen, but if you want the same effect as depth gouraud shading you can just put a black background and use the VDP2 transparency to have the same effect.
It also offloads work from the VDP1.
The only issue is that the color RAM is really limited, but so far it seems all the maps I tested got everything within about 1000 colors, and if it can't fit in CRAM I put a "safety" measure where it just uses CLUT.

I haven't made much progress on Sonic Z-Treme yet, so the game is currently improving only on a technical level, but I hope to be able to integrate everything in the game soon.

General Jo Engine Help / Re: Audio issues - repeating/skipping
« on: April 08, 2018, 01:39:49 am »
I hope you didn't give up on your project, but using the tone editor on a mac emulator you could load your audio to the audio RAM, avoiding the PCM DMA transfer, which should fix your issues.
It's quite complicated to setup, but I can help you with it.

Project announcement / Re: Sonic Z-Treme
« on: April 07, 2018, 02:49:50 pm »
You can issue program change commands, but I highly doubt it can process programs in parallel.

Project announcement / Re: Sonic Z-Treme
« on: April 07, 2018, 12:02:21 pm »
Good idea for the SCU DSP.
If that's what Burning Ranger does, the entire code could be retrieved with Yabause.
But I thought they used it for lightning.
You can see when there is voice audio playback if the SCU DSP gets a program change.

Project announcement / Re: Sonic Z-Treme
« on: April 06, 2018, 04:27:30 am »
The overhead is, I guess, for the main SH2, since it get decompressed by the SH2, then it's no different from uncompressed audio once it's transfered to the audio RAM.
It could be that the SBL library isn't super efficient, but even for uncompressed audio it's still expensive to use PCM (even if it's "just" 5%.
And more importantly it hogs the B bus, which is the same bus used for the vdp1 and vdp2.
For the DMA, it's always SCU DMA on the b bus.

CD audio goes straight to the DAC, so it doesn't consume cpu power (the SH1 can't be used for anything else than loading). It's the easiest option.

Then sequence audio is great as well, you have the SCSP and the M6800 just for doing that, it has it's own RAM, it can playback PCM data (from its own memory), so it doesn't consume cpu power except for transfering the play commands. It's a bit tricky to use, but for fx sounds it's a no brainer.

PCM audio from CD is good to play voices or play music while loading data, but it should be avoided as much as possible.

PCM audio from memory is easy to use and convenient for that, but it really should be avoided.

I don't know if it's possible to keep data in the CD buffer, so that you could store 512 KB of PCM data in that RAM, but it would be a good option (if possible) to at least save some main RAM if you have to use PCM memory playback.

I would really like to use MIDI audio as it's the more flexible option and keep the CD available, but it's also the hardest to use.

EDIT : The program I mentionned which converts sequences to MIDI. Now we need to figure out how to do the other way around!

Project announcement / Re: Sonic Z-Treme
« on: April 05, 2018, 05:02:18 am »
But if anyone wants to do it, it would be more than welcome for the whole community!
I need to finish the model converter I promised and continue working on the engine for a long overdue update.

Edit : Just added an image of PCM-ADPCM CPU overhead. Note that playing small sounds from memory is less expensive since you don't need to transfer data from the CD, but it still requires DMA and hogs the B-Bus.

Project announcement / Re: Sonic Z-Treme
« on: April 05, 2018, 12:41:09 am »
Yes, but the idea would be to write an app to do this. I would certainly take a while, but on another forum someone sent me an app that converts sequences to midi, so I would need to do the opposite.

Project announcement / Re: Sonic Z-Treme
« on: April 05, 2018, 12:29:35 am »
Yes, I will mix both.
So for menus or title screen, I might use ADPCM to allow loading in the background and keep some space on cd.
I will use normal  cd audio for ingame for now, but using midi audio would be nice as well.

Project announcement / Re: Sonic Z-Treme
« on: April 04, 2018, 08:27:27 pm »
Ok, using SBL and the Tone Editor on my Mac emulator, I got audio played from Audio RAM working.
You need to create a bank with the "voices" you want (using AIFF PCM files) and create a map file.

On the Saturn, you load the sound driver and the map data.

For the map file :
Byte 0 : MSB at 0 = used, bits 6,5 and 4 are for the type, with 0 being tone data, 1 for a sequence. The next 4 bits are the bank ID number (so 0 to 15).
Bytes 1, 2, 3 : Last 4 bits of byte 1 and the remaining bits are for the adress of the tone in memory.
Byte 4 : MSB is 0, the rest seems unused.
Bytes 5 to 7 : size of the tone data.
You then need to use end codes for the area map and for the global map : so 0xff and another 0xff.
You could put a couple of map info for more than 1 bank.

Code: [Select]
char sound_map[]= {0x00,
0x00, 0xb0, 0x00, //Start adress
0x00, //except for the MSB, seems unused
0x05, 0x61, 0x22, //size of the tone data
0xff, 0xff //end code

That means my sound data takes 352 546 bytes (all at 11,025 khz, mono, 16 bits - using 8 bits would halve that).
The map can include sequences, but I couldn't get the tools working on the Mac emulator, so I use Midi direct commands to the sound driver.

You need to load your tone data in the sound RAM using the offset 0xb000.

Now, to playback the audio, here is the function I wrote :

Code: [Select]
void TEST_AUDIO(Uint8 nb)  //Nb = number, both for voice and channel
   SND_CtrlDirMidi(0x02, 0x00, 0x03, nb, 0x20, 0x00);  //Bank change. Not needed if you have only 1 bank
   SND_CtrlDirMidi(0x02, 0x00, 0x04, nb, nb, 0x00);  //Voice change. That's the sound you want to play (16 values max)
   SND_CtrlDirMidi(0x02, 0x00, 0x00, nb, 60, 127); //Stop playing the previous sound on the passed channel. It will stop playing at the end anyway, BUT that channel will remain flagged as used if you don't clear it)
   SND_CtrlDirMidi(0x02, 0x00, 0x01, nb, 60, 127); //Start playing the current sound on the passed channel

Sadly it would take a while to study the tone data file in order to recreate a tool on PC to do all that.
The tone data includes stuff like the pitch and loop data.
For the pitch, I put it at 84 (for 11,025 khz) on the tone editor, so I put it at 60 (44,1 khz) for the Midi direct command so that it plays it at the correct speed.

I could probably also check at v-blank which channels are done playing the sound to clear them, it would make it easier to manage the channels.

Pages: [1] 2 3 ... 12
SMF spam blocked by CleanTalk