1. Fonts
I believe that the fastest way to draw any bitmap using Euphoria
(without getting into compiled sprites) is to use EMemCopy by Michael
Bolin.
I have implemented my own font routines. Since they are so integrated
into my own code I won't bother distributing them, but I'll take a shot
at explaining how my font code works.
First off you need a generic blitting procedure, which is basically a
wrapper for EMemCopy. It needs to be able to blit part or all of a
bitmap onto another bitmap. Not too difficult.
The font file can be as simple as a BMP file. I use a BMP file where
each character is separated by a space (a column of color #00). To load
the font you simply scan through the bitmap and when you reach a blank
column make a note of the x-position and the number of columns scanned
in since the last blank (the width of the current character). So the
first x-position is the offset for the first character, the second
x-position is the offset for the second character, and so on. The bitmap
file's height is the same height as your font, so there is no need to
track the y-position of each character, it is always #00.
Now when you need to blit a character you simply blit a portion of your
total font file. The offset is equal to the x-position you tracked
during loading, the width is the width of the character (also tracked
during loading). EMemCopy does this *really* fast.
Simple, right? I hope this offers a clear alternative to using the pixel
routine. I think RDS included it for the sake of being complete, but it
has *no* place in any graphics library that even wants to dream of
speed.
John.
2. Re: Fonts
John DeHope writes:
> EMemCopy does this *really* fast.
> Simple, right? I hope this offers a clear alternative to using the pixel
> routine. I think RDS included it for the sake of being complete, but it
> has *no* place in any graphics library that even wants to dream of
> speed.
Ouch! 
You're right of course. pixel() is much slower than mem_copy(), poke(),
special machine code, or techniques that only work in one graphics mode.
However I'd like to mention:
* pixel() is much faster in mode 19 than in other modes.
* pixel() of a fairly long sequence of points is *much* more
efficient than pixel() of a single point (atom)
* pixel() will safely clip points that are off the screen
If you have an algorithm that calls pixel() once per pixel,
you should strongly consider converting it into one that composes
a sequence of pixels before making a single call to pixel().
The same goes for display_image() - try to output bigger, especially
wider, images in each call.
* * *
Notice to registered users: It's now November. You are all
eligible to toss another dollar (of our money) in the collection tray at:
http://members.aol.com/FilesEu/ecoform.htm
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
3. 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.
4. Re: Fonts
I've been thinking of storing characters into a sequence with save_image
and then writing it to a file. I also noticed that if you take a saved
image and then add, multiply, divide, or subtract from a value to it's
subscripts it's foreground and background will change colors.
Happy coding!
- Matt
5. Re: Fonts
I've been thinking of storing characters into a sequence with save_image
and then writing it to a file. I also noticed that if you take a saved
image and then add, multiply, divide, or subtract from a value to it's
subscripts it's foreground and background will change colors.
Happy coding!
- Matt
ela/NameUserName/var/spool/mailbox/mss-01/k/i âÝ âÝ äkielaâ¿ â¿ +)/Mail é@
ÿ@ +)/MailboxPath$ ä ä àý ÿ@ ä¿ ä¿ MailboxPathAubrey
KielelaUNIX-UserName ã ã UNIX-UserName
/Accounts/kiela/MsgMaxQuota NameIX +)/UNIX-UserNam0
ã¿ ã¿ UNIX-UserName
+)/Name/Accounts/kiela/modifytimestamp MsgMaxQuotakiela at sk.sympatico.ca
/Accounts/kiela/POP-Address19980922221550ZName å¿ å¿ 18)/MsgM
SMTP-AddressmpPriority:kiela/SMTP-Addressmp
6. Fonts
Hello all and Merry Christmas!
Bear with a newbie, but does anyone have some font examples available?
I'm looking at 'prettying up' some text files with something a bit larger
than DOS text.
Maybe even with color...ooooh!
Thanks in advance,
Ray in Colorado
The Chalk Board BBS
Modem:(970)330-0383
