First J2me game

I finish my first MIDP 1.0 game this week and will be posting screen shots to my weblog…

I took a different route to porting to devices…

Devices like Nokia, Siemens and etc I take my MIDP 1.0 core code + closed apsi tha tmde it into 2.0 to prot to those devices…

On SonyEricsson its jsut changing image dimensions…

How is everyone else handling the mess of porting cdoe from one vendor to another?

oh and wlecome back fourm!

I was working on an experimental animation system (/engine) recently where I was using a kind-of vector driven system, which recalculated everything based upon the screen size (and that’s everything, including fps delay, pixel movement, and sprite shapes)… bresenham’s line algorithm rocks the world baby, yeah!!! Ahem. Sorry… got carried away there.

In any case, it proved to be a lot more difficult a task than I’d anticipated – and I’m still not convinced it’s the way to go for games. Not that it doesn’t work quite well – it does. On the P800 it looks awesome. On a GX10, quite good. And on the monochrome Nokia 8310i (I think that’s the model, but I can’t remember), it looks like absolute shite… as you would expect.
But it’s a lot of work to rejig your sprites into arrays of vector coords, and I haven’t looked into the actual memory usage doing things this way… like I said, experimental.

You do all this on the fly, when you have checked screensize after appstart? I’d guess this will get way too slow. I was working with fixed screensizes here and a preprocessor system. so I can generate code for different screensizes at compile time.

Yes everything was pre-calculated on app start. Startup performance was fine for my purposes, but yeah that was another reason I wasn’t convinced about it being a good idea. Go from 3 or 4 sprites in a simple animation, up to a couple of level maps, and 6-10 sprites needed for a game and startup time would probably degrade significantly. However I never actually tested that, so I don’t know. 1 second would be acceptable… 5 seconds not.

Your preprocessor sounds like a good idea though…

Are you working on a commercial project? Any chance for a collaboration?

Not a commercial product, but a commercial demo. It’s not going anywhere at the moment, so unfortunately I’ve got no chance for collaboration. Sorry.

Yap Vector graphics is a cool way when you have direct access to pixeldatas like on MIDP2.0, Nokia, Siemens, GX10 and some Moto. But on pure MIDP1 it is a little harder and slower. Bresenham isn’t the fastern a midpoint algo does best for speed.

My Engine MEE uses a wrapping system with Interfaces, and with a good optimizer and obfucator, these interfaces are replaced by classes for each targetted phones, using Ant.

Mik

looking forward to seeing your stuff.

Id imagine it would be nice to compile different versions for specific clients based on a config file? calculating vectors and graphics runtime sounds a bit hardcore.

Ya vector is hardcore or quit complexe to implements, I have tested some methods using flash or svg format not so smooth.

miklabs.com/wip for a sneak preview :o

Mik

hmm vectors…

I picked up Eberly’s 3D Game Engine Design book to research that method and some others…

But I do not think I will fully tackle until MIDP 2.0