«

[Japo]

Do we know if this could happen with other settings for machine different from the default, besides vgaonly? Also it may depend on other settings like scaler, or perhaps if you had aspect=true it would be 640x480 instead of 400? We can simply warn that fiddling with machine can have this effect.

According to the post in Vogons, this behavior is by design, necessary to support something. You should be able to convert the image file back to paletted, as long as you used a normal scaler, and not one that adds new colors by interpolation (if the scaler really influences these captures). Any image processing software has an algorithm to generate the optimal palette for an image, and if an image does not have more than 256 colors the optimal 256 colors palette generated should have the same exact colors as the original.

[Ohne Mitleid]

I have tested some of the settings for scale and aspect=true, with vgaonly and without. Scaler only appears to effect how the game is displayed to the player but does not effect the actual screen capture. A great example of this would be Dungeon Master 2, svga_s3 with scaler=hq3x. Even though the game window is scaled 3x and some of the graphics have the edges softened for the hq part, the screen capture is still 320x200, 8 bit color.

Aspect=true scales the game window to 640x480, but if coupled with vgaonly still yields 640x400 - 24 bit color captures. I haven't tested too many other combinations because I feel I have found out what I needed to know. I thought it may have been something I had done.

This all started when I was working on Lost City of Atlantis but I didn't take the time to resolve it then. I have an example which might help explain one of the situations I have run into. Since using your tutorial (), it allowed me to pick up on a very simple and organized way of getting my DOSBox games in one place, finally. I don't want the DOSBox icon for everything so I started making icons from captures. Now this is why it is a "problem".

The attachment shows the final icon, a capture of the title, a capture of the graphic for an in-between level change, the same graphic with a palette swap and a capture of aspect=true. All of the captures were done with the vgaonly setting except the aspect=true, which was a screen capture with alt+prntscrn. The aspect=true capture was done this way to show the size of the game display reflected 640x480, even though the DOSBox capture was 640x400 - 24 bit.

This game, Cool World, is set up so that any keypress advances gameplay. While on the title screen, a keypress will bring up the options screen, blocking the graphic. With vgaonly, you grab a capture but with 24 bit color. The Title screen contains the same 256 color palette as the level screen, but the level screen was captured while it was beginning to dim after pressing ALT+F5 for the capture.

If you take both captures, resize them to 320x200, save their respective 256 color palette after decreasing from 16 million colors, the colors saved are not the same. And as far as indexes go, if you substitute the title palette for the level palette and maintain indexes, the mess you see in the level w/ title pal picture is what you get. If you substitute and choose nearest color match, it will just display the same dimmed level picture, with the colors slightly dimmer. Without vgaonly, the palette can be swapped from title to level and you get the full brightness back.

The reason behind wanting a reliable indexed palette in this example was simple. It saved time. To make the icon, I wanted the title pic of the woman with the actual graphic text for 'Cool World'. The choice was to try and cut out the text then repair the places where her hands covered the letters, or get a clean shot of the text. The clean shot was afforded by the level capture, but with the inherent color palette problem only IF the palette was 24 bit and not the original 8 bit.

So on a case by case basis, I don't think every combination of configurations could be covered with just one post. I was just trying to figure this out for myself and then share the vgaonly caveat to anyone else who might be affected by it.

@Japo: Your tutorial was very well written. I didn't need to read it all but I was able to scan for just the bits I needed, which I feel is a key element to any good reference source. Thank you!

[The Fifth Horseman]

How about a slightly simpler workaround: start recording a video using CTRL+SHIFT+F5 before you run the game. Wait until whatever you wanted to capture gets recorded. Stop recording. Open the video with any media player with frame capture function, fast-forward to the frame you want and use the capture function to grab the picture.

[Japo]

Thanks OM. You cracked it open, don't worry about testing every combination. It's enough to know about this behavior, and anyone else can test further if he's interested about his own particular case.

If what you want is to capture an image before it changes when you press the first key of a two-key combo, you can re-map the DOSBox keyboard so that one single key captures a screenshot instead of (or in addition to) the default Ctrl+F5. In my custom default mapper it's PrnScr.

[Ohne Mitleid]

@The Fifth Horseman - Great suggestion! The animation capture might serve another purpose for me in the future. Besides a PrnScr, how would I get a capture without a 24 bit palette?

@Japo - I didn't know about Special Keys being able to be mapped to a single key. I'll definitely be looking into this.

DOSBox is relatively simple on the surface but really has a lot of depth once you start poking around. I am rather new to this whole thing, but I'm trying to learn as quick as I can.

My solution to capturing something that escapes because of a keypress is to play the game in less than fullscreen mode. When the image I want to capture is displayed, I grab the title bar of the display window and hold it with the mouse, press Ctrl+F5, release the mouse button and I have the capture I want.

It was a lucky guess. I have another example of a palette swap need. The game I am reviewing is really poor. I always try to play a game to completion before reviewing to be as fair as possible in my opinion. I cannot complete this one (you'll have to see the review for reasons).

I looked at the EXE in hex and determined there is no climactic end-scene reward animation. However, I was able to deduce what the End Game completion graphic was, and then swapped it out in the EXE for the Title screen.

This shows the end screen with the Title screen palette. Since I have an indexed 256 color palette used for the rest of the game, I just swapped it out to show the actual end game graphic. This would not be possible if either of the captures were done either with a non-indexed 8 bit palette or if either palette were 24 bit.

I thank you both, I appreciate the time you've taken to post and for the new ideas!