FeXoR
-
Posts
1.426 -
Joined
-
Last visited
-
Days Won
28
Posts posted by FeXoR
-
-
The engine does not really support multiple water levels (though they can be set) AFAIK.
At least it's not tested at all (and thought to be very buggy if used).
Water (e.g. Waviness) can be set with the environment settings:http://trac.wildfiregames.com/wiki/Rmgen_Library#EnvironmentHelpers
-
1
-
-
It is sad when the game developer turn an RTS franchise into cash cow.
I don't think it's the developers(?)
@Zeta1127: That's what customers are for (from some PPS point of view, I guess ^^).
-
I agree that well made 2D units are better to separate.
I also agree that the clean graphics allowing a good oversight in general is a good thing.
However, I also like graphics supporting different ambients (which likely contradicts the top point).
-
A 3D outline shader should do like: http://i.imgur.com/WVE3f.jpg
-
It is easy to add to ramdom maps. Though settings are not yet supported.
(If RMGEN lived in simulations it would be easy for all maps...)
However, building lots of javelin infantry is not bad for economy so I don't see the need for a palisade.
(I'm not playing a lot though so this might be better judged by a more active player)
-
Why would that be wanted?
In the end that would mean that the creator of a topic could erase posts of other PPL (which is bad in the first palace IMO).
Also there might be other PPL finding partial answer to their question in a topic while still have related questions so they may ask them in this topic though the creator of this topic might have all her/his questions answered.
-
1
-
-
Hephaestion: You are right. I use the "* 0.5" in the lines "vector_x" and "vector_y" because otherwise it would be twice the vector.
What I mean is when I go through the grid I calculate "dx" and "next_dx".
For x = 0, y = 0 next_dx is heightmap[1][1] - heightmap[0][1].
For x = 0, y = 1 dx would be heightmap[1][1] - heightmap[0][1].
So they are the same but I calculate them twice.
For dx/next_dx I could just remember next_dx and use it for the next tile as dx (if it's not a new x line, which is the same as "if y != 0").
That way I'd replace the calculation "heightmap[1][1] - heightmap[0][1]" with "dx = next_dx" and the condition "if y != 0" (in most cases) which should be a bit faster.
For dy/next_dy this will not work though (because dy will never have been calculated in the last tiles calculations).
Originally I looped and only calculated the dx/dy, put them in an array to then use them to calculate the slope later.
That way I did only calculate everything once but then I needed two loops which in the end was at least ugly (and likely slower).
Further explanation to disenchant the magic:
The heightmap is an array of map size arrays with map size floats in them (the height dependent on x (first arrays index) and y (second arrays index) coordinates).
So the height at coordinates x/y is heightmap[x][y].
This points define the most accurate edges (e.g. peaks and pits) of the heightmap (further called vortices).
I usually think of it as a cross-section paper where the vortices are the crossings of the lines.
Tiles are the square areas between lines (with the cross-section paper in mind).
I want to know the direction (2 dimensional only) of the highest incline of the tiles and how extreem the incline is.
Tiles are placed between the vortices so e.g. the first tile would have the corners at 0/0, 0/1, 1/0 and 1/1 (so the center of this tile is 0.5/0.5).
The incline is usually represented by a vector.
The direction of the vector indicated direction of the highest incline.
The length of the vector indicates how extreme the incline is (The length is just (vector_x² + vector_y²)^0.5), theorem of Pythagoras).
To get a tiles incline direction I first calculate the incline (difference of heights) of the four edges of a tile (dx, next_dx, dy and next_dy).
Then I calculate the components (x and y direction) of the vector of highest incline by just summing up the x and y incline of the edges individually (vector_x/vector_y).
Since I only need a value for the steepness (in this case, realistic terrain demo) and not the direction I then calculate the vectors length (vector_x² + vector_y²)^0.5.
For terrain placement on realistic terrain demo I only do two different things dependent on the incline (on low and high incline) so I might as well get rid of the "normalization" to increase speed (the " * 0.5" and the " ^ 0.5").
Speed is not critical here though since it only runs once.
For erosion and in general I need the normalized vector though so there's not much to optimize.
And sadly here performance is vital because it will be used several times.
-
1
-
-
Thx, sanderd17!
For the different water levels I'd need to know the structure of the water planes the engine should get from RMGEN..
Then I'd add it to the Map class in this (or a similar) structure (and maybe add a variable to enable different water levels which would be False by default to avoid breaking existing maps).
Not sure which part of code takes the outcome of the RMS then...
This would not help for erosion in any way though.
For that I'd need some C++ functions somewhere in the non-game-engine code that can be called by RMGEN (since RMGEN runs before the engine starts AFAIK).
I have simply no idea how to do that (only did this with C -> Python).
So if you could help here that would be terrific.
In general I'd really like if variables like min height, max height, gravity, wind speed, wind bumpiness, ... would be defined at exactly one place.
Some of those might be useful to be set from different parts of the code as well.
I don't know if the parsing will cause more trouble in the end then defining them over and over again in the different parts.
Some functions, however, would really be useful to have.
As an example fast slope calculation is needed by: Pathfinder, Unit AI, Player AI (simulations), random maps (RMGEN) and the graphics engine.
The specific needs for making water erosion for RMGEN faster would be a faster function to calculate the slope map:
- getSopeMap(heightmap)
Takes: heightmap (An rectangular (or square though I don't see the benefit) array of float32arrays)
Returns: slopemap (an rectangular array of arrays of arrays (size two, vector) of width and length one smaller than the give heightmap determining the incline of the surfaces between the vortices)
(This will also be useful for (non-tile centered) slope dependent terrain painting... and I don't see why the tile centered version should be used in these cases)
A similar function in javascript looks like:
function getSlopeMap(heightmap){heightmap = (heightmap || g_Map.height);var max_x = heightmap.length - 1;var max_y = heightmap[0].length - 1;var slopeMap = new Array(max_x);for (var x = 0; x < max_x; x++){slopeMap[x] = new Float32Array(max_y);for (var y = 0; y < max_y; y++){var dx = heightmap[x + 1][y] - heightmap[x][y];var dy = heightmap[x][y + 1] - heightmap[x][y];var next_dx = heightmap[x + 1][y + 1] - heightmap[x][y + 1];var next_dy = heightmap[x + 1][y + 1] - heightmap[x + 1][y];var vector_x = 0.5 * (dx + next_dx);var vector_y = 0.5 * (dy + next_dy);slopeMap[x][y] = Math.pow(vector_x * vector_x + vector_y * vector_y, 0.5);}}return slopeMap;}It returns floats instead of vectors for each surface and could be optimized (e.g. it calculates every edge vector twice, once for each appending tile)
I don't have enough overview to decide whats best to do in general.
-
The problem with the approach of the link is that the algorithm only works on a uniform map (equal height everywhere).
The hight could then be changed according to the shading.
However, I think I can make the erosion work reasonably fast (I have a few more ideas).
My latest version is indeed more sophisticated then everything I've seen so far in code.
It roughly works like:
- Let it rain dependent on height (get/change water depth map)
- Get slope vector map (from height map)
- Get acceleration vector map dependent on slope and gravity (would be nice to have the correspondent variable from the engine at hand)
- Calculate total speed vector map considering acceleration, last steps water speed and friction (dependent on the water depth and previously calculated water speed)
- Change the water depth map accordingly and the height map dependent on water speed and soil portion (dependent on water speed as well)
(This takes longer to calculate for each step obviously but the erosion effect is much stronger then just considering water derivation to appending tiles so much less steps are needed)
However, there's only one direction all water flows from one tile (two appending tiles getting it) so in the end the resolution might always be a little bad.
And wraitii was right at the start: One problem of the actual implementation is the slope is calculated wrong (shifted half a tile) so the outcome gets edgy at ~100 cycles even if gravitation, rain and soil portion is quite low and friction is quite high (already did this for the realistic terrain demo so all I have to do is puzzle everything together).
After this change it might be possible to raise the erosion strength (raise gravitation and soil portion, lower friction) so less steps are needed (10-20 would be OK meaning about 2-3 min calculating for giant maps... yes, still a lot but some other random maps take longer).
If this (quite realistic) approach fails in speed I can still use an older, simpler one (though I'd be a bit sad ^^).
[ofc. this would all be much faster if implemented in C/C++ and given to the random map libs as a shared function]
-
1
-
-
I agree with sanderd17.
This idea sounds more like a cheat then game content.
As player AIs (which as a side note are players) should not cheat (before the hardest settings) the human players shouldn't also (unless specifically determined as cheating).
-
1
-
-
Thx for the answer.
Concerning the snow:
I only have a decent overview about RMGEN codebase and not the simulation code (or the engine) so I can't help you here.
The "only visual" height change is also used for terrain flattening underneath buildings AFAIK so maybe you could look there.
The function would be similar to erosion functions like in here.
I also played around with rain amount depending on height (a linear function did do fine).
A function to redistribute the snow locally might be similar to getAdditiveWindErrosionedReliefmap() in the above linked map (only 8 possible directions though since tile, not vector-based but fast).
A global wind strength parameter will do fine (the local effects could be (randomly) determined in the functions doing things with wind involved).
An additional parameter like "windBumpiness" would be helping though.
I have no idea where those global parameters should be invoked (guess right in the C++ code since e.g. tree movement depends on it).
Ofc. the map/RMS designer should be able to set it.
-
1
-
-
Hm, got a javascript question:
What's the difference of defining a class function inside the body with this.function_name = function () {blablub}
or outside the class body with class_name.prototype.function_name = function () {blablub}
Code:
function Environment(name){this.name = name;this.SkySet = "default",this.SunColour = {r: 0.749020, g: 0.749020, b: 0.749020, a: 0},this.SunElevation = 0.785398,this.SunRotation = 5.49779,this.TerrainAmbientColour = {r: 0.501961, g: 0.501961, b: 0.501961, a: 0},this.UnitsAmbientColour = {r: 0.501961, g: 0.501961, b: 0.501961, a: 0},this.Water = {WaterBody: {Type: "default",Colour: {r: 0.3, g: 0.35, b: 0.7, a: 0},Height: 5,Waviness: 8,Murkiness: 0.45,Tint: {r: 0.28, g: 0.3, b: 0.59, a: 0},ReflectionTint: {r: 0.28, g: 0.3, b: 0.59, a: 0},ReflectionTintStrength: 0.0}},this.Fog = {FogFactor: 0.0,FogThickness: 0.5,FogColor: {r: 0.8, g: 0.8, b: 0.8, a: 0}},this.Postproc = {Brightness: 0.0,Contrast: 1.0,Saturation: 1.0,Bloom: 0.2,PostprocEffect: "default"}// this.deploy = function()// {// g_Environment = this;// }}Environment.prototype.deploy = function(){g_Environment = this;}As is it works.
Using the documented out code (inside the class body) Atlas starts but never finishes the random map.
-
Concerning TILE_CENTERED_HEIGHT_MAP variable:
Could someone plz tell me the reasons for/advantages of the two different terrain texture paint methods?
It is quite annoying for implementation of some heightmap functionalities (like e.g. using height/slope maps to paint tiles).
If one of the methods have proven to work better then the other it may be worth the thought of removing the other one.
(If both are suited in different cases (as I suspect) I'll just have to adjust the functions to that)
-
Oh my. That order got me confused. Thx!
So that's an improvement additionally to staying up to date. Great job!
-
So the conclusion is: All ESR31 versions are slower.So why should we go for ESR31 anyway? -
Nice.
The things I like most from your latest patch are:
- The ripping out guts animations
- The sacrificial pits with blood lakes on their ground (I'm working on a blood eroded terrain)
- The Golgothan excremental demon (see here) It perfectly fits in the timeframe.
EDIT: Oh, just found the pyramidal temple with the constant stream of PPL being quartered. Perfectly done!
I don't thing the skeleton spawn points should be restricted to the zombie players territory though. They block each other and stumble about each others bones (and enemy guts) ATM.
What about converting PPL to the zombies by ripping of their flesh and transform them to skeletons (until now only the guts are flying around and they are converted to zombies). At least alternatively? (The burning skin shrivel animation is done well. Perhaps burn the PPL? We could add support for the olfaktorik output device to make it smell like burned flesh)
Cool power suggestions: Like in this holy book maybe we could add the zombie hero ability of cursing the enemies like: "May your guts entangle the next thornbush!" (at least if they worship Om)
-
1
-
-
"Happy you are wrong this time:" ~ Hephaestion
Me too! I totally missed that development. THX for that.
(And if leper, Spahbod and sanderd17 agree on that it's as good as in I guess ^^)
-
2
-
-
I didn't try it yet but it should work: http://www.wildfiregames.com/forum/index.php?showtopic=18211#entry284318
-
2
-
-
It's not for oponnents AI's it's for NPC's in micro factions. So there is a loop. The AI plays on its own, but life goes on in loop in small villages.
IMO there's no need for this either. Gaia entities could just randomly walk around (depending on the original point of placement only so e.g. they don't veer away over a maximum distance or something).
The exact behavior could e.g. depend on the stance the unit has (though this cannot be set ATM AFAIK).
This functionality might however be turned on/off so more specific behavior could be added in scripts.
Trigger (that would make such things easy) are not implemented yet though and are not planned to be in part 1 AFAIK.
Anyways, you don't need actors like waypoints to deal with this. You can just add these points in the scripts.
-
Concerning waypoints for AIs on maps:
Thats a bad idea. Likely the map designer doesn't know that much about AIs in general and he would need far-reaching knowledge abot the player AI that actually uses the waypoints.
For random maps it is even worse because the RMS writer will likely know less about the actually generated map then an analysis of a specifically generated map would.
Having different AIs available might mean different waypoints are needed fo each of them so it gets worse the more modifiable things get.
-
2
-
-
Why not use freelancer.com and just put up projects for specific tasks?
I like the idea of giving freelancers an opportunity in 0 A.D..
However, it might be difficult to make this work for both sides:
- For 0 A.D.it's vital that things really improve by payed work.
- For the freelancer it would be vital to know he gets the money for his work.
So for 0 A.D. it would be optimal to set some (well defined) goals and offer payment for a solution (after it is done and tested).
(the problem here is the "well defined" I guess since solving one issue e.g. should not result in adding a new (maybe worse) issue)
For a freelancer it would be optimal if the payment is guaranteed (if the issue is solved by her/him) e.g. not dependent on the team liking the solution.
I don't know if this can be solved.
-
The (current) menu already gets warped at 600p height.
The 0 A.D. main menu at 800x600:
You need about 690p height to display it correctly.
I don't like this. The GUI should work even with smaller resolutions (scrollable widgets are hopefully available in out GUI toolkit).
In general I'd prefer resizing elements (like e.g. changing the font size (in options, not present ATM) would resize the buttons).
But visuals are favored over usability here once more. With scrollable widgets it would still work (though sometimes bad to handle).
Separating the editor from the options is a good idea IMO.
-
Hephaestion: THX much! Sometimes a motivating/inspiring post (or a kick in the butt) is what I need ^^.
I'll add more flowers.
-
I guess you could make huge texturing improvements by adapting a combination of height-based texturing and slope-based texturing.
Good idea! I'll do that!
Website menu is not displaying right in firefox
in Help & Feedback
Posted
I can't confirm this.
For me the menu item has the right size for all subitems to fit in the dropdown (At least in Firefox and Opera).
My screen width is 1280 pixels and it also works properly if resizing the window (I just have to scroll horizontally as well to see everything).
Maybe it's your screen resolution (and changing windows size does not act the same) or something different I can't tell at first glance.