Font or Typeface Smart Creation?

[First Spear]

 

I am thinking of putting a lot of text into a game program. The built-in font appears to be too large to show the amount of text with the frequency I want. Sometimes I would display all-text and sometimes I would want to show some text on the right and bottom of a screen with MOBs on the top and left.

 

I think the best thing to do is write my text on my computer in a small font, cut it into image "chunks", save and convert them, and then swap them in/out of GRAM as needed. I plan to use IntyBASIC.

 

Does that make sense? Is there a better way to get small-but-readable text on a screen?

 

Thanks.

 

By the way, I did a search for "font" on this forum and got a ton of nonapplicable hits so if someone has already addressed this I apologize.

[+DZ-Jay]

Your approach is sound, and it is probably what most games do in such a situation. Perhaps catsfolly and intvnut would like to offer some techniques, since they have done "small fonts" on their games before.

 

The way I would approach this is to pre-allocate some space in GRAM specifically for the text messages. That way, you can make sure you have enough space for all your text at any point. Then, like you said, you swap the cards in GRAM with others that contain the pre-rendered small text.

 

Another approach, which requires a bit more work, is to not pre-render the text, but to have a full ASCII alphabet in ROM and "write" the message out in GRAM by shifting, masking, and XORring the data directly. Perhaps having data with pre-shifted versions of the most commonly used letters in your messages.

 

However, if your messages are short, it may be better to just pre-render the text itself.

 

-dZ.

[freewheel]

Basically you've got it. The only challenge is that once you get letters that are smaller than a single GRAM card, it gets a lot more tedious - you basically have to pre-render your text for each and every word/sentence you're using. It's just barely possible to come up with a good font that fits 2 letters per card, so you could have a lot of common 2-letter combinations available. It's unfortunate that you can't "layer" cards to the screen - you can overlay MOBs but you'll run out of those way too quickly for most text.

 

One thing that gets tricky - fonting is actually rather complicated. Making a decent character graphic that is legible on screen, is difficult once you get small enough. And making the characters look like the same font can be extremely time-consuming. Then you get into issues like kerning, fixed-width vs proportional, serifs, and all the other good stuff.

[intvnut]

For static words/phrases, drawing the text as images is the way to go. You can tune individual words and phrases too to fit the available space. That's what I did with these examples from 4-Tris and the "Lunar MP Demo Reel":

 

 

 

I'm actually doing dynamic small fonts in LTO Flash. I have two small font sizes, actually. With those, I store the images of the individual characters, and then I have code that "renders" text into a buffer in RAM that then gets loaded into GRAM. It's basically the technique DZ-Jay mentions above. It's a PITA, really. But it looks really good. I have two font sizes, as the smaller size is harder to read. I believe in the screen shots below, the smaller size hasn't kicked in:

 

 

As freeweed pointed out, drawing a good font is tough. Especially so at the pixel sizes we're dealing with. The lower case 'e' is especially evil. Heck, an upper case 'E' leaves you few options as well.

 

Another downside is that it burns up GRAM like nobody's business. You can't have a lot of small-font text on screen. As you see in the LTO Flash! example above, only the highlighted game gets the fancy font treatment.

Edited December 20, 2014 by intvnut

[freewheel]

Ya know, with URLs on the INTV screen, my brain would just try clicking them. And be disappointed. Kinda surreal to see a URL on an 8 (fine, 16) bit system anyway. Sure, the INTV did exist commercially until just before URI syntax settled down, but still. This hobby is so bizarre in many ways.

 

Wait - has anyone done an INTV browser yet? And of course attempted the requisite IP stack and, you know, network interface of some sort?

 

Also - you guys are storing this smaller text and then mixing it with other letters into 8x8 cards for final display? Dynamically? Keen! I was all proud that I've created a rolling odometer, but of course this is with every possible digit combination pre-shifted and coded as GRAM. And of course loaded dynamically, because you can't store 70+ GRAM cards at once. I can't imagine the joy of doing this with an alphabet. I guess you've standardized your kerning etc. Makes me wonder how feasible this would be in IntyBASIC.

Edited December 21, 2014 by freeweed

[intvnut]

Ya know, with URLs on the INTV screen, my brain would just try clicking them. And be disappointed. Kinda surreal to see a URL on an 8 (fine, 16) bit system anyway. Sure, the INTV did exist commercially until just before URI syntax settled down, but still. This hobby is so bizarre in many ways.

 

