Nearing the end of the year I added a bonus video for showing the new things in the last few releases. Enabling grass, far view and bloom ate up much more performance resulting an FPS of 14 in the captured video.
This post is a regularly updated list of independent permanent web contents linking to jcrpg official sites:
To all jcrpg readers around here I wish a merry Christmas. Hope you'll have the possibility for a great time. I will pause the development and put it to rest for some days now. I advise you to do the same with your everyday tasks. Create and enjoy this little rest in between the storms of war of existence. ;-)
Headlines:
"Base geographies (Mountain, Plain, Forest) were refactored to point height calculated tile generation. Cave and River were rewritten to be compatible with the modified base geographies. Farview mode was refactored and beautified based on new geographies. New configuration parameter called RENDER_DISTANCE_FARVIEW was added. World generation was extended with rivers and caves. The demo game is now running in the generated world." Download, test and report!
The Cave and River has been modified to work together with all the new stuff in Geography. They fit together now well.
While I was tinkering with the new height based tile calculation method it occurred to me that with this new code at last I can make the far view mode work much better than before! The cube kind of a given height is calculated based on the neighboring cubes' height relative to the current cube's height. The method calculates if a slope or a ground or some other kind of cube is needed. Slope if the cube is at a lower height than neighbors, normal ground if in equal height, etc. And here comes the trick! In farview parts only every 4th cube is rendered and the scale of it is multiplied by 4. Before using this method farview rendering resulted in ugly gaps between ground and lower positioned ground parts unconnected with a slope. BUT with height based cube kind calculation we can have gapless view if the neighbors in far view are determined to be 4th cube in the 8 used directions for cube kind calculation instead of the next cubes around. Thus big sized slopes will be always put between two different levels of ground. Finally farview is usable and much nicer than anytime before! :-) Okay, not the nicest I've ever seen, but gives some base potential to later sophistication.
If you are testing JCRPG and it runs slow there are a few things you can check to improve performance.
Firstly there's config.properties in the root directory of the game that can be modified with a text editor. Things to care about in ascending order of impact on game aesthetics:
Yeah, perfection is a must. We got close to it: smithing on the ground component models and hours and hours of experimenting with the optimal height point geography generation plus the refactoring of all the classic geographies like Plain, Mountain, Forest resulted in a much varied environment full of slopes and levels to explore! :) Thus we are now in the second round: to beat the river and cave into its place...gee, hard work ahead! Maybe meaning another big refactoring to come... Shots depict now a bit of the varied climate with a small mountain part plus the new "next gen ground code" plains and forests. ;-)
I will reconsider some boosting of the whole geography with Height Point tile generation (where possible). That's because I could write a code that pretty easily handles the steeps and such. Check the shot. There's an easy way to add valleys too now so I'm thinking about using the valley thing or adding Height Point tiling to the Plain and such. But I'm leaning towards adding Valley and leaving plain as it is - and add a generic function to the Place root class that gives the height and such things if a Geography will need data outside its boundary (to fit the tiles together at the edge).
While trying to get work the mountains with different size and height in connection with the World Generator I decided to rewrite it fully from the basics...the square pyramid like look is not really usable in bigger size. Now it will be a point height based thing with some kind of mathematical function that tells Y in a point of (X,Z). The previous code was messy and too firm to be developed...the new one is planned to be better ... yet the classic look and standard, something like the shot shows with some more variation. :-)
Yeah, a big refactoring, hacking and bug hunting in the Cube/World section plus the Mountain and Cave code resulted in world sized Mountain and Cave geography addressable and usable in blocks. This means a mountain is shaped where its parent Mountain geography is having an area occupied in its WorldSizedBitBoundaries. It's usable, faster and convenient for world generation! One little thing is the AI cannot tell them apart only if I will add some later enhancement for the base Geography class that will make it able to tell some of its bigger areas apart. Understood? No problem, check the shot for the visual result. :-)
I had to go and fix, change and test some codes while moving on with the world generation code. Internal flora was colored by outside lights and the flora overwrote some cave limiter rocks making the outside hill badly visible from inside the cave! :-) You can experience this in the previous release I think. But before that a bit based boundary was implemented which stores the areas that the Geography may occupy. The previous version which stored the boundary coordinates in a hashset filled with Integer coordinates was slow and memory eater. Bit based I could create several layers of World sized Geographies of forest/plain in a world size of 10 thousands * 10 thousands Cubes with a 10x10 Cubes sized area granulation which means 1000x1000x100 bits sized data stored in the so-called WorldSizedBitBoundaries' byte array. Then I created a frame for the big map window to make it nicer. All is inside SVN!
World Generator step onto its next level with the working Climate addition. A preliminary version of UI menu windows is also committed into SVN. If you press F1 you get a pop-up window showing the World Map in big with a red dot showing your position. Pressing it again makes the window go away. The map is colored according to the climate belt colors. Shot shows the Window and the generator added Tropical belt. :)
I was busy coding to boost up the Ocean coastal code part. It's ready now and more or less working like it should. Fixed many things in its logic experimenting with it a lot. It caused quite a headache! :-D After that WorldMap was the next target to add a step by step updated red mark of current location onto it. Now I'll head to further develop the WorldGeneration geography addition part plus the Climate belt addition. Geography addition will be based on big zone hashing and similar quick tricks. :-)
A long time passed since the last release and looking at the changes in the last few weeks I decided to pack and push out one new - though the World Generator is in a rather primitive stage of development. The release is out, world generation is done when you start jcrpg yet you will enter the old one already known and put together previously by me without the new generator. Headlights: "UI base elements were added: load icon, compass, time meter, world map, HUD panel. Internal Flora is now configurable through FloraGenerators. Example internal flora in the Cave. Initial version of the World Generator is added. The World Map UI element shows a world generated by it. Updated JME libraries from CVS." Download it here! Hope to see you around commenting here or the forum. (This time it's gzipped for easier handling.) The screen shots depict the new compass/time block and loading icon plus the map. (The small yellow dot [Sun] shows the passing of local time where you stand, it is going around the compass.)
I'm working for a short time on the first steps into the User Interface to give some idea for you and for me what will be this all about. Integrated the map into one corner of my first attempt in GIMP to create some nice transparency boosted gfx for the main first person screen.
Just wanted to show you the first ugly vision of the thing called WorldMap view. :) It just shows the big ocean block and big land mass block variety.
:-) My expectation is met by the recently appearing problems. Generating the World from scratch shown that there were are and will be (hopefully less) bugs in the system. The World is a globe by default, so if the planet is a big landmass then you can walk all around. Thus I found that the player coordinates' setting lacked much in pair with displaying the World correctly.
There's now a limit introduced: the world minimum size (which is the maximum 3D view distance of the player at the same time) to avoid the possibility to see things twice from the same point of view! :-D It shouldn't be a problem in an absurd reality but it also makes displaying much harder and erroneous. I don't want to handle this silly double view problem, so I remove the possibility. The World constructor will throw an exception when going below the minimum size limit (currently the World must be at least 100 cubes in one direction).
The first tests were done with going all around the globe, returning to the start point. It seems to work correctly! Check the endless p*l*ain shot... ;-D
P.S.: The new Ocean geography is rounding up in SVN. Looks pretty weird though, but cool landmass is being born out of it. :) I should create some kind of world map view soon...uh, big work ahead again...
Geographies are mostly ready for the first iteration. I think it will be good to create the random World Generator for them as a test and as a source of fun. You will be able to parameterize the world with size/landmass/random seed, and the generator should create a walkable and coherent place. Now the Generator is in the works... It will be a must for the things to come...we'll need random geographies/worlds to test the wildlife and such thoroughly, so this is the ideal time to program the generator as the geos are there ready to put them into the world. :-)
Caving through the multilevel Surface implementation I found that the Climate part needed urgently a separation of Internal and Outdoor Flora generation. This is now done, ClimateBelt newly defines a BaseConditionsInternal and External to add a taste of weather based on the openness of the are you are in. Also FloraGenerator has been modified to store FloraListElement[] based on a key of not just the climate belt and level but inside/outside flag of the Cube too. Screen shot tells it weirdly currently! ;-) Example code:
public BaseFloraGenerator()
{
addFlora(Continental.CONTINENTAL_ID,ClimateLevel.CLIMATELEVEL_ID,
OUTDOOR,new FloraListElement[]{new FloraListElement(new Grass()),new FloraListElement(new OakTree(),20), new FloraListElement(new CherryTree(),50),new FloraListElement(new GreenPineTree(),50),new FloraListElement(new Acacia(),100),new FloraListElement(new GreenBush(),120)});
...
I've found the cause of the JME problem with the help of renanse at JME and removed it from jcrpg, so now the source in the SVN theoretically runs fine with the new JME 1.0 + CVS updates (well, of course the jars are already included in jcrpg SVN too). Great. :-) (This should mean e.g. improvement for shader errors on gf5xxx series.)
Another great thing is how the freegamer community (where jcrpg found its place for its coordination forum) is evolving day by day: now a free art search engine is up and running and jcrpg's free open source media content is also cataloged there.
Working on finalizing the first round of the Geography development I've added multiple level support into Surface interface, so that one Cave geography may include several levels (although Cave is not that complete to add possibility to enter one level of cave to another, but it's planned to add that thing later). Meanwhile I've run into a new problem in jcrpg with upgrading the JME version. I hope I'll find the solution soon.
The JME version of jcrpg has been upgraded to the new version 1.0 (+ a recent LensFlare patch that resolves my FPS problem with it). Small progress, but I just wanted 1.0 to get included in jcrpg because it solves some shader related problems with some nvidia geforce cards (gf5XXX series) and maybe others. I'm really happy that the fine 3D java engine JMonkey has at last reached its version 1.0! My congratulations to the JME team for their fine piece of work! (Although I know this post doesn't mean too much for them, but if I can turn some programmers to try it it'd a big success for me :-) It's good to have such a cool opensource 3D engine in Java.)
I've decided to release this small changes, bugfix version for the public on this happy day. :-) Highlights: grass vertex shader fix for intel integrated video card low temp limit, new animal models (gorilla, fox etc.), advanced lake with depth, waters with better looking coast, fix for small billboarding bug added. Check here. Freegamer is evolving day by day. Jcrpg blog has been included in http://planet.freegamedev.net/ which unifies blogs of free opensource game development.
Finally I can post on the blog again. There's been some hours of work on jcrpg since last post, but till now I couldn't post on the blog lacking internet at home. The Lake's been improved a bit, and coasts received some bumped border. Bugfixing again the billboard tree... slowly progressing with finishing the Geography part of jcrpg and the beginning of the wildlife development along with the UI part.
Jcrpg has received a nice page in libregamewiki, a well put together libre gaming wikipedia site founded by Kiba (who's also very active at freegamer).
While the coding
goes on slowly the lake is getting better. Meanwhile, life is back again on the freegamer forum topics! Inspired by Sirgazil's warthog contrib Khaal has contributed a redfox! Check the shot! If I clean up some things around the water and geographies in general, I will get to the task of creating the wildlife code part to use these cool contribs at last. :-)
Finally managed to put together one new aquatic test release! It contains Sirgazil's warthog near the wolfs and some other new things. :-)
Headlines: bumped terrain tiles, river and lake water geographies, optional far view mode were added. JME's water render pass applied on water surface with reflection (optional, switch off for less stress on GPU/CPU). Grass is added to the mountain slopes too and the grass vertex shader is improved.
Download bz2 available at sourceforge. If having problems with the unpacked files under Windows with winrar, check this forum thread.
Working on finalizing the first version of River to support different orientations, heading towards the still water part. Meanwhile a new contributor has appeared on the horizon of jcrpg! Sirgazil's first work is a very nice warthog model. Check the picture! When I will get to wild life programming this will be very useful, just like theotherhiveking's wolf model! Hope to see many such quality models in the future. :-)
I've decided to do the future development of the project and release it under the license GNU General Public License version 3. You can still get the previous versions under LGPL with the sources included on the sf.net download page of the project. Be aware that from now on there is no possibility to incorporate future jcrpg sources into a proprietary software. The whole project source base in the SVN is committed now with the new header and the COPYRIGHT file is changed too.
Currently working on the river. Getting close to completion. Some hours of coding...then heading to the lakes and seas, the still waters. If all these are complete a release with all the goodies (cool bumped ground, water with reflection, some optimization here and there) will be born. Then comes the rounds of fixing here and there again and the wildlife.
Update: River bed's been created and is mostly working. :-) Added some blocky curves to the river, steeps are using waterfalls now. Check the new screenshot.
Looking through the google, I've spotted that Toni Graffy at http://packman.links2linux.de/ created some RPM install packages of jcrpg for openSuse. You can have them here. That's cool! :-)
PS.: Bri has created a classic RPG forum at http://com3.runboard.com/bitomoander.
He's already created a lot of subforums for games including jcrpg! We can chat there about it!
Here stands the brief feature list of the Java Classic RPG framework and the reference game.
Java Classic RPG is a totally open source project (including source and media). Its source is released under GPLv3 License, media is generally GPL, CC or Public Domain depending on the contributor/source's wish.
Complete features:
- Classic tile based world view in opengl 3D
- Ground with small terrainblocks using its heightmap, smooth
- Cave with various parameters (height, size, density, levels)
- Plains, forests
- Economy, populations (partially working) with residences
- Classic keyboard input with four direction movement
- Neoclassic look around in 45 degrees.
- Changing day and night with orbiters and optional lighting and route parameters
- Climate with belts
- Flora engine with climate dependency: continental, jungle, desert and arctic implemented
- Configurable graphics detail level 3D core (based on JMonkeyEngine) with optional grass, water reflection, billboarded trees, fog state, bloom effect, shader based wind animation etc. that can load .obj and .3ds models.
- UI widgets & detailed map system (partially)
- Water system
- Wildlife engine (partially working, group based)
- 3D model animation (md5 based partially complete)
- Audio system playing sounds and music (.ogg)
- Strong skill system (skills partially added, coding of using them is being developed)
- Save/Load of game
- World generator for Geographies / Climates / Waters
- Ecology generator (partially)
- Object system (partially)
- Turn based combat (playable)
- Character leveling
Features of the future:
- Civilization engine (group intelligence instead of personal)
- Special NPCs for plots
- Plot, scripting, quest system
- External map editor
- Other tools
- The reference game
- ?
Basic documents: architecture, game logic.
Last modified 13 August 2008
Currently working on waters. First the river is being born. Not an easy task. Will be the first time to use the so called Surface interface of geographies. Water will be a special part among the World class' subelements. It will be a semi intelligent thing. Based on an X-Z coordinate it will replace geography surfaces with its own bed (settable width and depth). In SVN we only have a different Geography extension river currently, which is not a good approach, I will rewrite the code and extend World class to make use of Waters. The water surface will be using JMonkeyEngine's cool built-in shader based WaterRenderPass with reflection. Check the screen shot.
Meanwhile Qubodup has mentioned jcrpg in his submittal on slashdot, resulting a 4500+ webhit on sourceforge project webpage. Thanks Qubodup and slashdot.org for the marketing. :-) And looking at webhit statistics I also stumbled into a sticky thread at rpgcodex.com forum which is about indie RPGs and has recently posted and linked on jcrpg. Great! :-) I'm a casual reader of their site and often find there interesting forum topics.
Little time for jcrpg nowadays. Yet working on it. I've added some new bumps to the ground (looks less bare, yet you can turn it off for less stress on GPU), grass to the mountain slopes, little changes here and there. After that I've started working on water concept of jcrpg. Thinking first about it, and some very little programming too.
I've been experimenting with the vertex shader to go beyond the way one sinusoid function gave movement to the whole scene resulting in way too much ordered wind movement. It's not an easy task in ARB dialect. :-) Here is my solution (read the comments):
Posts
if (doGrassMove) {
// creating 5 diffs to look random
diff = 0.059f * FastMath.sin(((passedTime / TIME_DIVIDER)
* windPower)) * windPower;
newDiffs[0] = diff;
diff = 0.059f * FastMath.sin((((passedTime + 500) / TIME_DIVIDER)
* windPower * (0.5f)))
* windPower;
newDiffs[1] = diff;
diff = 0.059f * FastMath.sin((((passedTime + 500) / TIME_DIVIDER)
* windPower * (0.6f)))
* windPower;
newDiffs[2] = diff;
diff = 0.059f * FastMath.sin((((passedTime + 1000) / TIME_DIVIDER)
* windPower * (0.8f)))
* windPower;
newDiffs[3] = diff;
diff = 0.059f * FastMath.sin((((passedTime + 2000) / TIME_DIVIDER)
* windPower * (0.7f)))
* windPower;
newDiffs[4] = diff;
diffs = newDiffs;
if (vertexShader) {
vp.setParameter(new float[]{diffs[0],diffs[0],0,0}, 0);
vp.setParameter(new float[]{diffs[1],diffs[1],0,0}, 1);
vp.setParameter(new float[]{diffs[2],diffs[2],0,0}, 2);
vp.setParameter(new float[]{diffs[3],diffs[3],0,0}, 3);
vp.setParameter(new float[]{diffs[4],diffs[4],0,0}, 4);
}
!!ARBvp1.0
PARAM mv[4] = { state.matrix.modelview };
PARAM mv2[4] = { state.matrix.projection };
TEMP pos,projpos;
TEMP a,b,c,div1,div2;
################################
# Apply modelview transformation
DP4 pos.x, mv[0], vertex.position;
DP4 pos.y, mv[1], vertex.position;
DP4 pos.z, mv[2], vertex.position;
DP4 pos.w, mv[3], vertex.position;
################################
# Add offset
TEMP f0,f1,f2,f3,f4;
TEMP t0,t1,t2,t3,t4;
# create different fraction parts
ADD f0, vertex.position, 0.0;
ADD f1, vertex.position, 0.1;
ADD f2, vertex.position, 0.2;
ADD f3, vertex.position, 0.3;
ADD f4, vertex.position, 0.4;
# get fraction and substract 0.5 to have
# negative values too
FRC f0, f0;
SUB f0, f0, 0.5;
FRC f1, f1;
SUB f1, f1, 0.5;
FRC f2, f2;
SUB f2, f2, 0.5;
FRC f3, f3;
SUB f3, f3, 0.5;
FRC f4, f4;
SUB f4, f4, 0.5;
# multiply different sinusoid external
# params by the texcoord y
# (highness of the quad) into t[] values
MUL t0, program.local[0], vertex.texcoord[0].yyyy;
MUL t1, program.local[1], vertex.texcoord[0].yyyy;
MUL t2, program.local[2], vertex.texcoord[0].yyyy;
MUL t3, program.local[3], vertex.texcoord[0].yyyy;
MUL t4, program.local[4], vertex.texcoord[0].yyyy;
# The trick: multiply with the different fractions,
# some of them may result in f[x] being 0, giving
# the randomness to the movement
# as one of the displacement will fall off
MUL f0, t0, f0;
MUL f1, t1, f1;
MUL f2, t2, f2;
MUL f3, t3, f3;
MUL f4, t4, f4;
# multiply with 2, bigger movements
MUL f0, f0, 2;
MUL f1, f1, 2;
MUL f2, f2, 2;
MUL f3, f3, 2;
MUL f4, f4, 2;
# add all the f[] offsets to position
ADD pos.xz, pos, f0;
ADD pos.xz, pos, f1;
ADD pos.xz, pos, f2;
ADD pos.xz, pos, f3;
ADD pos.xz, pos, f4;
################################
# Apply projection matrix
DP4 projpos.x, mv2[0], pos;
DP4 projpos.y, mv2[1], pos;
DP4 projpos.z, mv2[2], pos;
DP4 projpos.w, mv2[3], pos;
MOV result.position, projpos;
MOV result.texcoord[0], vertex.texcoord[0];
MOV result.color, vertex.color;
MOV result.fogcoord, vertex.fogcoord;
END
In my few free moments for programming I've been concentrating on Charlie's report in previous post about fog and low view distance cave blueness. For the first I've experimented a while with the fog color and distances while adding per quad sinusoid movement to the grass with the help of fraction (frc) vertex command. Then a quick ugly solution for the cave blueness: sky sphere is culled when inside the cave. :-) Maybe I will add a better solution later.
P.S.: Testing performance and bloom I took two additional higher resolution (1280x1024) screenshots to the original two demonstrating distance fog and bloom together. :-)
I've found minor issues and some major just after releasing the pre-alpha test. Problems with tree foliage billboarding. Had to fix the rotation quaternion. After that found new major issues with renderToViewport and its performance when I set bigger view distances than 40, and hacking at it I've found some other memory affecting problems too. Download at the usual place.
Release time! :-) Highlights:
"
Optimization release with addition of the new Cave geography. Many parts of 3D core was optimized. Vertex/fragment shaders were added for grass/foliage wind effect. Geometry batching was added to terrain tile/model/grass/foliage loading. Cave inside the mountain is now available."
Downloads at the usual place: link. Feel free to post comments on your experience, bugs, performance, anything. ;-) You will need about 300MB free RAM to run it.
Batch raised the need for a vertex shader for wind animation. It was done yesterday. Now the problem of fog...vertex program made fog of JME ineffective. I had to write a new one and with a lot of trouble I succeeded in that. The new quad batching of trees and the random rotation gave another big problem which is still just partially solved...too much rotation made billboarding very hard for me...still working on it. :-) But at last all is much faster. If that's finished I will release a pre-alpha again for testing purpose, before heading on to adding waters.
After a rather complicated session of hacking the 3D core of jcrpg I can announce that with the previously batched terrain tiles, simple models, quad grass plus the new Foliage batching for the trees...the geometry batch optimization session is mostly complete! Tree foliage batching means a surplus of 20%+ FPS when animations are on and even more 30%+ when it is off. Overall a big boost of performance is working well now, and things mostly look like before, no loss of detail but a big gain of performance. Memory usage became a bit more varying, bigger garbage collections, but it seems to be okay, no signs of memory leak. Shots taken on a 6200Go, resolution is 640x400. (Walking in the forest it's around 80 FPS in that resolution. In 1024x768 it's around 45 FPS, without grass around 52FPS. Outside the forest it's around 70-80 FPS.)
P.S.: After posting this one I've found several weaknesses in memory usage of the new Batching. Fixed them along with the wrong cleanup of hmSolidColorSpatials field of J3DCore...now it's fixed in SVN, mem usage is correct...I hope! ;-D
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!
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.
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...
I've been working on the cave in the slow pace I can nowadays. I've made some new cave shots of the new quadratic cave walls and the nice cave entrance contributed by theotherhiveking. The cave will get some settable multilevel architecture and longer settable entrance gorge later. FPS is a bit low on the shots, but since then I've been trying to optimize it, mostly it is around 20-40 FPS on the 6200Go, with a nice VIEW_DISTANCE, so don't get shocked by the 20- FPS! ( Well, it's enough if I am the only one shocked by it! :-) )
I've tried to reconsider geography, but finally arrived at the conclusion, that I shouldn't make big changes, it would make it more complex to have them more robust unnecessarily. I kept it simple: Cave is not a subpart of mountain anymore, Cave will be a geography just as any other, but new rules between overlapping geographies are added to make them usable inside/under mountains. Cubes can overwrite other Cubes, like the Cave entrance must overwrite the hillside Cube, otherwise you couldn't pass through the hillside. Check the SVN to enter the such generated Cave entrance into the dark undermountain cave! :-)
I plan to add further rules for Cubes that will give place for easy overlap design of Geographies. It will create fully playable, walkable geographies no matter if you want to make small geography parts that overlap big geographies. Just like small cave can overlap the mountain now without problem. I will have to clear up the code anyway during crystallizing the concept.
Also the forum life at freegamer seems to kick off well, people are reacting, asking and contributing generously. Please visit it, if you want to get your share.
While developing the new cave I've arrived at the conclusion that I must redesign the working of the Place/Geography system to carry on with the more complex multi altitude areas to make them available for later economic use for nations/cities/people. Caves must be made habitable by the AI, but that said the geographies must give access to more complex data about themselves, yet it must remain fast, flexible and easy to program. So I will spend some time now on thinking about the architecture of Places.
On the forum many contributions, but the development is paused/slowed down for a short period because of lack of time. Cave development is under way, theotherhiveking jcrpg's new 3D artist ( I hope theotherhiveking won't mind that I call him that! :-) ) has created a very nice cave entrance and cave walls plus rocky ground, but till more time for development no news will be available on that.
P.S.: I could find some hours (hopefully I will find free time not too rarely in the next overloaded month) to start to develop cave geography in the mountains. I've got one preview screenshot for you.
We have got some new visitors in the world of Jcrpg...after the giant alien women left wolfs got around howling the house! :-) (Thank you theotherhiveking at freegamer forum!)
Contribution to the projects by new people around has become more frequent in the last few days! Yeah, wow, cool indeed! I am really impressed by people contributing their work for free! The quantity has really raised so by the hands of Charlie at freegamer forum jcrpg received an own subforum to better coordinate the development and contributions to the project. Thank you all for helping the cause! I've added the list of contributors (Hall of Fame) to the project tree in the SVN repository. The list will be included in all the future releases of jcrpg.
PS.: All the cool models are put to the repository of jcrpg for later use (I will put them in the svn when I have time, the bookcase by Harek, female/male and wolf models are already in). jcrpg will heavily need them when wildlife and human life will be more implemented. Until then I can only present demo screenshots... Wildlife will be the first part that gets implemented, after adding more geographies/waters and more climate perfection.
Using this jcrpg freegamer topic's posted models I performance tested it on the low-end test videocard (6200Go), and I am amazed and surprised! I got usable performance and loading time! More then 10 of these models on the screen, lot more polygons, yet 20+ FPS! Check the screenshot (keep in mind that this won't be in the game in the near future, just a test screenshot)!
Two days after the release I've received report of jerky movement in the snapshot. I couldn't stand without trying to repair it. Yeah, I could really find some new things to optimize. Now models out of camera are not added to the scenario, they are put there when turning. This is not JME's culling, but my calculation upon turning (in J3DCore.renderToViewport). The patch also contains the new smooth tree models. Download the patch at sf.net.
With this patch I could even get a very decent view distance of 35 cubes with load distance around 60 cubes (VIEW_DISTANCE=70, RENDER_DISTANCE=120) working on my 8800GTS, AMD64 X2 4800+ with a memory use around 500MB+ (although with a rather slow turning, big load time, but very usable moving forward/backward). For that of course I had to raise the heap size -Xmx parameter in the jcrpg.sh (or jcrpg.bat under Windows) to around 350MB (-Xmx350m). Anyway the optimal VIEW_DISTANCE is around 30-40 and RENDER_DISTANCE can be set to the double of these values. Take care of the -Xmx parameter in your jcrpg.sh/jcrpg.bat if you receive OutOfMemory or Heap is full. If you have less memory for testing set smaller VIEW_DISTANCE and RENDER_DISTANCE in the config.properties file.
DomoN has drawn my attention on the trees not smoothly shaded. Yes, they were not until now! :-) Exported to (non-rotated, exported normals) .obj instead of .3ds with normals set to smooth in blender. Looks much better...I had to spend some time figuring out that I've to modify the material files (.mtl) of the model and set Ka to 0.5 0.5 0.5 to have bright enough light on them.
