Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[TheSpaceMan]

How many tiles are the dwarf fortress exactly, and how many tiles are the world?

Find this interesting to know since i am going to code a world generator in the near future.

And also, is the shifting of continental plates calculated into the generation of the world?

[ July 12, 2007: Message edited by: TheSpaceMan ]

[ July 12, 2007: Message edited by: TheSpaceMan ]

[utunnels]

You can export a bitmap, and calculate by yourself.  

[TheSpaceMan]

Hehe. I find it very hard to calculate on the map. It's to easy to loose count. I was thinking that someone allready done this. ^^

[TheSpaceMan]

i would bet around 256 tiles wide for the world map.

It's mostly interesting to know what kind of detail you can get at what size.

[Asehujiko]

Generic map squares are 144x144, fortress is 480x480, no idea what the entire world is.

[Toady One]

World is 257x257, each square is now 768x768 in the unreleased one.  They aren't consistently sized in the current one (the dims given above are correct).

There are no plates in DF.  The timescale of continental drift isn't really useful for the game the way it works right now, over a thousand years.  Pushing things around a bit might improve the look of the maps slightly by creating more lines and breaks, but that's about it.

[TheSpaceMan]

May i ask what fractals are involved?
I am guessing som kind of basic perlin noise for the heightmap, some kind of erosion calculation för time and that trees spread acording to some rules about speed and how it's able to grow. Flowing water i guess is based on heightmap data as well and rules about flowdynamics, if a river is pouring south and hits a solid object, either the solid object disolves or the water will change path.

And i guess pumped liquids spawn children in all directions valid not currently occupied with liquid and updates details about water flow direction accordingly, also a falloff rate for the liquid that keeps it in check and allows it to dry up when no more water is supplied. And some kind of check when a area is flooded since game drops FPS untill a room in completly filled. Made a major lag peek when adding a dwarf to Pull Lever Repeat that regulates the flood gate.

Sorry for all my questions, it is only that i find DF extremly cool and inspiering. In some details it's one the boarder line between genious and crazy. "Trained gorilla armies..". Some people belived i was high when i tried to describe the game...

Since i am a game developer myself, had a dream about a simular design ( "Post-apoc valve Sci-Fi" not Fantasy) that i didn't know how to realise i find it quite uplifting to see that it can be done. According with the moto of the game that "A graphic isn't a issue untill the vision of the game is complete." is the same rules i live by. The game should allways be represented by the bare minimum, testing each part of gameplay untill perfection, only then, if needed, additional work of graphics and Effects should be allowed. A move the industry has twisted 180 degrees around.

What i am saying is that i hope that you feel like answering my questions in the manar you feel fitting, else keep up the good work. This is the first game in 8 years that i have grown addicted too.

[ July 12, 2007: Message edited by: TheSpaceMan ]

[Toady One]

I don't know what perlin noise is.  Last time I looked at a wikipedia article it didn't help me figure out what it would mean in terms of an algorithm.  I gather what I'm using for most of my fractals is called midpoint displacement.  The erosion stuff is kind of cobbled together, but, yeah, it's based mainly on the height map.  There are several fractals on top of each other for height, rainfall, temperature, etc. and these determine the biomes.  There are also some orographic precipitation/rain shadow effects it does that help to determine biomes.

The "pumped liquids" you are referring to seem to be the ones in the currently released version rather than all the stuff we'd been talking about on the future of the fortress thread (now that there are actually pumps).  The lag has nothing to do with the liquid itself, but with the pathing connectivity updates.

I hope you continue working on your game.  We'd also wanted to do a large scifi game, but you can only have so many giant projects going at once, so if we ever get around to it, it'll likely be chopped up into smaller pieces.

[TheSpaceMan]

I see. I actualy remeber looking at a tutorial about that earlier today. Still i think i personaly go perlin later.

You could se perlin noise as a multi layer pixel structure where each pixel in each layer is either 0 or 1.
Where each layer is a smaller size. The last thing to do is to scale all layers up to the same size, then adding the value for each layer to the height map according to height = (1.0f/nroflayers)*layers.

So you would only get the highest level hightmap where there are a white pixel in all layers.

Kinda... ^^

[Ilmuri]

Perlin noise is just another random number generator. Heightmaps are created by sampling together different frequencies and amplitudes of noise. Perlin has also made a faster (and all around better) version of it called simplex noise.

http://freespace.virgin.net/hugo.elias/models/m_perlin.htm seems like a nice tutorial.
http://mrl.nyu.edu/~perlin/ contains some nice experimentations he has done. Quite a guy I'd say.

[ July 13, 2007: Message edited by: Ilmuri ]

[TheSpaceMan]

Well atleast it's almost what i said.
I belive that my description would work well too even if it's diffrent. I belive that the perlin calculation shown uses splines to calculate the curves between points. The sugestion i said would bring i simular(maybe less exakt) version at a lower calculation cost. Still i am not quite sure.

I will use what feels best, and works best for me. As said on many places, when generating worlds there is no "complete" calculation when generating, simply try what works and use it.

[TheSpaceMan]

Tried my mutated interpetation of a perlin noise yesterday. It really gave a random noise. Still it wasn't as soft or, so to say, a visably accapteble noise sutible for terrain. It laied more towards white noise, with some destinctive peeks.

So i am going to take a look at midpoint displacement later today or tomorrow, and also try to implement some basic perlin then i am going to compare to see what can produce the best kind of 10 level heightmap.

A question for mr Toad.

Am i correct in the asumtion that the entire playing field and gui is part of one triangle patch in DF and that the changes to it are simply the change of a the texture at the current point in the patch?

I encounterd some major slowdowns myself working with so many 2D objects in a project (64x64), still some optimizeations i have thought about might solve it.

I think that my problem is based on to many draw calls. The strong side with one patch is that there is only one draw call but many texture changes, if not a mega texture is being used.

If a mega texture would be used, only one draw call would be needed... and only on texture... further research is requierd.... Just trying to inplement a easy system to use that won't require my constant attention and change, just that the research can be done at a acceptable FPS.

[Toady One]

I'm printing 4000 quads, I think (background color rects and then colored alpha textures on top).  It isn't expensive, provided you have any kind of reasonable card with reasonable drivers.  The slowdown might come from specifically how you are printing them and how your calls are arranged, but I don't know that much about it.  I'm sure there are people floating around here that might be able to help if you're more specific about what you are doing.

[TheSpaceMan]

Ah ok.
I think the main problem is that my engine was at the moment arranged to be a pure 3D engine, then retrofited to work as a 2D engine. The only way that could be achvied fast was to use a 3D mesh with lots of data that is not really needed for a Quad/2DObject, the mesh and all textures that are being reused are still pointers so memory is saved, but everything still passes trough 2 pixelshaders. One for each camera to add everything from the cameras view to a texture, and one final pass to present all active cameras to the screen att diffrent points.

I shall resort the 2D queue by ordering it like quad->list of textures, for every type of texture->list of matrixes for positioning for every place that textures is being used.
Right now it sets data  (quad,texture,matrix) for all textures each update.

Thank you for takeing your time and answering. ^^

[ July 18, 2007: Message edited by: TheSpaceMan ]

[qwertyuiopas]

The fastest method I know would be to put all data into arrays, than draw it to a buffer THEN draw it to the screen/interpret it into 3D.
so the processing is not split up bu many unneeded redraws.