mahjongg:·you should email one of the moderators to see if they can upload an image on the page. Actually I would upload it and use the same tag that this image uses. http://en.wikipedia.org/wiki/Image:Pearlsmain.jpg
It is copyrighted material but I am sure the author didn't upload it. But it also has a copyright tag. Since it is for reference purposes it should be ok to upload and just note that parallax is copyright owner.
Anyone can upload any picture to wikipedia commons, commons.wikimedia.org/wiki/Main_Page but if you do, you have to declare that the picture is made by you, or that there is another reason why the picture is common domain, or has a license that permits wikipedia to use it. If you do not give such a declaration, the picture may be deleted. This is what happened with Andre's picture. If you upload it then make sure to give it the right legal status, and explain why it has this status.
p.s. the wikipedia article about the HYDRA game development kit en.wikipedia.org/wiki/HYDRA_Game_Development_Kit also misses a picture of the HYDRA system, it only has a link to the picture on www.xgamestation.com. It would be great if a "legal" picture of it could be uploaded to wikipedia commons too, so we can show the Hydra on the wikipedia page itself.
If you are having problems getting the pictures incorporated in the wikipedia page, then just mention the filename(s) of the picture(s) here, and I will do it for you.
Mahjongg
Post Edited (mahjongg) : 7/14/2007 10:51:59 PM GMT
I was just reading through the image policy of wikipedia and I didn't know how strict it was, so basiclly Parallax would have to upload it and put whatever tag they wanted to associate with it.
Later I made it a bit more factual, as it was thought to be too much like an advertisement for the propeller
And still later somebody reworded it a bit so it now reads a little easier (I am not a native English speaker, and as a picture thinker I am known to make convoluted sentences)
Is it possible that the screen capture / save windows application is dropping the top scan line? I ported your code to my 2 color driver last night and used it to capture some SpaceWar screenshots (great utility by the way, and thanks for your work on it!), but I found that I was losing the top scan line of my image. I didn't do a whole lot of chasing to verify (I could dump the serial data stream and make some test patterns if needed I suppose), but I was pretty confident that I was dumping data from the start of the buffer, but that the top scan line was not showing up on-screen in the grabber app, and not showing up in the saved file. A couple of my screens have image data on the top line whose absence is very easy to see (the top line of letters and such).
For the moment I got around it by re-coding my grabber to send one scan line of garbage followed by the real data, so I could see the top line.
If you think I'm wrong then I'll go do some more investigation.
Good catch! The program would have the scanline in memory but skipped it when it was rendering it and also skipped it when it is converted to bitmap(that was caused more by an error from rendering it upside down).
Anyway new version has been uploaded that fixes this issue.
Excellent utility. I've taken a screen grab of Defender using this software. Did you speed it up? Because it only takes about 4 seconds to grab a screen.
To make the aspect look right, I send 2 pixels over the serial line for every one pixel on screen (4 for the scanner area). Because of the 320 pixel limit, I've had to trim 4 pixels off each side to do so. But for Defender that's OK.
I've found a tiny bug. You know those supersaturated colours you did that were $x8? Well you can also specify supersaturated colours as $xF. If $D8 is supersaturated red, then $DF is supersaturated red as well. Some say they can tell the difference between the two. I can't. But for completeness you should map them both. (I originally used the one you don't support for the smartbomb warheads, but I've swapped it now.)
Some suggestions:
1) Support arbitrary sized bitmaps. Perhaps you could allocate the bitmap after you've received the dimensions from the Hydra?
2) First time I got an image to display in the window, I spent a little time wondering where the file was. How about after an image has been grabbed, change the window title text to "Press space to save" and then "Saved to hydra_bitmap.bmp" after it's done so?
3) When the user minimises the window, drop the connection to the com port. Whilst I was tinkering with the Screen_Grab code in the Defender source, I had to quit and restart the EXE numerous times so I could reprogram the Hydra.
4) Don't overwrite hydra_bitmap.bmp each time, append a number to the filename instead. Simple way to do it is to try saving as hydra_bitmap.bmp, and it that fails then go into a loop trying hydra_bitmap_1.bmp and incrementing the index value each time, until a save happens without error.
5) Finally a pie in the sky suggestion. Support animated grabs. Of course you can't play the game whilst capturing, but it would catch any the colour cycling in Defender and any animated sprites in another game.
Game loops tend to advance when they get a vsync from the TV driver. In my case when tv_status is non-zero. So you could send every single frame down the line to the PC by making the Screen_Grab toggle that value and sending the picture over and over again. Then perhaps the PC could save to an animated GIF or MNG or some form of movie file. Or even just save as an indexed set of seperate bmp files. I believe there are apps that will accept a set of BMPs and compile them into a movie.
Anyhoo, they're only suggestions for it you fancy developing it further. But it already serves it's purpose very well as it is.
Excellent utility. I've taken a screen grab of Defender using this software. Did you speed it up? Because it only takes about 4 seconds to grab a screen.
I fixed this a long time ago. Basicily for each byte I sent to the PC, I sent back the Prop to verify it. I desided to just yank that code and just send a burst of bytes to the PC.
To make the aspect look right, I send 2 pixels over the serial line for every one pixel on screen (4 for the scanner area). Because of the 320 pixel limit, I've had to trim 4 pixels off each side to do so. But for Defender that's OK.
I may deside to make the window limit bigger for such things like this.
I've found a tiny bug. You know those supersaturated colours you did that were $x8? Well you can also specify supersaturated colours as $xF. If $D8 is supersaturated red, then $DF is supersaturated red as well. Some say they can tell the difference between the two. I can't. But for completeness you should map them both. (I originally used the one you don't support for the smartbomb warheads, but I've swapped it now.)
Hmm, I may have to look into that. I probably won't map new colors, but map the same oversaturated colors.
Some suggestions:
1) Support arbitrary sized bitmaps. Perhaps you could allocate the bitmap after you've received the dimensions from the Hydra?
I don't think I will be doing this because if an bitmap is scaled·at anything other·than·a multiple of two, the bitmap will look "off" and paint programs do a much better job of scaling images.
2) First time I got an image to display in the window, I spent a little time wondering where the file was. How about after an image has been grabbed, change the window title text to "Press space to save" and then "Saved to hydra_bitmap.bmp" after it's done so?
Lol, that might be a good idea. I am working on a small graphics editing tool and I may have to give this program a little user interface other than the title bar.
3) When the user minimises the window, drop the connection to the com port. Whilst I was tinkering with the Screen_Grab code in the Defender source, I had to quit and restart the EXE numerous times so I could reprogram the Hydra.
I originally had disconnect and reconnect routines in, but the reconnect routines would fail, so I ran into that a bit too where I would have to quit the program to reload. I can't promise this will be fixed in the future, but when·I go back to work on this, I will give it another shot.
4) Don't overwrite hydra_bitmap.bmp each time, append a number to the filename instead. Simple way to do it is to try saving as hydra_bitmap.bmp, and it that fails then go into a loop trying hydra_bitmap_1.bmp and incrementing the index value each time, until a save happens without error.
This is something I can fix in the future. I think it was something I didn't address because I didn't think anyone else would use the tool [noparse]:)[/noparse]
5) Finally a pie in the sky suggestion. Support animated grabs. Of course you can't play the game whilst capturing, but it would catch any the colour cycling in Defender and any animated sprites in another game.
Game loops tend to advance when they get a vsync from the TV driver. In my case when tv_status is non-zero. So you could send every single frame down the line to the PC by making the Screen_Grab toggle that value and sending the picture over and over again. Then perhaps the PC could save to an animated GIF or MNG or some form of movie file. Or even just save as an indexed set of seperate bmp files. I believe there are apps that will accept a set of BMPs and compile them into a movie.
Put this down for a maybe. The only thing is that if I did do it, it would save it as BMPs instead of animated GIFs. I am sure too that there are programs that can convert a series of BMPs into animated GIFs, but my only wonder would be how useful would this be? It would be very time consuming capturing a since it would take roughly·240 seconds to capture a single second of real time video. But we will see.
Anyhoo, they're only suggestions for it you fancy developing it further. But it already serves it's purpose very well as it is.
Cheers,
Steve.
I am glad you found the program useful. I really considered the project "done" other than any bug fixes, but I may have to look into working on a new version. I should have some time in a few weeks so maybe I will work on it then.
Comments
mahjongg:·you should email one of the moderators to see if they can upload an image on the page. Actually I would upload it and use the same tag that this image uses. http://en.wikipedia.org/wiki/Image:Pearlsmain.jpg
It is copyrighted material but I am sure the author didn't upload it. But it also has a copyright tag. Since it is for reference purposes it should be ok to upload and just note that parallax is copyright owner.
Post Edited (JT Cook) : 7/14/2007 3:18:10 PM GMT
p.s. the wikipedia article about the HYDRA game development kit en.wikipedia.org/wiki/HYDRA_Game_Development_Kit also misses a picture of the HYDRA system, it only has a link to the picture on www.xgamestation.com. It would be great if a "legal" picture of it could be uploaded to wikipedia commons too, so we can show the Hydra on the wikipedia page itself.
If you are having problems getting the pictures incorporated in the wikipedia page, then just mention the filename(s) of the picture(s) here, and I will do it for you.
Mahjongg
Post Edited (mahjongg) : 7/14/2007 10:51:59 PM GMT
Also nice job on the two pages.
Later I made it a bit more factual, as it was thought to be too much like an advertisement for the propeller
And still later somebody reworded it a bit so it now reads a little easier (I am not a native English speaker, and as a picture thinker I am known to make convoluted sentences)
Mahjongg
Is it possible that the screen capture / save windows application is dropping the top scan line? I ported your code to my 2 color driver last night and used it to capture some SpaceWar screenshots (great utility by the way, and thanks for your work on it!), but I found that I was losing the top scan line of my image. I didn't do a whole lot of chasing to verify (I could dump the serial data stream and make some test patterns if needed I suppose), but I was pretty confident that I was dumping data from the start of the buffer, but that the top scan line was not showing up on-screen in the grabber app, and not showing up in the saved file. A couple of my screens have image data on the top line whose absence is very easy to see (the top line of letters and such).
For the moment I got around it by re-coding my grabber to send one scan line of garbage followed by the real data, so I could see the top line.
If you think I'm wrong then I'll go do some more investigation.
Thanks!
Anyway new version has been uploaded that fixes this issue.
Excellent utility. I've taken a screen grab of Defender using this software. Did you speed it up? Because it only takes about 4 seconds to grab a screen.
To make the aspect look right, I send 2 pixels over the serial line for every one pixel on screen (4 for the scanner area). Because of the 320 pixel limit, I've had to trim 4 pixels off each side to do so. But for Defender that's OK.
I've found a tiny bug. You know those supersaturated colours you did that were $x8? Well you can also specify supersaturated colours as $xF. If $D8 is supersaturated red, then $DF is supersaturated red as well. Some say they can tell the difference between the two. I can't. But for completeness you should map them both. (I originally used the one you don't support for the smartbomb warheads, but I've swapped it now.)
Some suggestions:
1) Support arbitrary sized bitmaps. Perhaps you could allocate the bitmap after you've received the dimensions from the Hydra?
2) First time I got an image to display in the window, I spent a little time wondering where the file was. How about after an image has been grabbed, change the window title text to "Press space to save" and then "Saved to hydra_bitmap.bmp" after it's done so?
3) When the user minimises the window, drop the connection to the com port. Whilst I was tinkering with the Screen_Grab code in the Defender source, I had to quit and restart the EXE numerous times so I could reprogram the Hydra.
4) Don't overwrite hydra_bitmap.bmp each time, append a number to the filename instead. Simple way to do it is to try saving as hydra_bitmap.bmp, and it that fails then go into a loop trying hydra_bitmap_1.bmp and incrementing the index value each time, until a save happens without error.
5) Finally a pie in the sky suggestion. Support animated grabs. Of course you can't play the game whilst capturing, but it would catch any the colour cycling in Defender and any animated sprites in another game.
Game loops tend to advance when they get a vsync from the TV driver. In my case when tv_status is non-zero. So you could send every single frame down the line to the PC by making the Screen_Grab toggle that value and sending the picture over and over again. Then perhaps the PC could save to an animated GIF or MNG or some form of movie file. Or even just save as an indexed set of seperate bmp files. I believe there are apps that will accept a set of BMPs and compile them into a movie.
Anyhoo, they're only suggestions for it you fancy developing it further. But it already serves it's purpose very well as it is.
Cheers,
Steve.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Prop Room Robotics - my web store for Roomba spare parts in the UK
Post Edited (CardboardGuru) : 12/2/2007 9:39:40 AM GMT