Wait - has anyone done an INTV browser yet? And of course attempted the requisite IP stack and, you know, network interface of some sort?

 

Have you seen IntyOS yet? Arnauld is way ahead of me on dynamic GRAM usage. I'm sure if I provided hardware access to Ethernet, I imagine he'd be tempted to port the Contiki TCP/IP stack. We did blue-sky about such things once upon a time. If you read his descriptions, he definitely had network access in mind for IntyOS someday.

 

 

Also - you guys are storing this smaller text and then mixing it with other letters into 8x8 cards for final display? Dynamically? Keen! I was all proud that I've created a rolling odometer, but of course this is with every possible digit combination pre-shifted and coded as GRAM. And of course loaded dynamically, because you can't store 70+ GRAM cards at once. I can't imagine the joy of doing this with an alphabet. I guess you've standardized your kerning etc. Makes me wonder how feasible this would be in IntyBASIC.

 

Yes. I build text strings dynamically from an internal font in GRAM cards. So does IntyOS. And yes, there isn't any specialized kerning with the fonts I've developed. I imagine the same is true for Arnauld.

 

I developed fixed bitmaps for each character, and each has its bounding box. That does put some additional limits on font design (ie. no descenders that overlap the previous or next character, for example, such as an elongated tail on a g, j or Q). But, it's more than adequate for the limited resolution we're at. I believe Arnauld's fonts are similar. If he's watching this thread he can comment.

Edited December 21, 2014 by intvnut

[intvnut]

Also - you guys are storing this smaller text and then mixing it with other letters into 8x8 cards for final display? Dynamically? Keen!

 

Speaking of which... What do you think of the font I'm using for LTO Flash!?

[freewheel]

 

Speaking of which... What do you think of the font I'm using for LTO Flash!?

 

It looks pretty good in PC screenshots. I have a hard time passing judgement until I see it on a CRT scanlined screen, however. Which I cannot do, ironically, until I possess an LTO Flash.

 

More seriously, as this isn't a dig at that - does jzintv have a hidden "scanlines" mode? I find that these crude graphics often are much improved on a CRT - although things like fonts can sometimes look worse. I've been hoping I'd stumble upon it eventually. Even simulated scanlines give a good sense of how something will look.

[intvnut]

Does jzintv have a hidden "scanlines" mode? I find that these crude graphics often are much improved on a CRT - although things like fonts can sometimes look worse. I've been hoping I'd stumble upon it eventually. Even simulated scanlines give a good sense of how something will look.

 

It does not, sadly.

 

Someday I plan to rewrite jzIntv in C++14 (after LTO Flash! is out, clearly), partly as a teaching exercise to myself, and partly to make it all much more modular. I started programming jzIntv when i was still relatively fresh out of college and made some rookie architecture mistakes that make interesting features like this harder to add.

[First Spear]

I am considering writing a small Windows program to create/manage/render bitmaps of text. If I use a minimalist TrueType font, and can save to a specified pixel length (eg 5 cards wide x 2 cards high) and have Windows do the work, then I could save all text to RAM and swap it in-out of GRAM.

 

Basically you've got it. The only challenge is that once you get letters that are smaller than a single GRAM card, it gets a lot more tedious - you basically have to pre-render your text for each and every word/sentence you're using. It's just barely possible to come up with a good font that fits 2 letters per card, so you could have a lot of common 2-letter combinations available. It's unfortunate that you can't "layer" cards to the screen - you can overlay MOBs but you'll run out of those way too quickly for most text.

 

One thing that gets tricky - fonting is actually rather complicated. Making a decent character graphic that is legible on screen, is difficult once you get small enough. And making the characters look like the same font can be extremely time-consuming. Then you get into issues like kerning, fixed-width vs proportional, serifs, and all the other good stuff.

 

Through the magic of IntyColor...

 

Please comment on the legibility of the text. The game I am planning may be rather text-heavy, so I am trying to think through a way to have a lot of it in a "status area" that will not tire the eyes of the viewer.

 

Thanks.

 

 

 

Edited December 22, 2014 by First Spear

[freewheel]

The font is probably legible, but the gif is too tiny. I'd have to see it on a larger screen. Try taking a screenshot from your actual desktop, not the emulator. And run jzintv with -z1, so you get a bigger display resolution - if you're not doing this already.

 

