Page 1 of 1

Load font from tape directly to memory

Posted: Tue Dec 22, 2020 4:20 pm
by amateus

I was researching fonts and saw that mostly people has a asm file with some fonts and then loop through the characters and assign the tile to a char.

(taken from blackstar)

Code: Select all

pt = font;
   for (i = 0; i < 96; ++i, pt += 8)
      sp1_TileEntry(32 + i, pt);
I wonder if it's possible to save a font from an editor and load it directly to the spectrum character set. This, to my limited understanding, will avoid having an ASM with the fonts and load them through code as the example above, saving memory.

Tried to do it by exporting the ASM file from FZX editor, compiled and save it to a TAP and then load""code to the udg memory location.
It failed and produced a lot of interesting crashes :lol:

So the question is: is there a way of doing this like I was thinking, and will it be better, or am I just overthinking this? If so, how?

Thank you

Re: Load font from tape directly to memory

Posted: Tue Dec 22, 2020 5:35 pm
by amateus
(For a solution to load a font in 64000,768 and then poke it see ... php?t=1653)

Re: Load font from tape directly to memory

Posted: Tue Dec 22, 2020 9:51 pm
by Timmy
I think you are confusing a lot of things.

There are many ways to display a font, I'll list some here:

1) Using the BASIC PRINT routine. The BASIC routine find the location of its font by looking at some memory address (23606, 23607). The default font is stored in read-only memory, so if you want to store a new font, you must store it on some other place. The font size is 8x8 pixels.

2) FZX fonts are stored in a specialised fzx font format. It produces a proportional font. The size of this "file" is very flexible. FZX fonts can only be displayed using the fzx library. The font size is flexible.

3) SP1 has (many) tiles. Somehow, some interesting programmers defined in their games that tile 32 happens to be empty, and they defined tile 65 to look like 'A'. You don't have to. All sp1 tiles (or font tiles) happens to be 8x8 pixels, so sp1 can re-use the spectrum font for these tiles too. Also, sp1 initialised tile '65' to 8 bytes in the spectrum ROM that happens to look like 'A', but you can override that by using code that was shown in the first post of this thread.

You can use all 3 methods to display texts on screen. However they are not completely compatible. Inside all sp1_Rect's, only sp1 tiles can be used. Outside those rectangles, you can choose any other way to display things.

Fonts are always stored in memory, and to store them into memory one can load them from tape.

If this sounds confusing to you, then perhaps you should try making a game with SP1 only. Forget FZX and the BASIC font for now, and use them in a second game.

Re: Load font from tape directly to memory

Posted: Wed Dec 23, 2020 9:09 pm
by amateus
Yeah you're right, I was confusing this, thank you for your explanation.

Still in fonts tho, can you please clarify this behavior?

Code: Select all

unsigned char ready_text[] = "READY PLAYER ONE!.";
    struct sp1_Rect r = {18,  1, 22, 1};
    struct sp1_pss ps0;
    ps0.bounds = &r; 
    ps0.flags = SP1_PSSFLAG_INVALIDATE;
    ps0.visit = 0;
    sp1_ClearRectInv(&r, INK_WHITE | PAPER_BLACK, ' ', SP1_RFLAG_TILE | SP1_RFLAG_COLOUR);
    sp1_SetPrintPos(&ps0, 0, 0);
    sp1_PrintString(&ps0, ready_text);
    sp1_ClearRectInv(&r, INK_WHITE | PAPER_BLACK, ' ', SP1_RFLAG_TILE | SP1_RFLAG_COLOUR);
and the string that appears (in blue which is also wrong) is:

Code: Select all

I didn't change anything, except a and b character for a graphic.


Re: Load font from tape directly to memory

Posted: Tue Dec 29, 2020 1:09 am
by Timmy
1) Did you set up colours when you print the string? (my guess)

2) As for the string that appears, the problem is not in this part of the code.

Re: Load font from tape directly to memory

Posted: Tue Dec 29, 2020 2:49 pm
by amateus
Hi Timmy,

1) actually no, so it seems to be picking the last configuration?

2) what strikes me odd is that this is done without any interaction with the udgs, except for a and b which were changed, and this was done in the beginning of the project, so a L should have been printed correctly, cause I don't think the problem was memory at that point in time. I eventually applied the blackstar/mspacman solution I've mentioned in the first post, and all characters were correctly printed.