Screenshots Of Caanoo Apps


Orion4874 said:
Nice joyrider, will it work with the Wiz as well?

It probably won't work on the wiz, but the source code is included all you need to modify is the key codes and perhaps the /dev/* devices for the framebuffer and input. then a simple recompile should work.

i can also make a version without a daemon for usuage with telnet so you can take screenshots by using the commandline version inside telnet if someone needs that. but won't be for tonight and perhaps not this week, might be for the weekend but i have other things to do as well. (Lots of things happend recently in my life, slowly putting it back together)
 
Last edited by a moderator:
kouky said:
this doesn't seems to work here...
How do i make the autorun.gpu to be unix format?
I found useful webpage. It explains the way how to change dos2unix and unix2dos text format.
http://www.bastet.com/
 
Last edited by a moderator:
At work now, but i'll try to create a new version tonight with the following modifications:

1) Copy the daemon to /tmp and execute it from /tmp, the reason is that the deamon will be running in the background forever untill you reboot and keep the SD Card in use which means you can't mount the sd card for use with the SD Card connection (will give some message that it can't unmount /mnt/sd) (the telnet app has the same problem and only figured it out yesterday)

2) make sure you can use the joystick "click button" beneath the joystick. Currently it does not allow it and it was an error on my end since i totally forgot about it i will also make this the default button

3) save screenshots to /mnt/sd/photo instead of /mnt/sd so they show up under "photos" in the default gp2xmenu

i can't make a wiz version since i do not own a wiz myselve and have no build environment set up for it , but it's a very easy and quick port you just need to know the devices on the wiz, caanoo uses /dev/fb1 (i think, can't remember) and /dev/input/event1 and you have to change they key codes (use a simple test program for it or let the daemon print it by modifing the source). The program will most definatly work on a wiz given a recompile

will keep you guys posted
 
Did anyone test it, did all work as explained (for 16 bit games) ? i'm not going to spend my night adapting the previous things mentioned if noone has a need for it...
 
joyrider said:
Did anyone test it, did all work as explained (for 16 bit games) ? i'm not going to spend my night adapting the previous things mentioned if noone has a need for it...
I haven't gotten it to work, but I may be doing something wrong. I copied it to the APPS directory and ran it. I then pressed 1 and 2 while playing a game on Picodrive.

EDIT:
Never mind, it works like a charm! I tried it on Picodrive and Wind and Water! SWEET! Thanks, joyrider!
 
Last edited by a moderator:
Com64 said:
haven't gotten it to work, but I may be doing something wrong. I copied it to the APPS directory and ran it. I then pressed 1 and 2 while playing a game on Picodrive.

EDIT:
Never mind, it works like a charm! I tried it on Picodrive and Wind and Water! SWEET! Thanks, joyrider!

No problem, could you explain what it was you did wrong? could still be a bug of somekind or maybe something that can be solved programmaticly
 
Last edited by a moderator:
joyrider said:
Com64 said:
haven't gotten it to work, but I may be doing something wrong. I copied it to the APPS directory and ran it. I then pressed 1 and 2 while playing a game on Picodrive.

EDIT:
Never mind, it works like a charm! I tried it on Picodrive and Wind and Water! SWEET! Thanks, joyrider!

No problem, could you explain what it was you did wrong? could still be a bug of somekind or maybe something that can be solved programmaticly
I looked in the photo directory instead of the root directory for the screenshots.
 
Last edited by a moderator:
Com64 said:
I looked in the photo directory instead of the root directory for the screenshots.

Ah i'll see that i can fix that, i'll make a subdirectory under "photos" named screenshots given subdirectories show under the "photo's section" for now with the current version it's better to use the "explorer" section of the menu since they are saved in the root of your sd card (io /mnt/sd). There might even be a way to get it save the screenshots in the apps name like picodrive.gpe.1.png picodrive.gpe.2.png etc. I think there must exists a function to get the process pid with the most cpu usage somehow and then get the process name, sortoff like the "top" command does

edit: will boot back to linux now and adapts a few things
 
Last edited by a moderator:
joyrider said:
Com64 said:
I looked in the photo directory instead of the root directory for the screenshots.

Ah i'll see that i can fix that, i'll make a subdirectory under "photos" named screenshots given subdirectories show under the "photo's section" for now with the current version it's better to use the "explorer" section of the menu since they are saved in the root of your sd card (io /mnt/sd)
It would be great if you had the option of time-stamped screenshots.
If you restart the Caanoo and run the application again, does it continue counting from where it left off, or does it start counting over again?
 
Last edited by a moderator:
Com64 said:
It would be great if you had the option of time-stamped screenshots.
If you restart the Caanoo and run the application again, does it continue counting from where it left off, or does it start counting over again?

ah if the caanoo has such battery to back up the date and time and options to set it that is indeed an option yes. Filenames will never be overwritten, it will keep adding up the number in the filename till it finds a file that doesn't exist anymore so it's a good idea to not let the number of screenshots get really huge cause for example if you have 100 screenshots it will need to do 100 filechecks to be sure it had not overwritten the file. Solution until a new version is to move the screenshots to a seperate folder after a number of screenshots (manually). I will modify this so it'll write the last screenshot number in a seperate config file for 2 reasons being 1) the problem mentioned above and 2) if you ever delete a screenshot a gap will be created and the first *free* filename will be taken resulting in mixed game screenshots. This can be easily solved if i remember the last screenshot number in a file. If the date time thing works on the caanoo i'll make it an option in the same config as well. I'm first going to do the small changes and then see if there is a way to detect the framebuffer bitdepth (like 8 - 16 - 24 or 32 bit) to support more games not running in 16 bit graphics mode
 
Last edited by a moderator:
joyrider said:
Com64 said:
It would be great if you had the option of time-stamped screenshots.
If you restart the Caanoo and run the application again, does it continue counting from where it left off, or does it start counting over again?

ah if the caanoo has such battery to back up the date and time and options to set it that is indeed an option yes. Filenames will never be overwritten, it will keep adding up the number in the filename till it finds a file that doesn't exist anymore so it's a good idea to not let the number of screenshots get really huge cause for example if you have 100 screenshots it will need to do 100 filechecks to be sure it had not overwritten the file. Solution until a new version is to move the screenshots to a seperate folder after a number of screenshots (manually). I will modify this so it'll write the last screenshot number in a seperate config file for 2 reasons being 1) the problem mentioned above and 2) if you ever delete a screenshot a gap will be created and the first *free* filename will be taken resulting in mixed game screenshots. This can be easily solved if i remember the last screenshot number in a file. If the date time thing works on the caanoo i'll make it an option in the same config as well. I'm first going to do the small changes and then see if there is a way to detect the framebuffer bitdepth (like 8 - 16 - 24 or 32 bit) to support more games not running in 16 bit graphics mode
Just an idea: if there isn't a way to detect the framebuffer bitdepth, you could make separate executables for the different depths.

Also: the Caanoo does store the time and date.
 
Last edited by a moderator:
Com64 said:
Just an idea: if there isn't a way to detect the framebuffer bitdepth, you could make separate executables for the different depths.

Also: the Caanoo does store the time and date.

ok these things are done already now :

1) copy the deamon to /tmp and it's being run from there (done using script that starts it the gpe bin/sh file) (to not block usb mounting)
2) remember last screenshot number in a file (on /mnt/sd/photo/screenshots)
3) create /mnt/sd/photo/screenshots and save screenshots there now
4) support the joystick click button and make it the default key for taking screenshots (i don't think many games require you to use the joystick click button)
5) i tried using IOCTL FBIOGET_VSCREENINFO to get the framebuffer bit depth but it always seems to return 24 bit, maybe i'm doing something wrong. but it could be it's not usefull for this will have to test it more with this but it seems to take all screenshots in 24 bit mode (so this is not working). I'll try your suggestion but will adopt it, i'll add a command line parameter to define bit depth and use diffrent gpe script files to launch it, i will also make sure the script kills the previous instance using the killall commando to not let the deamon be ran multiple times (other wise you'd have to reboot the caanoo to take a screenshot if the game uses a diffrent bitdepth) (starting the app twice also ment double screenshots).
6) fixed and array overflow bug (slipped in due to hasty porting)
7) fixed forgotten fclose(f) on the keyconfig file

