awesome!!!
and ill port a new version of md5importer to the 2.0alpha.
Nice!
I noticed the RenControlEditor utility… Could be useful!
TestJMEDesktop seemed to act strangely though, my mouse was wandering around slowly in a small centimetre in the bottom left of the screen.
renanse said:
Update and try again if you were having issues. I had nio buffer tracking enabled by default for BaseSimpleGame derivatives.
Thanks! That fixed it!
jiminy said:
TestJMEDesktop seemed to act strangely though, my mouse was wandering around slowly in a small centimetre in the bottom left of the screen.
Thanks for reporting that. It's fixed now in SVN.
This is great news! I'm really happy to see that you're keeping your development very transparent, as I believe this is crucial for spotting and ironing out problems at very early stages. When
phpBB3 was in development for instance, they waited a very long time until they published anything for the public to test, even if it wouldn't have been completely stable. They ended up with 8 release candidates I think, which in my opinion reflects poor development flow.
Any takers for that one yet? :) I'm not by any means volunteering; just curious.
- Simple Bone and animation blending support. (Mostly this was checked in to keep us from having to maintain two versions of jME at work, I'd love to see the whole Bone and Skinning upgraded by a clever user or dev... hint hint.)
I vote to start another contest!
Bug Hunter 2.0
nymon said:Might wanna wait until a beta for that? :)
I vote to start another contest!
Bug Hunter 2.0
sweeeeeeeeeeeeet!
one day I'll have the time to get back to jme }:-@…
I can dream 
Dude…Sadr…make that banner a little smaller man…you take up half my screen with it. :-p
Will code exported with the BinaryExporter from version one be compatible with version 2 ??
No, in almost all cases it will not be backwards compatible. That's part of the reason for moving to a 2.0 designation.
darkfrog said:Ooh, sorry, hehe. I thought maybe the forum would resize if to the minimum size, but I guess that's only an SMF 2.0 feature. It should be fixed when you read this :)
Dude...Sadr....make that banner a little smaller man....you take up half my screen with it. :-p
Thanks. 
renanse said:
No, in almost all cases it will not be backwards compatible. That's part of the reason for moving to a 2.0 designation.
This is why you may consider to change the binary import export in the future to make it version proof. Its not a biggy for me as I only use it from RenderParticleEditor settings, but maybe the way you have implemented RenderControlEditor along with the code generation via properties is the way to go for tools.
theprism said:
but maybe the way you have implemented RenderControlEditor along with the code generation via properties is the way to go for tools.
why not both?
the original particle editor generated code. wouldn't mind seeing that tab come back
the binary format shouldnt really be used as storage for a game (especially not during development), but rather as an optimized final format to ship the game with. this is yet another reason we need to create an XML version of the binary capsule import/export process, which doesnt break due to code changes.
MrCoder said:
the binary format shouldnt really be used as storage for a game (especially not during development), but rather as an optimized final format to ship the game with. this is yet another reason we need to create an XML version of the binary capsule import/export process, which doesnt break due to code changes.
Think even for a final format it could cause issues if the game were to be further developed after release. XML is fine as a solution as long as it has a version tag and it can be supported across JME releases, otherwise its just the same.
I think the biggest plus for a text format is the ability to dif across versions in your source control.
renanse said:
I think the biggest plus for a text format is the ability to dif across versions in your source control.
Possibly similar pro for code generation, understanding it at compile time rather than runtime - seperation of data to runtime
MrCoder said:
this is yet another reason we need to create an XML version of the binary capsule import/export process, which doesnt break due to code changes.
Yes, because XML also opens up a direct path to jME for writing exports from other programs (as hevee did with his capsule based XML format and blender exporter).