Print

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

[Setharnas]

Don't forget that stuff like dorf interrelations, likes/dislikes and the resulting thoughts, dead mobs, trade agreements and so on also consist of data that needs to be stored and reevaluated. Data complexity will always build up, no matter what.

[Kogut]

I must say: Openttd is able to move around 1000 vehicles on 512x512 map. DF is lagging with 7 (seven) dwarves and one murky pool flood.
Something is wrong. Really wrong.

Quick fix: resize default embark area to 2x2.

Proper fix I: make serious profiling and improve inefficient algorithms (pathfinder? iterating over n objects without good reason?)

Proper fix Ib: do sth with bugreport 3267 - identified source of FPS loss (and probably there are other reports). http://www.bay12games.com/dwarves/mantisbt/view.php?id=3267

Proper fix II: scrap code responsible for simulations replaceable by simpler models:
"A dynamic weather model tracks wind, humidity and air masses to create fronts, clouds, rain storms and blizzards." ( http://www.bay12games.com/dwarves/features.html )
it can be translated as "DF makes a lot of calculations without more effect that simple 'if(rand()%30>25);' "
I think that weather may be be cached in nice table "weather[12];" with data for every month (table would be generated on embark, instead of iterating weather model through entire game).

Spoiler (click to show/hide)

struct weather
{
int probability_rain, base_duration_rain;
int probability_snow, base_duration_snow;
}

Toady should quit smoking the Adventure-pot and make Fortress mode playable again, or no more bug reports. I'm on strike!

Heh. There are exactly 1780 report, unassigned bugs. And 1193 resolved - so there is enough work for many years.

Edit: I registered to post it. By the way - it is awesome game.
Edit2: Sorry for terrible English.

[MagmaMcFry]

I must say: Openttd is able to move around 1000 vehicles on 512x512 map. DF is lagging with 7 (seven) dwarves and one murky pool flood.
Something is wrong. Really wrong.

Quick fix: resize default embark area to 2x2.

Proper fix I: make serious profiling and improve inefficient algorithms (pathfinder? iterating over n objects without good reason?)

Proper fix Ib: do sth with bugreport 3267 - identified source of FPS loss (and probably there are other reports). http://www.bay12games.com/dwarves/mantisbt/view.php?id=3267

Proper fix II: scrap code responsible for simulations replaceable by simpler models:
"A dynamic weather model tracks wind, humidity and air masses to create fronts, clouds, rain storms and blizzards." ( http://www.bay12games.com/dwarves/features.html )
it can be translated as "DF makes a lot of calculations without more effect that simple 'if(rand()%30>25);' "
I think that weather may be be cached in nice table "weather[12];" with data for every month (table would be generated on embark, instead of iterating weather model through entire game).

Spoiler (click to show/hide)

struct weather
{
int probability_rain, base_duration_rain;
int probability_snow, base_duration_snow;
}

Toady should quit smoking the Adventure-pot and make Fortress mode playable again, or no more bug reports. I'm on strike!

Heh. There are exactly 1780 report, unassigned bugs. And 1193 resolved - so there is enough work for many years.

Edit: I registered to post it. By the way - it is awesome game.
Edit2: Sorry for terrible English.

Well, I normally don't register anywhere to necro a thread with a first post full of technical details, but still, welcome to the forums, Kogut.

[Urist McDepravity]

Proper fix II: scrap code responsible for simulations replaceable by simpler models:
"A dynamic weather model tracks wind, humidity and air masses to create fronts, clouds, rain storms and blizzards." ( http://www.bay12games.com/dwarves/features.html )
it can be translated as "DF makes a lot of calculations without more effect that simple 'if(rand()%30>25);' "
I think that weather may be be cached in nice table "weather[12];" with data for every month (table would be generated on embark, instead of iterating weather model through entire game).

While I agree with other points, this one is terrible one. Complex simulations is the thing which makes many of us still wanting to play this game year after year. I want to be able to induce severe climate changes with my massive deforestation and magmafication activities.
After all, this is fantasy world simulator.

However, I believe that there is always some space for optimization, including caching where it does not hurt player abilities.

[nbonaparte]

right now, the occurence of rain is seemingly random. Making it actually random and attached to the moisture in the area would speed things up.

[macdonellba]

I must say: Openttd is able to move around 1000 vehicles on 512x512 map. DF is lagging with 7 (seven) dwarves and one murky pool flood.
Something is wrong. Really wrong.

In the case of OpenTTD, there are relatively few nodes on the road / rail graphs, and the roads only serve as edges on a graph, which makes any sort of pathfinding algorithm ridiculously fast - the only vehicles requiring CPU-intensive pathfinding are ships, and even then they have a relatively open grid to work on. Performing A* on a large grid, where paths are difficult to cache, is an entirely different matter.

[Kogut]

Main point is that openttd developers are focused on bugfixing and various improvements. Toady on adding new stuff. On the other hand basic openttd stuff is finished and what more devs are frequently rejecting many patches due to (sometimes) small problems. DF is still in theory alpha, but with goal "create a fantasy world simulator in which it is possible to take part in a rich history, occupying a variety of roles through the course of several games." this game will be alpha forever.

[Urist McDepravity]

with goal "create a fantasy world simulator in which it is possible to take part in a rich history, occupying a variety of roles through the course of several games." this game will be alpha forever.

And thats not a bad thing. At least our children will be able to play in the game of all games.
I think performance and bugfixing updates can wait before caravan and army arcs are done, with some of post-worldgen world advancement and proper sieges (tunneling, siege machines, etc), so there would be something to do in DF mode beyond megaprojects.

[MrWiggles]

Proper fix I: make serious profiling and improve inefficient algorithms (pathfinder? iterating over n objects without good reason?)

Being done.

Proper fix Ib: do sth with bugreport 3267 - identified source of FPS loss (and probably there are other reports). http://www.bay12games.com/dwarves/mantisbt/view.php?id=3267

Probably being done. Though due to the presumed nature of the beast, probably isn't just one reason.

Heh. There are exactly 1780 report, unassigned bugs. And 1193 resolved - so there is enough work for many years.

Thats poor measure of the bugs being quashed. As the 1780 count, includes the none bugs and various repeats, and there is a similar issue with the resolved count.

----

I must say: Openttd is able to move around 1000 vehicles on 512x512 map. DF is lagging with 7 (seven) dwarves and one murky pool flood.
Something is wrong. Really wrong.

OpenTTD is a far simpler game that it an out and out clone of a feature complete game. It does have various improvements that I've come to enjoy and relish, but comparing their two dev cycles and paces is out of scope.

Of course the dev are primarily focused on bug fixes, optimization and improvements, there isn't much else to do with the game. Its feature complete. What features it has, are far simpler then the current feature set of DF.


Toady however is trying to a much more complicated game. Yes, it could be ran on various simpler systems, but thats not the end aim for the Devs of Dwarf Fortress. The Dev of DF do not just add new features to the game. It goes through various cycles of new features, improvements on older systems, and out right replacing them and there is /constant/ bug fixes.

I agree that DF may never be done, but that doesn't seem to be a concern to the Devs. However, I disagree that it'll always be Alpha. The game is not feature compete but, the feature set that Toady and Threetoes want is finite, and to my understanding not growing.

[Mel_Vixen]

*edit: Since that thread is anyway necroed lets dig up some old stuff.*

It's already been said. Every time a job regarding an item is called, every item is checked.

It's not job related, it's that they're checked every frame to see if they're decomposing or bursting into flame or whatever.

Hopefully Toady can do something about this later on.

Decomposing should be relativly easy. Instead checking each item individually each frame things that can decompose could be moved to a list as soon they are brought into a state there they can beggin to decompose. So as soon food is left outside the particular itme gets set on the list. The mainthread has then only to check the list once in while to advance the decomposing.

That check could be multithreaded by splitting the List into multiple parts (depending on the size of the list) but i dont want to join this particular and redicilous bickering atm.

Thermics are a bit different i think. Suggestions?

I must say: Openttd is able to move around 1000 vehicles on 512x512 map. DF is lagging with 7 (seven) dwarves and one murky pool flood.
Something is wrong. Really wrong.

OppenTTD is able to move that vehicles faster because its map is far smaller. Df maps are 3 dimension with variable UG and Viraible OG levels
where Oppentdd is 2 dimensional (and further limited by streets).
This leads the typical A* Df uses to check more nodes (26 instead of 8 in a worst case scenario) then which ever pathing algo Oppentdd uses. 

Btw. Irrc we know how the liquid code for df works so how about that: You Threading gurus in here sink your teeth into this problem instead of each other?

[Tellemurius]

i dunno man im working on a new programming methodology that will allow possible cpu pooling for threads (you can stick 4 cores on one thread that add up their processing power, basically what AMD's new chip should do but in programming) so far im stuck but i know its possible.

[Kogut]

Proper fix I: make serious profiling and improve inefficient algorithms (pathfinder? iterating over n objects without good reason?)

Being done.

Proper fix Ib: do sth with bugreport 3267 - identified source of FPS loss (and probably there are other reports). http://www.bay12games.com/dwarves/mantisbt/view.php?id=3267

Probably being done. Though due to the presumed nature of the beast, probably isn't just one reason.

But is done after adding 12 types of grass. BTW I know about 4 real types of grass.

Heh. There are exactly 1780 report, unassigned bugs. And 1193 resolved - so there is enough work for many years.

Thats poor measure of the bugs being quashed. As the 1780 count, includes the none bugs and various repeats, and there is a similar issue with the resolved count.

What makes it really worse. There is Dwarfu, (s)he closes duplicated bugs, obvious not-a-bug etc. So we can assume that open bugreports are about real bugs and cannot that closed=fixed. In fact in last 25 closed bugreports there are
2x fixed
12x duplicate
4x no change required
7x unable to reproduce
So only about 10% of closed bugs are really fixed (it may be heavily biased, maybe Toady marks bugs as fixed in waves).

I must say: Openttd is able to move around 1000 vehicles on 512x512 map. DF is lagging with 7 (seven) dwarves and one murky pool flood.
Something is wrong. Really wrong.

OpenTTD is a far simpler game that it an out and out clone of a feature complete game. It does have various improvements that I've come to enjoy and relish, but comparing their two dev cycles and paces is out of scope.

I am not sure is it simpler, but being clone really helped. And in fact DFs feature level may be presented as finished game. But comparing development may be not the best idea: DF is not open source, openttd devs can say "all developers, whether core developers or not, do that for their own joy in their own free time. Thus they pick up what they think is the most rewarding and promising thing to spend their time with.". Etc.

I mentioned openttd because I know quite a lot about how it was developed and there is huge difference in devs thinking "This patch doesn't meet OpenTTD quality requirements." vs "18 types of grasses have been added for your bovine animals to graze on with more to come" with multiple waiting gamebreaking bugs on bugtracker.

Of course the dev are primarily focused on bug fixes, optimization and improvements, there isn't much else to do with the game. Its feature complete. What features it has, are far simpler then the current feature set of DF.

There are at least 2 big attempts to include new things - Cargodist ( http://www.tt-forums.net/viewtopic.php?f=33&t=41992 ) and More height levels ( http://www.tt-forums.net/viewtopic.php?f=33&t=40844&start=0 ). And n+ patches.

I am not sure that it has less features - a lot of effort was connected with NTP, NPF, YAPF - pathfinders made to improve efficiency and graphics (it is not full 3d but still more complicated than DF).

Toady however is trying to a much more complicated game. Yes, it could be ran on various simpler systems, but thats not the end aim for the Devs of Dwarf Fortress. The Dev of DF do not just add new features to the game. It goes through various cycles of new features, improvements on older systems, and out right replacing them and there is /constant/ bug fixes.

But in may end in game not runnable above 20 FPS and unplayable due to bugs.

I agree that DF may never be done, but that doesn't seem to be a concern to the Devs. However, I disagree that it'll always be Alpha. The game is not feature compete but, the feature set that Toady and Threetoes want is finite, and to my understanding not growing.

Yes, in afterlife donations are not required. IMHO it will be eternal alpha/beta. This amount of bugs is unfixable for 2 people. Maybe going open source may change sth, but I am not sure (and it will not happen in unforeseeable future).

[Ranzear]

There was nothing more satisfying in 40d than plodding along at 6-7 FPS loading a drawbridge-trash-compactor, pulling the lever, freezing for about ten minutes, and coming back to 75-80 FPS. Doing this in 2010 does positively jack.

Contaminants not disappearing being proven as a major resource hog of a bug is definitely needing a fast fix. I think the performance hit is even more severe on less stellar systems (particularly with less RAM), I've had forts drop to unplayable FPS after just two or three seasons when some cave-adaptation causes a pukefest in the main corridor (after I've completed my 'outdoor' main staircase to prevent cave-adaptation) and it gets tracked all around the fort.

[ShadowZane]

Alright I got (basically) 2 questions to all you genius coders out there
1. Is it possible, just POSSIBLE to run Dwarf Fortress (In far far future) as a REAL and actual multiplayer game?
2. Wouldn`t that increase FPS drastically as path finding could be reduced? (If players are doing it themselves the game doesnt need to check for stuff lying arround and so on and so on)

[nbonaparte]

It's possible, yes. Give each player an adventure mode interface, give them a single dwarf. That would be an MMO style change. An RTS style change would require the army and trade arcs finished, where players build forts independently and attack each other. That too could work in an MMO environment. The problem there is that of lag. There's a lot of information to transmit. I think a DF multiplayer would either have to be a LAN thing or it would require common connections much better than they are now.