gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Coding > score board

#3474 - blaow - Tue Feb 25, 2003 5:39 pm

is there any easy way to make a score board besides using a
sprite per every number 0-9...? thanks
_________________
blaow~~

#3476 - tepples - Tue Feb 25, 2003 5:53 pm

If you only scroll a limited amount, try setting a vcount interrupt to partition the image into status-bar and playfield regions. Super Mario Bros. and Super Mario Bros. 3 for NES do essentially this.

If you have a free layer, you can put your status bar in that layer. Super Mario All-Stars for Super NES does this.

Or you can treat a sprite as a pseudo-bitmap and draw numbers to that.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#3491 - JonH - Wed Feb 26, 2003 12:12 am

yeah, if you've got a spare BG layer I would use that method, mate. afterall, its what the character tiles used to be for ;)

#3502 - blaow - Wed Feb 26, 2003 6:40 am

Thanks, i will definetly go for the extra layer, things wont get to mixed up that way. now at the moment of putting the text on screen.. is it easyer to use a sprite for every number.. or is there any other way to put text on screen besides using a sprite for every letter in the alphabet?
thnks
_________________
blaow~~

#3507 - TurboHz - Wed Feb 26, 2003 9:42 am

You can build the text with tiles writen in the layer background.

Place your characters ordered as ascii and use the ascii value of the characters to select the appropiate tile...

#3510 - Daikath - Wed Feb 26, 2003 11:05 am

Where can you find a site wich gives the ascii layout? (aint too experienced with coding yet ;))
_________________
?There are no stupid questions but there are a LOT of inquisitive idiots.?

#3515 - TurboHz - Wed Feb 26, 2003 1:58 pm

http://www.asciitable.com

#3518 - Touchstone - Wed Feb 26, 2003 3:32 pm

What's this talk about having one sprite for every character? If you want text that say "level 01" for instance, you only need seven sprites. You don't need to have the entire alphabet available at all times. When you want the text to say "level 02" instead you copy the tiledata for "2" from ROM to sprite VRAM, over the previous tiledata that read "1". I would go for using sprites instead of a BG layer since I think it's more likely that I have a couple of spare sprites rather than a spare BG layer, but that's really up to you and obviously depends on how your game/demo is using the hardware.
_________________
You can't beat our meat

#3521 - JonH - Wed Feb 26, 2003 4:43 pm

you don't need to use the ascii codes. look heres my code which i made and borrowed some ideas from the Ferk source code.

Code:


#define ALPHABET_LENGTH 27
u8 alphabet[ALPHABET_LENGTH]=" abcdefghijklmnopqrstuvwxyz";

void text(char* text, u16 x, u16 y)
{
   u32 c=0;
      for( c=0; c < textlen(text); c++ )
      {
      bg1.mapData[(x+(32*y))+c] = find_char_raw(text[c]);
   }

}

//Gets the length of the string
int textlen(char* text)
{
   u32 i=0;
   while( (text[i]!= 0) ) i++;
   return i;
}

int find_char_raw(char the_char)
{
   u16 l,i;
   int char_id;

   for (l=0; l<ALPHABET_LENGTH; l++) //go through each char in the alphabet
      if ( alphabet[l] == the_char )
      {
         char_id=l;
         return char_id;
      }

   char_id=0; // ' '
   return char_id;
}


obviously, this uses data structures for the backgrounds and uses BG1 for the text output. now all i have to do to write text is use the function, thus:

Code:
text("hello world", 1, 1);


where the 2 numbers (x and y) represent the location i want the text to start, in 8x8 tiles rather than pixels.

notice how the code looks in the alphabet, which is an array of the actual characters within your tileset in the same order.

If anyone has a better way i would also be interested to know it ;)

#3523 - tepples - Wed Feb 26, 2003 5:11 pm

JonH wrote:
notice how the code looks in the alphabet, which is an array of the actual characters within your tileset in the same order.

If anyone has a better way i would also be interested to know it ;)

Your way is O(n) on the size of the alphabet. The faster way (O(1)) is to make a table of 128 entries, one for each ASCII code, such that table['a'] (table[97]) = the code in your font for 'a'.

I just use ASCII. Even Mega Man 5 on the 8-bit NES manages to use ASCII.

But if you're displaying short messages, and you're making an English-only game, you could just make "Score:" one 32x8 pixel image or something.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#3528 - DekuTree64 - Wed Feb 26, 2003 5:56 pm

