Taking SC5 snapshot of games

Page 4/5
1 | 2 | 3 | | 5

By ~mk~

Master (227)

~mk~'s picture

05-10-2012, 02:50

Found a couple of cases where the script doesn't work properly.
In Crafton and Xunk, openMSX reports the script tried to read an invalid address.
In Space Manbow, the screen is complete garbage.

But most of the times it works great.
Tried with many screen 1, screen 2, screen 5 and 8 succesfully.

By NYYRIKKI

Enlighted (5399)

NYYRIKKI's picture

05-10-2012, 12:05

~mk~ wrote:

Found a couple of cases where the script doesn't work properly.
In Crafton and Xunk, openMSX reports the script tried to read an invalid address.
In Space Manbow, the screen is complete garbage.

I have not checked out Crafton and Xunk, but Space Manbow was one of the first games I tested... In Space Manbow you get perfectly good screenshot of screen 5 status bar. For some reason OpenMSX don't seem to ever take SCREEN 4 screenshot of the game area. Maybe this is because "debug read" return values that are updated on VBLANC, scripts are synced to VBLANC or something like that. Maybe this is some OpenMSX setting(?)

How ever the result is what you should expect when game uses split screen effects. It is not a bug.

By wouter_

Champion (418)

wouter_'s picture

05-10-2012, 14:04

NYYRIKKI wrote:

... For some reason OpenMSX don't seem to ever take SCREEN 4 screenshot of the game area. Maybe this is because "debug read" return values that are updated on VBLANC, scripts are synced to VBLANC or something like that. Maybe this is some OpenMSX setting(?)

It indeed seems to be the case that openMSX console command are often processed around the same relative position in a VDP frame. This is easy to test by interactively executing the command machine_info VDP_line_in_frame, often _but_not_always_ this returns the value 0, indicating that console commands are often processed near the beginning of a frame.

However this is only a side effect of the current implementation, you should not rely on it. Host keyboard presses (e.g. to enter a console command) are handled as events. The current openMSX code processes events when switching from emulation to some other task. Such other task can e.g. be 'sleep a bit' (you need to sleep to synchronize the emulation speed with realtime speed, otherwise emulation would go way too fast). A good moment in time to synchronize is right after a VDP frame has been drawn. So combined this makes that often console events are handled at the start of a new VDP frame.

If you disable the emu/realtime synchronization (set throttle off ; set maxframeskip 99) and then do the same test as above, you'll see that the commands are processed at times much more randomly spread over the frame.

If for some reason you need an action in a Tcl script that is exactly synchronized with the VDP frame, you can use the after frame command. Possibly combined with the after time command. With the following command I could reliably create screen 4 screenshots of Space Manbow:
after frame {after time 0.01 {save_msx_screen bla}}

Though I first had to fix a typo in the script which caused problems for screen 4 (line 71 add a missing value '0x1800'). Possibly this is the same error that ~mk~ saw. I'll commit this fix shortly.

By NYYRIKKI

Enlighted (5399)

NYYRIKKI's picture

09-10-2012, 09:23

wouter_ wrote:

I'll commit this fix shortly.

Could you post here the latest version?

By wouter_

Champion (418)

wouter_'s picture

09-10-2012, 10:02

NYYRIKKI wrote:

Could you post here the latest version?

You can always get the latest version of the script here.

By sd_snatcher

Prophet (3092)

sd_snatcher's picture

28-12-2013, 20:18

I found a bug: Screen dumps from Fire Hawk have the sprites missing.

About the split screen issue: For many MSX2 games the script will be a lottery where it can sometimes dump either the score bar or the game screen. The best approach seems to be that save_msx_screen should be:

1) Check if line interrupts are enabled on R#0.
1.1) If line interrupts are disabled, save_msx_screen dumps the screen as it does today
1.2) If line interrupts are enabled, it must use the command debug set_bp 0x0038 to callback itself

2) The callback should proceed as this:
2.1) Wait until a line interrupt happens
2.2) check VDP_line_in_frame to obtain the line that triggered the interrupt
2.3) let the interrupt handler run for a cycle, because it will change VDP registers (screen mode and/or palette, etc)
2.4) Dump a specific file for that strip of screen
2.5) Rinse and repeat 2.1-2.4 until a frame interrupt occurs.
2.6) When a frame interrupt occurs, it will remove the bp callback from 0x0038

This way, a file will be dumped for each strip of the screen. I.e. in Space Manbow it will dump two files: a SCR5 for the score board, and a SC4 file for the game screen. In Aleste-2 it will be two SC5 files, each one with a specific palette.

By wouter_

Champion (418)

wouter_'s picture

28-12-2013, 20:40

sd_snatcher wrote:

I found a bug: Screen dumps from Fire Hawk have the sprites missing.

I'll investigate...

sd_snatcher wrote:

About the split screen issue: For many MSX2 games the script will be a lottery where it can sometimes dump either the score bar or the game screen. The best approach seems to be that save_msx_screen should be: ...

I consider screen-splits to be outside the scope of this script. It's hard to get this fully correct. For example the approach you proposed doesn't work when the screen-split is implemented via polling instead of via an IRQ (or via IRQ with IM2). But of course feel free to try to implement this yourself.

By sd_snatcher

Prophet (3092)

sd_snatcher's picture

28-12-2013, 20:56

Quote:

I consider screen-splits to be outside the scope of this script. It's hard to get this fully correct.

Ok. I think you're right. Probably the best way is to make sure that openMSX is stopped at a point that the save_msx_screen will dump the intended screen part. This can be accomplished by some nifty use of breakpoints.

But anyway I've found a bug in Space Manbow.

Inside the game, the script crashes with this error: expected integer but got “VRAM”.

It can be easily reproduced if you put a breakpoint at 0x38, run the interrupt handler until the screen mode changes to screen-4, then run the save_msx_screen script.

By Manuel

Ascended (15822)

Manuel's picture

29-12-2013, 10:29

we can't easily reproduce this ourselves... when you get this, can you get us the output of
set $errorInfo
?

By the way: puts stderr [set $errorInfo] outputs it on stderr, which may be easier to copy/paste.

By sd_snatcher

Prophet (3092)

sd_snatcher's picture

04-01-2014, 21:38

I've found another bug in save_msx_screen. It ignores the horizontal scroll register of the V9958 when it calculates the start address of the video page. This means that the screen dumps of games that use the horizontal scroll register will be offset.

Steps to reproduce the problem:

1) Choose a game that use the horizontal scroll register: Sea Sardine, Laydock-2, Mkid, etc
2) After the game starts, take a screenshot using save_msx_screen
3) The dumped screen image will be shifted horizontally.

Note: When testing, it's good to check Mkid specifically, because it uses screen-10.

Page 4/5
1 | 2 | 3 | | 5