I know It's a funny question, but, there is an easy way to capture
the images of an animated cursor within DosBox?
I've tried to capture video, convert the frames to png and then
cut the cursor from the background. But it's SO hard... And the
results aren't good enough.
If they're using some cursor animation, they have to perform the drawing
themselves (means dosbox has no idea about the cursor shape).
So there's no easier solution than grabbing each frame. But it might work
a bit better if you find some solid-coloured background, then you can use
blue-screen like techniques (chromakeying) to extract the cursor more easily.
But it might work a bit better if you find some solid-coloured
background, then you can use blue-screen like techniques
(chromakeying) to extract the cursor more easily.
I intended to do that. But the backgrounds are rather
coloured/complex and is not possible. To make it just a
bit more complex, the cursor is semi-transparent.
But thanks, anyway.
Just a though and maybe a stupid idea, but you could record the anim a few times just with different backgrounds. The common overlap is then the desired cursor. It's probably best to write a little program to do the frame comparisons and extract the images.
Or you hack the program to display only the cursor (DOSbox's debugging features might come in very handy :p)
evo, it is not a stupid idea at all. The problems are the cursor
transparency and antialiasing, but I could use a threshold value
(or better a pair of values to set a range). As you said, the key
is to use radically different backgrounds. With plain backgrounds
it would be an easy affair, but it is not the case.
I should have said that we are talking about complex (and pretty cool) hi-res cursors.
There is a debug option to avoid that the background gets
painted? I would be really interested on that.
Well, I will have to learn how to use libpng and make that.
Thanks a bunch, evo.
😉
Finally I've made a program to calculate de differences between
"n" input png files. When there are a lot of differences between the
same pixel on the "n" images I set the alpha channel to 0 on the
output image, i.e. 100% transparent, in other case I use the
average color. The results aren't good enough to justify the effort.
As I said the problems are the transparency and the antialiasing.
Well, It was a cool idea. Thanks evo.
> There is a debug option to avoid that the background gets
> painted? I would be really interested on that.
No, because memory access (and drawing a pixel is such an operation)
is not attributed with a "i'm a mouse cursor pixel" flag 😉
The only case where the mouse cursor is in a way independent from
the rest is when the default cursor is used, as then dosbox itself has to
draw that cursor. But this one is rather boring compared to what you're
trying to extract.....
Still i think it should be possible to find some uni-coloured (black or white
preferred) background somewhere in the game. Then extraction should
be much easier.
With solid cursors like this extracted from "The 11th hour", the results are quite impressive:
Source 1
Source 2
Clean image (yellow represents alpha channel)
wrote:No, because memory access (and drawing a pixel is such an operation) is not attributed with a "i'm a mouse cursor pixel" flag ;) […]
No, because memory access (and drawing a pixel is such an operation)
is not attributed with a "i'm a mouse cursor pixel" flag 😉
The only case where the mouse cursor is in a way independent from
the rest is when the default cursor is used, as then dosbox itself has to
draw that cursor. But this one is rather boring compared to what you're
trying to extract.....
Surely, it depends on the program on how easy it is to locate the cursor-drawing code. Maybe the drawing routines are even shared with the rest of the graphics rendering.
The situation is certainly simplest if the cursor drawing (within the program) is done directly in the mouse callback handler. A simple hack will have dosbox reject writes to video ram unless in the handler.
In the general case you might have to trace back your way from the mouse handler to drawing routine (disassemblers/debuggers and a good deal of x86 asm knowledge are your friends).
Alternatively, if you don't want to dig through asm listings you can search for all instructions that write the video memory and hack dosbox to ingnore/allow writes coming from specific code locations only. Trial and error methods let you find out what each of them draws.
> In the general case you might have to trace back your way from the mouse handler to drawing routine
Yes, this situation is the most likely one and can be easy or hard depending
on the game.
I just wanted to point out that there's no simple debugger switch to separate
the mouse drawing from the regular drawing code.
wrote:> In the general case you might have to trace back your way from the mouse handler to drawing routine […]
> In the general case you might have to trace back your way from the mouse handler to drawing routine
Yes, this situation is the most likely one and can be easy or hard depending
on the game.
I just wanted to point out that there's no simple debugger switch to separate
the mouse drawing from the regular drawing code.
Yeah, thanks for pointing out I sometimes forget that things obvious for me are not immediately obvious to others.
Anyways, it's not guaranteed that the above methods work, it could well be that rendering occurs no to video memory directly but to (off-screen) memory buffers while the final image copied to video ram ("rep mov'd" in asm terms).
That said, I don't have a general recipe for you to follow, you have to experiment with this yourself and the sophistication of the techniques involved really depends on the specific application.
Sorry that I don't come up with something easier, maybe there is a better way...
Either way, the 11th Hour mouse cursor captures look nice 😉
With a little post-processing they seem to be quite usable.