Interesting concept though, and I bet this could work: have a status area with just the last line or three of text, and have that updated as necessary. If most/all sentences were pre-rendered, it would be pretty easy to swap in and out to display them. A special-purpose tool would definitely be useful here. Tooling it up in a Paint-type program and then converting with IntyColor is tedious as all hell. Works great for a few screens, not so great when you're wanting to store a lot of stuff. I find myself manually entering a lot of BITMAP "01001000" lines - pixel counting like in the old days

 

The only thing to keep in mind is that you're limited to 64 cards for GRAM, IN TOTAL, for any given screen. So if you end up using 10, 20, 30 cards just for text - that really takes away from what you can use elsewhere - this may not be a huge problem depending on what the rest of the game looks like. Also.. storage of pre-rendered text isn't exactly efficient. Let's say your font is a 4x4 size (and that strikes me as an absolute bare minimum), that means you're using 16 bits just to store a single character. Whereas you can store an alphanumeric character in as few as 5 or 6 bits depending on how you do it. With a lot of text, this could add up.

 

It's definitely an interesting problem, and a fun challenge. Platforms like the Intellivision were not known for text storage/handling/display for a lot of reasons. It always blew me away to see just how much text could be crammed into the tiny home computer cartridges of the early 80s. I've never really spent the time to figure many of the tricks so a lot of this is magic to me.

[First Spear]

 

That is a screen-snip from the Paint .NET image-editing bundle I am using to learn more about Inty graphics.

 

The current thought in my head is to keep all of the chaning text in a 3x8 tile area in the bottom right corner of the screen. Maybe I'll go to 8 tiles high by 8 wide, I want to show a lot of text without flipping away from the rest of the game.

 

In order to get there, my current thought is to make a custom program to manage the text and generate BMPs that IntyColor will consume, and then use a CMD to make the .bas bits of the text.

 

That satisfies the software architect in me, but your note about inefficiency bothers the software engineer in me. I would hate to run into memory problems because I am not doing the text "right". I am interested to understand how I could render a lot of text in a status area without using pre-gen bitmaps.... I think that is too much of a stretch for me at my skill level. If I do the text-image rendering in Windows first, I can set lots of pixel limits and get the image to fit and visually test it. If I do the rendering in IntyBASIC (skipping for a moment that may be beyond my current skills) then it might be harder to calculate character widths and might be harder to test. I'm very, very open to ideas however!

 

Thanks!

 

 

[snip]

Interesting concept though, and I bet this could work: have a status area with just the last line or three of text, and have that updated as necessary. If most/all sentences were pre-rendered, it would be pretty easy to swap in and out to display them. A special-purpose tool would definitely be useful here.

[snip]

Also.. storage of pre-rendered text isn't exactly efficient. Let's say your font is a 4x4 size (and that strikes me as an absolute bare minimum), that means you're using 16 bits just to store a single character. Whereas you can store an alphanumeric character in as few as 5 or 6 bits depending on how you do it. With a lot of text, this could add up.

 

It's definitely an interesting problem, and a fun challenge. Platforms like the Intellivision were not known for text storage/handling/display for a lot of reasons. It always blew me away to see just how much text could be crammed into the tiny home computer cartridges of the early 80s. I've never really spent the time to figure many of the tricks so a lot of this is magic to me.

 

[First Spear]

These small fonts look really good. Did they start as a typeface on a modern computer and then ported to Intellivision, or were they made from scratch?

 

 

 

Thanks for sharing!

 

 

[snip]

I'm actually doing dynamic small fonts in LTO Flash. I have two small font sizes, actually. With those, I store the images of the individual characters, and then I have code that "renders" text into a buffer in RAM that then gets loaded into GRAM. It's basically the technique DZ-Jay mentions above. It's a PITA, really. But it looks really good.[snip]

 

[intvnut]

These small fonts look really good. Did they start as a typeface on a modern computer and then ported to Intellivision, or were they made from scratch?

 

txt1.gif txt2.gif txt3.gif

 

 

I drew these from scratch, occasionally using certain existing fonts for inspiration. For the LTO Flash! fonts, I spent quite a bit of time trying to give the font visual consistency, tweaking a pixel here or there by hand until I liked it. I do look to existing fonts for inspiration, but I didn't start with an existing font and run it through any sort of automatic conversion.

 

An exception is the LTO Flash title screen itself. That's a bitmap conversion from the LTO Flash logo, in SF Quartzite Bold Oblique.

 

linetexttest2-pdn.jpg linetexttest-jz.jpg

 

