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)…
It’s not so complicated. I have started to look into SDK code like one week ago from exactly same reason than you are thinking of doing it and my first PR was merged into master yesterday. Previously I haven’t worked in netbeans. Start with small details that aren’t hard to fix and eventually you’ll be able to contribute something bigger if you keep going 
You can get details on building the sdk here: [SOLVED] Need help with JME SDK building - #15 by Vortex
Hope this helps.
1 Like
The SDK can surely be distributed separately with compatible core engine libraries (if somebody cares for the distribution). The issue is that core engine changes might break how the SDK works so not all core updates can be pushed to the SDK. In general that was how the whole setup was designed, with the SDK plugin system being used to push only engine changes / SDK changes / single plugin changes. Which was also what happened during the 3.0 alpha/beta time and the lifetime of the 3.0 SDK with nightly updates up until it became incompatible to the newer 3.1 builds of the engine and SDK at which point only stable updates to the 3.0 SDK were delivered. The build targets etc. are all there.
In the case of core engine libraries breaking the SDK, wouldn’t it make sense to have some kind of modular tool structure (like SDK functions/tools as plugins) and then require an update of the broken tool to have it work with the new libraries again?
The functionality of the single broken tools could then be recovered again by smaller updates. That way no development would have to wait for the other. Of course updates that potentially break certain tools have to communicate that to the user before installation.
I mean like for the user he would still be able to work in the SDK (I guess that large parts like the code editor or the file system will never be touched by core engine changes) while having up-to-date libraries to code against.
I think that having the comfort of getting an update notification with an instant install option right in the SDK is a big bonus.
I don’t know since when you’re using jME but this “instant install update” was exactly what was happening as I just said. The single parts of the SDK functionality (e.g. Material Editor, Scene Composer etc.) are modular in nature. This whole thread is about maintaining that and it was decided it won’t be maintained anymore… You’re kind of talking past the point.
Ok, nevermind then, thanks for the insight. It was kind of hard to follow this long winded discussion.
I just hope there will still be such an easy entry point to JME as when I first discovered it.
I mean there are tons of open source game engines out there where you have to install an IDE, the libraries, dozens of dependencies, asset tools, etc. before you can get productive. I hope that JME will still be relevant among those without a single stand-alone SDK.
So… I say that then update only the engine. If sdk gets broken and bug reported we (the community) will fix it…
…eventually 
2 Likes
Hello guys, I am at the position of a complete beginner. I know how to code in Java and a couple of other languages, but I’ve never done something game/3rd dimension stuff before.
-
Will there be tutorials on the wiki?
I need something that shows me at least the basics. I don’t know which key topics are important for game developing, because I did not come from another project and just have to learn to migrate; I have to learn everything from the base. -
What do you recommend to me? To switch the engine to learn the basics and have a stable knowlege to overcome all the upcoming obstacles? But how? Unity is script based, Unreal Engine uses C++ or is also script based. Is it a better idea to take a look on libgdx?
As I said, I’m completely lost without any guide. But I want to find a way through, at least there is a will
Thanks. There are tutorials that teach me how to use jMonkey without the SDK? Then I’m going to to dig there and see what I find. See you later ^^
Yes, it’s basically lines of code - which work both with SDK or without SDK.
Be warned though, many links are broken: Those links to google code (there are some) - because jME is now on github and the old code is “archieved” by google code (whatever that means).
EDIT: jME 3.0 SDK still works and is (as I see it) the best way to start learning jME.
Google discontinued google code… that’s what that means. All google code projects everywhere that ever existed are now ‘archived’. You can download a zip of them but that’s it.
For better or worse, the deed has been done:
In all honesty though, I do think this is a Good Thing. It won’t be without its rough patches, but I’m sure it’ll be worth it before long.
I m just wondering, will the SDK auto update with the new library? Or do i need to download them and replace?
Unfortunately, no. SDK updates are part of the SDK and therefore also won’t be provided.
Just keep the 3.0 SDK in the download section, then everything will be fine for me and my students… :chimpanzee_closedlaugh: