This is the 4k competition... It is meant to be fun making them... all this bickering about how it is to be scored seems silly...

The way i see it, the competition is to attempt to create a game in 4k, i.e. the competition is your skills vs that 4096 byte barrier! Gaming is such a subjective thing that I would not hesitate to say that there is no "best" game that is produced.

I definetly do not go into the competition to "win" I go into the competition for the challenge and to see what my "best" can produce. If other people like my game then that is nice, but not a large motivator for me.

Was there from the beginning - 3rd post, 3rd post, and 2nd post in each years Thread =)

Only competed in the 1st & 2nd years though - maybe i'll make a return this year!Have so many ideas.... just need the time (and conviction) to see them through.I wish programming wasn't my job - I'd enjoy these competitions so much more! =/

You can use lightweight Swing components independently of the heavy weight AWT framework, it just takes abit of fiddling.

However, Swing rendering was never written with efficiency in mind - it tends not to be such a bottleneck when you have a passive (dirty) repaint system.If you used them in an actively rendered game, you may find them to be too inefficient.

The logic behind construction of an expression is fundamentally less complex than programming, only the obtuse syntax scares people off (and rightly so IMO).Give me an eclipse GUI plugin for building & maintaining them, and I might use them for more than trivial string spliting.

Has anyone managed to get the eclipse "detail formatter" working when debugging a midlet in the WTK?I simply receive a "java.lang.UnsupportedOperationException occurred invoking method." when eclipse tries to evaluate an Object type.

I've tried overriding the default detail formatter behaviour of calling "toString()", but it seems as though having any kind of statement in the detail formatter, that requires access to runtime will cause it to fail.

In addition to this, there are several problems with conditional break points.

1) Conditional break points cannot contain references to named constant values. (e.g. public static final int CHEESE = -1;)If they do, an "Exception processing async thread queue java.lang.UnsupportedOperationException" will occur when the break point is encountered.

2) If you break midlet execution,setup a conditional break point,disable the conditional break point,resume the emulator,re-enable the conditional break point.Eclipse will lose its connection with the emulator, resulting in the emulator hanging (presumably awaiting a response from eclipse)

Can anyone offer work-arounds for any of these limitations in the WTK emulator?

The only solution I can think of, is to completely throw out the WTK, and replace it with a few sets of midp libraries that are built upon J2SE, and run within a standard J2SE VM.As the additional features offered by the WTK are all but useless anyway, I think such a solution would stream-line development enormously.I'm amazed there isn't an open-source project that has attempted this already???

LooL !!! You can post your code and I'll tell you what is wrong. The main thing is that the variable code (int code = key.getKeyCode() can remeber only one value. So when you press a new button code it will change into the code of the last button pressed and it won't remember that you are still holding down the previous keys. When you use the boolean variables you don't change the up value into false because you just pressed left.I hope you understood ! I'm not sure I would understand what I wrote:)

That is not the reason at all.

The line "int code = key.getKeyCode();" in the first code example is storing the key code in a local variable. Even if pressing a second key caused a 2nd thread to simultaneously deliver another KeyEvent (which for the record - NO common VM does), it would still function fine.

To the original question.

Are you using Linux or Windows?KeyEvent delivery is bugged in Linux - and have been for the best part of 10 years.In Windows, you recieve the following sequence of events :-

<key is pressed down>keyPressed...keyPressed...keyPressed...keyReleased.<key is released>

In Linux, you recieve :-

<key is pressed down>keyPressed...keyReleased.keyPressed...keyReleased.keyPressed...keyReleased.<key is released>

If that isn't the cause of your problem, then I can only guess it is something else wrong in your code.p.s.may I suggest you use a switch statement instead of dozens of if/else's. It will improve the readability of your code.

oh, i thought opengl pipeline causes crashes with radeon series ! I read that on a lot of forums. I have an application which runs with the opengl pipeline enabled, it works fine for me (i have a nvidia card) and it doesn't work for a friend (he has an ati card).So, i don't understand

A driver update might help, but I too have found the OGL pipeline to be extremely flakey on ATI cards - even with the latest drivers.

At work, we migrated our CVS repository over to SVN without doing sufficient background research into the quality of SVN clients, and have on occasion been handicapped by the short-comings of various SVN clients.

The 2 we use are subclipse (for eclipse projects), and tortoiseSVN (when subclipse breaks).We end up resorting to tortoise all too often, due to the many bugs in subclipse. This is extremely frustrating having previously used the eclipse CVS plugin - an absolute joy to use, a wonderful piece of software.Subclipse can on occasion also be painfully slow; especially on machines with slow hard-drives;it appears to thrash the disc alot more than any CVS client ever did. (the dreaded "Updating SVNStatusSubscriber")

On several occasions we've also come across a fairly serious SVN server-side bug when performing merges between 2 branches involving files that have been deleted, and then recreated.

So - rant over - to my intended question

What SVN client do you all use?How heavily do you use them?and do you find them to be frustratingly buggy also?

Version control software is the last place you want bugs to appear,From my experience, I struggle to recommend SVN over CVS - especially if you are an eclipse user on a mid-range PC.

Does JBuilder not have a background compiler???I thought that was an absolutely pivotal feature of any advanced IDE;otherwise, you lose all kinds of life/time-saving features (code navigation, refactoring, automated code generation, typed searching, heirarchy visualizing etc etc etc)

