Friday, 26 March 2010

Ardor3D: Smaller things, little tweaks, maps

Got some progress again, little things standing in the way of porting were eliminated. DDS images reintstantiated this time not flipped (ardor3d's DDS loading has been recently rewritten from scratch, and it works like a charm, image flipping is now correct too). Save/Load game lacked the screencapture functionality, now that is solved as well, this time at last saving smaller sized images so save games won't take too much space.

One major thing that was successfully ported is the World map window and the Local map HUD element. Those needed realt time texture generation, and that part was nicely restructured in Ardor3D. Following their UpdateTextureExample (which demonstrates the technique how the Renderer can render directly to texture's byte buffer, partially or fully redrawing parts without reallocation), I could finally add that element to the array of ported things.

Tuesday, 23 March 2010

UI is ardorized

Most of the UI and input has been successfully ported to work with Ardor3D. I'm happy to get use of the BMFont feature of a3d, which made it quite easy to turn the used TTF fontset into the non-monospace bitmap based font A3D can use. I had to use this program from AngelCode, which is windows only, but luckily it's only needed once for one font set. Porting the UI spatial picking and connecting in UIMouseAction into the trigger based mechanism of Ardor3D and connecting keyboard event into the InputBase event handling made the whole UI usabel with mouse and keyboard again. Core class of the triggers and player's camera movement is now JClassicRPGClassicControl.

Next major tasks are animated models' loading and particle systems (magical light effects and such). -- side note, still couldn't crash the engine in the native part (driver or lwjgl)

Wednesday, 17 March 2010

Shadows, walking around, great stability

Quick report from the field: ParallelSplit shadowmap pass of Ardor3d is unleashed along with the bloom. Most of the static content loading is working plus now a basic walk input handler with keyboard and mouse is functional. That way I could test dynamic loading/unloading of the world. Fixing some issues now it's working just like it was with the jme2 engine. A lot of things to do yet before the migration is considered complete... Great thing is, still no native part crash! :)

Friday, 12 March 2010

Static parts are starting to look quite right!

I'm still messing with the new possibilities Ardor3D terrain system adds to the pool, meanwhile I've finally ported my special micro heightmap based tile to terrain batching system to Ardor3D. It was a bit of a work, but now that I've taken care of a heap of other smaller things in the code, static parts are starting to look like they should. :) With further help from Josh and Rikard @ ardor3d I could integrate new things and resolve bounding volume issues. Now culling is working perfectly, and thus FPS rocketed to around those values I was used to under jME2, or even higher. Also I'm experiencing very good stability, so far no native part crashes neither on my Intel GPU nor the ATi GPU notebook. The memory it needs to load the initial state isn't bigger than it was with jme2, maybe even less.

After porting the old tile to terrain system I had for jme2, i'm starting to think about combining the GeometryClipmapTerrain of ardor3d with my terrain system, that way I can prevent my head from a series of aches related to object placament and such... Well, you can check the screenshot of the current state of the art - in the background you can spot how the new clipmap terrain fits (not too nicely yet) with the old detailed terrain in the foreground.


If I can manage to combine these too, we'll have the best of both worlds, new and old: almost infinite view distance for the terrain (at least the mountains and plains even if not the trees and buildings) plus the detailed view of the surroundings. The FPS / memory hit is not high/minimal with the ClipmapTerrain so far, so it's worthy to try.

Wednesday, 10 March 2010

Further converting to Ardor3D

Nice progress is going on here with converting the project to Ardor3D engine. I've ported Obj loader of JME2 to Ardor3D. With a lot of help from Joshua (lead dev of Ardor3D) finally I could repair the remaining problems with the migrated Geometry batching too. That two made the static object rendering mostly complete. Also the partially billboarded trees are working now. After that I managed to integrate the GeometryClipmapTerrain of Ardor3D to replace the current awkwardish method how terrain was created in jcrpg's jme2 version. Still it's very basic integration: needs a lot of tweak like texture generation, dynamic loading and even alpha holes. I've created an extreme view distance screenshot for you, but it's really not for normal use, ate a lot of memory and gave low FPS - there's need for Level Of Detail based on distance for the trees and such to make it usable later. Anyway, check the screenshots (one with very high distance, one with normal. :)

Sunday, 7 March 2010

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.

Tuesday, 2 March 2010

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". ;)

Twitter