That is a screen-snip from the Paint .NET image-editing bundle I am using to learn more about Inty graphics.

 

The current thought in my head is to keep all of the chaning text in a 3x8 tile area in the bottom right corner of the screen. Maybe I'll go to 8 tiles high by 8 wide, I want to show a lot of text without flipping away from the rest of the game.

 

In order to get there, my current thought is to make a custom program to manage the text and generate BMPs that IntyColor will consume, and then use a CMD to make the .bas bits of the text.

 

That satisfies the software architect in me, but your note about inefficiency bothers the software engineer in me. I would hate to run into memory problems because I am not doing the text "right". I am interested to understand how I could render a lot of text in a status area without using pre-gen bitmaps.... I think that is too much of a stretch for me at my skill level. If I do the text-image rendering in Windows first, I can set lots of pixel limits and get the image to fit and visually test it. If I do the rendering in IntyBASIC (skipping for a moment that may be beyond my current skills) then it might be harder to calculate character widths and might be harder to test. I'm very, very open to ideas however!

 

Thanks!

 

 

Some thoughts:

 

In the font design itself, I find that "diagonal corners" are the enemy of readability. Notice how the Intellivision stock font avoids them like the plague. For letters like 'o', 'w' and 'm', you might consider squaring up the corners a little:

.

.###.  .#...#.  .#####.
.#.#.  .#.#.#.  .#.#.#.
.###.  .##.##.  .#.#.#.

.

For the text box, the largest you can go is 8x8 tiles, but that will likely slurp up all your GRAM if you structure it as a bitmap. 8 * 8 = 64. And on memory usage: an 8x8 bitmap eats 512 bytes of memory (256 words if you pack it). Something to keep in mind when you consider how much text you'll have in the game. That said, strings of text aren't tiny either, but they're smaller than bitmaps. If you have a lot of text, you might consider compressing that too.

 

I'm not entirely sure IntyBASIC provides the right tools to do dynamic bitmap fonts. Maybe once I get LTO Flash! done, I could whip up some code for a 'canvas' widget that might be a good fit for IntyBASIC. ie. declare a canvas, and you can treat it as a 1-bpp bitmap. Draw text, lines, etc. It'd really only be practical if you're using extra RAM, I think. (It can be done w/out extra RAM, but it's far easier to get right with extra RAM.) It wouldn't be the highest performance thing in the universe, but it'd still be pretty neat I think.

 

Or if someone wants to beat me to it, be my guest! I know Arnauld already has a bunch of routines for this sort of thing in IntyOS.

Edited December 22, 2014 by intvnut

[First Spear]

I sunk a few hours around Christmas to make a Win32 program that allows writing/manipulating/storing text along with font info, and saves as .bmp. My current idea is to make all of the text I want under Windows and then use simple Windows CMD to wash them all through IntyColor and then assemble the source (probably also under a script on Windows).

 

I'll share the Windows tool out in about a week when it's fully functional. The CMD looks like this:

C:\src\intv\IntyBASIC\intycolor>type ..\go.cmd
set oldcd=%cd%
copy %1.bmp \src\intv\intybasic\1.0.1
cd \src\intv\intybasic\1.0.1
intycolor -b %1.bmp %1.bas
intybasic %1.bas %1.asm
move %1.asm \src\intv\jzIntv\jzintv-20101224-win32\jzintv\bin
cd \src\intv\jzIntv\jzintv-20101224-win32\jzintv\bin
as1600 -o %1.bin -l %1.lst %1.asm
jzintv -z1 %1.bin
cd %oldcd%

And a screen shot of the output:

 

 

The screen shot is for a large-typeface title kind of thing, but for the actual game I am thinking about, I want to keep text relegated to a 8w-x-5h tile corner in a small font. Text would be swapped in/out depending on game events. But all ideas are subject to change.

 

[snip]

Interesting concept though, and I bet this could work: have a status area with just the last line or three of text, and have that updated as necessary. If most/all sentences were pre-rendered, it would be pretty easy to swap in and out to display them. A special-purpose tool would definitely be useful here. Tooling it up in a Paint-type program and then converting with IntyColor is tedious as all hell. Works great for a few screens, not so great when you're wanting to store a lot of stuff. I find myself manually entering a lot of BITMAP "01001000" lines - pixel counting like in the old days

[snip]

 

[intvnut]

I sunk a few hours around Christmas to make a Win32 program that allows writing/manipulating/storing text along with font info, and saves as .bmp. My current idea is to make all of the text I want under Windows and then use simple Windows CMD to wash them all through IntyColor and then assemble the source (probably also under a script on Windows).

 

