Morgawr wrote:Mmm.. honestly I may say that I doubt it.. I mean, I find it hard to believe that for every dialogue every game just manually colors different pixel depending on the dialogue itself... it sounds too much a bother...
I dunno how any commercial games do it, but doing it this way is simpler than it sounds, and I think it can be plenty fast enough for a lot of uses of text - e.g. menu screens, dialogue windows in RPGs, etc..
There are probably better ways to do it, I don't know yet.. How I've done it is basically like this:
1. Start off by making a function to set the colour of a single pixel, given an x and y position on screen.
2. Have a font stored in some kind of array. There must be lots of different ways of storing font data. The easiest to understand way (definitely not the best!) would be to have an array like this, for example: (simple letter 'A')
Code: Select all
0,1,1,1,1,1,0,0,
1,0,0,0,0,0,1,0,
1,0,0,0,0,0,1,0,
1,0,0,0,0,0,1,0,
1,1,1,1,1,1,1,0,
1,0,0,0,0,0,1,0,
1,0,0,0,0,0,1,0,
1,0,0,0,0,0,1,0
3. To draw the letter, make a function which iterates through each position in the array and if the value is 1, plots a pixel at that location.
4. To write a whole string, make a function which iterates through the string, calling the single letter drawing function for each letter.
So, basically building up your own simple version of printf(), bit by bit... Once you've made some functions like these, it's not a hassle to actually use - in your game code you'll be able to just go myPrint("hi there!",12,15) to print starting at pixel 12x15... or something like that..
..if any of that makes sense?
This of course lets you use fonts of whatever size you like, and have variable width letters, be able to scale up each letter on the fly by drawing multiple pixels for each point, etc.. It's obviously only a single colour font, I haven't got further than that yet. It's also slower than using a tiled mode, and you have to use a bitmap background of course.. but yeah, I think it could be okay for the average text display in many games..
Of course, having each letter stored as an array of ints of bools like that isn't very efficient, and you don't want to be having to type in 1s and 0s for your whole font by hand!
*this is where it gets slightly more scary*
I'm using Usenti (or I think you can setup Grit to do it?) to convert a graphics file containing the font into code.. so instead of the 'A' array above, you have each letter stored in two unsigned ints, looking something like this:
Being a newbie when it comes to bit twiddling, I was like "how the hell does that translate to 64 pixels? o_O" (8x8 font) at first.. this random picture I found helped me understand it:
http://www.hexprobe.com/hpmbcalc/docume ... hifter.jpg (it's a screenshot of some bit shift calculator app, ignore the stuff down the bottom, it's the diagram that's useful)..
see how the eight hex digits are broken down into four groups of two? each pair of hex digits representing an 8-bit binary number.. each 8-bit binary number represents one row of pixels (those 0s and 1s) in a letter. (that's why each letter is stored in two unsigned ints - each int holds 4 rows, each letter needs 8 rows)
...sorry if you already know that, it's probably obvious to people who've learnt about bitwise operations.. it's fairly new to me
So from there it's just a matter of figuring out how to change step 3 from above so that instead of just reading 1s and 0s from an array, it seperates out those 1s and 0s from the hex numbers..
I have no idea if this makes it faster or slower to draw the font, but it must use less memory, and is way cooler -_-
Anyway, hopefully some of that makes sense. I really don't know if this is a good way of going about it or not, it's just the way I tried a couple weeks ago, and it seems to work fine. You could of course use some already existing text display lib.
Ok I'll shut up now. Good luck!
