Frame Timing

Technical discussion for those interested in Supermodel development and Model 3 reverse engineering. Prospective contributors welcome.
Forum rules
Keep it classy!

  • No ROM requests or links.
  • Do not ask to be a play tester.
  • Do not ask about release dates.
  • No drama!

Re: Frame Timing

Postby Ian » Wed Jun 29, 2016 1:34 am

One thing I did notice is

void PRO_IO ( char *data
, long number_of_words
, unsigned long scsi_address
, long lun
, long data_goes_to_update_buffer = 1 ) ;

The scsi address is actually one of these

#define PRO_PINGPONG_BASE 0x8e000000
#define PRO_CULLING_BASE 0x8c000000
#define PRO_POLYGON_BASE 0x98000000
#define PRO_CONFIGURE_BASE 0x9c000000
#define PRO_TEXTURE_UPDATE_BASE 0x90000000
#define PRO_MODE_WORD_BASE 0x70000000
#define PRO_GENLOCK_BASE 0x74000000
#define PRO_SCROLL_COLOR_BASE 0x62000000
#define PRO_CHECK_MEM 0x20000001
#define PRO_DO_PREV_BUFF 0x20000002
#define PRO_GAMMA_COMMAND 0x20000004
#define PRO_RELOAD_DEFAULT 0x20000005
#define PRO_GAMMA_TABLE 0x20000006


You can see in my previous decompiled code, the texture update (as well as writing to texture memory) seems to write to

PRO_IO(v1 + 180, 2, **(_DWORD **)(*(_DWORD *)(v1 + 224) + 12) | 0x98000000, -1, 1);
which is polygon memory

This one :)
#define PRO_RELOAD_DEFAULT 0x20000005
That's supposed to load the default spinning logo

In the texture code
PackImage seems to call

PRO_IO(&v16, 1, 0x2000000B, -1, 0);

Not sure we are handling that one at all ? It's also not listed above
Ian
 
Posts: 2044
Joined: Tue Feb 23, 2016 9:23 am

Re: Frame Timing

Postby Ian » Thu Jun 30, 2016 2:29 pm

I had a totally out of the box thought with regards to this problem
Are the displays interlaced?
Maybe updates are supposed to happen every other field?

The text in ocean hunter looks interlaced, but it could just be a fade effect if the 2d layers don't support alpha blending

Image
Ian
 
Posts: 2044
Joined: Tue Feb 23, 2016 9:23 am

Re: Frame Timing

Postby Bart » Fri Jul 01, 2016 7:48 pm

Ian wrote:As for todo list, sure there is a bunch of other stuff to look at, clipping planes, specular, some unimplmented fog/light stuff we aren't handling. But I think we should just release now :) Also I don't have too much time to work on supermodel currently


Okay, I think we can proceed with current features but I do think a few things need to be added:

1. Specular lighting should be tweaked in the legacy engine and that method will be added to new engine until we revisit the problem.
2. The new engine should be on by default.
3. Config options should be added for 1) viewport symmetry (to allow the new engine to use symmetric viewpoints as in the legacy engine, making Lost World, VON2, etc. playable) and 2) near/far clipping planes. These could be configured on a per-game basis in the INI file.
4. ROMs handled by an XML loader.

I actually whipped up a new config system the other day. It's not great but it's a bit more natural than the current method. I need to rework the INI parser to support it and add XML parsing. Could take a couple weeks given the limited time I have but should be easily doable.
User avatar
Bart
Site Admin
 
Posts: 3086
Joined: Thu Sep 01, 2011 2:13 pm
Location: Reno, Nevada

Re: Frame Timing

Postby Bart » Fri Jul 01, 2016 7:49 pm

Ian wrote:I had a totally out of the box thought with regards to this problem
Are the displays interlaced?
Maybe updates are supposed to happen every other field?

The text in ocean hunter looks interlaced, but it could just be a fade effect if the 2d layers don't support alpha blending

Image


Interesting idea but I don't think so. I don't know much about interlaced graphics, though. The last time I dealt with that was when I wrote a Genesis emulator in high school that supported its funky interlace mode (where all 8x8 tiles suddenly became 8x16 tiles).
User avatar
Bart
Site Admin
 
Posts: 3086
Joined: Thu Sep 01, 2011 2:13 pm
Location: Reno, Nevada

Re: Frame Timing

Postby Ian » Sat Jul 02, 2016 2:53 am

You any closer to figure out the frame timing problem?
Ian
 
Posts: 2044
Joined: Tue Feb 23, 2016 9:23 am