I'll share the Windows tool out in about a week when it's fully functional. The CMD looks like this:

C:\src\intv\IntyBASIC\intycolor>type ..\go.cmd
set oldcd=%cd%
copy %1.bmp \src\intv\intybasic\1.0.1
cd \src\intv\intybasic\1.0.1
intycolor -b %1.bmp %1.bas
intybasic %1.bas %1.asm
move %1.asm \src\intv\jzIntv\jzintv-20101224-win32\jzintv\bin
cd \src\intv\jzIntv\jzintv-20101224-win32\jzintv\bin
as1600 -o %1.bin -l %1.lst %1.asm
jzintv -z1 %1.bin
cd %oldcd%

And a screen shot of the output:

 

intvfo1.jpg

 

The screen shot is for a large-typeface title kind of thing, but for the actual game I am thinking about, I want to keep text relegated to a 8w-x-5h tile corner in a small font. Text would be swapped in/out depending on game events. But all ideas are subject to change.

 

 

 

Pretty cool!

 

Just one comment: Have you thought about putting jzIntv and IntyBASIC in your %PATH% variable, so you can keep your project files in a project dir, and avoid all those cd and move commands? You can either do that system wide, or add a set PATH=yaddayadda;%PATH% at the top of your script. Something like this:

.

    set JZINTV=\src\intv\jzIntv\jzintv-20101224-win32\jzintv
    set INTYBASIC=\src\intv\intybasic\1.0.1
    set PATH=%JZINTV%\bin;%INTYBASIC%;%PATH%
    
    intycolor -b %1.bmp %1.bas
    intybasic %1.bas %1.asm
    as1600 -o %1.bin -l %1.lst %1.asm
    jzintv -z1 %1.bin
    

.

If you want to be real fancy, I suppose you could through some IF ERRORLEVEL magic in there too.

Edited December 29, 2014 by intvnut

[First Spear]

Edit - v0.9 release is now available on the Intv Prime website.

 

 

 

 

I slammed together a small Win32 (.NET 4.5.2) application that makes small text experimentation a little easer. I remember in a post somewhere you mentioned that you had made single-purpose utility programs in the past to "scratch an itch". Experimenting with putting bits of text on an Intv screen is my current itch. The game I am planning will need to swap lots of informational text in/out of a small set of cards in the corner of the screen.

So here is Inty Letter Press v0.7.

 

IntyLetterPress-20150108-174820.zip

Maybe other folks with a similar interest will find it useful.

At first launch, there is some test data visible for "Game01". Changing the textboxes or dropdowns or spinners or color-buttons changes an in-memory bitmap, with a 4x preview displayed.

Clicking on the preview image itself toggles a grid overlay to give the user an idea of what might happen if the image is washed through IntyColor to make cards.

Action buttons at the bottom of the screen are used to add new text items, save/generate data in and from memory, save all changes to disk, make all text metadata match the currently visible one, bulk-generate BMPs for all text items, etc.

 

The on-disk repository is a an XML document so changes to lots of text can be made without needing to use the GUI.

The fonts used in the program are in the runtime's filesystem, Windows-installed fonts are not used to keep the OS clutter down and keep portability. I found freeware and open-source fonts through a few web searches and included them with this distribution. Please share small and/or good looking fonts you find. I'll make at least a few more updates to get it to v1.0.

I made this for "me", so the docs and error checking and Exception handling is minimal. I am really not happy with how the program is laid-out internally, but for the Q&D job this is supposed to it, it's good enough.

[snip]
The way I would approach this is to pre-allocate some space in GRAM specifically for the text messages. That way, you can make sure you have enough space for all your text at any point. Then, like you said, you swap the cards in GRAM with others that contain the pre-rendered small text.
[snip]

Edited January 16, 2015 by First Spear

[First Spear]

Some quick improvements I have in mind are adding metadata for custom leading/kerning within text items to pack/spread text across cards, adding some actual docs, adding some messaging and on-screen help. But I think it basically works. I think.

 

[snip]

 

So here is Inty Letter Press v0.7.

 

[snip]

 

 

 

[First Spear]

Hmm. I need to ask the admins to delete the attachment program I uploaded recently, found an issue.

[First Spear]

Issue fixed.

 

Hmm. I need to ask the admins to delete the attachment program I uploaded recently, found an issue.