I have the following code on MacOS:
For Local fntSize:Int = 0 To 72
Font_Ubuntu_M[fntSize] = LoadImageFont ("fonts/Ubuntu-M.ttf", fntSize, SMOOTHFONT)
Font_Ubuntu_B[fntSize] = LoadImageFont ("fonts/Ubuntu-B.ttf", fntSize, SMOOTHFONT)
Font_Diavlo_L[fntSize] = LoadImageFont ("fonts/Diavlo_LIGHT_II.otf", fntSize, SMOOTHFONT)
Font_Diavlo_M[fntSize] = LoadImageFont("fonts/Diavlo_MEDIUM_II.otf", fntSize, SMOOTHFONT)
Font_Diavlo_B[fntSize] = LoadImageFont ("fonts/Diavlo_BOLD_II.otf", fntSize, SMOOTHFONT)
Font_Diavlo_Book[fntSize] = LoadImageFont ("fonts/Diavlo_BOOK_II.otf", fntSize, SMOOTHFONT)
Next
After any 3 font arrays are loaded, images cannot be loaded anymore. LoadImage or LoadAnimImage no longer seem to work. I tried commenting all but 2 font arrays in the sequence above and everything works fine.
Why is this happening, what can I do to prevent it? The same code works fine on windows 10 x64.
I'm adding more details, maybe someone can help.
SuperStrict
Framework SDL.gl2sdlmax2d
Import BRL.Retro
Import BRL.Font
Import BRL.Max2D
Import brl.FreeTypeFont
Import brl.jpgloader
Import brl.pngloader
Global fontDiavloBlack40:TImageFont
fontDiavloBlack40 = LoadImageFont("fonts/Diavlo_BLACK_II.otf", 60, SMOOTHFONT)
Graphics 800,600
SetBlend alphablend
'Global imgToLoad:TImage=LoadImage("graphics/dol_tex.jpg") '<-------- This works
Global Font_Ubuntu_M:TImageFont[73]
Global Font_Ubuntu_B:TImageFont[73]
Global Font_Diavlo_M:TImageFont[73]
Global Font_Diavlo_Book:TImageFont[73]
Global Font_Diavlo_B:TImageFont[73]
Global Font_Diavlo_L:TImageFont[73]
LoadGameFonts()
Global imgToLoad:TImage=LoadImage("graphics/dol_tex.jpg") '<----------- this doesn't
Repeat
Cls
DrawImage(imgToLoad,0,0)
DrawTestText()
Flip()
If KeyHit (KEY_ESCAPE) Or AppTerminate() Then End
Forever
Function DrawTestText()
SetImageFont(fontDiavloBlack40)
DrawText("Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.",20,200)
SetImageFont(Null)
EndFunction
'Summary: Loads all game fonts
Function LoadGameFonts()
For Local fntSize:Int = 0 To 72
Font_Ubuntu_M[fntSize] = LoadImageFont ("fonts/Ubuntu-M.ttf", fntSize, SMOOTHFONT)
Font_Ubuntu_B[fntSize] = LoadImageFont ("fonts/Ubuntu-B.ttf", fntSize, SMOOTHFONT)
Font_Diavlo_L[fntSize] = LoadImageFont ("fonts/Diavlo_LIGHT_II.otf", fntSize, SMOOTHFONT)
Font_Diavlo_M[fntSize] = LoadImageFont("fonts/Diavlo_MEDIUM_II.otf", fntSize, SMOOTHFONT)
Font_Diavlo_B[fntSize] = LoadImageFont ("fonts/Diavlo_BOLD_II.otf", fntSize, SMOOTHFONT)
Font_Diavlo_Book[fntSize] = LoadImageFont ("fonts/Diavlo_BOOK_II.otf", fntSize, SMOOTHFONT)
Next
End Function
Same code runs just fine in windows 10.
this are 6*72 TImagefonts!!! Perhaps the MAC cannot handle such a big number.
May I ask a question? For what do you need a such big number of fonts at the same time. Are in your app textes on the screen which use all 432 font at the same time together?
Maybe a solution or a workaround is to load only those 10 variants of fonts that are used at the same time?
QuotePerhaps the MAC cannot handle such a big number.
That would be my guess, but it does not make any sense. I mean it can handle lots of images but not TImageFonts? I checked and it can only handle 231 fonts. However, if I don't use the SDL framework everything works fine. I don't even know where the problem is to report it.
I'm not using all those fonts at the same time but I use them to dynamically scale down text to fit my dialog boxes. The game will be localized in a few languages so I have to make sure the text does not overflow.
How would you go about selecting a smaller font size at runtime?
did you already measure how long it really needs to load a complete set of all 6 fonts?
If it lasts too long for you, you could try to add the 6 source ttf-file via INCBIN and measure again the loading time.
Did you ever need a font in size 0? And perhaps it would be exact enough to have them with +20% size steps
you would need 16 sizes: 5 - 6 - 7 - 8 - 10 - 12 - 14 - 17 - 21 - 25 - 30 - 37 - 44 - 53 - 64 - 77
and even with 10% size difference you would only need 26 sizes:
5-6-7-8-9-10-11-12-14-15-17-18-20-22-25-27-30-33-37-40-44-49-54-59-65-72
so you could keep 12 active font variants in a TList. And when you need a new one you could remove an old one.
Quotedid you already measure how long it really needs to load a complete set of all 6 fonts?
If it lasts too long for you, you could try to add the 6 source ttf-file via INCBIN and measure again the loading time.
No, what would be the use of that?
QuoteDid you ever need a font in size 0? And perhaps it would be exact enough to have them with +20% size steps
No, I obviously don't need a font in size 0. It was a mistake on my part. Your idea of 10% increments sounds like a good approach.
Still this sounds like an issue with Blitzmax. Can you try running the following code on your Mac? If you get more than 231, then it's clearly a hardware issue with my old MacBook.
SuperStrict
Framework SDL.gl2sdlmax2d
Import BRL.Retro
Import BRL.Font
Import BRL.Max2D
Import brl.FreeTypeFont
Import brl.jpgloader
Import brl.pngloader
Global fontDiavloBlack40:TImageFont
fontDiavloBlack40 = LoadImageFont("fonts/Diavlo_BLACK_II.otf", 60, SMOOTHFONT)
Graphics 800,600
SetBlend alphablend
'Global imgToLoad:TImage=LoadImage("graphics/dol_tex.jpg") '<-------- This works
Global maxFontCount:Int=323
Global Font_Ubuntu_M:TImageFont[500]
LoadGameFonts()
Global imgToLoad:TImage=LoadImage("graphics/dol_tex.jpg") '<----------- this doesn't
Repeat
Cls
DrawImage(imgToLoad,0,0)
DrawTestText()
Flip()
If KeyHit (KEY_ESCAPE) Or AppTerminate() Then End
Forever
Function DrawTestText()
SetImageFont(fontDiavloBlack40)
DrawText("Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.",20,200)
SetImageFont(Null)
EndFunction
'Summary: Loads all game fonts
Function LoadGameFonts()
For Local fntSize:Int = 0 To maxFontCount
Font_Ubuntu_M[fntSize] = LoadImageFont ("fonts/Ubuntu-M.ttf", fntSize, SMOOTHFONT)
Next
End Function
you should only load the fonts you want when you want them. There is no reason to load stuff just because you can
you should only load the fonts you want when you want them. There is no reason to load stuff just because you can
I agree with that. How would you go about implementing it for a feature like the attached screenshot. Each dialog "bubble" has a text block that must fit inside. If it doesn't then it's scaled down and broken into lines until it does. I have around 60 scenes like this one and the text size is computed at run time, when a story scene is loaded. The game will be localized in 6 languages. The German version is probably the one with the longest texts.
Would I check font size 32, it does not work, then load font size 31, check again, may not work, load font size 30, etc. then move to the next dialog bubble and start over?
There are multiple options to achieve it:
- load font sizes in steps (1,3,5,7...13,15 ...) and maybe only the "default" ones in the designed font size (so it "fits"9
- maybe during initial setup try out the localized stuff for each scene and find out what fonts are needed (you will never need ALL - for specific localizations)
- fix the width and make height of the bubbles adjustable (or fix height and make width a bit adjustable)
- You might even play with the idea of a "virtual" font - not actually loading the font but having the glyph information cached (so you can calculate text widths and heights without ... much trouble)
Most promising: use an image font class not creating an image texture for each single glyph - 300 files with maybe 300 glyphs in it already make up 90.000 textures :)
Texture atlas ... am not 100% sure but it sounds like it could help here.
https://github.com/TVTower/TVTower/blob/master/source/Dig/base.gfx.bitmapfont.bmx
I think I somewhen linked it for you already. It is my code to load TTF fonts into image atlases (saves textures) and also has functions for line wrapped / stylized (color, italic, bold ... shadow/glow) text in NG.
bye
Ron
ok, will check all the options. For sure will reduce the amount of fonts used. It's just so weird that it works with standard brl but not with SDL.
Quote
I think I somewhen linked it for you already. It is my code to load TTF fonts into image atlases (saves textures) and also has functions for line wrapped / stylized (color, italic, bold ... shadow/glow) text in NG.
Yes, you did. But this game was built using Vanilla, I'm just now using NG to port it for MacOS. Will probably switch completely to NG soon.
I measured the loading of a TimageFont. First time loadfing needs less than 1msec. If you repeat the loading of the same font but with a different FontSize the time needed shrinks to 0.3msec
QuoteI measured the loading of a TimageFont. First time loadfing needs less than 1msec. If you repeat the loading of the same font but with a different FontSize the time needed shrinks to 0.3msec
I still have no idea what to do with this information.
There clearly is an issue with SDL and TImageFont as we've ran some tests on discord yesterday and at some point the limit was broken then it came back on for no reason.
I have significantly reduced the amount of fonts loaded and for the next game I will optimize it even further. Your suggestion to use % increments is nice and Derron also gave me a few very good options @Discord. That along with his font class should greatly optimize the texts in my next game.
PS: I've written this message Monday morning but forgot to press "Post", sorry for late reply Midimaster
QuoteI measured the loading of a TimageFont. First time loadfing needs less than 1msec. If you repeat the loading of the same font but with a different FontSize the time needed shrinks to 0.3msec
Whilst this is mostly irrelevant to the issue of using too many fonts.
Here's the actual actual answer to the (unwanted) speed:
1. When you fist load a font - the font is loaded into memory - and it will stay there until the garbage collector clears it,
2. when you create a font with a different size - the font is already in memory, and the new size is created from that - That is the reason it becomes faster.
3. this is because of the way blitz is programmed. it's been that way for a long time and is simple to understand.
OK.
@Ashmoor Listen to Derron - he really knows his stuff and what is going on underneath with blitz.
You mentioned that different languages needed different font sizes - then that is how you progress - test and find the optimal font for each language.
But... There is another way you could do this:
Render your fonts/text to an offscreen canvas that will support the text and then copy this canvas to your main canvas. resizing to fit. Derron can give you more advice on how to do this :)
rendering to a texture is not of much help - as this will scale width and height. but "width" is kind of constant (per screen) so if using a smaller font more text will fit onto a line - and this will lead to different parts of the complete text to be "wrapped" (line wrap).
Had this in mind too but scrapped it.
My idea was to use a dynamic "stepping" for the font sizes and its variations.
if your font was size 10 - also load 8 and 9 (step size 1)
if your font was size 20 - also load 16 and 18 (step size 2)
if your font was size 30 - also load 24 and 27 (step size 3)
The bigger a font the less pixels a "bit smaller" font size will save.
This is similar to the 10% thing suggested above already (did not read about it before trying to help). 10% is of course easier to calculate :)
A way more prolificient approach is to find out what fonts are needed on game start (if not cached for the choosen localization language already). The game knows potential dialogues ... and "layout" of the speech bubbles on the screen -- so it can calculate everything in advance.
This way it will only load the fonts it really needs.
BTW: the font Ashmoor was using contained 1200 glyphs ... and I sent him a font which only had 120 glyphs in it. then we checked if loading 3000 files instead of 300 lead to the same issue - it didn't.
We also loaded the font with very huge sizes so that the glyphs were 2k textures... no change. So the "issue" itself is still unresolved. We just circumvent it now by loading way less assets (think of 1200 glyphs * 250 font sizes ... all of them GC managed :)).
bye
Ron
QuoteWould I check font size 32, it does not work, then load font size 31, check again, may not work, load font size 30, etc. then move to the next dialog bubble and start over?
This is somehow what I do with JM games (and it is not perfect as you know).
Another possibility is to use fewer and bigger fonts, and scale them down depending on the cases. By example size 32 would be used for texts from 24 to 32, size 24 for 16 to 24... but that may blur the texts a little.
Maybe a reason why it crashes with SDL is related to the amount of memory used for this purpose ?
I guess that a tt font is converted at runtime in bitmaps and for a reason or another SLD limit that bitmap size, while directX would not care ? Just wondering...
Quote from: Pingus on August 19, 2021, 01:25:18
Maybe a reason why it crashes with SDL is related to the amount of memory used for this purpose ?
I guess that a tt font is converted at runtime in bitmaps and for a reason or another SLD limit that bitmap size, while directX would not care ? Just wondering...
quoting myself (answer above yours).
Quote
BTW: the font Ashmoor was using contained 1200 glyphs ... and I sent him a font which only had 120 glyphs in it. then we checked if loading 3000 files instead of 300 lead to the same issue - it didn't.
We also loaded the font with very huge sizes so that the glyphs were 2k textures... no change. So the "issue" itself is still unresolved.
bye
Ron
QuoteMaybe a reason why it crashes with SDL is related to the amount of memory used for this purpose ?
I don't think it's directly related to the memory but I'm not good enough to tell.
And I don't think it's the amount of glyphs in a font either. For example I just ran a test now on windows and the program halts after loading 510 font instances. One font has 1264 glyphs leading to a total of ~650k glyphs loaded, the other font has 223 leading to a total of 120k glyphs. They both halt after 510 instances.
This is the font loading function
Function LoadGameFonts2()
For Local fntSize:Int = 1 To 1800
'Font_Ubuntu_M[fntSize] = LoadImageFont ("fonts/Ubuntu-M.ttf", fntSize, SMOOTHFONT) '<------- 1264 glyphs, loads 510 instances
Font_Ubuntu_M[fntSize] = LoadImageFont ("fonts/Grande_Andretti_-_limited_charset2.ttf", fntSize, SMOOTHFONT) '<-------------- 223 glyphs, loads 510 instances
If Not Font_Ubuntu_M[fntSize]
Throw "Font load failed: fntSize=" + fntSize +". Loaded a bit more than " + fontGlyphCount + " glyphs."
EndIf
Print Font_Ubuntu_M[fntSize].CountGlyphs() + " glyphs loaded."
fontGlyphCount :+ Font_Ubuntu_M[fntSize].CountGlyphs()
Next
Print "loaded a total of " + fontGlyphCount + " glyphs."
End Function
However, Blitzmax is not consistent in itself. The first time I ran the code above today, from MaxIDE, I only got about 130k glyphs loaded from both fonts. Then I switched a bit between release and debug and got it back up to 510 instances.
Edit: I have 32 GB Ram in my system and 6GB video memory. I'll try to update to the latest blitzmax version from GitHub and will see how that goes.
You can try to run a debug build, debugstop before actually loading the 510th font instance. And then check if one of the elements becomes "null" albeit it shouldn't.
bye
Ron
Quote from: Ashmoor on August 17, 2021, 15:20:13
QuoteI measured the loading of a TimageFont. First time loadfing needs less than 1msec. If you repeat the loading of the same font but with a different FontSize the time needed shrinks to 0.3msec
I still have no idea what to do with this information.
....
What I wanted to say is that your pre-loading is not neccessary. If you load the font in the moment, when you need it this would not cause timing problems.
If you want to test different sizes of a font you could always start with a first size, then decide if it is to big or to small. This would only need 1msec. Now you decide for the next size, load it to the same TImageFont and check again if it fits. This would need less than 1msec, because the font-file is still in the buffer. This means a repeat loading of the same font in different sizes would also not cause timing problems.
If you think about a strategy of loading I would not do this with a seqence like: 32, then 31 then 30... but:
Testing 32 Fonts from size 1 to 32Start with size 16
Load this size
Decide wether it is to big or to small
If it is to big substract 8 -> test with 8
If it is to small add 8 --> test with 24
Load this size
Decide wether it is to big or to small
If it is to big substract 4
If it is to small add 4
Load this size
Decide wether it is to big or to small
If it is to big substract 2
If it is to small add 2
Load this size
Decide wether it is to big or to small
If it is to big substract 1
If it is to small add 1
Found!!!
This method only needs 4 checks to find the optimal font.
This can be coded very easy with a simple iteration.
QuoteBlitzmax is not consistent in itself
You've always got to have the following clear in your head:
1. macos and window and linux, etc are not the same.
2. there is completely different code going on behind the scenes. this might be differences in logic, handling etc.
3. sometimes completely different libraries to do the same thing on different systems.
4. BlitzMax hides all of this from you and gives you a simple command
5. the os compilers can be and are very different
6. the hardware and os are very different beasts. macos can be more forgiving, and windows more strict
7. the memory handling between os is completely different
windows uses win32
macos uses - all sorts of stuff, cocoa for example. plus you are dealing with both c and objective c
The thing you HAVE to do is test on both systems and write code that is both clear and concise. and in some instances os specific!
Quote from: Midimaster on August 27, 2021, 08:35:30
What I wanted to say is that your pre-loading is not neccessary. If you load the font in the moment, when you need it this would not cause timing problems.
If you want to test different sizes of a font you could always start with a first size, then decide if it is to big or to small. This would only need 1msec. Now you decide for the next size,
[...]
This method only needs 4 checks to find the optimal font.
This can be coded very easy with a simple iteration.
Assuming this takes 1 ms per "font to load + to find out dimensions" it means you already spend 4 ms for identifying the font.
This needs - in worst case - to be done a multiple times on the screen (multiple dialogue boxes - each with other text and thus requiring multiple font sizes to be "checked").
If there are at the end 2 boxes with "totally different font sizes" (so not loaded already) this will already be 8 ms just for "font stuff".
Yet you might require more than 1 ms:
- load font (decode ttf, rasterize glyphs)
- do the text wrapping based on the glyphs
Somewhen you reach a required time leading to a visual "hickup". So this most probably only works satisfying if you do fade-to-black screen transitions or static imagery with no animation.
Best approach stays the identification of "to use font sizes" at the begin of the game / first use of a language. Especially if your dialogue texts are "fixed" and not containing dynamic information (individual character name, item names, day names ...) as this means the line wrapping information is "constant" and can be precalculated then.
Next best bet is to scale the bigger fonts - or to "know" what font sizes are "realistically" used. You wont need "font size 200". You might need "10,11,12" for "text", "24,25,26" for headers etc.
This will result in maybe 20 font sizes at the end. Multiplied by "bold/italic"-style variations
BTW another approach to "fit" smaller font sizes is to slightly increase "word spacing" ("width of a space-char") and glyph-advancement (of course you here better have your custom font draw class). This way you can slightly "increase" visual dimension of the text without falling back to a "bigger" font.
Maybe - only some percents - this can also be done to "scale down" (make chars a tiny bit more "narrow" etc). Without affecting the visual appearance of the glyphs itself (they are not scaled - just the whitespace is manipulated).
bye
Ron
QuoteBTW another approach to "fit" smaller font sizes is to slightly increase "word spacing"
or just write a dirty text render system, where you draw each character giving space. if you already know which languages will be 'longer' then you could also do this with a different font.
BUT...
If you already know how many languages and which are causing issues then just tailor the output for each language. load the needed fonts for each language when the language is picked (use flags for the language picker) and virtually forget most of this thread - brute force is always the best way ;)
normally texts stay at the screen for a couple of seconds. So you need not to proceed the same testing each FLIP. If you need to display new text, you could check the text once and load the font and asign it to the box. If BoxFont<>NULL means "text is already checked, use this font!"
I testet that finding out the best size does not need more than 2msecs. Each current text box should have its own BoxFont
Quote from: Midimaster on August 27, 2021, 11:26:34
normally texts stay at the screen for a couple of seconds. So you need not to proceed the same testing each FLIP. If you need to display new text, you could check the text once and load the font and asign it to the box. If BoxFont<>NULL means "text is already checked, use this font!"
I testet that finding out the best size does not need more than 2msecs. Each current text box should have its own BoxFont
Nobody wrote you should do that each frame. But you wrote about doing it "on request" (or "when needed"). Which means it could happen during an animation (balloons with text pop in ...). If then such a lookup takes longer (no SSD but classic HDD, bigger font files - he uses a one with 1200 glyphs needing rasterization) it can lead to a little "hickup".
This is just a "minor" thing - of course.
Essence of what we all replied is surely: only load the fonts you need - instead of 250.
Yet it still indicates there is a "bug" somewhere - and maybe a bug which does not only affect fonts but maybe other things too. Hence the request to debug the font loading on his side properly.
bye
Ron
Check which font loader Blitz uses. I've had issues with freetype font on numerous occasions going back many years.
There is also the fonts themselves - it only takes one wrong glyph to throw the entire font off. Mac and PC handle fonts very differently
So Derron is (again) correct, with the possibility of further bugs deep within the system.
As an aside to this - wonkey had a font issue that caused very strange memory issues and wonkey/monkey are derivatives of BlitzMax.
My own take would be to load minimal fonts and potentially rewrite the output routines - say one font of a bigger size that can be scaled simply down. Marks way of loading fonts is not (imho the best way to approach things, best to keep fonts to a minimum) a brilliant solution - lots of TImage plus memory overheads.
The loads of Timages allow to circument an issue "easily": maximum texture size supported by ones GPU.
My font class places all the glyphs on a single texture - so at a font size of 200 it surely would run into issues with maximum texture sizes here and there. You might need to have multiple atlases then (so at the end you might have 10 atlases with 20 big glyphs each - to have all your 200 characters rasterized and available).
Once I found the time to make my font class independent from my DIG-framework (means custom FontSprite, FontSpriteAtlas types etc) I could easily add this too (as the glyph does not need to know where their texture actually comes from - ist has a "draw(x,y)" and whatever happens in the background is not of their matter :)).
bye
Ron
Thanks for all the replies guys. Currently I am too busy to find a two hour window to run better tests. I will try to do it tomorrow and maybe we'll get to the bottom of this.
@iwasadam when I said it's not consistent in itself I meant within the same system. When I tested the loading of fonts I did what Derron advised and added a debug stop before loading the crashing instance and went step by step after that. The program didn't halt. I stopped it and ran it again without the debugstop line, it loaded the fonts without issue. I tried with 2000 instances and it worked. I closed MaxIDE and started it again and then the same code, that didn't crash last time would crash again. I need to record my screen while running the tests so I can be sure that I don't set some flags differently.
If you think it is Blitzmax creating "varying" code, then just run the same binary over and over (instead of creating/compiling to a new binary each time).
The issue might still be with RAM/VRAM, memory pages, ... it might even be some race condition / threading (dunno how freetype loads fonts).
bye
Ron
I'm trying to add all the latest updates from github but I'm getting an error "Can't balance types Byte Ptr and LPARAM", pointing to line 532 if win32maxguiex.bmx
I got BlitzMax_win32_0.129.3.45.7z for win32 x86/x64
got bmk and bcc from brucey's github
copied bmk and bcc to "src"
used command prompt to build them "bmk makeapp -a -r -h -t console ../src/bmk/bmk.bmx" and "bmk makeapp -a -r -t console ../src/bcc-ng/bcc.bmx"
copied resulting exe files to "bin"
copied new modules into "mod" folder ( brl.mod, database.mod, maxgui.mod, physics.mod, pub.mod, sdl.mod)
restarted maxIDE and went to program/rebuild all modules.
I must be doing something wrong. This is on windows 10 x64.
I am guessing MaxGUI is a 32 bit thing and that's why it does not build with the rest of the modules so I skipped it completely.
I tried running the code with debugstop() and all the glyphs are null. Not a single glyph is actually loaded. I checked max2d.mod/imagefont and it seems like no glyph is actually loaded until the draw() call. Only the glyph arrays are initiated, both for the source font and the TImageFont. I may not understand the code though, it looks too advanced for me. I have attached a debugger print screen.