Digital Screen Grab
JT Cook
Posts: 487
Here is the latest version of my Hydra digital screen capture client. It now includes super saturated colors, bitmap saving, and takes about 5 seconds to transfer a sceenshot from the·Hydra to the PC. I have also·included the color lookup table incase someone wants to write their own app. This version also fixes a bug where the 1st scanline was no rendered.
At the bottom are some sample screen grabs, the X-Racer, Alien Invader, and Dr Hydra·screens had a little color touch up in Paintshop Pro.
(Original first message, old screenshot removed)
This is something I have wanted to try for a while and today just jumped right into it.·I wanted to get a copy of a video screen right from the Prop chip instead of doing a video capture. I wanted a way to create exact pixel perfect screenshots and also thought this concept would be good for people who do not have video capture hardware.
It is actually pretty simple. I run the program like normal, then when I hit select·the program·turns off the TV driver and start a fake TV driver. Instead of rendering a video signal I send the buffered pixel scanline over serial. Then after that scanline is finished, I request a new scanline and send that over serial. If you are using the default parallax drivers where the entire screen is buffered, this should be even easier since you don't have to turn off the display.
I wrote a simple app in Visual C with SDL to catch the pixels and draw them on the screen. I also have a palette look up table (which took forever to enter).
The only downside is it takes about 10+ minutes to transfer a single frame. This is something I am going to try and speed up, but I was just trying to get a proof of concept type of thing working.
Also there are some color issues that need worked out, but that will have to wait until I come back.
Well time for bed, work, then after that a weekend of camping.
Post Edited (JT Cook) : 8/3/2007 11:05:30 PM GMT
At the bottom are some sample screen grabs, the X-Racer, Alien Invader, and Dr Hydra·screens had a little color touch up in Paintshop Pro.
(Original first message, old screenshot removed)
This is something I have wanted to try for a while and today just jumped right into it.·I wanted to get a copy of a video screen right from the Prop chip instead of doing a video capture. I wanted a way to create exact pixel perfect screenshots and also thought this concept would be good for people who do not have video capture hardware.
It is actually pretty simple. I run the program like normal, then when I hit select·the program·turns off the TV driver and start a fake TV driver. Instead of rendering a video signal I send the buffered pixel scanline over serial. Then after that scanline is finished, I request a new scanline and send that over serial. If you are using the default parallax drivers where the entire screen is buffered, this should be even easier since you don't have to turn off the display.
I wrote a simple app in Visual C with SDL to catch the pixels and draw them on the screen. I also have a palette look up table (which took forever to enter).
The only downside is it takes about 10+ minutes to transfer a single frame. This is something I am going to try and speed up, but I was just trying to get a proof of concept type of thing working.
Also there are some color issues that need worked out, but that will have to wait until I come back.
Well time for bed, work, then after that a weekend of camping.
Post Edited (JT Cook) : 8/3/2007 11:05:30 PM GMT
256 x 225 - 5K
256 x 190 - 7K
256 x 192 - 14K
256 x 192 - 8K
Comments
Cool idea, and looks like it could be very useful for taking pixel perfect images for posting [noparse];)[/noparse]
Nice one, can't wait to see·it working.
Baggers.
Andre'
I haven't worked on a way to speed it up yet, but I am guessing it is mostly due to the serial code and rendering code code on my PC client that is slowing things down.
Anyway here is a new screen with everything fixed.
any date for release?
I tried to do screen grabs on Alien Invaders and Dr Hydra, but I can't compile even the original code in the new version of the Propeller Tool because of a compile error.
I might release something Friday, but it will depend on time. The PC client is really pretty minimal and does not export the screen grabs. I just do a print screen,··paste it in·PSP, crop, decrease color, save as gif. Also the PC client right now is hard coded for COM 6, I need to make some kind of interface to select a com port.
Edit: I bet if you do some run length encoding on the Propeller side, it will speed things up enormously. Also, GIF is a simple algorithm; you might be able to employ GIF's LZW compression on the Propeller side before you ever send it down the wire. I read a book that explains how to make GIF files.
do you know how to save a bmp file?
I could add one if you want?
Baggers
Edit: Dennis, it also depends on how much ram's left prop side. [noparse]:)[/noparse]
If JT Cook hasn't done this already, perhaps the serial driver and fake TV driver could be merged, requiring only one cog instead of two.
I'm sure JT has it sussed already, as cogs are as sparce as ram when it comes to scanline renderers. [noparse]:)[/noparse]
Also the fake TV driver is just written in SPIN. The only thing it really does it just read bytes from the scanline buffer, then when it is done advance the scanline counter. The scanline rendering COGs (different from the TV cog) just look at the current scanline value, and if it is the one to be used, it will copy the scanline image from COG memory to public memory. Timing is not critical since all this is getting displayed over serial which is much slower than 60hz. I haven't seen how other TV drivers work (like the one for DK) but I don't imagine it would be much different than this. The only driver I don't see this working for is Andre's one COG renderer since it renders the scanline and synthesises the video signal in one COG. But this could also be done by creating a different cog that instead of outputting video to write a scanline to public memory and wait for a counter to advance, but this would take a little more work.
Also since it takes only about 5 seconds for a frame grab, I beleive that any kind of compression on the Propeller side would slow it down. Since everything is rendered a scanline, it can only compress a scanline, and calculating the scanline + sending it would be longer than 5 seconds. Also I don't think my program has the memory to store the RLE info after it has been calculated.
·
As for TV driver in spin, nice idea, since it doesn't need to take up another cog then [noparse]:)[/noparse]
I also agree with you on the compression side, or should I say non compression, being faster.
After all 5 seconds isn't long for doing a screen grab to post on the forums or whatever you want to do with it.
Very cool though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Hydra in a LEGO NES:
http://forums.parallax.com/showthread.php?p=654788
I am releasing the PC client app I made. With it you can select the screen resolution (up to 320x240), but it still doesn't allow you to save the image to disk (just do a print screen and paste it in your favorite image editing program). Read the readme file for more details on how to run it. No source yet.
Also I have included a couple of programs to try it out with. I hacked up the original parallax graphics demo to use. I forgot how a$$-backwords the bitmap driver was setup in memory, that took longer then I wanted to·to figure out.
The second program I include was Donkey Kong, which I noticed the palette was reversed. It still isn't perfect because some of the whites are not getting decoded correctly, but I didn't feel like spending the extra time trying to figure it out (I·was lucky that I figured out how the palette was setup·
Think of this as an alpha release, so don't be surprised if it doesn't work for you.
My colours match the ones in the Hydra book, which I take to be official for the Hydra if not the Prop. I recall some other programs use colors offset by $80. That might well be down to the Parallax driver. It's arbitrary really.
I haven't looked at your code, but my guess on why you're missing some of the greys and whites is that you are are expecting them to be $02 to $07. i.e. with the chroma set to zero, whereas chroma might actually be anything. I try to help stabilise the chroma signal by using the same chroma as the pixels to either side where possible, even though it's actually a greyscale pixel. I'm not sure if it works, but it certainly does no harm.
You're probably missing the colour on the fireballs because they are supersaturated colors. i.e.Chroma enable set, Luma = 0, and chroma offset by 8.
Both these color issues are unusual uses of color, but "legal" and potentially may be used in other programs, so you probably ought to support them.
I don't know how significant it is, but the DK picture is missing the top scanline and has two extra that shouldn't be there on the bottom.
Post Edited (CardboardGuru) : 6/30/2007 12:48:44 AM GMT
I also noticed the missing scanline, I am wondering if a higher scanline number will trigger it, like it is waiting for scanline 250 or something before it renders the first scanline. Or maybe the first scanline is already in the buffer and I when I set the requested scanline to 0, it actually pulls scanline 1. Hmm. Anyway that will be something else·I will look into Monday. And for the bottom of the screen, I just guessed at that (I was too lazy to look it up).
Post Edited (JT Cook) : 6/30/2007 5:49:04 AM GMT
Right now I am assuming that valid colors fall from $X2-X7 and $XA-$XE, but I see that the flame uses $X8 which shouldn't be a valid color.
Maybe I am reading the palette wrong, but what are the colors you use for the flame?
If you have the Hydra book, take a look at the TIP in the box at the bottom of page 240. $x8 are supersaturated colors.
The flame uses:
$07 $6c and $e8.
That's white, orange and cyan.
OK, not really cyan. When you have supersaturated colors, the chroma displays 180 degrees out of phase. So it's not cyan at al, it's supersaturated orange. ($e-$8 = $6 = orange)
When mario has the hammer, $80 is added to each of those colours, to give a white and cyan and supersaturated blue palette.
In fact I'm going to follow suit and use that for my avatar. Thanks.
Post Edited (CardboardGuru) : 7/7/2007 11:26:03 AM GMT
Andre'
Email has been sent.
The article about Andre' recently had Andre's picture removed (probably because of licencing problems), perhaps Andre can upload a legal version to Wikimedia commons?
A legal picture of the internal block diagram of the propeller would also be a nice addition to the propeller page, if parralax agrees it can be used.
I can't however guarantee it won't be removed, perhaps someone thinks it's too "commercial"
Andre'
p.s. The wiki entry for the hydra looks good, thanks.