LMAO!
extra characters cos i rly wanted to contribute this post
It’s what I’m doing as soon as this tutorial game is out (this time, weekend seems to be a realistic release date).
I’m working on the BitmapFont2 / BitmapText2 thing - and made a really powerful tool.
I also attempted to write better support for Unicode in jME (to bundle it with BitmapText2).
The problem with the Unicode thing is: Their algorithms and design is very complex - many hundred pages and some cryptic tools to prove their algorithms work when implemented. I was able to extact all Unicode properties from their character database - but that’s it. The meta data can be used, but not to its full potential (more like 30 percent, but still useful). I currently support better Unicode on my machine than even Java8 does…
The problem with the BitmapText2 thing is: A good solution needs a lot of thought, iterations, and time (I’m working since half a year on that stuff and sunk a couple hundred, if not thousand, hours in design and implementation.
So …
First me will contribute “PacificJaime” or “PacificMonkey” (let the community decide for the final name).
Then I will contribute some more TestXYZ and the BitmapText2 (maybe even some fixes to turn old BitmapText into a real text tool - if I can understand the complex code of @mulova and thus provide a fix to his/her great work.
So…
There is work being done. I hope to attract new potentials. I hope to give something - maybe even offer a job once my company started to make enough money to support one full time jMonkey coder…
You take offense very easily. That post was not directed at anyone in particular even slightly… and especially not you.
I meant what I said. We’re standing around here arguing about how some future dream code should be developed and whether it should follow this approach or that approach. It’s like trying to figure out how we want to organize the sheep pens and the grazing land before we’ve ever even seen a sheep, let alone purchased one. It’s silly.
Let the folks who will actually do the work (at this point they are mostly imaginary) decide how the work will be done and then we’ll see what we have. The only constraint is how the SDK will be released. For everything else, it would be a great travesty if even one person thought “Oh, well… I didn’t want to make a tool that that way so I didn’t do it.”
If we end up with a dozen tools all done different ways then I think we will be extremely lucky to have to deal with that problem.
1 Like
Does it work at least as well as NetBeans Platform 8.0? If so, then please submit a PR.
The SDK is still built along with the rest of the engine with every commit and the build is passing.
It’s just that there are some bugs and lack of maintainer to manage releases.
I’m trying to work on some of the issues in issue#329. And I’m not alone.
It would be good to have a tag “sdk” in issues though.
That’s a good idea. I’ve created an SDK label.
I was also interested in fixing #356. But there is no need?
https://github.com/jMonkeyEngine/jmonkeyengine/issues/356
@Ogli Regarding the “Sheep” comment: I think you misunderstood @pspeed. The “sheep” comment is the same as saying, "I think we’re arguing about how to arrange the chairs for the wedding, when all I need is knife … ". (errm…or something like that… 
Seriously though, the “sheep” comment is a fairly common idiom that means that the argument is worrying about details that are irrelevant until something else is accomplished first. Whether or not the idiom applies in this case is debatable, but, I’m sure @pspeed did not in any way intend to infer you were a sheep.
1 Like
Yes, that’s correct for the SDK’s Font creator.
If you are on Windows or can use Windows-Emulators, then BMFont.exe is the better choice for that.
it’s a free tool (now Open Source): BMFont - AngelCode.com
And the forum is here: http://www.gamedev.net/forum/49-angelcode/
I guess the Font Creator is one of the simplest bits of code to re-use so why not fix it?
1 Like
Didn’t know that this is a well-known ideom. Thanks for that info. I was not sure myself how it was meant, so that’s why I put an “if you were referring to…” at the beginning. But thanks for the hint. 
:chimpanzee_closedlaugh:
The other one is way better and has many more switches to use.
I think it would be wasted time to invest in fixing the SDK’s one.
But everyone may decide for themselves.
Maybe someone wants to fix it, in order to learn something new.
Well having one that is platform independent and can be adapted any way we want sure sounds good to me.
I have used that as well, but I just want the SDK to be user friendly for new users. So they can try out stuff before needing bigger guns.
2 Likes
So now I have time to answer, the next exam is over 2 weeks away 
Well it compiles and loads models etc, so technically it works.
Having it compile doesn’t guarantee that there are no runtime bugs obviously, which is why I will be testing it in the next few days.
One thing which is really cool about Netbeans: It’s ANT-Task made it 85% compatible with 8.1 (It automatically updated dependencies and added compatibility deps on compile time).
I’ve manually added them so this doesn’t happen each compile.
I will figure out if the code works without the compat8 modules (i.e. updating it to be 8.1 compliant, since there were mostly “moving-out/in-package” refactorizations).
The next step will be a simple 3.0 to 3.1 project wizard, however someone who can’t update his modules will spam the forums when he tries to switch from jbullet to bullet-native…^^
To the Font Guys: What would be really mind blasting is some Class, you simply throw a font and a size at and it returns a BitmapFont like this:
BitmapFont fnt = FontManager.getFont("Arial", 12, FontType.Italic);
Whereas the FontManager will create the texture and memory-buffer it. Of course that only works for System/Installed Fonts but it would be really good if you want to support 4K (and thus need a bigger size) as opposed to upscale/downscale the font a dozen times.
ATM I’m fixing the old home screen. So that will be done soon as well.
If it also supports all the stuff from BMFont.exe (like outlines rendered and channel packing) this could be the killer app to BMFont.exe. As normen already said: it also is cross-platform then. But what you suggest would be very cool to have. Currently I just intend my software to use pre-rendered fonts with the user selecting the size for Latin and CJK manually and specifying the locations to all these fonts, and then merging them, plus a ton of stuff that this textbox would be too small to write in. 
I remember @DannyJo having written something about a tool called “Hiero” from libgdx. Don’t know it yet, but maybe it is cross-platform and provides a online-API to real-time render bitmap fonts into ImageBuffer or similar. He said, it does generate distance fields, which could be used for outlines too (just write black borders to the image using the info from the distance fields). About channel packing etc. I don’t know.
It somehwat feels like being unfair to the plans of dropping the sdk though.
Well, we’ll see what the future brings.
2 Likes
Moving to the latest NetBeans isn’t really hard most of the time. You’ll have to import a few other packages per module maybe, some things that have changed or became deprecated pop up as warnings during the build (or during runtime). Then I made an ANT task that allows updating the dependency versions of all jME modules to the version in the NetBeans distro that is used - just to make sure they give the proper warnings when used in an older NetBeans or jME SDK somehow.
As the build process downloads the netbeans base by itself it doesn’t really matter in which NetBeans version you compile the SDK - as long as you use the included build targets for that at least once. Then NetBeans picks up on the correct base and it even works building it directly from the IDE.
2 Likes
Hi,
just wanted to say that I hope the SDK will live on in one form or the other!
For me having one simple installer and cross-platform goto-executable is the main advantage which puts JME ahead of all the other open source engines regarding usability and workflow.
I think it makes great sense to offer this more code-centric SDK bundled with a tailor-made IDE. In this regard it even beats Unity in my opinion.
I have no idea about the inner workings of the SDK or Netbeans, so forgive me if I’m wrong, but would it be so difficult to still offer the whole JME package (SDK + engine libraries) as a single installer package but keep development seperated? This would then allow for the more rapid engine updates to happen more frequently.
The SDK user would then get notifications when one or the other has been updated and an integrated upgrade option. (SDK message: “A new version of the core library is available, update now?”)
I think something similar is already implemented for plugins, isn’t it?
I would also try to help out with keeping the SDK alive but I haven’t really looked into the source code or building it, as it seems to be quite complicated. Maybe I’ll find the time in the near future. Would be great if there were some guides to how the SDK source is structured (from the viewpoint of a regular JME user, like the Wiki)…