Change log for next version

Short change log for next version (coming soon…)


  • Data driven materials with dynamically linked shaders

  • Content Management System that allows loading and locating of content/game data.

  • Input System that supports Keyboard, Mouse and Joystick under one easy API. Much easier and less convoluted than the original jME input system.

  • Full support for DDS and HDR textures

  • Basic render Queue added with front-to-back sorting

  • Linux and Windows 64 bit support using (unreleased) LWJGL2.2

  • Half float data is supported for both textures and vertex buffers, reducing bandwidth needed to upload HDR images and small meshes.

  • Minor consistency changes and bug fixes

i really really liked the last version of this that you put out…

any chance of a road map or a desired feature list/wish list?

plus is this going to be a community effort or an individual project…

ncomp said:

i really really liked the last version of this that you put out...
any chance of a road map or a desired feature list/wish list?
plus is this going to be a community effort or an individual project...

The road map is quite simple, get it to become a next-gen game engine ASAP. That doesn't just mean advanced graphics, but also in terms of functionality, like ease of use and features that are suited toward games.
Momoko_Fan said:
get it to become a next-gen game engine ASAP


That's a great goal! However, without a good definition of what a "next-gen game engine" actually is, it's kind-of hard to know what is left to do. Do you know of a good definition of what a "next-gen game engine" is, and thus what your goal is?
Momoko_Fan said:

Input System that supports Keyboard, Mouse and Joystick under one easy API. Much easier and less convoluted than the original jME input system

I hope it won't complicate the task of integrating bug fixes of the AWT input system.
gouessej said:

Momoko_Fan said:

Input System that supports Keyboard, Mouse and Joystick under one easy API. Much easier and less convoluted than the original jME input system

I hope it won't complicate the task of integrating bug fixes of the AWT input system.


Why would we still be using the awt input system?  The new lwjgl Display.setParent() gets rid of the need for this system, since you can then use the faster lwjgl input system.  I'll have to double check, I may be wrong. :?  I love what you guys are doing with this project though!
SomethingNew said:

gouessej said:

Momoko_Fan said:

Input System that supports Keyboard, Mouse and Joystick under one easy API. Much easier and less convoluted than the original jME input system

I hope it won't complicate the task of integrating bug fixes of the AWT input system.


Why would we still be using the awt input system?  The new lwjgl Display.setParent() gets rid of the need for this system, since you can then use the faster lwjgl input system.  I'll have to double check, I may be wrong. :?  I love what you guys are doing with this project though!


Probably for Jogl use.
Momoko_Fan said:

Short change log for next version (coming soon..)

  • Data driven materials with dynamically linked shaders

  • Content Management System that allows loading and locating of content/game data.

  • Input System that supports Keyboard, Mouse and Joystick under one easy API. Much easier and less convoluted than the original jME input system.

  • Full support for DDS and HDR textures

  • Basic render Queue added with front-to-back sorting

  • Linux and Windows 64 bit support using (unreleased) LWJGL2.2

  • Half float data is supported for both textures and vertex buffers, reducing bandwidth needed to upload HDR images and small meshes.

  • Minor consistency changes and bug fixes



Awesome. I like to try this and learn from it after finishing my project.
Praise for your devotional work.  :)

The input system is rather tailored at the moment to be compatible with LWJGLs, but that's because of some of it's quirks in behavior. I don't think it would be difficult to support AWT InputListeners with this system, as long as enough testing is done to make sure it actually works.


jwatte said:

That's a great goal! However, without a good definition of what a "next-gen game engine" actually is, it's kind-of hard to know what is left to do. Do you know of a good definition of what a "next-gen game engine" is, and thus what your goal is?

Well, just take a look at a next-gen engine and you'll see what I am talking about:
http://www.unrealtechnology.com/features.php?ref=technology-overview
http://en.wikipedia.org/wiki/Id_Tech_4
http://www.terathon.com/c4engine/features.php
SomethingNew said:

I love what you guys are doing with this project though!

There's only one guy working on this right now, me.  :)
More people may join, if they have the skills..
renanse said:

Probably for Jogl use.

Yes you're right. I need the AWT input system.

Momoko_Fan said:

The input system is rather tailored at the moment to be compatible with LWJGLs, but that's because of some of it's quirks in behavior. I don't think it would be difficult to support AWT InputListeners with this system, as long as enough testing is done to make sure it actually works.

The problem is that I have had to pay someone to help me to provide some big fixes for the AWT input system and I would like not to have to do it twice. JMonkeyEngine's creators say it supports JOGL, we need then the AWT input system to avoid relying on LWJGL and I wish that JME really supports JOGL. It means that if the bugs that are going to be fixed in the AWT input system in JME 2.0 reappears in JME 3.0, it will not be acceptable on my view, it will not be acceptable as a release candidate as it will be a regression.

I point out this possible problem in the long term but you have to know that I appreciate your deep investment in the development of JMonkeyEngine, we need (more) people like you, people who really believe in this project.