I use ASCII, but not all of it. Since there are a lot of control characters at the start, I just make space the first tile (space is #32), and then just skip any tiles past where you plan to use. So then you just do like mapData[y*32+x+i] = tileTable[text[i] - 32]. tileTable has one GBA screen format entry for each tile. It should be generated for you by your image converter tool (I know Kaleid does, but I've nver tried any others, so I'm not sure).
Then just put blank tiles for characters you don't need, but are between ones you do need, and then the image converter should use the same index for all the blank ones, so they don't take any extra space.

#3542 - Daikath - Wed Feb 26, 2003 11:45 pm

Could you use this for japanese characters also?

Because there is no region lock on the GBA it is cheaper to make one versions for all regions then to let the versions for one region sell very bad while you dont have enough versions for another regions to supply the demand.
_________________
?There are no stupid questions but there are a LOT of inquisitive idiots.?

#3543 - animension - Thu Feb 27, 2003 1:16 am

Japanese characters use a completely different system than ASCII. While ASCII characters are included in Japanese character sets, the Japanese sets go far beyond ASCII in scope and number. Writing a text display sub-system for Japanese is much more complicated than one for English.

First off, there are at no less than 3 mainstream standard encoding methods: JIS, Shift-JIS, and EUC. I think there's also a Unicode format for Japanese characters but I haven't seen much use of this form anywhere. The difficulty is translating the Japanese encoded text into character codes. If you don't already know the algorithm for converting encoded double-byte characters in a Japanese format, you will need to read up on the methodology of this format and write your own algorithm for it. Since each encoding is uniquely different, if you want your text conversion code to be flexible enough to work with different formats you will have to write conversion code for all three mainstream standards. You could even go so far as to auto-detect the format based on the encoding of the text, but I don't know anything about how this is done.

Second, It would be *impossible* to render the text in a small size like 8 x 8 pixels since at that size the details that distinguish some characters from others are completely lost. The minimum size for readable Japanese text is around 12 px. I recommend 16 pixels. Since you would have to work with 2x2 tile set for tilemap display systems or a 16x16 pixel sprite for a sprite display system per character, the memory and CPU overhead per character is more costly. In addition, since each character will have to be quadrupled in size (twice as wide x twice as high) the storage space required in ROM to store the character data will also quadruple.

Third, there are an enormous number of characters to import into C code. I think there's somewhere along the lines of 5000 characters for the full set, but I don't know the exact figures. Considering that font data will be 4 times as large per character because it won't be readable smaller than 16 pixels by 16 pixels, you can imagine how much more ROM space a character set will take. That's approx 25 times the number of characters * 4 times the storage space per char, equals approx 100 times the ROM storage space of an 8 pixel by 8 pixel ASCII set. Also, if you don't already have a full set of font data for all the characters, preferably in C header format, making one will take a very, *very* long time if you don't have a utility that will do this for you automatically (if you DO have one, I would very much like to find out how to obtain it!). If you are able to read/write Japanese, you may be able to find a full set of characters with their respective character codes available online by searching on google.co.jp.

All in all, Japanese text display systems are much more complicated to develop from scratch and take up lots more of your in game memory to display as well as loads more ROM storage. If at all possible, try to find a library of characters encoded in C arrays with correct character codes associated to each one so that you won't have to extract font data.
_________________
"Beer is proof that God loves us and wants us to be happy."
-- Benjamin Franklin

#3546 - JonH - Thu Feb 27, 2003 1:47 am

tepples wrote:

Your way is O(n) on the size of the alphabet. The faster way (O(1)) is to make a table of 128 entries, one for each ASCII code, such that table['a'] (table[97]) = the code in your font for 'a'.


Ah yes I can see how that might be quicker! thanks for the info tepples, it is most appreciated. :)

#3547 - Daikath - Thu Feb 27, 2003 3:12 am

Thank you for that post Animension :) it has been a lot of help.
_________________
?There are no stupid questions but there are a LOT of inquisitive idiots.?

#3549 - animension - Thu Feb 27, 2003 4:29 am

Daikath, one thing I did forget to mention in my last post was that if you did indeed want to tackle the complexities of a Japanese text display sub-system, you wouldn't need a separate one for plain ASCII since ASCII characters are included. This would eliminate the need to use separate libraries for English and Japanese version. What I suggest is that if you do want to program a game for English and Japanese is to develop only the Japanese display system and use it for the English version. The only difference between the two games would be the content of the text and not the display system.

Personally, I much prefer the larger 16 x 16 pixel text display systems on Japanese games than the small 8 x 8 pixel text commonly found in American titles. It makes for easier reading, especially under not-so-optimal lighting situations since the text is larger.
_________________
"Beer is proof that God loves us and wants us to be happy."
-- Benjamin Franklin

#3562 - tepples - Thu Feb 27, 2003 6:53 pm

animension wrote:
Japanese characters use a completely different system than ASCII. While ASCII characters are included in Japanese character sets, the Japanese sets go far beyond ASCII in scope and number. Writing a text display sub-system for Japanese is much more complicated than one for English.

Unless you use only kana (about 100 distinct characters) and no kanji, as most games on 8-bit platforms did. Of course the problem with kana is that Japanese has a few words distinguished by the accented syllable (compare English 'desert' == dry place vs. 'desert' == to be truant), and kana does not represent the accent. But if you drop kanji and keep only kana and romaji, you don't need to use any more space for glyphs than you needed for ISO Latin 1.

Quote:
Second, It would be *impossible* to render the text in a small size like 8 x 8 pixels since at that size the details that distinguish some characters from others are completely lost.

Perhaps for kanji, but I can tell 8px tall NES kana apart and I don't even know Japanese.

Quote:
I think there's somewhere along the lines of 5000 characters for the full set

There are only about 2000 Jo:yo: (common) Kanji.

Quote:
Also, if you don't already have a full set of font data for all the characters, preferably in C header format, making one will take a very, *very* long time if you don't have a utility that will do this for you automatically (if you DO have one, I would very much like to find out how to obtain it!).

Any bitmap conversion tool will do this for you. Just convert a 1-bit font bitmap to .chr and then include it in a GBFS archive. Having your artist create the 1-bit font bitmap, however, is the problem.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#3567 - animension - Thu Feb 27, 2003 8:13 pm

tepples wrote:
Unless you use only kana (about 100 distinct characters) and no kanji, as most games on 8-bit platforms did. Of course the problem with kana is that Japanese has a few words distinguished by the accented syllable (compare English 'desert' == dry place vs. 'desert' == to be truant), and kana does not represent the accent. But if you drop kanji and keep only kana and romaji, you don't need to use any more space for glyphs than you needed for ISO Latin 1.


As a fluent Japanese speaker and long time gamer, I can tell you that it was a godsend when developers started using kanji in their games. It is much harder on the Japanese eye to read strictly kana since by the time we are able to go to middle school we are trained to read very quickly by shapes -- almost like viewing the characters as pictures -- much the same way sight reading is done in music. With kanji, by merely glancing at a kanji for a split second, we can immediately know exactly what is being conveyed, which is the entire point of kanji. As a native speaker of both English and Japanese (I grew up in a bi-lingual environment) I can read way faster in Japanese than I can in English when kanji is involved because one character conveys an entire thought, where as many letters convey a word which conveys a thought. Granted, you can do this to a degree with English where you recognize words based on the shapes of its component letters and can "sight" read in this manner, but not to the degree of sophistication and accuracy that you can with kanji in Japanese. This in mind, imagine the pain it is to drop down to a kana only level to read. It certainly won't be obvious to a non-trained eye, but to those who are trained to sight read Japanese with kanji it's like pulling teeth and honestly makes reading a chore. If you are going to ever develop games in Japanese, as a gamer and a native speaker, I strongly advise you NOT to use a kana-only character system. I for one will be tempted to toss the ROM in the gomibako (wastebin).

tepples wrote:
There are only about 2000 Jo:yo: (common) Kanji.


Yes, but the Japanese character sets include hi-joyo (non-common) kanji in order to display kanji that are not used commonly but found in titles and family names. In addition, there are hundreds upon hundreds of what are known as "Kigoh" or symbols in the Japanese char set that you won't find in ASCII, such as a solid diamond, outline diamond, 8th notes, heart marks, etc etc. With the hi-joyo kanji, the hankaku version of both kana sets (half-width), all the kigoh, and whatever else I may have neglected to mension, the charset is significantly larger than 2000 characters found in joyo kanji. Nevertheless, the point remains, without an extraction utility, obtaining a one bit font bitmap with all the characters will take forever. In addition, mapping them to the correct character code will take conceivably just as long.

Creating a functional and *acceptable* (kana only is NOT acceptable as a Japanese speaker) Japanese text display system takes a ton of work if you are going to do it from scratch.
_________________
"Beer is proof that God loves us and wants us to be happy."
-- Benjamin Franklin

#3570 - Daikath - Thu Feb 27, 2003 10:41 pm

