Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (579)
games submitted by our members
Games in WIP (500)
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  
  TiledLayer - implementation question / suggestion  (Read 2333 times)
0 Members and 1 Guest are viewing this topic.
Offline ameano

Senior Newbie




abstract void


« Posted 2005-02-21 09:34:49 »

Hi All

I was just wondering would it not have been better if Sun used a byte for each of the cells in tiled layer or even better short? I mean a short only consumes 2 bytes as opposed to the 4 bytes of an int.

Assuming you have 4 layers of 64 * 64 bytes, thats 16k worth of heap memory being used... Does TiledLayer use any form of compression?

I personally don't think there is any need for int values as noone is going to be able to fit 4 billion tiles in their game anyway...

Is is just me or does anyone else agree with this? Huh
Perhaps we could write our own ByteTiledLayer or ShortTiledLayer implemenation...

Regards
Ameano

Ameano
rules are there to be broken... same goes for the rules of programming classes in j2me
Offline Abuse

JGO Coder


Medals: 10


falling into the abyss of reality


« Reply #1 - Posted 2005-02-21 16:08:54 »

From a performance perspective, the Sun implementation of javax.microedition.lcdui.game package is abysmal anyway.

I've seen very few games that have used it.

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

Senior Newbie




abstract void


« Reply #2 - Posted 2005-02-22 07:38:24 »

Ok, well I've been thinking about the advantages and shortfalls of the Game package... I'm new to games programming and j2me but not programming. so what your saying is that its better i write my own tile/ scene management routines?

Sprite / GameObject is one I will definitely I look into, but the inclusion of frame sequences is quite useful and makes things really easy... I suppose setClip can be used, but I have heard it causes problems...

Ameano
rules are there to be broken... same goes for the rules of programming classes in j2me
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline davidaprice

Junior Member





« Reply #3 - Posted 2005-02-22 07:42:03 »

Quote
From a performance perspective, the Sun implementation of javax.microedition.lcdui.game package is abysmal anyway.

Surely what's relevant is the performance of each phone manufacturer's implementation of the game API? Are they all equally abysmal? I've used TiledLayer myself and always been satisfied with its performance, but I'm not a commercial game developer. It seems like it ought to be possible to make a fast native implementation, and save lots of off-screen image memory at the same time (compared to the MIDP 1.0 solution of creating an offscreen background image from the tiles).

Quote
I've seen very few games that have used it.

How can you tell if they use it? I've not seen the source code of the popular J2ME games. Is it maybe just that so far, commercial games must be compatible with MIDP 1.0 to reach the widest market, so they can't use the game API at all?

Not arguing, just very curious about this...
Offline ameano

Senior Newbie




abstract void


« Reply #4 - Posted 2005-02-22 07:45:36 »

or even better do you know of any better packages? Or do you code your own?

Thanks

Ameano
rules are there to be broken... same goes for the rules of programming classes in j2me
Offline ameano

Senior Newbie




abstract void


« Reply #5 - Posted 2005-02-22 07:54:56 »

also in response to davidaprice, is the performance you have gained based on an emulator only or tested on actual devices?

and how many layers do you typically have, how big and how many sprites does your game deal with?

Regards
Ameano

Ameano
rules are there to be broken... same goes for the rules of programming classes in j2me
Offline davidaprice

Junior Member





« Reply #6 - Posted 2005-02-22 08:00:33 »

It's actually really easy to code your own Sprite & TiledLayer package using just the MIDP 1.0 APIs. For Sprites, have all the animation frames in one long horizontal PNG image, and draw the required frame by clipping to the size of the sprite and drawing the image offset left by the required number of frame widths. For TiledLayer, use the same trick for the PNG file of tile images, and create a big offscreen image of the background by creating a blank image and drawing the required tiles on it using the same clipping trick.

MIDP 2.0 Sprites don't really give you much. The TiledLayer potentially avoids the need for the big offscreen image, depending on how the manufacturer implements the API. You also can have transparency in the TiledLayer, which isn't possible in MIDP 2.0 since the blank offscreen image starts opaque white. If you have multiple TiledLayers scrolling at different speeds (nearer ones faster), you can get a pseudo-3D effect.
Offline shmoove

Junior Member




Doh!


« Reply #7 - Posted 2005-02-22 08:10:02 »

Quote

Surely what's relevant is the performance of each phone manufacturer's implementation of the game API? Are they all equally abysmal?

The problem here seems to be that Sun's reference implementation is very innefficient (it draws all the tiles, even if they are not onscreen), and many manufacturers have apparently just used that implementation as their basis and didn't bother to optimize it for performance. I personally haven't used the Game API much (we are from the use as much MIDP 1.0 to reach a wider market philosiphy), but I've heard a lot of people complain about it's performance on a wide variety of phones. Hopefully the newer phones that come out will fix this issue. The Sprite object is OK, but the LayerManager classes tend to be poorly impelmented.

shmoove
Offline caraiz

Senior Newbie




Java games rock!


« Reply #8 - Posted 2005-02-22 09:47:28 »

I had done some tests in differents mobiles, and normally TiledLayer is sooo slow, only at Motorolas seems run ok.
The problem is that in almost all mobiles fill the screen with small images is slow, and i suppose that TiledLayer is doing this.
So its better implement a backbuffer where draw the visible tiles and redraw the tiles which change when u do scroll, so u can get almost the same speed than draw a image with same size that screen.
This is, u can pass easily from 12-15 fps to 40-50 fps...

Offline ameano

Senior Newbie




abstract void


« Reply #9 - Posted 2005-02-22 09:59:36 »

so its just to stick to midp 2 now?
what about gamecanvas that has a lot of useful stuff, such as querying key states??


Ameano
rules are there to be broken... same goes for the rules of programming classes in j2me
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline ameano

Senior Newbie




abstract void


« Reply #10 - Posted 2005-02-22 10:20:06 »

ok even i didnt understand my last statement...

so isit best to stick to midp 1 for now, considering most people dont even have midp 2 phones... i have a nokia 6600 which ive had for more than 1 year, runs midp 2 but not a lot of phones do...

what about gamecanvas that has a lot of useful stuff, such as querying key states?? no?

Ameano
rules are there to be broken... same goes for the rules of programming classes in j2me
Offline Abuse

JGO Coder


Medals: 10


falling into the abyss of reality


« Reply #11 - Posted 2005-02-22 10:37:55 »

From the perspective of portability, there is very little functionality in midp2 that cannot be replicated in midp1 quite easily.

The thing you should steer well clear of, is using Graphics.drawRGB, and Image.createRGBImage.

Extensively using these can make porting to midp1 phones *alot* of work.

getKeyStates realy isn't very useful either, its functionality is easily replicable through keyPressed/keyReleased and some state flags. Also, there are a few midp2 phones that simply do not honour the contract of that method (and simply return 0).

Stick all your sound & vibration code in a seperate class, as  sound playing is the most unportable feature exposed in J2ME.

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.

xsi3rr4x (37 views)
2014-04-15 18:08:23

BurntPizza (33 views)
2014-04-15 03:46:01

UprightPath (48 views)
2014-04-14 17:39:50

UprightPath (31 views)
2014-04-14 17:35:47

Porlus (48 views)
2014-04-14 15:48:38

tom_mai78101 (69 views)
2014-04-10 04:04:31

BurntPizza (129 views)
2014-04-08 23:06:04

tom_mai78101 (229 views)
2014-04-05 13:34:39

trollwarrior1 (193 views)
2014-04-04 12:06:45

CJLetsGame (200 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
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!