SDLPoP Fonts Format

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

Moderator: English Moderator Team

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

Re: MININIM Source Code Study

Postby 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: 1327
Joined: December 11th, 2008, 9:48 pm
Location: Hungary

Re: MININIM Source Code Study

Postby 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

Postby 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

Postby 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

Postby 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
Sultan
Sultan
Posts: 186
Joined: February 17th, 2016, 1:59 pm
Contact:

Re: MININIM Source Code Study

Postby 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

Postby 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

Postby 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: 291
Joined: June 25th, 2009, 10:01 pm

Re: SDLPoP Fonts Format

Postby 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: 1327
Joined: December 11th, 2008, 9:48 pm
Location: Hungary

Re: SDLPoP Fonts Format

Postby 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 6 times

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

Re: MININIM Source Code Study

Postby 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

Postby Nick2017 » March 1st, 2017, 1:09 pm

Yes, I got it working now, Thanks!


Return to “SDLPoP”

Who is online

Users browsing this forum: No registered users and 1 guest