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
Jo-Engine release / Re: Release 9.0
« on: August 12, 2017, 06:46:18 pm »
Can't wait to try it!

Share your code / Re: Collision BB generator (WIP) + FPS demo
« on: August 10, 2017, 03:49:28 pm »
Huge update!
The map tool now reads .Obj files and outputs a binary map format.
The FPS demo is now using this map format and you can change maps by reading them on the disk.
Just press L/R + start in game to switch maps.

I still have lot of work to do on the tool and there might be bugs that I didn't find out yet, so if you find any make sure to tell me!

The good folks at SegaXtreme helped with it, and it was an issue with data alignment.
Seems to be fixed for now!
I will update the tool and FPS demo in the next few days to show map loading from the disc.

Great! Thanks!

I know the topic is now in "Wish list", but I could need some help.
Bad news ; while the binary mesh loading works in Yabause, in SSF it's a real mess (but works with lower compatibility) while on real hardware it doesn't work at all (it crashes before even loading anything).
It's probably a mistake related to memory allocation or initalization, but I have no idea what's wrong at the moment.
I've attached the files, if anyone with better knowledge of memory allocation could look it up, I would really appreciate!

Code: [Select]
//Start address is 0x00200000

void * LoadBinaryMAP(void * startAddress)

 char * stream;
 void * currentAddress;
 int length;
 mesh_tot = 0;
 stream = jo_fs_read_file("MAPT.ZTM", &length);

register unsigned int idx = 0;
register unsigned short i=0;
register unsigned int ii=0;
register unsigned int iii=0;
register unsigned int nbpoint=0;
register unsigned int nbpolygon=0;

currentAddress = startAddress;

mesh_tot = jo_swap_endian_ushort(*((unsigned short *)(stream)));

for (i=0; i<mesh_tot; i++)
    jo3dMesh[i] = currentAddress;
    nbpoint = jo_swap_endian_uint(*((unsigned int *)(stream+idx)));
    nbpolygon = jo_swap_endian_uint(*((unsigned int *)(stream + idx)));

    jo3dMesh[i]->data.pntbl = (POINT*)(jo3dMesh[i] + sizeof(unsigned int));
    for (JO_ZERO(ii); ii<nbpoint; ii++)
        for (JO_ZERO(iii); iii<3; iii++)
            jo3dMesh[i]->data.pntbl[ii][iii] =  jo_swap_endian_int(*((int *)(stream + idx)));
    jo3dMesh[i]->data.pltbl = (POLYGON*) (jo3dMesh[i]->data.pntbl + sizeof(POINT)*nbpoint);
    for (JO_ZERO(ii); ii<nbpolygon; ii++)
        for (JO_ZERO(iii); iii<3; iii++)
            jo3dMesh[i]->data.pltbl[ii].norm[iii] = jo_swap_endian_int(*((int *)(stream + idx)));
        for (JO_ZERO(iii); iii<4; iii++)
            jo3dMesh[i]->data.pltbl[ii].Vertices[iii]=jo_swap_endian_ushort(*((unsigned short*)(stream + idx)));
    jo3dMesh[i]->data.attbl = (ATTR*) (jo3dMesh[i]->data.pltbl + sizeof(POLYGON)*nbpolygon);

    for (JO_ZERO(ii); ii<nbpolygon; ii++)
        jo3dMesh[i]->data.attbl[ii].texno = jo_swap_endian_ushort(*((unsigned short*)(stream + idx)));
        jo3dMesh[i]->data.attbl[ii].sort = SORT_MAX;
        jo3dMesh[i]->data.attbl[ii].flag = Dual_Plane;
        jo3dMesh[i]->data.attbl[ii].colno = No_Palet;
        jo3dMesh[i]->data.attbl[ii].gstb = No_Gouraud;
        jo3dMesh[i]->data.attbl[ii].dir = MESHoff, sprNoflip, UseLight;

    jo3dMesh[i]->data.nbPoint = nbpoint;
    jo3dMesh[i]->data.nbPolygon = nbpolygon;

    currentAddress = (void*) (jo3dMesh[i] + sizeof(jo3dMesh[i]));
jo_printf(0, 6, "current adress :            %d     ", currentAddress);
return currentAddress;

I managed to build my custom binary file format and read it on the Saturn, so I can display a mesh loaded from a binary file on the CD.

