Good TextOut alternative?

Started by
6 comments, last by Buster 23 years, 11 months ago
I currently have a DrawString() function which will draw a string to any surface. However, it grabs a hDC and uses TextOut() which everyone knows is not very quick. Now this works fine if you are just showing debug stuff, like what''s the current framerate, or the value of this variable or something. I was wondering if anyone has a good alternative to TextOut() so I can display text in a production (read: fast) environment. In the past, to display numbers, I''ve had a 0-9 bitmap that I parse out and blit digit by digit. Does the same technique make sense for full text? -Michael
Advertisement
Have you tried DrawText()? I''m not sure how well it performs in the speed category, but it does give you more control than TextOut().

Martin
______________Martin EstevaolpSoftware
I have a feeling one is a subset of the other, dunno which. I should have been more specific. Ideally I''d like to get away from GDI.

As an example, you can take Application X, which is ripping along in all its 3D glory at 75 frames/sec. Throw this into the loop:
DrawText("Hello There", xpos, ypos); // my wrapper for texting

And it loses 5-10 frames right there.
Wellll.... yeah basically just do the same as for text as for digits. Some ideas of course you could already know this:
1) Do letters ASCII 32 (space) to 127 (last letter you could possiblely need: Z).
2) Also you can get the letters printed out by the PC, the idea is to create a memorydc, then create a font struct, use the GDI to textout the letters (this is in your util font maker of couse ) then blt to the surface, and write it out however you do that.
3) Getting variable width letters is easy, just create a struct with
int Width
int TotalWidth;
when you create the font, setup each letters width with GDI funcs (gettextwidth or something like that) and add the totalwith
To draw, just do a blt to currentx,y,Sizes[*Letter].TotalWidth,0,Sizes[*Letter].Width.
then increment currentx with the current letters width and the letter pointer of course!
notice that when you do ascii sequence, you can just reference the width with the letter itself. Cool or what!
anyway if you knew all that sorry but I just wanted to save somebody else some time - it took me 1 week to get my font system working (then again I;m not that a good coder
Good luck with your game/engine (delete as appropaite).
I''m looking into that now... I''m creating a bitmap with the font on it (all 256 in one long strip), and an array that looks sort of like this:

pseudo-code:
letter {
bool canPrint; // also good for hiding chars if you want
int xOff; // where is it on bitmap?
int w, h; // how big is letter?
};
letter myLetters[256];

Then I just need to rip through the string and blit out each char if canPrint is true.

That''s all theory of course... can''t program till I get home!
Buster: Be careful with that ''256 in one long strip''. Some cards don''t allow surface larger than the primary surface.

Just my 2cents worth.

Happy coding.
"after many years of singularity, i'm still searching on the event horizon"
Yes use that bitmap becuse it is faster

(yes use TextOutA only for debug )

specially if u put it into videomemory
it is in the videomemory is it not?

but take care make it a very High strip because video surfaces cant have big widths (only when in video memory)
take care DDSCAPS_OFFSCREENPLAIN puts it into
Video memory but sometimes into SYSTEM memory so it may not
work on all systems

obysoft
DX 7 allows wider-than-video bitmaps. I''m still checking the CAPS just in case (legacy code from DX5). If somehow it can''t do a wide bitmap, the bitmap is folded over. The user (programmer) never knows it happened.

This topic is closed to new replies.

Advertisement