Screen update query

Post by **PhilPotter** » January 27th, 2017, 11:18 pm

Dear All,

I'm currently working on a new Java + OpenGL 4.x based emulator that I wrote from scratch, based on available docs and using NO$PSX's debugger as a help in testing things. This was part of my university degree which is now finished, and although I didn't fully finish the emulator, I got it complete enough to do well, and I wanted to carry on with it.

My problem is that I seem to be having a rather odd issue with Crash Bandicoot (my testing case) - basically, between frames the polygons (although not rectangles oddly) jump ever so slightly between left and right. When displaying the entire VRAM contents, I can see that Crash Bandicoot (PAL) is rendering at 25fps - it renders two frames from top-left segment of VRAM and then two frames from the top-right. My emulator is setup so that as soon as it enters the Vblank period it displays whatever the display area registers + number of pixels/lines is set to, and also triggers an interrupt.

I've checked by comparing images side by side at each point, and the two areas of VRAM always differ at this point, even on static images like when the little house structure stops moving in the intro. The interesting thing is that NO$PSX (when I break on a VBlank interrupt) has differing contents for the top-left and top-right areas of VRAM as well.

Does this mean I am just updating the screen too early and need to adjust my timings? I checked the number of non-vblank interrupts caused by timers inbetween each vblank as well, and my emulator is pretty much the same as NO$PSX in that regard. I am sure I will think of something eventually, but at the moment I'm just racking my brains and would appreciate if anyone else has come across this problem during emu development? Many thanks.

Regards,
Phil

Post by **PhilPotter** » February 3rd, 2017, 11:22 am

Solved this on my own in the end - I was causing a rounding error of some kind when converting the vertex coordinates to OpenGL coordinates. I was dividing the vertex coordinates by 511.5 then subtracting 1.0 to get the GL coordinate - must have thought that was a good idea (probably because I figured 1023 / 511.5 - 1.0 = 1.0. Anyhow, dividing by 512 instead eliminates the problem.