The official way to do that is to fill the holes with degenerated triangles (i.e. rendered as textured lines).

Take advantage of fixed point math (float operations are horribly slow) and use SquareRoot0 for magnitude and catan instead of atan2 for direction.

Sorry to necropost but only now I noticed this. armips has support to link both objects and libraries used in PSY-Q. You can extract code and symbols for an lnk to elf conversion.

It's likely a missing volatile declaration or some macro using a type cast. Doubt GCC got that broken with standard variable types on MIPS, but if volatile is already there it's certainly not a good thing.

I suppose the reason why I don't run into such compiler related issues is because I write all low level stuff in my libraries entirely in assembly which is how its supposed to be done when dealing with hardware registers. Problem is PSY-Q libraries are mostly written in C, only a very restricted am...

I mean intentionally weird code like the following taken from libspu: // spu time waster void _spu_Fw1ts() { int v[2]; v[1] = 13; v[0] = 0; goto stuff; while (1) { v[1] += v[1] * 12; v[0]++; __asm__ volatile ("nop"); __asm__ volatile ("nop"); __asm__ volatile ("nop"); s...

If you did write any low level libraries then you should probably already know what kind of screw ups modern GCC can do to PSX i-cache (code reorder specifically, which can be awful) and with hardware register access (i.e. unwanted default optimization to operations like spu stagger for wait loops)....

Does this even work with Psy-Q natively or with converted libs? Because otherwise you're in for a can of warms with those system calls and open source libraries to port correctly.

The BIOS doesn't have a header, the first byte of it is the entry point. All id strings contained inside the data are retrieved via system calls and can not always be found in the same spot.

So does PSYQ if you configure it and use a recent make. You can even compile PSXSDK with the official toolchain if you change a few things around.

Sure, send a pastebin link, it's easier to read.

You can't mix libgpu and libgs unless you know exactly what the latter does internally. With that said, I think you are missing quite a few initialization points for libgs internals, like OTag definitions for size and ot starting pointers. Functions such as GsClearOt require a GsOT structure for myO...

You have a call to ClearOTagR() that isn't necessary because it's already in GsClearOt(). Also do not update both TILE primitives' RGB channels, only redefine those for the current buffer TILE or otherwise you will get glitches with colors jumping around.

Try a better solution like a loop to initialize those primitives: // after declaration for(i = 0; i < 2; i++) { setTile(&tile[i]); setDrawMode(&dr_prim[i], 0, 0, getTPage(0, 2, 0, 0), 0); setSemiTrans(&tile[i], 1); setRGB0(&tile[i], 128, 128, 128); setXY0(&tile[i], 0, 0); setWH (...

You're still doing it incorrectly, you need something like this: // declaration TILE t[2]; DR_MODE m[2]; [...] // inside draw loop AddPrim((u_long *)&myOT[ActiveBuffer][0], &t[ActiveBuffer]); AddPrim((u_long *)&myOT[ActiveBuffer][0], &m[ActiveBuffer]); Also don't bother with MargePri...

You still have only one primitive for each type, you need two per frame: they have to be different or otherwise DMA will commit suicide. Also you aren't setting any blending mode in DR_MODE.

Unfortunately we don't have any rips of extremely old PSYQ versions, just the libs with only Japanese documentation (something like 3.4 iirc). Having access to older sdk disks would definitively help in figuring out some dates there.

Simply check which features were supported in GCC 2.8.1 and you will know what PSQY-Q's toolchain supports, since it's a modified GCC with custom linkable objects and overlay support through linker maps.

That's because you need two primitives, one per draw environment. Also, you need to set the transparency flag on TILEs otherwise blending won't trigger.

You would use a TILE + DMODE primitive that covers the whole screen, create the DMODE as subtractive color, then change the TILE RGB to change fade transition. RGB = 255 means the mask will make the screen fully black, RGB = 0 makes the screen visible again.