Video capture unit

dilettante · 2009-04-29 12:56:19

I've been going through the nocash technical reference and the code in GPU.cpp trying to understand what needs to be done to get 3D rendering in both screens. As far as I can tell, GPU_set_DISPCAPCNT already implements what is written in the nocash page, with the exception of the offset wrap around to 0x0 if it exceeds 128kb. However, even adding simple and probably inefficient checks if offset + scanline * 512 exceeds 128kb doesn't make 3d rendering in both screens work.

What else needs to be done for proper video capture emulation? I can help write a patch if someone explains what's lacking.

lbalbalba · 2009-04-29 17:09:51

Consider joining the developers on IRC, and discuss things with the development team. (not all the devs read these forums). IRC details : http://wiki.desmume.org/index.php?title … _is_IRC.3F

Last edited by lbalbalba (2009-04-29 17:12:25)

zeromus · 2009-04-29 18:22:05

3d renders in both screens on 1000 different games. If it fails in one game, it is due to a subtle bug. There is another thing which can cause this to fail which has nothing to do with the capture unit but rather the timing of the emulator confusing the game and making it swap screens at the wrong time.

If i knew what was lacking i wouldve fixed it already.

lbalbalba · 2009-04-29 18:51:41

zeromus wrote:

3d renders in both screens on 1000 different games. If it fails in one game, it is due to a subtle bug.

Which raises the question: In which game and version, and where in this game does this behaviour occur ?

dilettante · 2009-04-30 03:57:00

zeromus wrote:

3d renders in both screens on 1000 different games. If it fails in one game, it is due to a subtle bug. There is another thing which can cause this to fail which has nothing to do with the capture unit but rather the timing of the emulator confusing the game and making it swap screens at the wrong time.
If i knew what was lacking i wouldve fixed it already.

Sorry, wrong assumption on my part. All the other games I've tested only use 3D in one screen and they work properly. Shortly after I posted this I decided to add a little debug output (scanline number) to DispCapture that did seem to make timing worse. Also uncommenting the debug output in set_DISPCAPCNT showed that the capture parameters changed at l < 191, often around 138 or so which is probably responsible for the flicker.

dilettante · 2009-04-30 04:05:38

lbalbalba wrote:

zeromus wrote:
3d renders in both screens on 1000 different games. If it fails in one game, it is due to a subtle bug.
Which raises the question: In which game and version, and where in this game does this behaviour occur ?

Not to flood with you with the same information all over the place Dragon Ball: Origins US version.

It occurs as soon as 3D rendering starts just after the publisher and game developer logos are shown. About to post a bug report in the bug tracker.

Last edited by dilettante (2009-04-30 04:06:34)

zeromus · 2009-04-30 04:27:37

I still havent researched it to prove it, but in cases of bad timing the game might try to change dispcapcnt at the wrong time, thus creating these problems. I would expect it to be closer to just after the vblank, though... most games wait and then do it immediately after vblank so it doesnt matter what the timing is

#1 2009-04-29 12:56:19

Video capture unit

#2 2009-04-29 17:09:51

Re: Video capture unit

#3 2009-04-29 18:22:05

Re: Video capture unit

#4 2009-04-29 18:51:41

Re: Video capture unit

#5 2009-04-30 03:57:00

Re: Video capture unit

#6 2009-04-30 04:05:38

Re: Video capture unit

#7 2009-04-30 04:27:37

Re: Video capture unit

Board footer