I’m at the moment coding my own variant of the “StatsView” class that needed access to the guiFont of a class like SimpleApplication.
I noticed, that there is no public accessor for the guiFont variable - so you either have to create a new Font or inherit from SimpleApplication and insert a “getGuiFont” method.
Because when I would have to tell other programmers that they would have to use my derived CustomApplication class, my code won’t be reusable for them.
Also, creating a new gui font might not be working when future updates arrive - at least a public static like this should be available somewhere in the engine:
[java]public static final String guiFontName = “Interface/Fonts/Default.fnt”;[/java]
SimpleApplication is going to be deprecated at some point and replaced with something better. In that case, there probably won’t even BE a gui font built in because it’s need has long since been superseded.
There is literally no reason not to just load your own. The AssetManager is caching them anyway.
@pspeed said:
there probably won't even _BE_ a gui font built in because it's need has long since been superseded.
Oh, now you’ve made me curious. I hope that Angelfont bitmap fonts will still be supported. (And I hope LWJGL will too).
You should still think about the static-String-thing that I mentioned. I saw way too many hard coded and thus error-prone strings in the jME and test codes.
Sure, .fnt files will still be supported. That has nothing to do with eventually deprecating SimpleApplication over a better base Application class without all of the protected fields and other needless cruft SimpleApplication has accumulated.
Loading the default font is no different than loading a lighting or an unshaded material, really. You have to know that the resource is available and what it’s called. I frequently think it would be nice to have some string constants for these things but a) there is no good place to put them, and b) it’s a false safety because code would/could still break if things are moved around.
Hm, you are right. A unit test or something like that would be needed, that loads all standard assets and breaks if one isn’t found.
A good place for these constants would be found during work or pre-publish refactoring/polishing phase.
By the way, my software cursor with animated pictures is up and running, but my game is not finished yet. And I am way too late for the contest anyways. But I’m highly active and must have written thousands of code lines during past two weeks. It’s really fun to work with jME and the SDK.
Also just tested my game with loading of materials with different texture sizes: 1024x1024, 2048x2048, 4096x4096
Results are interesting: 0.08 seconds, 0.45 seconds, 1.5 seconds
I have a quite beefy machine, with SSD and three monitors (screen resolution when playing jME games: 5760 x 1080
This is soo much fun!
I’m just having the time of my life here.
