I proudly present a little preview of my achievments:
It started with the Blendswap Arcade contest and quickly shiftet to a “I need something…” (and later) “I want this something to be reusable … and perfect!” situation.
So I refactored more and more code into my “support library”, which is growing every day and will be open source when I’m done.
Here are two demo screens from my “font” and “hud” implementations, which make use of AngelCode bitmap font generator and jME3 BitmapText class. Also some of my own code and artwork went into this subsystem.
I could show the animated cursors and a prototype of my game - but it’s best to experience the system in action later.
The final library will be published together with the game (which makes use of many features of this library).
It would be interesting to see what kind of improvement ideas other people will have when they see the code.
So far it was great joy to see how @YongHoon did some things and StackOverflow was a good resource too.
It’s still hard, to find good fonts. Hanazono gives me around 90,000 signs - but there is no Hangul (Korean). And there are many gamers in South Korea…
I never gave up on this and recently packed hundreds hours of work in it.
So I’ve made good success on this software in the last few weeks.
And I decided to stay with jME3 in order to make my vision become real.
But what I need now, to finish this tool for bitmap fonts, are two things.
Maybe someone could help me get a first hint for the search:
I need a good example to save and load my custom .fnt2 format as a binary file.
For the human-readable text file I used .fnt files and jME BitmapFontLoader.java as a starting point for my derivative work. Now I need to write a high-performance version, i.e. binary asset loader / writer.
I need a fast image-manipulation on .png files (create them, read / write, copy rectangles from image to image, invert pixels, blur, outline). I wrote my own class using Java BufferedImage in order to get this functionality available, but I don’t know if that’s the best way to make it.
Further questions might include: How do I use jME serialization to automatically load fonts before I load complex BitmapText like structures which make use of the fonts. And more questions. Most of this is optional, but might become a desired feature by others at some point.
Thanks for reading
And fellow monkeys, you don’t need to wait another year for this open source tool to become available… :chimpanzee_amused:
jME3 already has a binary serialization system which is used to save and load model files. You can try to reuse that system and make the BitmapFont class serializable. Another option is to support the official binary format for bitmap fonts (e.g. the “Binary” export option in the BMFont tool), then you can directly export fonts in binary format and load them in jME3.
I wouldn’t recommend doing that while the application is running, but for offline usage you can use jME3 ImageRaster to access pixels in an image, or ImagePainter (a jME3 plugin) to manipulate images on a higher level.
Okay, I will try to find and use these two binary (de)serializers. Since the models are assets, there should also be code for binary asset loading along the way. Nice idea! Thank you very much.
I will compare the ImageRaster against the speed of BufferedImage, should be a lot faster I guess.
For the ImagePainter plugin: How can I write code against the latest version of plugins? My current approach would be to copy the .jar files of other code to my project, so that users can use my .jar files easily. I don’t know much about code management for Java in general and for jME plugins in particular. Is there a good tutorial for something like that?
Thanks for the help,
expect the open source git repository soon (I’m afraid people will find my code quite ugly, but also quite helpful - at least those who also use the BMFont.exe freeware from AngelCode or those who want some smiley replacer, unicode support, animated glyphs etc.).
There is one more “nice to have” feature for which I need support:
I need a text file with the names of all the currently available forum smilies.
I need a zipped folder with image files of all currently available forum smilies.
The format of the text file would be:
[1st line:]
[2nd line:]/images/emoji/twitter/smile.png
[3rd line:]
[4th line:]/images/emoji/twitter/smiley.png
[…]
[2N-1 line:]Nth smiley code
[2N line:]Nth smiley path
Would someone of the forum admin related people be so kind to prepare such a list for this project?
I could grab this info all by hand, but that would mean a lot of manual work for me…
Further, if one had such a format, automatic rebuild after changes becomes possible.
Man, do I hate working on that library! I would rather like to continue my monkey-game.
But I’m fighting till the end - if there is such thing as an end (even when code is finished I still have to write the docs as .pdf file, then users might have questions and I will need to give the very least support possible…)
Also, making it ready for extendability (users can write their own implementations, send their own Factories in, extend my classes as subclasses, etc.) cost a lot of time (factor of 10x time) and bloat code (factor of 3x code).
Well … at least I learned a lot !!! (by doing and by reading Bloch and Stackoverflow :chimpanzee_grin: )
Don’t wait too much to publish it. You may be surprised on what others ppls will have doubt or make request. Maybe they will never extend on component that is ready for, but will ask to overload a private function. Or they may ask something that isn’t that clear on docs and what is very explained they will never read…
I think both libs can coexist for different purposes, I am even trying to use the TTF one in a non standard, non expected way :).
Just set a milestone goals list, do not embrace all the world (all possibilities) at once :).
Release something usable as “version 1” (it may even receive contributions and tips/code review).
So basically it seems you have an older version that is usable what would be cool already, may be we just should avoid extending it as you may probably change it a lot. At my console commands project, I change it SO MUCH, it got so completely differently structured and named classes… hehe… just tell ppl not to extend it, but use it “as expected”
Later on, If your lib requires too much redesign to accommodate all the extras you would like, release the new changes as “version 2” therefore incompatible with “version 1”, so end users would required to adapt their code when upgrading.
…
I would rather like to continue my monkey-game.