Hrmm...
Well I'm thinking of what could cause any trouble:
Font glyphs and sprites from sprite sheets aren't actually all that different, in fact they try to solve practically the same problem-- you've got this one texture and need a bunch of lightweight instances of it that you can move around and position however you would like.
Glyphs are practically never used alone, they are chained together as text onscreen and many glyph implementations probably assume so. That isn't the case with sprites. That means that you could run into trouble if your glyph implementation assumes too much.
Font file standards are also written with the assumption that the font file will store information about how to BUILD glyphs ( a slow process ), or it will contain the glyph itself. There are potential problems with misusing any particular font file standard as a sprite sheet. If you use a builder-type font file standard and you encode your sprites (glyphs) as vector art for example, then you will pay a performance price for that. If you use a raster-type font file standard then you will pay for loss of quality if you try to stretch or magnify your image too much ( that happens with bitmap images anyway, so no biggie ). Also, SFML doesn't support every font type out of the box, so a potentially tasty option might not actually be an option.
Various font file standards may also encode information about the width or the relative placement of the glyph along some line, or its endianess, which for most sprite sheets isn't exactly information that we really want. Others are quite complicated, for example take a gander at
http://en.wikipedia.org/wiki/TrueType, which includes its own virtual machine!
As for referring to each sprite as a character, that leaves you with something to think about. It would certainly be unclear that you meant "that sprite that looks like a tree" if you encode that as the letter capital C, but a letter is just a number, and a number can be cast from an enum so maybe you don't have to be terse unless you want to (for example with a notepad "map" file that just contains character information).
Also consider that UTF8 and ASCII aren't the end all be all. You could very well use another font format with wide characters, and then you could configure your (otherwise arbitrary) choice of "terse" characters to
actually look like the thing they represent in notepad or whatever. I'm sure that somewhere someone has made a unicode symbol that looks like a tree.
You are right about the performance for games which really spam the hell out of sprites, like particle engines.But not every game has those requirements, and these benefits might outweigh the costs for non performance critical applications.
I just think a WYSIWYG
map editor in a
simple text editor like notepad is the coolest thing since koolaid. You could programatically generate maps for a roguelike just as easily as you could parse text! You could allow the user to specify his own maps without a lot of hassle. Modifying the map becomes equivalent to modifying text, so any text processing code that exists also becomes map modifying code, which is quite a useful feature. Imagine that you have a big game and you want to provide the user a utility that allows them to search for a specific combination or arrangement of tiles, you could implement that easily with a text search or even allow him to pattern match with something like perl.
Imagine that the user opens up his dinky in game map, and he sees the same notepad representation that I have been suggesting here. I mean if you stop to really think about it, its not really that ugly when you consider all the advantages.
If no specific font format fits the needs of a tilemap, I could just make my own
All that would boil down to is modifying the source code of SFML to work with my totally made up newfangled file format. Aint nothing wrong with that.
