Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (498)
Games in Android Showcase (117)
games submitted by our members
Games in WIP (564)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Most friendly way to take a mobile screen grab?  (Read 2094 times)
0 Members and 1 Guest are viewing this topic.
Offline ribot

Junior Member




Ribot - mobile UI specialist


« Posted 2005-03-16 08:10:47 »

Hi all,

I was wondering what people would suggest as to the best way to save a portion of the current screen (a rectangular section of pixels).  

For example, I paint a range of rectangles, circles and random images to the canvas.  When I press a key, it takes a snapshot of a portion of the screen.  What is the best way to grab the data?

Would the following work?

DirectGraphics dgSrc = DirectUtils.getDirectGraphics(g);
short[] pixels = new short[nPixels];
dgSrc.getPixels(pixels,0,w,0,0,w,h,DirectGraphics.TYPE_USHORT_444_RGB);

http://ribot.co.uk - design agency focused on mobile
http://www.retrospecs.co.uk - online vintage eyewear store
Offline Abuse

JGO Knight


Medals: 12


falling into the abyss of reality


« Reply #1 - Posted 2005-03-16 09:10:39 »

If your code is properly structured, all you would need to do is create an offscreen image, get a Graphics context to it, and pass it into paint(..).

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline ribot

Junior Member




Ribot - mobile UI specialist


« Reply #2 - Posted 2005-03-16 09:45:08 »

I can now confirm that this method works, and works very well at that.  Very fast with no obvious impression on additional heap space requirements.

I've also been trying to use TYPE_BYTE_8_GRAY, TYPE_BYTE_332_RGB... but I get illegal argument exceptions.  Could anyone list the TYPEs which are accepted by recent nokia devices (or point me in the direction of where I can find some info on this).

http://ribot.co.uk - design agency focused on mobile
http://www.retrospecs.co.uk - online vintage eyewear store
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline shmoove

Junior Member




Doh!


« Reply #3 - Posted 2005-03-16 10:02:56 »

The 4444 and 8888 formats are the most common on the Nokia color phones. I still haven't seen a color model that didn't support 4444.
Using the phones native format (DirectGraphics.getNativePixelFormat()) will give you the best performance as no conversions will be needed.

shmoove
Offline Abuse

JGO Knight


Medals: 12


falling into the abyss of reality


« Reply #4 - Posted 2005-03-16 10:18:47 »

I ask again - why do you want to grab pixel data from the screen.

Why not just redraw the state of the current screen, to your own back buffer?

It is a far more portable, and infact far more reliable way of doing a screen capture.

Even using J2SE, this is how you should do screen captures!

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline ribot

Junior Member




Ribot - mobile UI specialist


« Reply #5 - Posted 2005-03-16 11:14:31 »

"I ask again - why do you want to grab pixel data from the screen." - because I need access to the pixel data to store into an RMS as an array or shorts.

I'm using 444 RGB (rather than 4444) because I want to try and store as little information in the RMS as possible.  Does it sound like i'm going through the right routes?

Your feedback has been much appreciated!

http://ribot.co.uk - design agency focused on mobile
http://www.retrospecs.co.uk - online vintage eyewear store
Offline Abuse

JGO Knight


Medals: 12


falling into the abyss of reality


« Reply #6 - Posted 2005-03-16 12:17:06 »

hmm, 12x128x128/8 /1024.

A screenshot on a series 40 will take up 24kb (assuming you arn't going to compress it)

Could you not store, and recall the current state of the program (for the screenshot), and use less than 24kb?


Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline ribot

Junior Member




Ribot - mobile UI specialist


« Reply #7 - Posted 2005-03-16 12:28:25 »

Abuse - I actually have a system that saves the state of all the environment and graphic object variables (user objects, swarm data, and other user data) - serialized to an RMS.  I'm having to test the pixel data method as the application I'm building is updateable via a network.  Users can download screengrabbed data objects, but going the state-based route - could potentially require a large number of other sprites to be stored on the device.  If the object is based on pixel data, the user will just need to download this and the network system would not need to check for any additional graphics to download.

Or maybe I'm just lazy?  Or not confident enough with the stability of httpConnections?  But you're right - image pixel data can potentially consume a large amount of space in the RMS.

http://ribot.co.uk - design agency focused on mobile
http://www.retrospecs.co.uk - online vintage eyewear store
Offline shmoove

Junior Member




Doh!


« Reply #8 - Posted 2005-03-16 13:02:34 »

Another option (how doable this is depends on how these images are created) that could potentially save you a ton of space would be to store the images procedurally a la vector-graphics. You said the image is just a bunch of circles and rectangles and lines, so you could store it as a bunch of instructions so that it can be reproduced (store each shape as a bunch of vertices+color info+fill or outline+brush style, and each image as an ordered series of shapes). This would mean that you would need to keep track of things while the users are drawing the images though.

shmoove
Offline ribot

Junior Member




Ribot - mobile UI specialist


« Reply #9 - Posted 2005-03-16 13:10:08 »

Thanks for the idea Shmoove!  Unfortunately, I've got lots of lovely little pixel graphics.  The circles and squares were just an attempt to simplfy my attempt at describing my situation.

http://ribot.co.uk - design agency focused on mobile
http://www.retrospecs.co.uk - online vintage eyewear store
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline ribot

Junior Member




Ribot - mobile UI specialist


« Reply #10 - Posted 2005-03-16 13:30:24 »

Ok, now that I've got a screen capture system to compare to my state-based system - I can now weight up the positives and negatives of both...

...I'm quickly coming to the conclusion that using TYPE_USHORT_444_RGB takes too much space.  Has anyone used TYPE_BYTE types with Nokia devices?  If so, which ones?  If I can use a byte array instead, the pixelgrab technique would just about win me over.

Many thanks.

http://ribot.co.uk - design agency focused on mobile
http://www.retrospecs.co.uk - online vintage eyewear store
Offline Abuse

JGO Knight


Medals: 12


falling into the abyss of reality


« Reply #11 - Posted 2005-03-16 14:20:12 »

Have you tried adding compression?

If you can accept a lossy screenshot (as I assume you can if you are considering TYPE_BYTE for the pixel format), you should be able to get a 24k screenshot down to around 2-4k.

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline ribot

Junior Member




Ribot - mobile UI specialist


« Reply #12 - Posted 2005-03-16 19:34:59 »

"Have you tried adding compression?" - Not yet, what's the best way to tackle this?  I could encode my own gif-based algorithm, but I'd rather not re-invent the wheel.  Any tips on compression?

Many thanks for all the feedback!

http://ribot.co.uk - design agency focused on mobile
http://www.retrospecs.co.uk - online vintage eyewear store
Offline Abuse

JGO Knight


Medals: 12


falling into the abyss of reality


« Reply #13 - Posted 2005-03-16 21:07:40 »

I'd just google for a jpg implementation.

Although, it'll probably use floats :|

You may have trouble finding 1 based on fixed point only.

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Grunnt (20 views)
2014-09-23 14:38:19

radar3301 (14 views)
2014-09-21 23:33:17

BurntPizza (31 views)
2014-09-21 02:42:18

BurntPizza (22 views)
2014-09-21 01:30:30

moogie (20 views)
2014-09-21 00:26:15

UprightPath (29 views)
2014-09-20 20:14:06

BurntPizza (33 views)
2014-09-19 03:14:18

Dwinin (48 views)
2014-09-12 09:08:26

Norakomi (75 views)
2014-09-10 13:57:51

TehJavaDev (108 views)
2014-09-10 06:39:09
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!