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

[Dark_Tundra]

Sure thing, I'm looking forward to avoiding this in future

Code: [Select]

<?xml version="1.0" ?>

<creatures>

 <creature gameID="TITAN"  file="megabeasts.png" >

  <variant special="Normal" sheetIndex =0/>

  <variant special="Skeleton" sheetIndex =0/>

  <variant special="Zombie" sheetIndex =0/>

 </creature>

</creatures>

I actually used Deon's cyclops as a start(although I redrew most of it by the end).

Here's an ettin:


P.S. And a based on the same body cyclops (m, f):

[Belal]

Just a small update on items.

DF does loop through the entire item vector at least once every frame, although it clearly does not load the full item information for each item every frame.

An easy test to see that this is true is put a breakpoint at any pointer on the item vector located at offset 0x015BDF68, they will all be triggered each frame.

Our problem is the current memory reading methods are slow, however once we have the shared memory DFHack working on both windows and linux we should have much better read speed.

[CobaltKobold]

Dark_Tundra: Alpha channel or magenta for transparency?

[Elvisman2001]

I read several pages trying to find an answer. . .  but the thread is rather thick. Anyway, i am running windows 7 64 bit.
I run DF and get to the game play screens. Then i run Stonesense. After hitting 'F9', it tells me it cannot find a DF process. . .  any ideas or. . . ?

Looks like a magnifigo program. wish i could get it to work.

[Deon]

Cool titan, Dark_Tundra! I will definitely include it in my graphics files ASAP. I'll see if I have the same problem, but it's very unlikely.

[Impaler[WrG]]

DF does loop through the entire item vector at least once every frame, although it clearly does not load the full item information for each item every frame.

Wow why am I not surprised    This explains why having several thousand stone present in a fortress totally kills the frame rate, theirs an update on every single inanimate piece of stone every turn, probably every tree and shrub too.  A lot of the slow down that people assume is from pathfinding might actually be from items.  A sensible solution would have been to put inanimate objects on a separate vector and not loop over them every constantly as they can only be modified by some outside action.  Other objects that might be subject to self-directed decay or growth could be on separate lists that get update periodically like once a day.  Only creatures and other constantly active objects need to be looped over every single frame.  And that's just game logic, rendering shouldn't be checking anything outside the viewing frame ever.

[Footkerchief]

A lot of the slow down that people assume is from pathfinding might actually be from items.

Well, that's been known for a while.  But yeah, it's alarming that it's doing that much useless work, and separate lists are a must.

[kaypy]

Perhaps someone can shed some light on what I've done wrong...

Yep, that looks like a problem with alpha. Make sure you are using a magenta background.

DF does loop through the entire item vector at least once every frame, although it clearly does not load the full item information for each item every frame.

Oww. So much for a better way to do it...

I read several pages trying to find an answer. . .  but the thread is rather thick. Anyway, i am running windows 7 64 bit.

I think the 64-bit-ness will be altering the memory layout, so it no longer looks like DF to the access library. Might be worth looking to see if theres anything about it over on the DFHack thread.

[Impaler[WrG]]

Well, that's been known for a while.  But yeah, it's alarming that it's doing that much useless work, and separate lists are a must.

I Don't think its very widely known, I hear much more blame given to Pathfinding probably because people very easily notice Pathing induced 'lag spikes' when Idle dwarves all rush out of the fortress or an army is invading while item induced slowdown increases more gradually and doesn't cause spikes.

[Khalan]

I read several pages trying to find an answer. . .  but the thread is rather thick. Anyway, i am running windows 7 64 bit.
I run DF and get to the game play screens. Then i run Stonesense. After hitting 'F9', it tells me it cannot find a DF process. . .  any ideas or. . . ?

No problems here running Windows 7 64-bit and Stonesense.
If you have Stonesense or DF installed in C:\Program Files(x86), that may be why it's not working as this area is protected by the OS.  Try installing in a different folder.

DF does loop through the entire item vector at least once every frame, although it clearly does not load the full item information for each item every frame.

Oww. So much for a better way to do it...

If that is the way Stonesense will also need to do it, maybe it would be possible to set the object update to only run every x seconds independent of the auto reload rate to avoid too much performance loss if necessary?

[Dark_Tundra]

Dark_Tundra: Alpha channel or magenta for transparency?

It's magenta, I was under the impression that stonesense does not support alphas.

I read several pages trying to find an answer. . .  but the thread is rather thick. Anyway, i am running windows 7 64 bit.
I run DF and get to the game play screens. Then i run Stonesense. After hitting 'F9', it tells me it cannot find a DF process. . .  any ideas or. . . ?

Looks like a magnifigo program. wish i could get it to work.

I had that problem, try ticking "run as administrator" on the shortcut/executable.

[Jay]

I think the 64-bit-ness will be altering the memory layout, so it no longer looks like DF to the access library. Might be worth looking to see if theres anything about it over on the DFHack thread.

Absolutely not.  It changes the way it addresses the memory.  Besides...
32-bit compatibility mode is (nearly) flawless.
It works fine for me.
The problem is more likely to be UAC.
Run Stonesense as an administrator.

[Lord Nightmare]

Well, that's been known for a while.  But yeah, it's alarming that it's doing that much useless work, and separate lists are a must.

I Don't think its very widely known, I hear much more blame given to Pathfinding probably because people very easily notice Pathing induced 'lag spikes' when Idle dwarves all rush out of the fortress or an army is invading while item induced slowdown increases more gradually and doesn't cause spikes.

This is a bit offtopic, but a dfhack tool to auto-purge useless stone would be awesome for quickly nuking lag... but we can't yet determine stone types from a pile i don't think... Once thats done we could make it insta-nuke all the useless rocks.
Or maybe transmute them into something useful like bauxite...

LN

[Impaler[WrG]]

Nuking objects from DFHack sounds very very hard to do without corrupting DF itself, DF has a habit of storing multiple pointers to things in all kinds of places which will multiply the chances of a Segfault enormously, I seriously doubt it's going to ever be possible to do what you describe.

On a related note I was just having a brainstorm on how to best implement the reduced updating I was speculating on earlier.  I had at first said theirs should be separate lists for inanimate and infrequently updated objects.  But on further though this could cause clump all the updates for the list together resulting in a lag spike, also its not very flexible, you'd need to re-write it with a new list for each type of item.  I'm thinking some system which dynamically puts items into buckets based on a 'cooldown' time they report back when they update.  Each cycle the bucket counter gets decremented until it reaches zero then all the items update and the bucket counter is reset and if necessary some items could be moved to different buckets (say if an object switches between a frequent/infrequent updating state).  Thoughts??

[kaypy]

I'm thinking some system which dynamically puts items into buckets based on a 'cooldown' time they report back when they update.  Each cycle the bucket counter gets decremented until it reaches zero then all the items update and the bucket counter is reset and if necessary some items could be moved to different buckets (say if an object switches between a frequent/infrequent updating state).  Thoughts??

At least initially, I would be thinking something pretty simple: Have a configurable option for 'number of items to update each frame', and store how far through the item vector we have scanned. Keep going each frame until we reach the end, and loop back to the start.

It depends a bit on how DF handles its items though: does each item get a fixed point in the vector? What happens when an item is destroyed?