|
|
|
|
|
|
|
Make "plasma_tunnel.elf" work.
Posted on 2005-10-22 00:00:00 |
|
Implemented instruction BLTZL.
Fixed the GS handler so it can continue taking vertices after 3 vertices has been specified for a triangle primitive. Added support for PRMODE, PRMODECONT registers and added basic support for the ST register. Here's the result after those things in: 
There's still some problems right now though... - Texture mapping is wrong. I don't know if it's due to the clamping mode not being set correctly, because it writes something in the CLAMP register when uploading the texture. There's also the Q component of the texture coordinate that I'm not taking in consideration... I have no idea what this component should be doing and if it would have an impact in the case of this demo. But it's not set to 0 though, so maybe there's some important information there... Looking through the code would probably give me some more insight about this component. - The Z component of the vertices are really big (in the order of 10^9). This goes a bit against the hypothesis I've made while working on the "CubeMastah" demo. I'll need to find a solution that accomodates both demos, as the only thing I'm doing right now is dividing the Z component by 0x10000000 when drawing a STQ/textured triangle. - The demo takes a lot of instructions to render its scene completely. If we use the hypothesis that the PS2 EE runs at 250MHz and that it's able to execute at most 4166666 instructions for each frame, this demo would still be unable to make it to provide a frame at each 1/60 of second. Because this emulator uses a fixed number of instructions to decide when to swap buffers, we see all of the scene being rendered if I use a small number of instructions (500000 -> 30MHz is the number I was using for all demos). Using a big number is going to penalize other demos and will just make them wait for no reason. A technique used in nSX2 is to swap buffers each time the CSR register is accessed, making sure the programs don't wait too much or that the emulator swap buffers too much, giving interesting results. In most of the demos I've seen, the CSR is accessed only in the loop that waits for the start/end of the v-blank period, but I don't know if the framework used for commercial games works this way too, so I'm not really sure I want to implement something like that. I'll try to have at least the texture mapping problem fixed for the next time. |