But that work might get you a publisher for your game easier ;), if you have one program wich you can use for all regions and therefor spreading the risk.
_________________
?There are no stupid questions but there are a LOT of inquisitive idiots.?

#3571 - tepples - Fri Feb 28, 2003 3:24 am

animension: Point taken.

Daikath: If you want one program for all regions, then you have to hire people to translate all of your game's text from English into Spanish, Portuguese, French, German, Italian, Dutch, and Japanese. That gets expensive, and it also bloats your binary size if you're using voice actors and your game is E-rated. (E-rated games can't just use subtitles because players of E-rated games often can't read well.)

Or just use English and Esperanto ;-)
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#3572 - Daikath - Fri Feb 28, 2003 3:52 am

Can;t think of one GBA game in dutch though :) And I am dutch ;).Maybe it costs more to have it translated but if I have the code open enough so its easy to implement different languages i wont have to rewrite the stuff ;). And I also dont remeber there being voice actors for a GBA game ;).

It is for a RPG. One more mature then other typical GBA RPG's (the style is still the same, but the storylines and themes are much more mature then your average console RPG). So for them to enjoy the game they pretty much have to be able to read.
_________________
?There are no stupid questions but there are a LOT of inquisitive idiots.?

#3578 - animension - Fri Feb 28, 2003 8:11 am

How fortunate. I have found a Japanese text display library available for free for commercial or personal use. At the moment it only supports mode3, but that is a limitation based on the functions that manipulate the character set arrays. It includes character data arrays in single-bit per pixel form for JIS code 0x2121 through 0x7426, and of that range 6879 character entities are defined, including obscure kanji, half-width and full-width version hira/kata kana, and the symbols. The characters follow the JIS coding system, but converter functions are available to convert input in EUC to JIS and Shift-JIS into JIS. The pixel data is 16x16 pixels for full width characters and 8x16 pixels for half-width kana and symbols. There is an 8x8 pixel set for ASCII characters but the author says it's incomplete.

If you can read Japanese, the source code is available on this page: http://j-gbadev.hp.infoseek.co.jp/sakuhin The item is called "TonoMoji". The source is encoded in EUC and comments / documentation is entirely in Japanese. I am planning on making this library more abstract (that is, not limited to a mode, but merely returning font pixel data) and available in English with documentation since the library owner states that it is free to be modified and redistributed as well. From what it seems, this would solve the problem of having reinventing the wheel to display Japanese.
_________________
"Beer is proof that God loves us and wants us to be happy."
-- Benjamin Franklin

#4114 - TrisOver - Wed Mar 19, 2003 1:37 pm

If you know your characters are between 'a' and 'z', the easy way to know the character rank is:
short rank;
char character;

rank = character - 'a';

ig:
if your character is 'c',
rank= 'c'-'a'=2
_________________
TrisOver

#4125 - MrMr[iCE] - Wed Mar 19, 2003 9:40 pm

In the reversi clone I did, I just use 4 sprites, 2 per player, to show the scores (max score is 64). I load the numbers for the sprites in sprite data ram, and when Im ready to display the digits, just change which tile those sprites draw. For example (assuming 16 color sprites), I load the data for numbers 0-9 into tile indexes 20-29 in sprite data ram. Lets say sprites 3 and 4 are the score digits for player 1. If I wanted to show the score 46, I would set sprite 3 to show tile 24, and sprite 4 to show tile 26 (by changing attribute 2 in the sprites)
_________________
Does the corpse have a familiar face?

#4934 - sgeos - Tue Apr 15, 2003 7:52 am

I actually managed to display text using shift-jis. I kind of dropped the project though. Hand coding by hex value sucks. I'll wait until I can get linux installed with gcc compiled to deal with shift-jis string literals.

-Brendan

#41617 - ajb_advance - Sat Apr 30, 2005 9:03 am

Slightly late to this thread, but here: http://kanji.zinbun.kyoto-u.ac.jp/~yasuoka/CJK.html is a source for Japanese bitmap fonts in codepage layout.

#42370 - Steve++ - Tue May 10, 2005 6:36 pm

I've been thinking about japanese characters too. Thanks for the link. I bet those 16x16 pixel characters could be squeezed a bit smaller with the aid of sub-pixel rendering. I probably wouldn't use those particular ones, as there would be too many scaling artifacts. Perhaps I could use a Japanese TTF font and render every character three times wider, each in a 24x8 (or perhaps 21x7) pixel box. It would be interesting to see the results.

Would it be necessary, or can Japanese text convey the same as English text with less characters?