unknownbrackets / ps2autotests Goto Github PK

I've been working on some GS blending tests and I've been using the facilities provided by the PS2SDK to build them (namely, the graph and draw libraries).

I know you've been writing code to build VIF packets and such, so, would you want to include a similar framework for building GIF packets inside the test repository or would you think it's acceptable to use the SDK's libraries for that?

Thanks!

I was thinking of adding a simple test for the MSKPATH3 VIF command. At some point, it would also be interesting to test other VIF commands separately.

Would that kind of test fit in the dma/vif category or would those be better placed in another directory?

The PSX had a Geometry Transformation Engine as COP2 for basic linear algebra calculations. It would be interesting to know if it still exists on the PS2's IOP, or is potentually emulated in software.

To enable the GTE, you first need to set bit 30 of COP0.r12.

Here is some sample code for using it, which calculates the weighted average of two color vectors: http://pastebin.com/0S3wGed9
The signature for the function there is void LoadAverageCol(unsigned char in1[3], unsigned char in2[3], long weight1, long weight2, unsigned char out[3]);
Note that the last parameter is passed on the stack.

What would be the best way to go for adding game specific tests to the test suite? I'm talking about adding tests like this one: https://github.com/jpd002/Play-/blob/master/tools/VuTest/TriAceTest.cpp

The idea is just to test specific scenarios that we encounter while developing the emulator. pspautotests doesn't seem to have anything like that, so I was wondering if that would be something that would belong to this test suite.

I was wondering if you had something in the works regarding building import object files (no idea if that's the right nomenclature) needed to import functions into IOP IRX modules.

If not, I've got something working on my side. I can send a PR with my changes so you can have a look at it.

PS2 doesn't support denormal number so 0x00000001 is interpreted as 0.

If the intent was to get the smallest positive number above 0, it ought to be 0x0080_0000 (ie with a biased exponent of 1).