Re: Frame Timing

Postby LsrgcBath » Mon Jul 04, 2016 12:41 pm

Bart wrote:
Ian wrote:As for todo list, sure there is a bunch of other stuff to look at, clipping planes, specular, some unimplmented fog/light stuff we aren't handling. But I think we should just release now :) Also I don't have too much time to work on supermodel currently


Okay, I think we can proceed with current features but I do think a few things need to be added:

1. Specular lighting should be tweaked in the legacy engine and that method will be added to new engine until we revisit the problem.
2. The new engine should be on by default.
3. Config options should be added for 1) viewport symmetry (to allow the new engine to use symmetric viewpoints as in the legacy engine, making Lost World, VON2, etc. playable) and 2) near/far clipping planes. These could be configured on a per-game basis in the INI file.
4. ROMs handled by an XML loader.

I actually whipped up a new config system the other day. It's not great but it's a bit more natural than the current method. I need to rework the INI parser to support it and add XML parsing. Could take a couple weeks given the limited time I have but should be easily doable.


Bart, sorry to bother you...

About the Specular Lighting, I know you two are not very happy with the outcome with the current method, but I particularly liked more the way the effect work with the new method on the actual legacy engine, it would be very difficult to implement, for example, to have the original method or use the new method, through an option, something like: -old-specular, -new-specular, or using a fragment shader, we can choose between the two methods? I know it's very easy for me in my deep ignorance to imagine that can be simple like that, but also I can imagine that the code should be rethought and this could be a pai in the ass, "break" things, or even it´s not possible in any way.

Another thing... you will add on the official release the option to customize the music tracks that use .mp2, that you and the Shekel managed to get work? In my tests, this tweak work very well and probably, i would really miss the lack of this option, IMO, it adds alot to the experience of playing the emulator, it would be sad not usign the work done in this feature.

Cheers and happy 4th of july and 240th BD US!! \o/
User avatar
LsrgcBath
 
Posts: 130
Joined: Sat Jan 21, 2012 2:43 pm
Location: Brazil - Sao Paulo

Re: Frame Timing

Postby Bart » Mon Jul 04, 2016 12:55 pm

Ian wrote:You any closer to figure out the frame timing problem?


