Print

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

That's right

That is right

[Rose]

currentley, the XML file linked in the OP is only valid for the next version of stonesense, sorry.

[Randomtask]

I'm excited for the new release, guys. Been loving SS ever since it came out.

This thread doesn't get nearly enough positive comments. I just wanted to chime in and show some love for the crew working hard on this.

[harborpirate]

I don't think its a permissions or memory locking/blocking problem with DF or DF Hack, because I've gotten Dwarf Therapist working with it just fine. I haven't been running StoneSense any differently than DT.
Since the OP memory.xml didn't work I ran through the repository real quick just to see if any others worked (a stab in the dark).

One thing of note: I'm running the Mike Mayday graphics pack on top of v31.12. Not sure about the others who are having this problem.

[peterix]

This one should work until the next version is released: http://github.com/peterix/dfhack/raw/master/data/Memory.xml

[Andeerz]

regardless, of the two, it's actually Slade that's more likely to be purple.

Indeed!  Obsidian was black first.  I would prefer obsidian being eventually a somewhat shiny black stone, not matte and boring.  I would also prefer slade as some sort of off-black purple or blue or red or whatever, not obsidian.

[Reese]

hmm...

I've been noticing that the current version can be more than a little laggy on keyboard controls(moving the view around in SS with DF paused), I was wondering if anyone might have any suggestions to see where I might be bottlenecking.  I recall having much more responsive controls when I was using SS with 40d, and I'd like to see if there's something I can do on my end to improve performance.

[Rose]

current bottleneck is graphics, mainly, but memory reading takes a good chunk of time as well. if some coding guru could make em both happen at once, things would go quite a bit faster.

[James.Denholm]

You mean... multithread?

[Rose]

Yes, multithread. that area of programming that I find to be strange and mystical.

[James.Denholm]

Ain't that against DF tradition?

[peterix]

Ain't that against DF tradition?

Not really. DF as it is now uses three threads AFAIK. One for sound, one for graphics and one for the actual game.

[Innominate]

Multithreading here shouldn't be too difficult (said as someone who only has a theoretical knowledge of it), but may require some tricks. Potential problems with writing tile data to memory while the graphics thread is trying to read it. If tile data is essentially atomic (i.e. it is impossible for a read on a single tile to occur "in between" stages of writing), that wouldn't be a problem. But if in memory tile data has multiple attributes then it's possible a read call could end up reading a junk combination. You'd either have to use some sort of locking, which means the graphics part has to wait while the memory reader updates a tile, or a buffering system (which could be easy to implement), which means roughly doubling the amount of memory used on the data. Of course, that usage is peanuts compared to keeping the images in memory, so I'd favour the second.

[peterix]

That's exactly the idea.

Three threads.
One does only painting and user I/O.
One processes raw data into drawable areas.
One reads from DF.

Have two drawable regions. One belongs to the painting thread, one to the processing thread. When the reading thread has all the data read, the processing thread is woken up and given the data to process. When the processing is done, the processing thread syncs with the drawing thread and the drawable regions are swapped. Then they desync and the processing thread empties its drawable area, prepares it for processing and goes to sleep.

Drawing thread paints stuff on the screen and handles input.
Reader thread runs from a timer.
The area loaded should be a bit bigger than what's painted on the screen so moving around doesn't lag visually.

Reading, processing and screen output run at the same time -> moving around in stonesense is smooth, DF isn't stalled by the processing (because locking is used when accessing its memory already in DFHack, this is very important).

Also, it needs tons of optimization in the processing and drawing steps.

[Rose]

yeah, right now, DF reading and processing happens at the same time, while drawing waits.

[devek]

Or capitalize on how rarely tiles are changed and just have two threads.

Each tile is just a pointer to a structure.

The processing thread reads and looks for changed tiles. Rather than updating the structure for that tile, it makes a new one and updates the reference pointing to it. Don't free the old structure right away, store it in a list to free later.

The drawing thread can just draw away. The data it is reading may be out of date (the old reference), but it won't be changed while using it.

But honestly, it seems kind of silly. Why have multiple threads using almost no cpu instead of one? It isn't like you're doing nuclear simulations.