Using an image for my font (J2ME)
Author
Hi guys,
I'm making a mobile phone game using J2ME (as some of you may already know) and at the moment, we are using the phones in built fonts to display our text.
I was about to start changing that so that we use a bitmap image for the characters, but I wanted to get some advice before implementing it and then finding it doesn't work properly on handset X or using firmware Y etc.
So any information you can give me on the subject would be greatly appreciated. I've had a couple of searches on google but I havn't found any golden nuggets of information.
I'm most interested in the various ways people have done it, and which way is the most portable, and also, any tools or software I would need (or would just make my life easier)
Any links to good articles/tutorials on this would be very helpful
Thanks,
Multiverse
there's no silver bullet [wink]
usually, it's done by reusing the sprite class (if you have one) and adding drawstring-like methods to it. you will also need a byte array to map characters ascii code to the sprite cell index (static or loaded from resources).
also, you will have the choice of having an image for each char multiplied by number of palettes (this works ok on most of the phones) or to have an image (for each palette) containing all the chars. however, you'll have to chose depending on the phone capabilities: some phones dont like to create many images (either because they have a limitiation to this number, or because it will cause memory fragmentation or whatelse) while others dont like big images.
usually, it's done by reusing the sprite class (if you have one) and adding drawstring-like methods to it. you will also need a byte array to map characters ascii code to the sprite cell index (static or loaded from resources).
also, you will have the choice of having an image for each char multiplied by number of palettes (this works ok on most of the phones) or to have an image (for each palette) containing all the chars. however, you'll have to chose depending on the phone capabilities: some phones dont like to create many images (either because they have a limitiation to this number, or because it will cause memory fragmentation or whatelse) while others dont like big images.
It's pretty much the same as doing a bitmap font on any other computing device. Have a strip of how ever many characters you need and draw them next to each other to display text. Obviously memory limitations or image limitations might cause problems.
Author
Thanks guys
@pkelly83, yeah, i knew it would be similar, I just don't want to write something, find it not working and then somebody tell me 'it doesn't work because nokia phones dont blah blah blah'. I'm sure everyone whos wrtten a J2ME game has experienced that. ;)
@werekarg, I was planning to do the first of your suggestions, one thing that I'm not too sure about though is how to include non-ascii characters (for example, the copyright symbol). I could just define their codes but i'm not too sure about doing that since I need to support quite a few non-ascii characters and things could get quite messy. Any ideas on what to do about that?
@pkelly83, yeah, i knew it would be similar, I just don't want to write something, find it not working and then somebody tell me 'it doesn't work because nokia phones dont blah blah blah'. I'm sure everyone whos wrtten a J2ME game has experienced that. ;)
@werekarg, I was planning to do the first of your suggestions, one thing that I'm not too sure about though is how to include non-ascii characters (for example, the copyright symbol). I could just define their codes but i'm not too sure about doing that since I need to support quite a few non-ascii characters and things could get quite messy. Any ideas on what to do about that?
have a look at this: ascii iso 8859-1 iso 8859-1 is the most common encoding, supported by almost all mobile devices.
the byte table will have 256 entries. the 169th entry - (c), for example, will keep the value of the sprite cell index representing (c). of course, not all entries will be valid, since you're not going to need all the characters from 127 to 255.
this encoding is valid only for several languages (most common, fortunately). if you plan to port for...russian, you'll have to look into unicode stuff.
the byte table will have 256 entries. the 169th entry - (c), for example, will keep the value of the sprite cell index representing (c). of course, not all entries will be valid, since you're not going to need all the characters from 127 to 255.
this encoding is valid only for several languages (most common, fortunately). if you plan to port for...russian, you'll have to look into unicode stuff.
I found out that as werekarg had said, you have to plan two solutions depending on your target phones.
I usually go for the "big image/get little chunk (defined in some array) from it/draw on the screen" rather than "one char/one image" approach, because it uses a lot more memory and in small phones that's never a good thing ;)
Of course, you should make that part of your code as replaceable as possible, because if you port your game, sometimes you just have to choose the other more memory hungry approach (in some cases, because of performance issues).
I usually go for the "big image/get little chunk (defined in some array) from it/draw on the screen" rather than "one char/one image" approach, because it uses a lot more memory and in small phones that's never a good thing ;)
Of course, you should make that part of your code as replaceable as possible, because if you port your game, sometimes you just have to choose the other more memory hungry approach (in some cases, because of performance issues).
Author
Thanks Werekarg,
Thats going to come in very handy! :D
Would you mind explaining about a couple of things you mentioned please? I don't quite understand what you mean by:
"you will have the choice of having an image for each char multiplied by number of palettes (this works ok on most of the phones) or to have an image (for each palette) containing all the chars"
could you explain what you mean by 'palette'?
and also:
"you will also need a byte array to map characters ascii code to the sprite cell index (static or loaded from resources)."
Could you clarify this for me a little please?
Sorry to be a nuisance, but i greatly appreciate your help.
Multi
Thats going to come in very handy! :D
Would you mind explaining about a couple of things you mentioned please? I don't quite understand what you mean by:
"you will have the choice of having an image for each char multiplied by number of palettes (this works ok on most of the phones) or to have an image (for each palette) containing all the chars"
could you explain what you mean by 'palette'?
and also:
"you will also need a byte array to map characters ascii code to the sprite cell index (static or loaded from resources)."
Could you clarify this for me a little please?
Sorry to be a nuisance, but i greatly appreciate your help.
Multi
regarding the second point:
here's a photoshopped explanation.
regarding the first point: dont know exactly how to explain...usually, all images that i store in the jar come from indexed bitmaps/pngs (since you wont need more than 256 colors for an image, at least on mobile). this allows you to use palettes (think photoshop, in menu image/mode/color table) to obtain several useful effects - for example, to have a font both in red, white, yellow or whatever colors. this way, you will export a bitmap and several palettes, so that you wont eat jar size.
in memory, depending on the method you chose (each char an image vs big image), for each palette, you will have to duplicate all the images created.
so, while the normal implementation ("each character an image") would be:
Image[] images;
...
graphics.drawImage(images[map[string.charAt(i)], x, y, flags);
the paletted implementation would be:
Image[][] images;
...
graphics.drawImage(images[current_palette][map[string.charAt(i)], x, y, flags);
(this implementation varies depending on the device. on nokia, you may use drawpixels, on midp2 you may use drawrgb - largely depends on how you keep the image data).
i really should make a tutorial out of this [wink]
if you want to see a working implementation, check "lethal metal" in my signature. there is a font implementation in the CFont.java file.
here's a photoshopped explanation.
regarding the first point: dont know exactly how to explain...usually, all images that i store in the jar come from indexed bitmaps/pngs (since you wont need more than 256 colors for an image, at least on mobile). this allows you to use palettes (think photoshop, in menu image/mode/color table) to obtain several useful effects - for example, to have a font both in red, white, yellow or whatever colors. this way, you will export a bitmap and several palettes, so that you wont eat jar size.
in memory, depending on the method you chose (each char an image vs big image), for each palette, you will have to duplicate all the images created.
so, while the normal implementation ("each character an image") would be:
Image[] images;
...
graphics.drawImage(images[map[string.charAt(i)], x, y, flags);
the paletted implementation would be:
Image[][] images;
...
graphics.drawImage(images[current_palette][map[string.charAt(i)], x, y, flags);
(this implementation varies depending on the device. on nokia, you may use drawpixels, on midp2 you may use drawrgb - largely depends on how you keep the image data).
i really should make a tutorial out of this [wink]
if you want to see a working implementation, check "lethal metal" in my signature. there is a font implementation in the CFont.java file.
Hi there
i was reading through the post and i was thinking, what to do with
diffent screen resolutions. Ofcause you can make diffent bitmaps but then its not as portable between phones as you might like. Just a thought.
i was reading through the post and i was thinking, what to do with
diffent screen resolutions. Ofcause you can make diffent bitmaps but then its not as portable between phones as you might like. Just a thought.
Author
Thanks Werekarg!
That's just what i was looking for, thanks for spending the time to explain it for me.
@jap, yeah thats a good point, I'll probably just have to make a custom bitmap for each screen size, since I have to that for various images anyway.
If anyone else has something to add please feel free! (at the moment I need as much help as I can get! :P )
Thanks again to everyone whose posted so far!
Multi
That's just what i was looking for, thanks for spending the time to explain it for me.
@jap, yeah thats a good point, I'll probably just have to make a custom bitmap for each screen size, since I have to that for various images anyway.
If anyone else has something to add please feel free! (at the moment I need as much help as I can get! :P )
Thanks again to everyone whose posted so far!
Multi
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
