Fonts
Whoa! I must have stepped on somebody's toes! I certainly didn't mean to
beat up Jiri, or to imply that his font code is poor. I just wanted to
offer an alternative way of doing it.
Using EMemCopy and the new SVGA-EMemCopy you can do fonts in any linear
graphics mode (I think 19 is the only one) or any SVGA mode. I think
this covers most of the graphics modes people are using for their
programs.
It is also a trivial issue to scan through a bitmap and swap out all of
the colors for different colors. Granted, I usually use just 1-color
fonts but you could do it with multi-color fonts too. You could build
the shading right into the font, for added speed. When a font color
change is needed, just change the pixels in the font. Or, better yet,
duplicate the font with the new color.
Special effects such as underlining can be done per-character regardless
of how you put the character there in the first place. So blitting it
from memory and drawing it with pixel() makes no difference on this
issue.
I was not being clever. I was trying to promote diversity of thinking.
There is more than one way to skin a cat.
I did *not* deliver any swipes to you. I simply said that pixel() is
slow. It has to be, because it never knows what graphics mode it is
running in. Also, there isn't a much faster way to do anything involving
moving memory bytes than to use a generic machine language memory
copying routine... EMemCopy.
Finally, in defense of pixel(). This is a great generic drawing routine.
There is nothing wrong with it. The issue is speed, and speed only. I
like to write games. I think everyone would agree that games should be
fast, so using the fastest support routines seems to be a smart choice.
Finally, some bitching. It seems like every time I post something to
this list I get flamed by the most prominent members of the list. Do you
guys *really* think I am trying to make fun of, bash, or degrade you
code?
John.
|
Not Categorized, Please Help
|
|
