Print

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

[BoredVirulence]

Actually, a virtual machine CAN coerce an executable into doing something else. It requires detailed knowledge of the assembly though. Once a certain function is hit, you can track that with the instruction pointer, have the virtual machine run its own set of functions (to replace that function), set the instruction pointer to the end of the function. As I said before, its a hack, it requires knowledge of the assembly, and it would require huge memory mapping efforts after every release, which isn't terribly different from DF hack, except the scale would be much worse.

... One clear candidate for a separate thread is the calculations for events external to the fortress (at least in fortess mode) since they have a very small interaction with the fortress itself (probably only diplomat/liason reports) and thus should have a limited need for multiple access protection and separation, another one is graphics, a third one is equipment wear, and a fourth is liquid flow and temperature calculations (there are probably others as well)...

Your suggestion...
Although graphics are already multithreaded. Certainly the active world is a good candidate, I never particularly agreed with equipment wear. Pathfinding, liquids, and temperatures could be done, they would just use, an already shared resource, the map. Of course it doesn't prevent all issues, there would need to be protection to prevent data races, but it seems we already have a lot of those problems with dwarves not checking their path through flowing water. And how amusing would it be to see a dwarf try and path through a hallway, only to find the path was blocked by a wall, and force him to recalculate?

Having worked with multithreading, you can and will run into those issues you mentioned, but sometimes it is actually simple enough.

[PatrikLundell]

I agree that marrying a virtual machine with knowledge of the binary and overriding the targeted operations would yield the desired result, but if you already know the binary to that extent I'd rather replace the function call(s) with a call to the new operation(s). To build a VM around it seems like serious overkill.

[Putnam]

Even a high end computer is utterly useless and will turn to a crawl on this.
Because high end computers are multi core processors.
And DF Works with only 1 core ever.

I myself have a 6 core cpu. The game still manages to slow without breaking my cpus sweat.

http://brooker.co.za/blog/2014/12/06/random.html

For one: it's really freaking hard to do multithreading, especially with an application like DF.

Second: it's more than likely at least 80% RAM speed that is making the bottleneck, with your CPU able to go much, much, much, much, much, much faster than it actually does because the vast majority of its time is spent waiting for RAM accesses.

[Karkov]

One of these would probably get you a much faster Dorf Fort, though I'm not quite certain I'd be willing do dish out $1,700 for my game to run at a couple of frames per second faster.