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 ... 9 10 [11] 12 13 ... 23
151
Project announcement / Re: Virtua Skimmer
« on: May 16, 2018, 04:00:22 am »
I tested it on real hardware, I tried with 7 models (around 180 quads per model) and the results are rather good, with 60 fps with 4 models, then the VDP1 can keep up, but the CPU doesn't. By not updating each frame, it might be possible to keep 60.

https://youtu.be/XapzA2yPEAU

152
Project announcement / Re: Virtua Skimmer
« on: May 15, 2018, 02:54:42 am »
And you also have to consider that the textures aren't included in the h file.

That being said, I just made a small update, I think I got the per-vertex normals right as the whole shading seems smoother now.
I did the update in less than 10 minutes, but it seems to work well.

I also added the vertex normals in the .h file, but I didn't try to see if it works.

I updated both the tool and the demo.


153
Project announcement / Re: Virtua Skimmer
« on: May 14, 2018, 11:53:17 pm »
In fact, the .h file takes the same amount of memory (it's in ASCII form, so it takes more memory, but after compiling, it's all binary).
But the most important thing is that it's not hardcoded, so you can load different models for different levels and all.

154
General Jo Engine Help / Re: Fixed Light Source?
« on: May 14, 2018, 11:36:45 pm »

155
Project announcement / Re: Virtua Skimmer
« on: May 14, 2018, 11:30:21 pm »
Ok, small update, I added realtime gouraud shading.

The per-vertex normals might not be 100% right, so the results might not be as smooth as what you get with the official Sega 3d tool.

Enjoy!

EDIT : I think I got the per-vertex normal OK, see the demo in newer posts.


156
Project announcement / Re: Virtua Skimmer
« on: May 14, 2018, 04:16:10 am »
Just to help you a bit with your project.

I made a model converter and binary loader, so you can use it to load your player and other entities.
It allows you to load multiple models and display them easily.
It should fix your memory issues if you use the binary files (ZTP).
It doesn't read the texture coordinates, so you need to either flip your quads yourself or flip the textures (a bit of a pain, but that's how the Saturn works sadly, with no texture coordinates).

For flat shaded quads, use a 8x1 texture, as my converter doesn't read the MTL file. I plan to transform these 8x1 textures to normal polygons (untextured) at a later time.
Make sure your images have no more than 16 colors and are saved as 32 bits TGA images (no RLE compression).

I might switch to FBX to allow animations and I'd like to add realtime gouraud shading someday, so for now it's just simple and dumb lightning, but anyway enjoy!

NB : The model converter is in the TOOL subfolder. The ZTI image converter is also there.


157
General Jo Engine Help / Re: Fixed Light Source?
« on: May 10, 2018, 01:30:24 am »
You could separate your mesh in different meshes, each mesh acting as a limb/bone. Then it's just a matter of pushing/poping matrixes to animate the meshes.
Another option you be to have 1 mesh, but store multiple vertices  (si you do something like myPDATA->pntbl = &point_array1).
The main issue with that is that each verticle takes 12 bytes, so you can imagine that it would take a huge amount of memory, but still less than having full meshes.

158
General Jo Engine Help / Re: Fixed Light Source?
« on: May 10, 2018, 01:05:39 am »
Yes, I recommand you use CLUT on every texture, it allows you to switch between gouraud and vdp2 effects easily.
On flat shaded quads you can easily use light effects. Look at the Akira3 SGL demo for a really nice effect (RB demo also looks great with realtime gouraud).

159
General Jo Engine Help / Re: Fixed Light Source?
« on: May 10, 2018, 12:28:25 am »
I'm not sure if that's sarcasm, but if not here is the link where RB explains it : http://www.rockin-b.de/saturn/saturngametutorial/SaturnGameTutorial.htm#useRealtimeGouraud

160
General Jo Engine Help / Re: Fixed Light Source?
« on: May 09, 2018, 08:56:34 pm »
You need to calculate the point.
See the SGL demos or RockinB's tutorial.

161
Project announcement / Re: Virtua Skimmer
« on: April 26, 2018, 01:58:09 am »
 Good job!
I'll try to give you a hand if I can find some free time.

Using the tool I made you should fix all your memory issues.
You probably allocate memory for sprites but don't clear it.
Also make sure your sprites are loaded from the disk, not hardcoded.

For the framerate, when you use "slSynch ()", it will wait unitl the end of the allocated time before rendering again, so it shouldn't be too fast nor too slow depending on your settings. The jo core run also calls slSynch at the end of each loop.
You can try different settings (like your speed increases x units * nb of frames).
Make sure your emulator also has its frame limiter option on.

For the vdp2 effect you want, it involves using line scrolling.
I never tried it yet myself, but I think there is one SGL demo using it.

For collisions, you can simply use a bounding box or sphere and use the quads' normals to calculate where it should push you.

You will need a basic spatial subdivision for that (a grid is the easiest choice and what I would suggest you to try).

162
Project announcement / Re: Sonic Z-Treme
« on: April 22, 2018, 11:08:32 pm »
Here it is running on real hardware.
I'm quite happy with the results as it's not optimized.

https://youtu.be/Bkpy5MdjM8I

163
Project announcement / Re: Sonic Z-Treme
« on: April 21, 2018, 03:56:24 pm »
Well, gouraud shading works well for fade in/out as long as the color fits the backscreen.
I'm using a NBG0 bitmap layer, but with splitscreen managing the backgrounds gets a bit complicated.

164
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.

https://youtu.be/r4Gkgqitv44

165
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]
//HEADER
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
} _MOD_DATA;

//TEXTURE DATA
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));
            ii+=2;
        }

    }
    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));
        }
    }
}


//PDATA
/*****
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++)
        {
            //Normals
            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));
            }
            //Vertices
            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));
            bUint16=swap_endian_ushort(TextureAttributeArray[mesh_array[i].attbl[ii].texno].texno);
                file->write((char*)&bUint16, sizeof(unsigned short));
            bUint16=swap_endian_ushort(TextureAttributeArray[mesh_array[i].attbl[ii].texno].atrb);
                file->write((char*)&bUint16, sizeof(unsigned short));
            bUint16=swap_endian_ushort(TextureAttributeArray[mesh_array[i].attbl[ii].texno].colno);
                file->write((char*)&bUint16, sizeof(unsigned short));
            bUint16=swap_endian_ushort(TextureAttributeArray[mesh_array[i].attbl[ii].texno].gstb);
                file->write((char*)&bUint16, sizeof(unsigned short));
            bUint16=swap_endian_ushort(TextureAttributeArray[mesh_array[i].attbl[ii].texno].dir);
                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!


Pages: 1 ... 9 10 [11] 12 13 ... 23
SMF spam blocked by CleanTalk