Unfortunately not yet :( My focus at home is to check off the items on my release to-do list but I will be chipping away at the disassembly I've been working on during my down time at the office.
User avatar
Bart
Site Admin
 
Posts: 3086
Joined: Thu Sep 01, 2011 2:13 pm
Location: Reno, Nevada

Re: Frame Timing

Postby Ian » Sun Sep 25, 2016 9:59 am

I'm pretty sure the

case 0x88: // 88000000
GPU.Flush();

Should actually trigger our frame to draw.

I logged some calls to see what the output looked like with the 'flush' command

WriteHighCullingRAM
flush 88000000
drawn frame <------- sdl swap buffers
WriteHighCullingRAM
flush 88000000
drawn frame
drawn frame
WriteHighCullingRAM
flush 88000000
drawn frame
WritePolygonRAM
WriteTextureFIFO
drawn frame <-- this one is called too early
WriteHighCullingRAM
flush 88000000 <-- swap buffers should should be here after writing culling ram i assume
WritePolygonRAM
WriteTextureFIFO
drawn frame <-- too early again
-----> deleting 0 1024 1024 512 512
WriteHighCullingRAM
flush 88000000 <-- assume swap buffers should be called here
create format 0 x: 1024 y: 1024 width: 512 height: 512
drawn frame
WriteHighCullingRAM
flush 88000000
drawn frame
WriteHighCullingRAM
flush 88000000
drawn frame
WriteHighCullingRAM
flush 88000000
drawn frame
WriteHighCullingRAM
flush 88000000
drawn frame
Ian
 
Posts: 2044
Joined: Tue Feb 23, 2016 9:23 am

Re: Frame Timing

Postby Ian » Sun Sep 25, 2016 11:19 am

Bart wrote:Investigations related to frame set up and timing will be posted to this thread.

Obviously the register at 0x88000000 has something to do with triggering the rendering process. Here is the sequence of DMA transfers for two consecutive frames in dayto2pe. This is in the first tunnel of the medium-level track. In the second frame, the first of a series of texture uploads via VROM are performed (to prepare the haunted house scene). Note that in both cases, 0x88000000 is written twice and apart from the VROM texture upload, the two frames are indistinguishable:

Code: Select all
Frame 1:

Real3D DMA copy (PC=00002838, LR=000030A4): 001016A0 -> 980010C8, 4
Real3D DMA copy (PC=00002838, LR=000030A4): 001016A4 -> 980010CC, 4
Real3D DMA copy (PC=00002838, LR=000030A4): 001016A8 -> 980010D0, 4
Real3D DMA copy (PC=00002A3C, LR=000030A4): 001A88D4 -> 9802CC2C, 88D8 (byte reversed)
Real3D DMA copy (PC=00002D00, LR=00001A60): 001C2358 -> 98038738, 2614 (byte reversed)
Real3D DMA copy (PC=00002D00, LR=00001A60): 001C7BA0 -> 9803AD4C, 2F0 (byte reversed)
Real3D DMA copy (PC=00002D00, LR=00001A60): 0010502C -> 980017F8, 4
Real3D DMA copy (PC=00002D00, LR=00001A60): 00105030 -> 980017D4, 4
Real3D DMA copy (PC=00002D00, LR=00001A60): 00105034 -> 980017D8, 4
Real3D DMA copy (PC=00002D00, LR=00001A60): 00105028 -> 980017D0, 4
Real3D DMA copy (PC=00002D00, LR=00001A60): 001C8180 -> 9803B03C, 5C (byte reversed)
Real3D DMA copy (PC=00002D00, LR=00001A60): 001C81DC -> 9803B098, 5C (byte reversed)
Real3D DMA copy (PC=00002D00, LR=00001A60): 001C8238 -> 9803B0F4, 5C (byte reversed)
Real3D DMA copy (PC=00002D00, LR=00001A60): 001C8294 -> 9803B150, 5C (byte reversed)
Real3D DMA copy (PC=00002D00, LR=00001A60): 001C82F0 -> 9803B1AC, 5C (byte reversed)
Real3D DMA copy (PC=00002D00, LR=00001A60): 001C834C -> 9803B208, 5C (byte reversed)
Real3D DMA copy (PC=00002D00, LR=00001A60): 001C83A8 -> 9803B264, 5C (byte reversed)
Real3D DMA copy (PC=00002D00, LR=00001A60): 001C8404 -> 9803B2C0, 5C (byte reversed)
Real3D DMA copy (PC=00002D00, LR=00001A60): 001C8460 -> 9803B31C, 5C (byte reversed)
Real3D DMA copy (PC=00002D00, LR=00001A60): 001C84BC -> 9803B378, 5C (byte reversed)
Real3D DMA copy (PC=00002D00, LR=00001A60): 001C8518 -> 9803B3D4, 5C (byte reversed)
Real3D DMA copy (PC=00002D00, LR=00001A60): 001C8574 -> 9803B430, 5C (byte reversed)
Real3D DMA copy (PC=00002D00, LR=00001A60): 001C85D0 -> 9803B48C, 5C (byte reversed)
Real3D DMA copy (PC=00002D00, LR=00001A60): 001C862C -> 9803B4E8, 5C (byte reversed)
Real3D DMA copy (PC=00002D00, LR=00001A60): 001C8688 -> 9803B544, 5C (byte reversed)
Real3D DMA copy (PC=00002D00, LR=00001A60): 001C86E4 -> 9803B5A0, 5C (byte reversed)
Real3D DMA copy (PC=00002A3C, LR=000030A4): 00660010 -> 8E000000, E80
Real3D DMA copy (PC=00002D00, LR=00001A60): 00661D10 -> 8E001D00, 1000
Real3D DMA copy (PC=00002D00, LR=00001A60): 0066AA10 -> 8E00AA00, 120
Real3D DMA copy (PC=00002D00, LR=00001A60): 0066B040 -> 8E00B030, 1260
Real3D DMA copy (PC=00002D00, LR=00001A60): 00662D10 -> 8E002D00, F78
Real3D DMA copy (PC=00002D00, LR=00001A60): 006736B0 -> 8E0136A0, 13C
Real3D DMA copy (PC=00002D00, LR=00001A60): 006742B0 -> 8E0142A0, 320
Real3D DMA copy (PC=00002838, LR=000030A4): 0073EF88 -> 88000000, 4 (byte reversed)
Real3D DMA copy (PC=00002838, LR=000030A4): 0073EF88 -> 88000000, 4 (byte reversed)

Frame 2:

Real3D DMA copy (PC=00002838, LR=000030A4): 001016A0 -> 980010C8, 4
Real3D DMA copy (PC=00002838, LR=000030A4): 001016A4 -> 980010CC, 4
Real3D DMA copy (PC=00002838, LR=000030A4): 001016A8 -> 980010D0, 4
Real3D DMA copy (PC=00002838, LR=000030A4): 0055F2D0 -> 90000000, C (byte reversed)
Real3D VROM texture upload
Real3D DMA copy (PC=00002A3C, LR=000030A4): 001C2358 -> 98038738, 2614 (byte reversed)
Real3D DMA copy (PC=00002D00, LR=00001A60): 001C7BA0 -> 9803AD4C, 2F0 (byte reversed)
Real3D DMA copy (PC=00002D00, LR=00001A60): 0010502C -> 980017F8, 4
Real3D DMA copy (PC=00002D00, LR=00001A60): 00105030 -> 980017D4, 4
Real3D DMA copy (PC=00002D00, LR=00001A60): 00105034 -> 980017D8, 4
Real3D DMA copy (PC=00002D00, LR=00001A60): 00105028 -> 980017D0, 4
Real3D DMA copy (PC=00002D00, LR=00001A60): 001C8180 -> 9803B03C, 5C (byte reversed)
Real3D DMA copy (PC=00002D00, LR=00001A60): 001C81DC -> 9803B098, 5C (byte reversed)
Real3D DMA copy (PC=00002D00, LR=00001A60): 001C8238 -> 9803B0F4, 5C (byte reversed)
Real3D DMA copy (PC=00002D00, LR=00001A60): 001C8294 -> 9803B150, 5C (byte reversed)
Real3D DMA copy (PC=00002D00, LR=00001A60): 001C82F0 -> 9803B1AC, 5C (byte reversed)
Real3D DMA copy (PC=00002D00, LR=00001A60): 001C834C -> 9803B208, 5C (byte reversed)
Real3D DMA copy (PC=00002D00, LR=00001A60): 001C83A8 -> 9803B264, 5C (byte reversed)
Real3D DMA copy (PC=00002D00, LR=00001A60): 001C8404 -> 9803B2C0, 5C (byte reversed)
Real3D DMA copy (PC=00002D00, LR=00001A60): 001C8460 -> 9803B31C, 5C (byte reversed)
Real3D DMA copy (PC=00002D00, LR=00001A60): 001C84BC -> 9803B378, 5C (byte reversed)
Real3D DMA copy (PC=00002D00, LR=00001A60): 001C8518 -> 9803B3D4, 5C (byte reversed)
Real3D DMA copy (PC=00002D00, LR=00001A60): 001C8574 -> 9803B430, 5C (byte reversed)
Real3D DMA copy (PC=00002D00, LR=00001A60): 001C85D0 -> 9803B48C, 5C (byte reversed)
Real3D DMA copy (PC=00002D00, LR=00001A60): 001C862C -> 9803B4E8, 5C (byte reversed)
Real3D DMA copy (PC=00002D00, LR=00001A60): 001C8688 -> 9803B544, 5C (byte reversed)
Real3D DMA copy (PC=00002D00, LR=00001A60): 001C86E4 -> 9803B5A0, 5C (byte reversed)
Real3D DMA copy (PC=00002A3C, LR=000030A4): 00660010 -> 8E000000, E80
Real3D DMA copy (PC=00002D00, LR=00001A60): 00661D10 -> 8E001D00, 1000
Real3D DMA copy (PC=00002D00, LR=00001A60): 0066AA10 -> 8E00AA00, 120
Real3D DMA copy (PC=00002D00, LR=00001A60): 0066B040 -> 8E00B030, 1260
Real3D DMA copy (PC=00002D00, LR=00001A60): 00662D10 -> 8E002D00, F78
Real3D DMA copy (PC=00002D00, LR=00001A60): 006736B0 -> 8E0136A0, 13C
Real3D DMA copy (PC=00002D00, LR=00001A60): 006742B0 -> 8E0142A0, 320
Real3D DMA copy (PC=00002838, LR=000030A4): 0073EF88 -> 88000000, 4 (byte reversed)
Real3D DMA copy (PC=00002838, LR=000030A4): 0073EF88 -> 88000000, 4 (byte reversed)


But why is it written twice? Hmm... Need to investigate.


My guess is .. either the game is actually running at 30fps. Or the 2nd one is a no-op. Daytona seems to call a double flush every frame. None of the other games I've tried do.
Ian
 
Posts: 2044
Joined: Tue Feb 23, 2016 9:23 am

Previous

Return to The Dark Room

Who is online

Users browsing this forum: No registered users and 1 guest

cron