Print

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

[ag]

I have some reasonable things to try that would improve performance in my mind, but that's not one of them.

Some things I'd suggest to look into:

• Rewrite flagarrayst::has_flag without using get_slot_and_addbit_uchar, so that the compiler could fully inline it when the flag is a constant.
• Units should cache the effective state of frequently checked caste flags like OPPOSED_TO_LIFE in a bitfield, so that the check could be done with one instruction, instead of multiple checks, branches, memory accesses and function calls. This seems to be one of the top sources of slowness in friend-or-foe checks in the current version.
• I'm wondering if sticking to integer math for temperature is that good of an idea, since modern CPUs probably have quite good floating-point units, while branch mispredictions and integer division are slow. With floating-point you can even cache the reciprocal of SPEC_HEAT in a field, and use only multiplication and addition. Integer math also causes some boundary jitter bugs with item containers that prevents temperature updates from ever stabilizing.
• Speaking of temperature, why can't it be done every 5 or 10 frames, instead of every frame, with an increased exchange coefficient to compensate. Something like tallow takes over 10000 frames to reach equilibrium with the environment from a 10 degree difference, and while that happens, all items in a 16x16 tile block have to be updated. Likewise, all units seem to be always being updated...
• I don't remember if items created in workshops are set to the environment temperature, instead of some fixed preset one, but if they aren't, that should probably be fixed too for the above reason.

[Trif]

The purpose of the thread is to discuss current developments.  Specific bugs should be reported on the bug tracker, and specific suggestions belong for the most part in the suggestion forum.

[BinaryBeast1010011010]

if I may, I didnt suggest anything nor did the above poster, I asked a question regarding df programming without greening it since I hoped someone could answer it and didnt want to bother toady. the kind sir ag answered and gave me clues about what could be done regarding my question. it's not just an answer I agree, it's also an incentive to look more into the raws and how df works.

I do not deserve my own suggestion forum, mind you.

[CaptainArchmage]

"and fortresses, which connect the surface to the underground and are the same sort of sites that you create."

If fortresses now connect the surface to the underground societies will we now find restrictions upon where we can embark, or if not a restriction then a new possibility to make a fortress as an entrance to our mountain home?

Will our fortresses still become the capital after a time? It seems a bit weird to turn the front door into the throne room, so to speak.

It seems that my main deciding factor for where to place what should be some far-flung colony in the style of Ancient Greece or some vital fort watching over a trade route is actually whether or not there's an aquifer.

The idea is that fortresses connect the surface to the underground, and since we embark on the surface, that should eliminate most of the restrictions for building a Dwarf Fortress far away. In the future, however, we may have to deal with getting there, so there will be places that are difficult to get to, or will require ships. For example, after the naval release, embarking on an island may result you in having a boat instead of a wagon. The details of that have yet to be worked out and there's only a slight chance of them going in this release.

Worldgen fortresses seem to be exclusively in mountain areas, which do not have aquifers as frequently as non-mountain biomes. There will probably be some way around this.

Trade routes are in but the actual movement of caravans is abstracted out, so you won't find them on the road in adventure mode. Toady had put out a map of trade routes in 0.31.13.

Toady, do you have any ideas or goals for when ships, boats, and vehicles are added? Specifically, do you see ships, boats, and vehicles as being optionally designed by the player within the game, or just being hardcoded or defined within the raws?

[reality.auditor]

Just musing, would it improve speed to rewrite it in assembly?

No.

[Aerval]

Wow I thought it would be object oriented.

What's not oo in c++?

I remember Toady once guessed about several thousand objects, he wrote for df. Might be a bit exaggerated but it definitely is oo.

[AutomataKittay]

Wow I thought it would be object oriented. Just musing, would it improve speed to rewrite it in assembly?

There're reasons that assembly isn't very used compared to higher level codes! Optimizing compilers can pull out more tricks, much faster, than most people can do. Plus it's pretty nitty gritty and ASM's harder to write over larger code segements because it involves micromanaging stuffs

Sure, a person can use tricks that compiler can't take advantage of, it's still not going to run twice as fast compared to decent compilers.

OO isn't a magic bullet for anything, either, it's a useful tool when applied well.

[BinaryBeast1010011010]

Just musing, would it improve speed to rewrite it in assembly?

No.

care to clarify for a nub?

I do not know the first thing about c++, when I say oo I was thinking python or ruby for an example... Since I'm pretty new here I cant recall the "auld days" of C. why did he switch? how hard had it been?

[MrWiggles]

There been a lot of threads already discussing how ToadyOne should be programming the game, why does it need to be in this one?

[King Mir]

Just musing, would it improve speed to rewrite it in assembly?

No.

care to clarify for a nub?

I do not know the first thing about c++, when I say oo I was thinking python or ruby for an example... Since I'm pretty new here I cant recall the "auld days" of C. why did he switch? how hard had it been?

No, because C++ is faster than assembly, unless you're know assembly as well as a compiler writer. Even then, it would be prudent to use C++ for speed of development.

[dree12]

Just musing, would it improve speed to rewrite it in assembly?

No.

care to clarify for a nub?

I do not know the first thing about c++, when I say oo I was thinking python or ruby for an example... Since I'm pretty new here I cant recall the "auld days" of C. why did he switch? how hard had it been?

No, because C++ is faster than assembly, unless you're know assembly as well as a compiler writer. Even then, it would be prudent to use C++ for speed of development.

And C++ is also far more platform-independent than assembly.

[BinaryBeast1010011010]

so anything but assembly to be platform independent, I got it.but what c++ have that C doesnt?

[King Mir]

so anything but assembly to be platform independent, I got it.but what c++ have that C doesnt?

The standard template library and object oriented programming, which among other benefits, allow you to express to the compiler what you want to do instead of how to do it, which allows the compiler to be smarter about optimizing your code. It is also makes it easier to organize a large project into parts, as that's an integral part of OOP. Lastly, it makes managing memory easier than C, especially C++11. There are other benifits too, so there is little reason to use C for a project like DF.

At it's worst C++ is as good as C. At it's best it's as abstract as Java, yet faster.

[BinaryBeast1010011010]

Are some unix os written in c++?

[hermes]

Are some unix os written in c++?

http://lmgtfy.com/?q=list+of+unix+os+written+in+C%2B%2B