End Task in task manager forcibly shuts down the process on Windows. Your application doesn't get a chance to do anything, as far as I know.

'End Process' has the behaviour you describe there.

'End Task' appears to behaviour in a near identical fashion to Command+Q.I assume it sends a message with the meaning of "please terminate the application soon", because if the application is still active in 5 seconds time the OS assumes it has stopped responding and pops up its own dialog querying whether you wish to forceably terminate the application.

I was completely unaware of the Mac's standardized mechanism for displaying certain menu items; it is interesting that Swing hasn't yet addressed this limitation.A great reason to design applications so they are sufficiently intuitive to not require menu bars! =)

By the sound of it, Command+Q is equivalent to clicking "End Task" in task manager?

If that is the case, unless you specifically want to remap or disable the functionality of Command+Q, should the shutdown code not be performed using the platform independant mechanism exposed through shutdown hooks?e.g.java.lang.Runtime.getRuntime().addShutdownHook(new Thread(new CustomCleanerupper()));

hmm, you're gonna need to add little ai to your ghosts, like that they don't turn in way they came from and that they mostly move towards player (or if they see him in the distance). But first I suggest you try just random movement at intersection, equal chance of going all ways.

This is what I'm trying to do with my Platform libraries - you write your game to the Platform API, then link with the Applet lib for a web game, the Nokia series 60v1 for s60 midp1, s60v2 for midp2, the vodafone lib for sharp gx's, and so on.

I then distribute the game, and as part of that process it gets tested in an operator lab so we're sure it works on all handsets prior to release.

The only drawback is only the very best games will get published, as there's so much mediocre stuff out there already.

I suppose I should get round to writing a proper thread about this =)

The overhead of an abstraction layer is significant, you will need a strategy to reduce this overhead to a bare minimum for a portable development framework to be practical.There are 2 paths such a strategy can take; heavy use of a pre-processor; or byte code engineering.The choice depends on your available toolset and the development tools you rely on.

Conventional compatability testing will give you a list of buggy methods for a particular device.

Now with the awful quality of J2ME API implementations, I have begun to think this is the wrong way around.It would be easier to list the API methods, and against it list the handsets on which the method is faulty.

For a little fun (and also a little education!), I propose we begin a Thread to achieve this.One person will state an api method (fully qualified!) ,and others *race* to respond with a device on which said method behaves incorrectly. (and how it behaves incorrectly)The first to respond gets to select the next method! =)

So, what do you all think? =)

If someone is willing to select a method to kick us off?

For the sake of fair-play; lets keep the API set to just the major ones, say :-

Anyway, I had a bit of fun with J2ME and MIDP 2.0 trying to develop a simple game.The main reason I liked it was because it introduces you to basic game techniques but is also relatively simple to use.

What I would like to know is, how do you make sure your game is compatibleacross all mobile phones that run J2ME? I've heard that professional game developers have to compile about 200 versions of any one game.

So I guess my question is, as a bedroom coder, is it possible to make a fairly compatible game without buying 200 phones to test them on? Can it be done with software emulators? How do people with tight or non-existent development budgets make their games compatible?

Cheers,

CM

Basically, you can't.

The best you can hope for is to sell your idea/prototype game to a larger company to develop.

The fragmentation in the market is horrendous, the resources needed to get even a fairly trivial game available on a sufficient number of handsets for one of the carriers to consider putting it on their decks is tremendous.

The subset of midp/cldc that you can rely on as functioning correctly across all handsets is non-existant, I don't think there is a single method in the entire API that hasn't been incorrectly implemented in atleast one handset.

Depends on the handset, and whether you intend to support flipping in your tileset.

You should definitely implement a layer of abstraction, so you can render through various APIs (and various mechanisms within said APIs) without having to rewrite any core game code.

A few notes you will find useful :-

Nokia

1) drawPixels on Nokia Series 40's is approx. 3 times faster than drawImage. (though I believe it is due to the implementation of drawImage having its performance dependant upon the size of the source image).2) drawPixels is broken on Platform 2 series 40's. (it doesn't honour clip areas correctly, and under certain cirumstances will blow up with an AIOOBException)3) storing your images in raw 4444 pixel format in the jar will result in the images consuming ~10-15% more jar space.4) drawRegion leaks lots of memory very quickly on midp2 S60's.

Samsung

1) drawRegion is inconsistently buggy across the many different handsets. The general rule is that, only mirroring, flipping and both together work. Though each handset appears to be broken in different ways.For example, the Samsung D500 can do all 8 transforms - so long as the region of the source image being drawn (in the target coordinate system) does not extend beyond 176 in either X or Y axis'. (co-incidence the screenWidth is 176? I think not...)The Samsung D600 breaks in a completely different fashion, if the target area of the drawRegion intersects any screen edge, and the transform being performed is a rotation, the source image will become corrupted, and garbage will be drawn to the screen.

The list goes on and on, it is comical how pathetic the phone manufacturers are at implementing a trivially straight-forward API such as midp2.I realy think Sun need to get their arses in gear, and enforce some kind of quality control on JVM implementations that *claim* to support a certain API - when they clearly don't.

The most reliable, most consistent, and best performing midp implementations are easily SonyEricsson.The high-end Sharp handsets (902SH and similars) are also very good, which is odd after the early handsets were so poo.

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