nice game I worked out the first 5 characters by simply trying. For the others I had to use your dictionary-link to get an idea of how to do this.*never knew anything about japanese letters - now I do

it gets a bit boring for later levels, because it's simply always o e u i awith only different consonants before - and you even get those with using that page

Or does this change for later levels - I've never got that far - 'ne' was my highest - but I think with some more playing I would get better

you could also let the letters that come in the level pop up before the level starts for e.g. 5 sec, so people see them before playing, which might result in better remembering and more positve results while playing.In the end I only worked down the combination and actually didn't pay any attention to the letters.

it gets a bit boring for later levels, because it's simply always o e u i awith only different consonants before - and you even get those with using that page

It doesn't really get harder because otherwise the player would not get to practice the hiragana on the higher levels much.

Quote

you could also let the letters that come in the level pop up before the level starts for e.g. 5 sec, so people see them before playing, which might result in better remembering and more positve results while playing.

It's a good idea, but including 47 bitmaps in the 4k has left me a bit pushed for space. Perhaps, if I can crunch things a bit more.

You should SuperPack it. Used correctly in cunjunction with 7Zip, I guarantee that it will reduce the size of your program.

I'll take a look at doing that (or something similar) this coming weekend. Currently, all the images are in a single 1bit depth png with transparency. Several tools were tried to shrink that png; pngcrush was the most effective by a good margin. However the resultant file is only about 50% of the size of the raw bits, so it should be possible to do better by inserting the data as strings or longs into the main class. Hopfully netbeans is up to the task. I managed to crash it by pasting in an entire music track as 'longs' on a single line. It was ok as a number of shorter lines. Not that there's been room for sound in anything produced yet.

I also need to investigate why the ships are invisible on OS X. Either the images are not loading, or more likely, there's a compositing problem. First invisible monsters, then invisible cars (both now fixed) and now invisible aliens. Maybe I should write a game where invisibility is part of the gameplay, since it appears (sic) to be so easy

Netbeans doesn't need to do anything. The string is inserted automatically into the compiled file. It looks for a String that has the value "$data" and replaces it with the nibblized data.

Quote

I managed to crash it by pasting in an entire music track as 'longs' on a single line. It was ok as a number of shorter lines. Not that there's been room for sound in anything produced yet.

The problem with using long arrays is that Java creates a constant index for each of those values, then creates a load instruction at the beginning of the program for each element of the array. Java arrays are a lousy way to keep your size down. :-(

Quote

I also need to investigate why the ships are invisible on OS X. Either the images are not loading, or more likely, there's a compositing problem. First invisible monsters, then invisible cars (both now fixed) and now invisible aliens. Maybe I should write a game where invisibility is part of the gameplay, since it appears (sic) to be so easy

The SuperPackME decoder (see Decoder.java) is guaranteed to work on OS X. (It should, I developed it there!) The key is to use the GraphicsDevice.createCompatibleImage() call instead of specifying your own image format.

Just draw the image using what ever characters you like. Try to use the same ones for all images so they compress well.Then set the color of each character. No need to set the transparent character as it is 0 any way.

The simplicity of the creation of the image plus letting the zip utility do all the work of compressing seams to win. At least for my images. Don't forget to change the 9 to match what ever image size you need.

If the source and destination areas are the same size, i.e. no scaling is required, then the library treats it as a special case and renders it much faster. Unfortunately the special case code ignores the 'bgcolor' parameter and leaves the background colour unchanged.

To work around this problem either requires splitting the sprites up into separate images, allowing drawImage(img, x, y, color, null) to be used, which does work, or prefilling the background of each sprite with drawRect(x,y, width, height). The latter is a bit nasty, but might be possible.

/Edit: Nasty kludge incorporated to support OS X. Hopefully works on the Mac now.

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