Java-Gaming.org Hi !
Featured games (81)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (119)
games submitted by our members
Games in WIP (576)
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  
  Resizing images in MIDP 1.0  (Read 1599 times)
0 Members and 1 Guest are viewing this topic.
Offline jbanes

JGO Coder


Projects: 1


"Java Games? Incredible! Mr. Incredible, that is!"


« Posted 2004-12-13 13:47:45 »

I'm curious if anyone has managed to solve the MIDP 1.0 issue with resizing game images to fit the screen. The only solution I've seen to date (see here) is extremely slow and rather wasteful.

I only ask because I have solved the problem, and want to know if anyone else independently developed the same solution. (Don't worry, I'll release it soon.) :-)

Java Game Console Project
Last Journal Entry: 12/17/04
Offline serdarso

Senior Newbie




Java games rock!


« Reply #1 - Posted 2004-12-13 16:14:40 »

I have did somethting before, it was relatively succesful. The method at the link is not a proper scaling as it just kindly duplicates the pixels by drawing them over and over again by slighlty shifting. I cant expect any good view out of it. We are waiting to see yours or least main logic beind it which is more interesting than the application itself.
cheers
Offline jbanes

JGO Coder


Projects: 1


"Java Games? Incredible! Mr. Incredible, that is!"


« Reply #2 - Posted 2004-12-13 16:47:33 »

Oh fine. Don't tell me then. ;-)

Ah well, it's probably the same thing. The code can be found here:

http://java.dnsalias.com/blockattack/source/ImageUnpacker.java

The concept behind it is quite simple. Pixel data is stored in my own proprietary format (see here) that produces smaller files than PNGs, and relies on the JAR compression to reduce the file size even further. The pixel data is then reconstructed into an image by using Image.createImage(width, height), then painting 1 pixel rectangles of the proper color.

From there, resizing is a simple issue to solve. The simplest solution is to scale the size of the drawRect() calls to "stretch" the pixels. This is the algorithm I'm using at the moment. But since you have the pixel data, and a way of reconstructing an image from it, there's nothing preventing the developer from using nice looking scaling filters.

So, is it the same? Different? Better? Worse? :-)

Java Game Console Project
Last Journal Entry: 12/17/04
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline shmoove

Junior Duke




Doh!


« Reply #3 - Posted 2004-12-14 08:05:26 »

Well, if you have access to the pixel data, then resizing becomes a lot more feasible, and I'm not talking about resizing by doubling, tripling, etc. the size.
If you're interested, you can try to use this code and fit it to the use of your own pixel format.

The biggest drawback with your method though, is that you can't have any transparent pixels because Image.createImage(int,int) creates a fully opaque Image to begin with. The only way around this problem would be to write a png encoder so that you can take your format and transform it into a png that does support transparency.

shmoove
Offline Abuse

JGO Knight


Medals: 13


falling into the abyss of reality


« Reply #4 - Posted 2004-12-14 09:42:58 »

If you are using a midp1 device that doesn't check the adler or crc32 checksums on png files, you could use a png that has an uncompressed zlib stream inside it, and Image.createImage(byte[]...).
You would then effectively have per-pixel access, the only cost would be a native mem copy during createImage(byte[]...)

If the phone did perform either the adler or crc32 checksums, I think you'd find the speed cost would be prohibitive, (not only would createImage have to check the crc's, but your code would have to generate them).

:edit:

btw shmoove, the resizing code was a very generous gift! =)

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

JGO Coder


Projects: 1


"Java Games? Incredible! Mr. Incredible, that is!"


« Reply #5 - Posted 2004-12-14 11:57:52 »

Quote
Well, if you have access to the pixel data, then resizing becomes a lot more feasible, and I'm not talking about resizing by doubling, tripling, etc. the size.
If you're interested, you can try to use this code and fit it to the use of your own pixel format.


Nice MIDP 2.0 code schmoove! Thanks for sharing that with everyone!

Quote
The biggest drawback with your method though, is that you can't have any transparent pixels because Image.createImage(int,int) creates a fully opaque Image to begin with.


That's a good point. Since my current game uses rectangular sprites, I'd forgotten all about mutable images being opaque.

Quote
The only way around this problem would be to write a png encoder so that you can take your format and transform it into a png that does support transparency.


Not to fear! There is another way! :-) What is needed is a "sliver" engine. The idea would be to scan the longest dimension into individual lines of pixels. By trimming the transparent area off of each line and saving the offset, you can draw the complete image on screen by looping through each sliver image. The method could be further optimized by grouping slivers that have the same length and offset.

Believe it or not, there is some precedent for such a design. Raycasting engines ala Wolf3D and Duke Nukem 3D make use of "scaled slivers" to produce 3D effects. The design is really an advanced form of 2D scaling for 3D effects that had been in use since the days of Pole Position. The primary difference in Raycasting was the addition of true spatial calculations (somewhat costly trig).


Quote
If you are using a midp1 device that doesn't check the adler or crc32 checksums on png files, you could use a png that has an uncompressed zlib stream inside it, and Image.createImage(byte[]...).
You would then effectively have per-pixel access, the only cost would be a native mem copy during createImage(byte[]...)


Abuse, I've often heard talk of this method, but I'm curious if you've ever actually seen someone use it? I tried stripping down a PNG encoder about a year ago, and I was not pleased with the results. The encoder itself can easily take up as much space as an entire game, and is rather tricky to code and test.

Java Game Console Project
Last Journal Entry: 12/17/04
Offline Abuse

JGO Knight


Medals: 13


falling into the abyss of reality


« Reply #6 - Posted 2004-12-14 12:58:38 »

A number of games I have ported have used it.
However, most have simply used it so they can access, and swap the palette for a png, I havn't yet seen one that has used this method for manipulating the pixel data.

I have written a light-weight png encoder/decoder, it realy is quite easy - the png format lends itself quite well to a small implementation. (The only exception to this, is the use of 2 diffferent CRC methods - which is a right pain in the arse)
All in, its a few hundred lines.

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.

Longarmx (38 views)
2014-10-17 03:59:02

Norakomi (28 views)
2014-10-16 15:22:06

Norakomi (24 views)
2014-10-16 15:20:20

lcass (28 views)
2014-10-15 16:18:58

TehJavaDev (54 views)
2014-10-14 00:39:48

TehJavaDev (54 views)
2014-10-14 00:35:47

TehJavaDev (43 views)
2014-10-14 00:32:37

BurntPizza (64 views)
2014-10-11 23:24:42

BurntPizza (36 views)
2014-10-11 23:10:45

BurntPizza (78 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

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
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!