Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (754)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (842)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1]
1  Java Game APIs & Engines / J2ME / Re: How do you ensure portability? on: 2006-08-09 11:28:38
I just found this:

Does anyone know anything about it?
2  Java Game APIs & Engines / J2ME / Re: Image manipulation on: 2006-07-30 10:25:51
RGB->HSL & HSL->RGB code is up and running. If anyone is interested in it, let me know and i'll mail or post the code for you.
3  Java Game APIs & Engines / J2ME / Re: How do you ensure portability? on: 2006-07-30 10:20:31
J2ME Polish ( is supposed to (though I havn't tried it myself) ensure compability and more.
4  Java Game APIs & Engines / J2ME / Re: TiledLayer & blit performance on: 2006-07-25 11:20:03
Wow thanks a lot Anon666!

I read in an article in may that at least motorola is making some effort to make life easier on us developers for midp 3.0. But as long as the midp 2.0 handsets are still out there (which they will be for long still) one will always have to concern oneself with backwards compability. That's why I'm considering to use j2mepolish ( for upcoming projects, has anyone got any experience with it?
5  Java Game APIs & Engines / J2ME / Re: Image manipulation on: 2006-07-24 13:01:33
OverKill: I thought it'd be impossible to have the game im designing midp 1.0 compatible but I'm going to read up on how they differ before i decide that. Maybe the real question is if the midp 1.0 handsets have enough heap.. Im not sure what you mean by all devices but I'll of course try and make it compatible with as many as possible.

Too bad that game development companies don't share bug lists or ideas & source code for that matter among each other, it would benefit the mobile games and therefor the market as a whole and I don't think anyone would loose anything on it really.

I might try using DirectGraphics for the 3650 and 7650 models although ive read some threads that it wount solve the problem (while others believe it does help).

I got the png palette manipilation working last week including, recalculating checksums. I've implemented a few simple functions (e.g. colorize) so far but I havn't begun working with the RGB<->HSL conversion yet.
6  Java Game APIs & Engines / J2ME / Re: TiledLayer & blit performance on: 2006-07-24 11:00:56
Thanks a lot guys, I'm on it! I guess there is a lot of cpu to be saved by making one large blit instead of many small.

I just need to get one more question answered, please.. If I implement my own renderer (I suppose I'll be using an instance of Image for the back buffer), what method should I use for the blitting operation? Graphics.drawImage(), Graphics.copyArea(), Graphics.drawRGB() or something else?

Great forum by the way, I hope i can contribute somewhat.
7  Java Game APIs & Engines / J2ME / Re: Image manipulation on: 2006-07-18 14:30:56
Seems like I've got some things mixed up, let's see.

In our experience the 6630 and 6680 do not have any problems with transparency, the 2 are infact considered near-compatibles.
I'm refering to bug 2.21 in the 2nd Edition Platforms Known Issues v2.9 pdf that affects S60 2nd Edition, FP2 and FP3, all S60 2nd Edition, FP2 devices, Nokia N90 (SW 2.0530.3.5). Now that I look at it again I realize that it concerns the Nokia M3G (JSR-184) implementation, and since Im not dealing with 3D i guess I shouldn't worry about it.

To my knowledge the 6600, 6630, 6680 ect do not leak memory on image creation. (unlike the 3650, and 7650 which leak loads).
My bad, I got that impression from a thread on So the 3650 and 7650 are the only handsets with createImage problems?

Drawing images with drawRegion(with transforms) on the 6600 & 6630 will however leak memory, and will cause application slow-down and eventual crashes after a few 100,000 invocations. (less than a minute of application execution)
I'm not currently using drawRegion but does this leak affect other any functions, i.e. are there other functions (e.g. Sprite.paint or TiledLayer.paint) that uses drawRegion?

On a side note, Thread.yield() has issues on some handsets.
Thanks, I'll use sleep(), for 20-50ms as adviced in the Known Issues In The Nokia 6600 MIDP 2.0 Implementation pdf instead.

In general, I would suggest stearing well clear of getRGB & createRGBImage - it will almost certainly cause you no-end of compatability issues.

A superior alternative would be to perform the color filtering before the png is created - operating on the PLTE chunk of the raw png data.
This will be alot faster (as you will be able to operate on the palette directly), and will not be prone to any device issues. (in the vodafone drop list, there isn't a single handset that doesn't support transparency in png images)
The png format is simple to manipulate, and well documented - it should not take more than a few days to implement what you are wanting.

I believe we already have some code to do modulation of png palettes (for colorizing monochrome graphical fonts), unfortunately, its not my IP, so I can't simply give it away. (and certainly not for comercial purposes Sad )
Im going to take your advice and stay clear of createRGBImage and getRGB, they really seem to cause nothing but problems. Apart from the max 4k pixels bug on Nokia 6600 this method will result in a considerable heap usage peak which will make lots of older handsets run out of memory.

I had a brief look at the official png specification at a while back and it seemed like it would take some time to figure out how the modify the PLTE chunk and fix the CRC and such. So if you have any links to threads, articles or tutorials on that it would be really appreciated. As for the color manipulation bit, there are lots of code and pseudo code available that converts RGB to HSL and vice versa but they are all using floats which is not supported by the J2ME. But I don't think that will be so much of a problem and I'll make sure I'll post the integer RGB<->HSL functions here when they're done in case anyone else is interested. Making a commercial game doesn't mean you can't share your code or ideas with other developers, just that you try and earn some money in the process. We are actually discussing if we should distribute the games for free on our website in addition to the commercial distribution.

Thanks for the response!

8  Java Game APIs & Engines / J2ME / Re: TiledLayer & blit performance on: 2006-07-18 13:21:14
Thanks for the reply Anon666!

Dynamic origin quadrant back-buffer sounds mighty fancy  Grin What API function do you use for the blitting? Does the Sprite.paint() function suffer from the same varying performance as does TiledLayer.paint()? I find the sprite transformation to be really handy - the biggest drawback of TiledLayers is that you cannot mirror your sprites. But i suppose that if one hopes to get some decent performance the gfx has to mirrored and stored in some buffer first to be blitted normally.
What do you mean by "I suggest you write your own optimised renderer - perhaps using a back-buffer"? I use backbuffering but just the the only way that affects things is that i call myGameCanvas.flushGraphics() to flip the buffers, nothing else.
9  Java Game APIs & Engines / J2ME / Image manipulation on: 2006-07-17 11:28:56
In our upcoming game we (SLX team, GBG Sweden) plan to use "post processing" on tilesets and sprites, i.e. we'll apply filters modifying Hue, Saturation, Lighting and such after an image is loaded.

//Pseudo code
int[] pixels = new int[width*heigth];
img=null; System.gc(); Thread.yield();   //To save some heap before recreating image
Image dest = Image.createRGBImage(pixels, width, height, true);

This poses a few problems. I hope to get some feedback before we start off the development process, and I'd like to share some thoughts as well.
First off, the code above will require a lot of free heap memory. It is a good idea to load image data in order of descending size to avoid out-of-memory errors.
Then there is the issue of phone model compatibility. Due to a buggy java implementation getRGB() and createRGBImage() will not work on Nokia 6600 and Nokia 7610. Since I plan to load-release-reload a lot of gfx the Nokia Series 60 phones (6600, 6630, etc.) will run out of memory eventually because of memory leaks. I also know that Nokia 6630 ignores all types of transparency; Nokia 6680 handles raw alpha channels correctly, but ignores color-key and palette transparency. What other bugs on these or other phones should one be aware of? We really should have a common list of known issues in J2ME implementations so one easily can get an overview.

As this is a commercial project, we aim to have the game compatible with lots of phone models, do you think this is all impossible if we use these post processing techniques?
Feedback please!

Mathias Johansson
SLX Entertainment
10  Java Game APIs & Engines / J2ME / TiledLayer & blit performance on: 2006-07-17 10:02:01
Hello everyone!

Im planning to develop a game which will require numerous TiledLayers (around 3 or 4) for rendering. This means that most tiles in many layers will be fully transparent (tile index 0). I suppose TiledLayer.Paint() looks something like this:

//Pseudo code
for (x=0;x<this.cols;x++)
   for (y=0;y<this.rows;y++)
      if (this.tiles[x][y]!=0)

So for each TiledLayer this double loop will be executed each frame although blitTile() will only be executed a few tiles since most tiles are transparent. My question is: Will this generate a performance overhead - or is the cpu needed for the loop negliable as compared to the blit operations? If this is an overhead, could i increase performance by not using TiledLayers and instead blit a list of tiles for each layer using Sprite.paint(), Graphics.drawImage(), Graphics.copyArea(), Graphics.drawRGB() or something like that? Or is TiledLayer somehow magically optimized?

Nice forum by the way, first post for me here. Peace!

Mathias Johansson
SLX Entertainment
Pages: [1]
DesertCoockie (20 views)
2018-05-13 18:23:11

nelsongames (68 views)
2018-04-24 18:15:36

nelsongames (65 views)
2018-04-24 18:14:32

ivj94 (748 views)
2018-03-24 14:47:39

ivj94 (79 views)
2018-03-24 14:46:31

ivj94 (555 views)
2018-03-24 14:43:53

Solater (94 views)
2018-03-17 05:04:08

nelsongames (168 views)
2018-03-05 17:56:34

Gornova (338 views)
2018-03-02 22:15:33

buddyBro (998 views)
2018-02-28 16:59:18
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05 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‑
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!