My concern now is that I'm using the jo_fs_read_file, which returns a char stream, which takes memory while I'm loading everything to the right place.
It's not a huge problem while loading small images and sound files, but for a map taking 1 MB, it just won't be doable (unless I'm mistaken and got it all wrong).

Is there a way, in Jo Engine, to just use a pointer to read the file and return each time only what you need (like 8, 16, 24 or 32 bits from a start pointer)?
If not, can it be added in the next version?

About you / Re: Hello!
« on: August 02, 2017, 03:21:26 pm »
I played Panzer Dragoon 2 to death when I was a kid, so I'm a bit biaised.
But having a new kind of game is always great, I'm sure you will come out with something interesting!

Thanks a lot, this is greatly appreciated!

Awesome! Can you share more details with us? This is a really annoying issue that we all have (except those lucky modchip owners)

About you / Re: Hello!
« on: August 01, 2017, 02:22:13 pm »
Wow, it already looks amazing! I'm happy that more people are joining the small (but growing) Saturn homebrew community! Don't give up and don't hesitate to ask if you have questions!

Share your code / Re: Collision BB generator (WIP) + FPS demo
« on: July 30, 2017, 04:16:11 pm »
I'm also using larger values to prevent loss of precision, but the issue must be different than that since -1 doesn't result im the opposite of 1.
Even if you only move on one axis, one direction goes faster than the other.
The negative int shift issue seems to fit the actual seen problem.

I guess I should use the SGL functions for now until a solution is found.
I updated the demo in the second post, the only difference is the use of gouraud shading, weapon switching and look up/down (Euler only for now)

Share your code / Re: Collision BB generator (WIP) + FPS demo
« on: July 30, 2017, 01:52:09 pm »
I took a quick look at the latest version of my code, and I don't use shifts for movements (since I just integrated your code).

The Jo_cos_mult/sin functions use JO_DIV_BY_32768 (or >>15) and they accept signed integers returned by the cosinus/sinus lookup table.
Code: [Select]
static  __jo_force_inline int	jo_sin_mult(const int value, const int angle) { return JO_DIV_BY_32768(value * jo_sin(angle)); }

Maybe adding a check would help?
Like, instead of simply returning the value >> 15 :

Code: [Select]
int val = value * jo_sin(angle)
if  (val<0)
    return -JO_DIV_BY_32768(JO_ABS(val)); 
    return JO_DIV_BY_32768(val);

Or is it supposed to be dealed with by the compiler?

EDIT : Did a small test by modifying the math.h file directly, it didn't really help.
Here is a video of the issue, but without the modification to the math.h file :

Share your code / Re: Collision BB generator (WIP) + FPS demo
« on: July 30, 2017, 02:55:03 am »
Yes, I played quite a lot with both in Sonic Z-Treme, overall I had much better results with logical shifts (You just wouldn't believe it unless you saw it).
But after reading the link you sent me, you are right, for signed int the shift right is different for positive and negative values.
Funny thing is that I wrote a workaround in Sonic Z-Treme by  adding 512 (Instead of using floats, I used integers where 1=1024 to keep precision at low cost, but shifted right when sending these for drawing and collisions, so >>10), but I thought I just wrote a cheap workaround.
I guess that might be correct as it will get rounded down after being shifted (-1+1)>>1=0, or (-1024+512)>>10=0.
I guess that also explains why SGL demos are almost always using Unsigned integers and are always doing shifts.

One small question : just how much does shifting saves/costs in Cpu cycles? And SGL demos doing shifts for just about everything, doesn't that waste some CPU ressources?

Share your code / Re: Collision BB generator (WIP) + FPS demo
« on: July 28, 2017, 10:55:40 pm »
Your contribution is highly appreciated!
I will improve the FPS demo (and tool) to work with the mesh loading you wrote.
People will be able to turn it easily into other genres (3d person games, RPG, etc.).
Hopefully this will bring more people on board! ;)

About the FPS demo : There is a bug with the controls, and I have the same problem with Sonic Z-Treme : it seems to always go faster one direction. Now, it might be something I don't understand about the >>#  and <<# functions and negatives/positives, but it's quite anoying when you are trying to move in diagonal.
Anyone got an idea about that? Johannes suggested a weird overflow issue, but I really can't find it.
Any suggestions for modifications to avoid that?

Share your code / Re: Collision BB generator (WIP) + FPS demo
« on: July 28, 2017, 05:30:05 pm »
Like usual, thank you and amazing work Danny! I integrated your smooth FPS control in the FPS demo.
I didn't make a video of it, but you can see I updated the video in the previous post to show what it looks like with a VDP2 plane (with transparency), and I think it shows how much potential the Saturn has for beautiful effects!
I'll try over the weekend to update the collision tool to output .h files compatible with the format you made and integrate that in the FPS demo as a starting point for others.

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