DRAW CALL debugging.

Developer's Forum, for discussion of bugs, code, and other developmental aspects of DOSBox.

DRAW CALL debugging.

Postby katastic » 2019-2-13 @ 00:57

I want to do some research into how "scenes" are drawn in various oldschool games.

The simplest example: A game with no double buffering or page flipping draws to the screen (hopefully!) after every vsync. That means it's simply modifying VRAM and I could hook into each time that happens.

So if I were to force a draw-to-the-OS every time the CGA/EGA/VGA/whatever memory was written to, I could--in essence--build a video with each "frame" being the individual draw calls as they appear.

So, does anyone have any tips for exploring the code base (or existing debug solutions?). Where to touch, what APIs/code files. Any information on how you would do that, what function you would hijack, etc.

I would imagine that there's a "VGA" source file with all the registers and memory accesses go through a memory-access function.

Also, any ideas for how to hijack double buffering or page flipping. I would imagine double buffering would be difficult, but page flipping is (as far as I can remember about 90's coding) simply a indexing register where you change where the "start of" page (the screen) begins in VRAM, and it's still drawing to VRAM.

Another "problem" to solve is, how would I get this data to the screen (or image dump)? For example, "Mode X" is a VGA paged memory mode where red, green, blue are all separate pages. e.g. All reds pixels in a row for the screen. Then all green. Then all blue. (Whatever the actual pixel order is). But if I'm dumping that, I'd have to recombine it somehow.

Thanks.
katastic
Newbie
 
Posts: 2
Joined: 2019-2-13 @ 00:48

Re: DRAW CALL debugging.

Postby ripa » 2019-2-14 @ 20:00

I did something like that when I was reverse engineering Test Drive III maps.

First of all, get this ready-made tool called Bitmap Memory Debugger:
http://www.theycamefromhollywood.com/bmd/

You will be able to examine Dosbox's memory visually.

Dosbox global variable MemBase holds the pointer to the emulated RAM. Modify Dosbox memory.cpp to print the address of MemBase after allocating it. Then you can look at the RAM contents with BMD, and you'll probably be able to spot the rendering framebuffer of the game. If you then run the game in Dosbox debugger, break into the debugger while the game is rendering, and then let Dosbox execute a few thousand cycles at a time and watch how the rendering buffer changes.

If you want to examine the video memory, you will need to look elsewhere. I think you can find the pixel data at global variable vga.mem.linear_orgptr or vga.fastmem_orgptr. You can print the address of those and look into them with BMD.

VGA memory starts at virtual address A000:0000. If the emulated program accesses VGA memory, I think it goes through Dosbox's page handler. There's a function called MEM_SetPageHandler. There's a different page handler per video hardware. See VGA_SetupHandlers in vga_memory.cpp.
ripa
Oldbie
 
Posts: 555
Joined: 2005-4-18 @ 00:53
Location: Finland

Re: DRAW CALL debugging.

Postby reenigne » 2019-2-15 @ 08:39

I'm not sure where you got the idea that red, green and blue are on separate pages in Mode X - I've never heard of a video mode where memory is organised like that! Most VGA games use 256 colours with one byte per pixel and a palette. The separate pages in Mode X correspond to the low two bits of the X coordinate, though many VGA games (including all those that support MCGA) use mode 0x13 which has a linear memory organisation.

To tell when the game is starting a new frame you could wait for it to poll the status register - I think pretty much every game that synchronise to the raster beam will use this technique to do so. Of course, not all games are synchronised to the raster beam so you'll have to find another way to define "frame" for those that aren't.

I will be interested to see the results of your research!
User avatar
reenigne
Member
 
Posts: 484
Joined: 2006-11-30 @ 05:13
Location: Cornwall, UK

Re: DRAW CALL debugging.

Postby katastic » 2019-2-16 @ 23:48

ripa: GREAT HELP. I'm looking through source code and making progerss!

reenigne: You're right. I was thinking of EGA or something. Mode X is "planer" but it's pixels per bank--not colors.

That's a good point for games that ARE vsync'd. For direct drawing, I can see it by scanning/dumping VRAM during periods of retrace. For double buffered, that won't work. For page flipping, that might still work but I'd have to combine "every other frame" back together.

Ideally, I'd really like to (if simple enough) track the exact periods (with respect to retrace) of drawing, and then dump them as "frames" any time there is a write to that memory. Which again, should work for page flipping and direct drawing, but not double buffer. I could easily divide "sections" or "intervals" between each retrace as a complete frame and then log the individual writes as a list.

HMMMM. Since the double buffer (but not triple buffering?) usually has a fixed position in RAM, I might be able to detect a memcpy from RAM to VRAM (starting with the VRAM write), and reverse engineer/lookup the source RAM position, and then watch that position in RAM for writes.
katastic
Newbie
 
Posts: 2
Joined: 2019-2-13 @ 00:48

Re: DRAW CALL debugging.

Postby rasz_pl » 2019-2-17 @ 00:35

speaking of tracing draw calls, stumbled upon this gem yesterday "Profiling Of 3 Games Running On The S3 ViRGE Chip" http://www-graphics.stanford.edu/~bjoha ... study.html
rasz_pl
Newbie
 
Posts: 68
Joined: 2017-6-04 @ 00:57


Return to DOSBox Development

Who is online

Users browsing this forum: mbsystem and 1 guest