So all is working now except point 5, i'll add point 5 using the commandline parameter, create scripts and png's for 8 - 16 - 24 and 32 bit depth to see the diffrence and do a new release i'll also check for the date time thingie first since if RTC works on caanoo it can't be too hard

edit: ran into a few bugs which i did not solve yet, i'm off to bed so it'll be for tomorow most probably
 
Last edited by a moderator:
I released it with binaries for 24 bit games and 16 bit games check the news section, and the archive once the updated file gets accepted
 
Hi,

Maybe a stupid question but how do I know which app/emulator/game runs in 16 bit or in 24 bit ? Do I have to screenshot in the two modes every time ?

Thanks.
 
FreddyBoubil said:
Hi,

Maybe a stupid question but how do I know which app/emulator/game runs in 16 bit or in 24 bit ? Do I have to screenshot in the two modes every time ?

Thanks.
You can usually tell by the variety of colours.
 
Last edited by a moderator:
FreddyBoubil said:
Hi,

Maybe a stupid question but how do I know which app/emulator/game runs in 16 bit or in 24 bit ? Do I have to screenshot in the two modes every time ?

Thanks.

You can't really tell by just looking at the screen. But you can tell by taking a screenshot using the deamon in 16 bit mode, if the game is using 24 bit you will notice the screenshot is distorted so you could try taking a screenshot go back to menu and look in photo\screenshots16\ and see if if the picture is garbled or not if so try the 24 bit version. The only binarie i came across that used 24bit while testing was the Default Menu itselve. You could try taking a screenshot of the default menu with the 16 bit version and looking at it then you know what i mean with garbled screenshots.

Certain games produce black screenshots like quake and most gph *real* games like kaitsen patsier, propis,.. (so not the arcade emulator ones) i don't know how this comes but my guess is those games do something diffrent then SDL does to draw to the screen or perhaps they use /dev/fb0 themselves or something but i haven't looked at that anymore. (i could check it using quake sources).

I'm also not certain if the caanoo supports 8 bit graphics mode if it does i'll have to make or find a conversion function and create an 8bit deamon as well. (unless someone knows a way to detect the bitdepth using /dev/fb0)
 
Last edited by a moderator:
Back
Top