Ardor3d test migration in progress

I'm in heavy evaluation process, taking closer look at the two alternative 3D engines for migration. Currently in a long process to convert the existing sources to use Ardor3D, to let me test how the new engine performs. Stability is the most important factor. Most of the codes in my experimental workspace are converted to Ardor3D. I could take a screenshot of the main menu. I still need to find a way to refactor the Input, the Terrain and the Audio system of jcrpg to let it work with Ardor3D's architecture. Hopefully the most beneficial will be the Terrain part, as there's a nice shader based terrain that streams data, and can produce 'megatexture' to cover the terrain. This will take a lot of time, I can foresee. But hopefully will lead to a better 3D architecture, speed and look.

If things settle down I'm planning to move to a different SVN repo, possibly googlecode. I'm a bit frustrated with SF.net SVN speed at times. Now will be the time to do so, as I'm restructuring the project while doing the migration stuff, moving the media to an upper directory, to let developers checkout less data. Also jcrpg will now build with Maven.

New Voicepacks contributed! Twitter for jcrpg. Migration to JME3 under consideration.

Hello again! Things are slowly-slowly creeping to a spinning up here, hopefully now that I'm less inclined towards actual gaming - finishing Witcher I'll get back to business, developing the game. Right now I'm starting to consider migration from jme2 to 3d-engine jME version 3 created by lead dev MomokoFan @ jme forum. I'm looking at the project and how complete and stable it is right now before deciding to migrate or not.

But other kind folks too are relentlessly keeping things going on. For now latest great additions are two male voicepacks created by Rigardi from Austria and MaximB from Israel (author of Linux Gaming News). Both packs are of great quality, Rigardi's pack is one for a sane and fair person, while MaximB created a 'Drunken Dwarf' pack. Now we have 3 voicepacks with the previously announced female pack by Bunches that will be integrated to the game soon. Thanks, guys! :)

For your information I've opened a microblog at twitter that will be the quickest way to follow jcrpg dev progress on my side. Follow me here: http://twitter.com/illespal. It may also feature tweets about other linux related things too, so don't be surprised if you get something like: "hey, new catalyst out, more things broken" or "woohoo, new kernel is faster than anything". ;)

jME and lwjgl updates in SVN

I'm currently catching up with what has been going on in the jMonkeyEngine development. It's still a rather active community there, I'm glad to see - patches are incorporated in the jme svn, dependent libraries updated. So I took the time and updated jcrpg's dependencies.

Next thing I must have a look at before the planning is to debug a recent in game text related bugreport - fonts are getting totally unreadable with some GPUs under Windows. Have any of you experienced the same thing (messed up fonts in-game) with latest release - if so what GPU/OS do you have?

PS: Just attached the bug's screenshot. Anyone else with it?

Migrating jME version from 1.0 to 2.0

A long pending aspiration of mine has come to fulfillment! JClassicRPG's full sourcecode and dependency have been converted / changed to JMonkeyEngine 2.0 by me. :) JME 2.0 is called alpha but it is as stable as it should be by the overall experiment of the community. It also uses the new major version of lwjgl (2.0), which is also containing major improvements.

The conversion is mostly about using Enumerations instead of static int constants, removing multiplicity of the buffers of TriMeshes, removing the now non-existent TriangleBatch class usage, convert AlphaState to BlendState, use some new classes like Texture2D instead of the now abstract Texture class.

It wasn't too hard to migrate because in the end it turned out to be not such a hard thing to migrate the opensource md5reader2 library as well. It's a separate library which jcrpg depends on created by other nice jme people at jme forums, but who seems to be a bit away, so me had to do the conversion of it. You can grab the modified jme 2.0 version of it at the forums here.

You can get the whole new jcrpg with jme 2.0 compatible source code from SVN.

Depth Of Field, extensive VBO, partially ShadowMap

After previously getting some good advice from MrCoder @ jme, now I've discussed a few things with Momoko_Fan @ radakan.org plus again with some hints from MrCoder - two major things could be achieved in one day - meanwhile a third is on the way to perfection. First it's depth of field effect. I love it definitely, far away things get blurred - and it's really nice that the shader used is a merge of bloom + DoF effect - two things at once! :) Now at last it pushed me to add a better handling of UI in a separate RenderPass so that bloom/shadow and other effects won't conflict with each other so much.

Also previously I've tried to use VBO but I remember having problems with it, some crashes or so, but now again by the advice of Momoko_Fan I revisited it and it seems things have become cleaner in jClassicRPG because now VBO seems to work pretty well... meaning a boost of FPS again! The situation is that it has come really at the good time 'cause I removed a 'cut off of rendered parts behind you' optimization to be able to reenable mouse-look.

So yeah, mouse look is also enabled now.

Meanwhile a new user contribution to jme is being done, so as a test I've integrated it - the ShadowMap render pass created by kevglass @ jme! It's working quite good although it has some smaller problems yet - probably they can be solved soon.

Good! :D All in SVN.

It can't get any smoother :)

With a mindslicing TerrainBlock tricky extension the tiles are now using the normals as if it were a big normal TerrainBlock, not several ones - one per ground tile exactly.

In our cube based architecture the tiles have to be generated one by one, so normals were missing from the ground tiles because the separated TerrainBlock meshes cannot calculate with the vertex positions of the neighbouring tiles. Now the trick is - use the full RenderedArea's cube elements to get neighbor opposite/adjacent Cube's already present height data, create a one size bigger (9 points 3x3) heightmap and build vertices/normals from that heightmap for the original 4 cornered (2x2) heightmap's normal buffer. Uh, crazy to write down, but it's working. The shot shows how gooood. :) And it's not slow either luckily! :)

Animation goes live

Check SVN for the latest sources if you want to run the game with walking gorillas. :-) It was not an easy turn to make it work all together.

First Sirgazil@freegamer was so kind that he made a walking animation sequence to his gorilla model. Next I was trying to make it into jME scenario with the help of BlenderCollada exporter. But it turned out that the export is not so good to make it easily work with jME's collada loader, plus the development of the exporter is halted as far as I know. Then frustrated I visited jME forum and finally found the good way to go: the project md5reader2 for jME (after some changes in the animation reader's code and recompile) was almost perfectly working - except smooth normals were not displaying in the game. I had to re-UV map the gorilla model with a different wrapping and try again - yeah, it's working now! It seems that later animated models for the game that will be created in Blender should be wrapped for example with Smart UV mapping method (or some similar) to be sure that it will work well with jME.

Working on optimization

With help of one superb jme programmer I've added a new JME element to jcrpg which still needs some fine tuning. It's GeometryBatch, grouping the ground tile objects into one object of big batch. This boosts performance a bit, around 5-20% depending on several factors. I've got some problem with the lens flare and this new thing though which I've have to review for that reason.

P.S.: It is mostly done, the optimization and the lens flare now works correctly together. Check out SVN!

P.S.2: After the success of yesterday I managed to add batching to other parts as well. Simple wall tiles are now grouped together into batch, adding a performance bonus of 5%+. After that it occurred to me, that the best 3D part to add batching to is grass. So I rewrote VegetationSetup class to use GeometryBatch. It meant greater success, 2x/4x more grass (yet not animated and only single texture, no flowers yet) and good performance!

Optimization for the Caves

jcrpg received simple but huge optimization with lessening the view distance of outside objects when inside the cave, and the opposite also, when moving outside in the nature, the models inside the cave are rendered with a much lower view distance (all this is done in J3DCore.renderToViewport, each cube is checked for internalLight boolean property against the current player positions' inside or outside flag) . This boosts the performance much. It will be usable everywhere, where internal parts are covered with external parts, so it doesn't matter if they are not rendered. So exactly the Caves are most excellent for such optimizations, as the mountain covers it totally. Later internal parts of big buildings can be covered by outside walls, and using this technique FPS eater internals will be cut out from scene.

Meanwhile the cave code received much perfection and bug fixing, it is nearing completion in its first form. I've found a culling problem when externalRootNode's children are in very low number (when player is inside the cave), the whole internal scene was culled for no apparent reason. May be a JME bug, or what the heck! Anyway the solution is that when moving to internal parts from outside or back the order of internal root node and external root node are exchanged in its parent's child list (parent is the so called groundRootNode), and thus the problem goes away...maybe this is indicating a JMonkeyEngine bug or something I don't know about culling and node order?

I will think about some other geography improvements, maybe clean up things, adding comments to codes before moving on to wildlife. Before that you can expect a new prealpha release.

JMonkeyEngine upgraded and more caving

JME inside jcrpg has been upgraded to the new 1.0rc1 version. Seems to work well, and I like the idea of its new and easy texture and resource locator plus the java.util.logging system update in it. Also JME 1.0rc1 uses the new version 1.1.2 of lwjgl. Meanwhile I've been working on separating internal parts (like caves) from external parts (nature): internal and external parts now use different lightstates allowing internal cubes to be independent of outside lighting (Sun/Moon). You now carry your torch (point or spotlight) in the cave... later it will be optional, depending on your having a torch or other light source...so you will have a hard time without one such thing. :)

P.S.: In SVN version you can use bloom effect now on older cards without FBO support thanks to the cool JME update. Also I've found that the rootnode was put into a default passmanager without really needing that. I removed this step, and now performance with bloom and shadows are much better!
P.S.2: Another new feat: multilevel cave! Some fixes plus that in SVN, expect slow framerate with the multilevel dungeon...