> GraphicsResource.ClearFonts(); // need to clear fonts since they keep FontLoader state, they will be reinitialized on time (#261)
I'm pretty sure separating ClearFonts out of Game.Clear was an optimization to reduce after-game load time, because loading fonts wasn't very fast for some reason. What is that "FontLoader state" that is not being kept?
C4FontLoader::Clear gets rid of the pVectorFonts, however CStdFonts created before keep a pointer on it and try to use it to render not-yet-encountered glyphs. #276 has instructions to reproduce this crash.
As for a better solution, what about splitting up C4FontLoader::Clear() into C4FontLoader::Clear() (clearing FontDefs) and C4FontLoader::ClearFonts() (clearing VectorFonts) and make Game.Clear only call FontLoader.Clear() so that the vector fonts which are still in use remain valid?
As for a better solution, what about splitting up C4FontLoader::Clear() into C4FontLoader::Clear() (clearing FontDefs) and C4FontLoader::ClearFonts() (clearing VectorFonts) and make Game.Clear only call FontLoader.Clear() so that the vector fonts which are still in use remain valid?
Yes, that sounds better.
Alternatively, any data that is not cleared by a game clear (i.e., VectorFonts) could be moved out of C4Game into C4Application. This would make the whole process a bit more straightforward, as having some members cleared and some not can be confusing (and caused the crash in the first place).
Alternatively, any data that is not cleared by a game clear (i.e., VectorFonts) could be moved out of C4Game into C4Application. This would make the whole process a bit more straightforward, as having some members cleared and some not can be confusing (and caused the crash in the first place).
This thread reminded me that I wanted to simplify the font loader code by removing the bitmap file path. So I looked into that, and made some other simplifications to the startup code as well. (I estimate about a dozen steps of cleanup are left before that part is nice and friendly...) The result is at http://bitbucket.org/guenther/openclonk/. There's now just one rather empty fontloader class, which holds a cache with one instance of the freetype data, which is used to render the fonts, and thrown away when the font changes and no font is left using it. Theoretically, it should now be safe to just never call anything Clear()-like on the fonts, but that patch'll have to wait. And I'll have to actually test changing fonts.
Will your refactoring take care of the issue Sven raised? If so I wouldn't have to do it myself :)
after this "fix", nothing works.
there is some error like
there is some error like
[11:50:14] FATALER FEHLER: Fehler bei den Schriftdefinitionen
[11:50:14] FATALER FEHLER: Programm abgebrochen.(InitSystem)
carli@carli-laptop:~/openclonk/planet$ ./clonk
[15:54:45] Using XRandR version 1.3
Warning: ForEachFile with * (/home/carli/openclonk/planet/./*.c4p)
[15:54:46] No valid key file found.
[15:54:46] Command line:
[15:54:46] ""
[15:54:46] OpenClonk Beta (Cerulean)
[15:54:46] Version: 4.10.0.0 [002] Beta linux (ddea81d4af91)
[15:54:46] Fehler bei Grafikdatei CursorMedium: Datei nicht gefunden oder ungültig.
[15:54:46] No Gamepad found
[15:54:46] Fehler bei Grafikdatei CursorMedium: Datei nicht gefunden oder ungültig.
[15:54:46] Fehler bei Grafikdatei CursorMedium: Datei nicht gefunden oder ungültig.
[15:54:46] Fehler bei Grafikdatei CursorMedium: Datei nicht gefunden oder ungültig.
[15:54:46] FATALER FEHLER: Fehler bei den Schriftdefinitionen
[15:54:46] FATALER FEHLER: Programm abgebrochen.(InitSystem)
[15:54:46] Spiel deinitialisiert.
[15:54:46] Engine heruntergefahren.
Exitcode is 02.
You are trying to run an old version of the engine, which hasn't any of the commits mentioned in this thread. Next time, please retry with a fresh engine and entertain the idea that the problem might be on your end, before claiming that others have made a grave mistake. Otherwise, it might become too frustrating to deal with you to make it worth the effort.
Doesn't matter, your engine reports itself as build from a three week old source, I'm going to assume it didn't just pull a commit id out of a hat.
Not only that, but the id of the error message carli's seeing isn't even referenced anymore in the current version.
Pulling a commit id out of a hat would actually be easier - just alter the timestamp of the header - than having a current version which produces the error message.
Pulling a commit id out of a hat would actually be easier - just alter the timestamp of the header - than having a current version which produces the error message.
[15:54:46] Version: 4.10.0.0 [002] Beta linux (ddea81d4af91)
Maybe you build to a different location? Or your build fails so the old engine is not replaced?
If in doubt, I usually delete all old engines and rebuild.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill