Hey folks,
A recent discussion between Mojo and myself has brought to light a bit of a question on whether the jme.jar library itself should contain any data files (eg. defaultfont.tga, the gui’s defaultlookandfeel, some kind of default image for the particle system, default images for lens flare, etc.)
Mojo’s arguement is that jME is an API and as such, he feels it should contain 0 data files. The files currently there such as defaultfont and the lookandfeel should probably be moved out to keep it a pure API. Users should provide their own such files when programming with jME.
While I respect that point of view, in my opinion, certain items within jME should have default data files included with jME. Perhaps this can be done via an additional small jar (only containing a couple default items) of some sort if not within the actual jme.jar. I believe not having a font or default images for lens flare, etc. will only add a barrior to using jME as a whole.
Anyhow, those are the views in a nutshell. I’m sure some expounding will follow.
What do you guys think?
I do feel that there should not be any data files in the jme.jar and all should be kept in jmetest.jar for demos, tests, beginners, etc. Currently the only files in jme.jar are the font files, and I’m not a huge fan of those being in there either, but currently they need to be due to the way SimpleGame and the widget library works.
I don’t think having “default” data for things is a good idea, because it becomes far to easy to have bloat. When should we have defaults, when shouldn’t we? Before too long, jme.jar is the size of jmetest.jar containing all sorts of game related data.
Lens Flare (the class the started this discussion), in my view, is a logic effect. It takes a number of quads and positions them on the screen in parrallax (that right?) with a light point. These quads then have a texture applied that defines what each flare looks like. The look of the flares is application specific and therefore should be provided by the user.
My main point is to keep the core jME API clean and as small as possible (jme.jar).
We decided to have this as a public discussion, because it got heated and Renanse threatened me with bodily harm… I SWEAR!
Hehe, yeah, I made his brain hurt. 
Actually, we don’t have to have the font in there for SimpleGame. It could be undefined in SimpleGame and each test could set it to some file in the test jar. The only thing is, this makes it (imho) harder to use SimpleGame for those beginners out there.
we’d have to include default images for all of Guurk’s new UI stuff… bloat.
I think Cep’s Starter Guide is going a long way to taking care of any hurdle a beginner will face, providing an image for lens flares and fonts will be a very small hurdle…
It’s my opinion that the jME .jar should be as small as posible. One of java’s strong suits is webstart applications, and downloading the games over the internet. It’s almost a bragging thing to be able to say “Look at this sweet game I made, and it’s less than a meg to download”. I also think it is confusing to run as a beginer and see a white bar at the bottom of the screen. It’s like “I’m just a noob I don’t know how to fix this”.
It’s my recomendation that we make jME .7 as small as posible. Put widget in its own package. Put model converting in its own package (but keep model loading in the core). Put default images in their own package. Make jME give some kind of obvious error when there is no texture image being used.
I’m of the opinion that jME should be as efficient as it can be at a base level. With correct documentation and error warnings, users should be able to figure it out. This is similar to the LWJGL reason for forcing everything as buffers instead of giving an array option. When I was a noob at java, I never found it too difficult to put another .jar in my classpath as long as I knew I had to.
I totally agree with mojo. No data files in the jME API jar because what if they wanted a different font?
Not an issue since you can easily change the font either way.
but that would mean unjarring the jar, removing the font thats already with jME to remove bloat, and jarring again.
Which is just a hassle really…
DP
So I like cep’s suggestion which (stop me if I’m wrong) would mean that we code in the name of the default resource (so say in SimpleGame our font location might say “jmedefaultsfontdefaultfont.tga”) and then we’d package a jmedefaults.jar or similar that contained the actual font. If they don’t include the defaults jar and don’t specify their own file, they get a white box. Otherwise they can include the jar and not spec their own font.
I can handle a default media jar…
Which is just a hassle really...
DP
Uh, no it wouldn't... it would mean simply adding the following to your main() before calling start():
app.fontLocation = "some/other/font.tga";
Which is doable already as well.
There just needs to be an obvious, strong error warning about “We can’t locate the default jar. You should include jmemedia.jar into your classpath”
sorry, i wasn’t reffering to the default media jar, i was refering to the current jar state.
DP
Useful, but we’ll need defaults for other items as well. Also, I think we were looking to get away from awt eventually.
Being a newbie I would vote for a jmemedia.jar containing all required default fonts, images and settings.
If I can override them in my code later on that’s fine.
But writing my own game I would expect to put jme.jar and jmemedia.jar into my classpath but why should I add jmetest.jar? I am not writing a testcase so I would never assume that I am needing jmetest.jar.
And if I ever distribute a game I would not want to have something test in my deployed stuff - that only gives some unprofessional impression IMHO.
Just my 2 Euro cent,
Tommy
I’ll throw in on the “keep jme.jar slim” pile. Having just started with jME and working through Cep’s excelent tutorial I find it is very easy to get everything set up and working. Adding another jar to the classpath or adding an extra initilization line to set up the font is no big deal, even for someone with not a lot of Java experience (ie me).