Page 1 of 1
Re: MININIM Source Code Study
Posted: February 19th, 2017, 3:20 pm
by Nick2017
Do you know if I can get the original fonts from the DOS version? I guess they must be inside the EXE file somewhere...
Re: MININIM Source Code Study
Posted: February 19th, 2017, 4:30 pm
by David
Nick2017 wrote:Do you know if I can get the original fonts from the DOS version?
You can get it as PNG images from SDLPoP:
https://github.com/NagyD/SDLPoP/tree/master/data/font
Nick2017 wrote:I guess they must be inside the EXE file somewhere...
Yes, it is.
Here it is in its original format:
https://github.com/NagyD/SDLPoP/blob/ma ... 009.c#L719
Scroll down for the code that converts it into images.
Re: MININIM Source Code Study
Posted: February 19th, 2017, 7:31 pm
by Nick2017
Excellent, thanks! are they 8x7? because I counted the pixels of the original game and they seem to be 8 pixels wide and 7 tall, am I right?
Re: MININIM Source Code Study
Posted: February 20th, 2017, 1:37 am
by Nick2017
Are those fonts ok? because I'm trying to draw them and they seem to be garbage. Or maybe I'm missing something...
Re: MININIM Source Code Study
Posted: February 20th, 2017, 4:29 pm
by Nick2017
Ok, I've been looking at the function "font_type load_font_from_data(/*const*/ rawfont_type* data)" and it seems like the vector hc_font_data[] has the following structure:
Code: Select all
typedef struct font_type {
byte first_char;
byte last_char;
short height_above_baseline;
short height_below_baseline;
short space_between_lines;
short space_between_chars;
chtab_type* chtab;
} font_type;
but what I don't understand is, if every char has that structure or that is only at the beggining of hc_font_data...
Re: MININIM Source Code Study
Posted: February 20th, 2017, 4:38 pm
by oitofelix
Nick2017 wrote:Ok, I've been looking at the function "font_type load_font_from_data(/*const*/ rawfont_type* data)"...
This is not MININIM related. Please move this discussion to an appropriate thread, probably in SDLPoP's forum.
Re: MININIM Source Code Study
Posted: February 20th, 2017, 9:55 pm
by Nick2017
Sorry, I went off topic, please delete my posts if you can.
SDLPoP Fonts Format
Posted: February 20th, 2017, 9:57 pm
by Nick2017
I've been looking at the function "font_type load_font_from_data(/*const*/ rawfont_type* data)" and it seems like the vector hc_font_data[] has the following structure:
Code: Select all
typedef struct font_type {
byte first_char;
byte last_char;
short height_above_baseline;
short height_below_baseline;
short space_between_lines;
short space_between_chars;
chtab_type* chtab;
} font_type;
but what I don't understand is, if every char has that structure or that is only at the beggining of hc_font_data...
Re: SDLPoP Fonts Format
Posted: February 25th, 2017, 1:01 pm
by Falcury
It's only at the beginning of hc_font_data.
Probably, rawfont_type is a more accurate description:
Code: Select all
typedef struct rawfont_type {
byte first_char;
byte last_char;
short height_above_baseline;
short height_below_baseline;
short space_between_lines;
short space_between_chars;
word offsets[0];
} rawfont_type;
At offset 0x000A, there is a table of 16-bit offsets for each of the character glyphs, starting at char_20 and ending at char_83.
Then, starting at offset 0x00D2, the actual character glyphs begin.
The glyphs themselves are used in the SDLPoP source code as an image_data_type:
Code: Select all
typedef struct image_data_type {
Uint16 height;
Uint16 width;
Uint16 flags;
byte data[0];
} image_data_type;
The character glyphs are stored using 1 bit per pixel, 1 byte per row (so font characters can never be more than 8 pixels wide).
Because of the way that the glyphs are packed, the image_data_type struct is probably not the best way to describe the glyphs, now that I think of it.
If you want to take a look for yourself, look in David's
PRINCE.EXE disassembly, at the seg_font segment.
If I'm not mistaken, the hc_font_data byte array came directly from there!
And the character glyphs themselves are neatly layed out in the disassembly, so all of the glyphs are directly recognizable. Examples:
Code: Select all
seg_font:01A8 07 00 char_32 dw 7 ; DATA XREF: seg_font:tbl_font_offso
seg_font:01AA 06 00 dw 6
seg_font:01AC 01 00 dw 1
seg_font:01AE 78 CC 0C 18 30 60 FC db 1111000b
seg_font:01AE db 11001100b
seg_font:01AE db 1100b
seg_font:01AE db 11000b
seg_font:01AE db 110000b
seg_font:01AE db 1100000b
seg_font:01AE db 11111100b
seg_font:01B5 07 00 char_33 dw 7 ; DATA XREF: seg_font:tbl_font_offso
seg_font:01B7 06 00 dw 6
seg_font:01B9 01 00 dw 1
seg_font:01BB 78 CC 0C 18 0C CC 78 db 1111000b
seg_font:01BB db 11001100b
seg_font:01BB db 1100b
seg_font:01BB db 11000b
seg_font:01BB db 1100b
seg_font:01BB db 11001100b
seg_font:01BB db 1111000b
seg_font:01C2 07 00 char_34 dw 7 ; DATA XREF: seg_font:tbl_font_offso
seg_font:01C4 07 00 dw 7
seg_font:01C6 01 00 dw 1
seg_font:01C8 1C 3C 6C CC FE 0C 0C db 11100b
seg_font:01C8 db 111100b
seg_font:01C8 db 1101100b
seg_font:01C8 db 11001100b
seg_font:01C8 db 11111110b
seg_font:01C8 db 1100b
seg_font:01C8 db 1100b
Re: SDLPoP Fonts Format
Posted: February 26th, 2017, 10:15 am
by David
Falcury wrote:
The character glyphs are stored using 1 bit per pixel,
Correct.
Falcury wrote:
1 byte per row (so font characters can never be more than 8 pixels wide).
Not true.
Although most characters are really not wider than 8 pixels, char_81, char_82 and char_83 are wider than that.
Those characters are glyphs for some special keys: char_81 = [ALT], char_82 = [CTRL], char_83 = [ESC].
I wonder why are they there.
Other special (non-ASCII) characters are char_7F (ø) and char_80 (✓).
char_7F is used in Brøderbund's name in the "to purchase" message after level 2 (shown after the quotes) in the PoP1.3 demo.
By the way, PoP2 (the hardcoded font) has these glyphs mapped to different codes: 0x1B=[ESC], 0x1C=[ALT], 0x1D=[CTRL], 0x1E=✓, 0x1F=ø.
And of course the German and French versions of PoP1 have some accented letters:
German: 0x84=ö, 0x85=ü
French: 0x84=é, 0x85=à, 0x86=è
And finally, PoP2's "nice" fonts have these: 0x3C = opening quote, 0x3E = ø.
Falcury wrote:
If you want to take a look for yourself, look in David's
PRINCE.EXE disassembly, at the seg_font segment.
If I'm not mistaken, the hc_font_data byte array came directly from there!
Correct.
You know what?
I have a small program that can convert PoP1 and PoP2 fonts into readable form.
Here it is, together with all fonts from PoP1 and PoP2.
Re: MININIM Source Code Study
Posted: February 26th, 2017, 10:33 am
by David
oitofelix wrote:Please move this discussion to an appropriate thread, probably in SDLPoP's forum.
Done.
Re: SDLPoP Fonts Format
Posted: March 1st, 2017, 1:09 pm
by Nick2017
Yes, I got it working now, Thanks!
Re: SDLPoP Fonts Format
Posted: July 1st, 2017, 9:46 am
by Norbert
Maybe the partial underscoring of ALT was caused by an export bug?
https://github.com/NagyD/SDLPoP/blob/ma ... es1129.png
It also feels like the text should be moved 1 pixel to the right.
Re: SDLPoP Fonts Format
Posted: July 8th, 2017, 8:35 am
by David
Norbert wrote:Maybe the partial underscoring of ALT was caused by an export bug?
It also looks like that in the original version:
- dos_font_specials.png (1.03 KiB) Viewed 4984 times
Showing the characters from 0x7F to 0x83.
(I hex-edited the
Loading... text instead of one of the status bar texts, because in the status bar the ALT/CTRL/ESC glyphs would have their bottoms cut off.)
Here is the disassembly:
Code: Select all
seg_font:05A7 08 00 char_81 dw 8 ; height in pixels
seg_font:05A9 10 00 dw 10h ; width in pixels
seg_font:05AB 02 00 dw 2 ; width in bytes
seg_font:05AD 7F FE CD C7 B5 EF B5+ db 1111111b,11111110b ; 1
seg_font:05AD EF 85 EF B5 EF B4 6F db 11001101b,11000111b ; 2
seg_font:05AD db 10110101b,11101111b ; 3
seg_font:05AD db 10110101b,11101111b ; 4
seg_font:05AD db 10000101b,11101111b ; 5
seg_font:05AD db 10110101b,11101111b ; 6
seg_font:05AD db 10110100b, 1101111b ; 7
seg_font:05BB 08 00 char_82 dw 8
seg_font:05BD 13 00 dw 13h
seg_font:05BF 03 00 dw 3
The ALT glyph is marked as 8 pixels tall, but the 8th row is missing, thus the header of the next glyph is used as 8th row.
Re: SDLPoP Fonts Format
Posted: July 8th, 2017, 12:23 pm
by Norbert
David wrote:The ALT glyph is marked as 8 pixels tall, but the 8th row is missing, thus the header of the next glyph is used as 8th row.
Interesting.
Actually, where are these modifier keys even shown?
Maybe they planned to add a help screen that would show shortcuts.
Or perhaps they just added most keys in case they would need them.
