Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (536)
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  
  XML on a mobile phone  (Read 1637 times)
0 Members and 1 Guest are viewing this topic.
Offline vredungmand

Senior Newbie




Java games rock!


« Posted 2004-08-14 16:37:04 »

I have just bought the new Sony Ericsson K700 and is quite impressed with it. The JavaVM is really fast and stable so the following is probably quite feasible but the question is whether it is a good idea.

I wrote an XML parser (see http://vredungmand.dk/programming/sjg_xml/) a while back that I use to parse configuration files in my applet games. The configuration files are more or less the backbone of my framework (see http://vredungmand.dk/programming/sjg/) and I get a really nice and flexible architecture from it.

The question is: Should I port the XML parser and use a similar scheme on J2ME? I can see the following alternatives:

1. Port the XML parser and let it work similar to the applet framework.
2. Write a step in the build process that convert the XML files into something that can be read faster (a binary data file).
3. Do configuration in the Java code. (I.e. mazes.add("maze1", "...........x...............x........xxxx..................."); ) possible generated by a build step.

I would like to program games for slightly less capable phones as well.

Any advice? Do you guys always sacrifice good architecture/design for speed when it comes to J2ME?

Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #1 - Posted 2004-08-16 07:14:57 »

Quote
Any advice? Do you guys always sacrifice good architecture/design for speed when it comes to J2ME?
Short answer:
[size=50]YES![/i][/u][/size]

Long answer:
Depends on how many devices you want to support, and how large your game is. But basically you'll want to avoid classes, accessor methods and so forth - make fields public instead of set/get and avoid anonymous classes (typically threads). You need to optimize graphics and the resulting jar file too - oh and get proguard, can't live without it.

Doing a basic shootemup or puzzle you could probably squeeze in an xml parser (of which there are many others). However, I would not recommend it. Depending on the dynamic nature of the game you want, you should try to preprocess the configuration into the game at compile time.

Offline vredungmand

Senior Newbie




Java games rock!


« Reply #2 - Posted 2004-08-16 11:03:56 »

Short answer:

[size=8]OH NO[/size]

I ported everything yesterday. The XML parser, the scripting engine and the decoupled-GOF-state-design-pattern-based-game-loop-screen thingee. Setters, getters, inner classes, threads? You bet. It is actually working but I think I will move the XML parsing to compile time as you suggest.

My target platform is the newest Nokia and S/E phones with minimum 128x128 screens. Basically I plan to take my full collection of applet games and port it to J2ME. Then sell them to the chinese and make a million dollars.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline vredungmand

Senior Newbie




Java games rock!


« Reply #3 - Posted 2004-08-16 11:05:35 »

In short, I will code as usual and then optimise later.

Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #4 - Posted 2004-08-16 11:28:33 »

As I said, it all depends on what you actually have of code resources.
Sure if you're doing "simple" games you could possibly store it all in the 64kB limit (Nokia, S40) - however for larger games this really becomes an issue!
The stuff I currently work on is a Multiplayer gaming platform with lobby support (private/public chat, ignore invitations etc.) and multiplayer games (including back end server). And let's just say that the amount of work done to cram this into 64kB jar (and 200 kB heap) is not insignificant. Using ~10k for config parsing is not an option for these situations.

Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #5 - Posted 2004-08-16 11:29:08 »

Quote
In short, I will code as usual and then optimise later.
Aye, but do get accustomed with a refactoring tool ;)

Offline vredungmand

Senior Newbie




Java games rock!


« Reply #6 - Posted 2004-08-16 16:00:27 »

java.lang.OutOfMemoryError ... hmmm ...

Offline vredungmand

Senior Newbie




Java games rock!


« Reply #7 - Posted 2004-08-16 20:06:26 »

The problem is not really the extra code. The parser is document based rather than a SAX parser. This means that the structure of the XML document is mimicked by an object graph, at least tripling the memory needed (the data file, the XML object graph and the actual objects (sprites, mazes, frames whatever)).

Anyway I got the applet Taleban vs. Robot (game: http://vredungmand.dk/games/taleban/ design doc.: http://vredungmand.dk/programming/sjg/taleban/) ported with the exact same design as the applet version. It runs perfectly but I can tell that I am definately pushing this little poor thing with XML stuff.

The jar size is 60 KB. I will move the parsing to compile time tomorrow. I am really happy that J2ME phones today are so good that you can actually do this sort of thing.



(Yeah - it was such a big moment that I had to take a photo of it.)

Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #8 - Posted 2004-08-16 21:24:08 »

The real issue with phones these days is that though you can do 90% of what you want properly - you'll also be spending 90% of your time pulling hair out because of some crappy j2me implementation. I have yet to meet a phone without somekind of weird issue - some worse than others :/
Whats really great is that if you can *choose* to only support x number of phones - alas, you'll probably need to be a corporate troll for that to be possible.

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.

CogWheelz (9 views)
2014-07-30 21:08:39

Riven (20 views)
2014-07-29 18:09:19

Riven (14 views)
2014-07-29 18:08:52

Dwinin (12 views)
2014-07-29 10:59:34

E.R. Fleming (32 views)
2014-07-29 03:07:13

E.R. Fleming (12 views)
2014-07-29 03:06:25

pw (42 views)
2014-07-24 01:59:36

Riven (42 views)
2014-07-23 21:16:32

Riven (29 views)
2014-07-23 21:07:15

Riven (30 views)
2014-07-23 20:56:16
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
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!