SDLPoP Fonts Format

Open-source port of PoP that runs natively on Windows, Linux, etc.

Moderator: English Moderator Team

Post Reply
Nick2017
Sheikh
Sheikh
Posts: 30
Joined: January 7th, 2017, 10:45 pm

Re: MININIM Source Code Study

Post by Nick2017 » February 19th, 2017, 3:20 pm

Do you know if I can get the original fonts from the DOS version? I guess they must be inside the EXE file somewhere...

David
The Prince of Persia
The Prince of Persia
Posts: 1512
Joined: December 11th, 2008, 9:48 pm
Location: Hungary

Re: MININIM Source Code Study

Post by David » February 19th, 2017, 4:30 pm

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.

Nick2017
Sheikh
Sheikh
Posts: 30
Joined: January 7th, 2017, 10:45 pm

Re: MININIM Source Code Study

Post by Nick2017 » February 19th, 2017, 7:31 pm

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?

Nick2017
Sheikh
Sheikh
Posts: 30
Joined: January 7th, 2017, 10:45 pm

Re: MININIM Source Code Study

Post by Nick2017 » February 20th, 2017, 1:37 am

Are those fonts ok? because I'm trying to draw them and they seem to be garbage. Or maybe I'm missing something...

Nick2017
Sheikh
Sheikh
Posts: 30
Joined: January 7th, 2017, 10:45 pm

Re: MININIM Source Code Study

Post by Nick2017 » February 20th, 2017, 4:29 pm

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...

User avatar
oitofelix
Wise Scribe
Wise Scribe
Posts: 202
Joined: February 17th, 2016, 1:59 pm
Contact:

Re: MININIM Source Code Study

Post by oitofelix » February 20th, 2017, 4:38 pm

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.

Code: Select all

 88888  FFFFF Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
 8   8  F     http://oitofelix.freeshell.org/mininim/
 88888  FFFF  mailto:oitofelix@gnu.org
 8   8  F     irc://chat.freenode.org/oitofelix
 88888  F     Please, support my work: http://oitofelix.freeshell.org/funding.html

Nick2017
Sheikh
Sheikh
Posts: 30
Joined: January 7th, 2017, 10:45 pm

Re: MININIM Source Code Study

Post by Nick2017 » February 20th, 2017, 9:55 pm

Sorry, I went off topic, please delete my posts if you can.

Nick2017
Sheikh
Sheikh
Posts: 30
Joined: January 7th, 2017, 10:45 pm

SDLPoP Fonts Format

Post by Nick2017 » February 20th, 2017, 9:57 pm

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...

Falcury
Wise Scribe
Wise Scribe
Posts: 337
Joined: June 25th, 2009, 10:01 pm

Re: SDLPoP Fonts Format

Post by Falcury » February 25th, 2017, 1:01 pm

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

David
The Prince of Persia
The Prince of Persia
Posts: 1512
Joined: December 11th, 2008, 9:48 pm
Location: Hungary

Re: SDLPoP Fonts Format

Post by David » February 26th, 2017, 10:15 am

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.
pop_fonts.zip
(25.45 KiB) Downloaded 11 times

David
The Prince of Persia
The Prince of Persia
Posts: 1512
Joined: December 11th, 2008, 9:48 pm
Location: Hungary

Re: MININIM Source Code Study

Post by David » February 26th, 2017, 10:33 am

oitofelix wrote:Please move this discussion to an appropriate thread, probably in SDLPoP's forum.
Done.

Nick2017
Sheikh
Sheikh
Posts: 30
Joined: January 7th, 2017, 10:45 pm

Re: SDLPoP Fonts Format

Post by Nick2017 » March 1st, 2017, 1:09 pm

Yes, I got it working now, Thanks!

User avatar
Norbert
The Prince of Persia
The Prince of Persia
Posts: 3170
Joined: April 9th, 2009, 10:58 pm
Contact:

Re: SDLPoP Fonts Format

Post by Norbert » July 1st, 2017, 9:46 am

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.

David
The Prince of Persia
The Prince of Persia
Posts: 1512
Joined: December 11th, 2008, 9:48 pm
Location: Hungary

Re: SDLPoP Fonts Format

Post by David » July 8th, 2017, 8:35 am

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
dos_font_specials.png (1.03 KiB) Viewed 148 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.

User avatar
Norbert
The Prince of Persia
The Prince of Persia
Posts: 3170
Joined: April 9th, 2009, 10:58 pm
Contact:

Re: SDLPoP Fonts Format

Post by Norbert » July 8th, 2017, 12:23 pm

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.

Post Reply