(FontMachine) 9MB Font fails to load in DX9 mode

[Yellownakji]

Hey there,

I was told that, in NG, you can check if an asset is loaded with the expression " if fnt_system "... (In this example, checking for the main Tbitmap font..)

--

I've made my own loading loop, utilizing this.   I use it to load required text strings, sounds and images however, i've encountered an issue that i can't seem to resolve, at least i'm ignorant to seeing a solution currently.

The 'fnt_system' actually crashes, when being loaded in DX9 rendering mode.  It returns a violation access, so i assume the font fails to load properly or completely?

In GL mode however, the font loads fine...   the app actually freezes itself for a second to catch up with the loading in GL mode..  so i wonder if it was an improper load?

--

Does anybody know a better loading technique / a more.. accurate way to see if a asset exists / is ready?  Open to ideas.. needs to run in DX9 mode.

I have gotten other fonts to load, but they were only a few KB in size.. This particular one is 9MB.

--

Thanks. 

[Derron]

Maybe add "Font Machine:" to your thread title ... without that little side note at the end of your thread I would not have known what you were talking about.

If compiled in debug mode you should see where exactly it fails.


bye
Ron

[Yellownakji]

I'm aware Ron, but it does not really answer my question.   The error itself is a D3D9 surface failing to create... Then Blide opens the D3d9MAX2D.bmx @ line 118 (_d3d9Graphics.AutoRelease _texture)

It only does this when i attempt to load this font, in DX9 mode.

[Derron]

doesn't it tell you if eg. "_texture" is null?

Is the 9MB texture maybe too big? what dimension does it have?
I never used "FontMachine" as I wrote my own BitmapFont-Class (+sprite atlas +effects like dropshadow/glow). But all in all it will do the same thing: render glyphs onto a big image sheet. So if you use a big font size (72 or so) then the resulting texture might be bigger than simple 2k*2k. Depending on that size things might fail somehow (gpu driver issues).

Can you recreate the issue with a simple sample doing nothing more than creating the graphics context (opening up the window...), loading the file and using the font in a simple cls + draw + flip loop?
With this (and the asset itself) people might be able to check it out and maybe are able to help.


bye
Ron

[col]

If NG is set up the same as the legacy BMax then the actual gpu texture for the font character(s) are only created when you hit a DrawText command. If you get a crash at the point of loading the font then something else related is going on.
If you are loading a font into an existing variable name that has a font so that the old font is now up for being collected by the GC, then the GC could in turn release the textures used by that old font, that could be exposing a possible bug.

You could be doing things manually in your own code as opposed to using the BMax font commands, but the possible issues above will still apply, if this is the case what texture size is the font?.


PS. We did use to have a similar sounding issue but it was fixed - maybe there's a regression in there somewhere.

As Derron says... if you can post the font and a small demo that reproduces the issue then I'm sure the problem can be found pretty quickly.

[Yellownakji]

So, it's been some hours.   I toyed around a good bit and have found a solution.

It seems .FMFs that exceed 2mb should not be used with 'incbin' when rendering in DX9 mode.  Something to do with an overflow of allowed texture indexes. -- Instead, load them from a resource folder..   

Loads fine now.   However, you COULD use 'incbin' if you were rendering in GL and perhaps Mojo. 

[Derron]

But this isn't a bug with DX then ... it does not matter from where the stream comes ... from memory or from an external file. The texture loaders receive the data to decode, and that's it - at least I assume so (without looking at the brl.mod-sources now).

How can the file be 9MB sized - a png file of that size means the texture is hard to compress (random pixels everywhere) and someK*someK big.


Maybe you can provide the FMFs-file for col? so he could have a in-depth-look on his windows machine.


bye
Ron

[Yellownakji]

FMF is just a container.  You can verify this in a hex editor.

Every glyph, shadow (as well as texture, border) for each glyph are individual PNGs.   So if you have 6,000 glyphs or so like i do, you'll also have another 6000 for shadows etc.

--

This font contains everything.  Standard latin + latin extensions, cryrillic, hangul, hirigana, katakana etc etc.. and their extensions + useless wingdings.  Huge font; 52px with 128x128 packing.

--

Can't load it from internally (when DX9 mode is being used) but i can load it from a resource folder fine.    Also can't just include it internally and not use it like other files; it'll crash if i use INCBIN.   However, in GL, none of that exists.  works fine however GL will not suffice right now; too hefty for my target hardware.

--

Here's the FMF..:
https://www.dropbox.com/s/9op2dqff4u0ubqn/system.fmf?dl=0
--

Usage:

[global/local] fontvarname:tbitmap = new tbitmap

fontvarname.load("[dir]\font.fmf")

' If fontvarname.FontLoaded = True ' can be used to see if it's loaded.

' fontvarname.drawtext("string",x,y) ' is how you draw with the font.

[col]

Do you also have the code for the TBitmap type? Is that your own code or is there a module that needs to be downloaded? I'll need working ( although with the fault ) code.
If its your own code that you want to keep private then feel free to email me.

[Yellownakji]

Do you also have the code for the TBitmap type? Is that your own code or is there a module that needs to be downloaded? I'll need working ( although with the fault ) code.
If its your own code that you want to keep private then feel free to email me.

It's from the Blide.fontmachine module;  It's been ported to NG.
https://github.com/bmx-ng/blide.mod

I'll isolate the bare minimum requirements for the bug.  Yes, i'd prefer to keep my code private.  It's nothing public worthy.. most of the code is prototype-y and dirty.

I'll send it your way.
--

Also, i'm using the latest release of BLIDE as my IDE.   If that helps.

[Yellownakji]

Just wanted to add here that using 'GCsuspend()' fixes this auto-collection issue.   Setting the GC to manual didn't help but completely turning it off solved it.

Of course, not the final solution.  But this does prove that it's the GC.

[Derron]

I assume it is not the GC but the way the code is handled.

As long as something holds an reference it wont get "collected" - the bug is that it gets "unreferenced" before it should - at least this is most likely the culprit, not the GC.
Disabling the GC just allows to reference some points in the memory without having a guarantee that the memory is still containing a valid object - it is not marked to be "cleanable".

bye
Ron

[Yellownakji]

I assume it is not the GC but the way the code is handled.

As long as something holds an reference it wont get "collected" - the bug is that it gets "unreferenced" before it should - at least this is most likely the culprit, not the GC.
Disabling the GC just allows to reference some points in the memory without having a guarantee that the memory is still containing a valid object - it is not marked to be "cleanable".

bye
Ron

There's nothing special about the code though.    Everything i want to include is right at the top of the main file, neatly organized.    Then i create the Timage variables and set them when needed.

How would they be getting unreffed?

It can't be that i include them but not automatically use them because i've always done that in the past. 

[Derron]

You are including some bla.fontmachine-module right?
Let's assume there is a bug not in your code ... and a bug might also be some kind of "misconception" (assumptions about blitzmax-gc/modules/...-behaviour)

Last year or so we found a rare race condition in loops (for or while, would have to look it up) leading to locals getting GC'd too early because BlitzMax somehow assumed it got out of scope already.


bye
Ron

[Yellownakji]

The bug happens without font machine though.    This is happening on just bog standard Timages and audio.

For the record.

--

Was this 'locals' bug fixed?  Perhaps there is a similar solution?