OK, Q&A time.
@Full map screenshot: The reason it takes so long is because all of the images are stored in video ram by default, and writing from video ram to system ram (as happens when you take a large screenshot) or vice versa, takes a very long time. When all of the textures are in system ram, as will be an option in the next release, it will go far far far faster. (took me about 20 seconds)
Stonesense needs some optimization love. Actually, a lot of it. I did it for the previous release, but don't have time for messing around with it right now. I do have some ideas on what to do though.
Sorry, my fault. I'm a freaking noob here... >_<
First, why the hell do a few sprites eat up so much memory that it doesn't work with integrated intel graphics? Does it load everything and then generate how each sprite looks for every single material? That would be most unfortunate and in dire need of replacement with a sprite cache with garbage collection.
No, no new sprites are generated. The main cause of problems is not, in fact, the video memory reqirements, but OpenGL. Microsoft doesn't seem to like it, and so most onboard drivers that come with windows have shitty OpenGL support.
The only reason OpenGL is currently default is because the version of allegro being used for this release has drawing issues in DirectX. These are fixed in the next version, so DirectX will be the default, and there will be a software option as well. (but this one is kinda slow)
Second, that whole-map-screenshot. As you said, it should piece it together from smaller parts. 20 hours is just too much ... hell, my browser can display that whole thing without any lag, it shouldn't take so long to generate.
20 hours will be a thing of the past, thankfully.
The problem with peicing it together from smaller parts is that... hmm.... it's doable, actually, but I'm hoping after the next release it won't be needed.
Third - DFHack is not used effectively, and when the SDL merge hits, it will become even more apparent. Input code should be decoupled from display and maploading from everything else, by using a double-buffering scheme with DFHack being used in a thread. Everything should be as >ASYNCHRONOUS< as possible.
And there are probably heaps of other things that could be optimized... I would have to dig into the codebase.
Input code
is decoupled from display, other than the arrow keys, which don't need to be, and the mouse, which should be... I'll go ahead and fix that.
As for making the rest of the stuff asynch, like I said, I
m a noob programmer that doesn't know how to do mystical threading voodoo
I'm just wondering how I can tell if content in the repository is compatible with the new release, or if it should be by default.
Yea I don't think much is compatible out of the box on the repository yet. From what I've seen for creatures though it's usually just a simple find and replace job to make them compatible. Go to the content's xml file and wherever you find 'sex="F"' replace it with 'sex="1"' Find sex="M" and replace that with sex="2"
It won't have the new jobs yet but they should just put in whatever the maker set up as the default sprite if it can't determine the job.
You don't need to do that. sex="M" and sex="F" still work fine, the numbers are only for if you have castes.
it's the jobs that are the issue, and you can use DFhack to get a list of valid ones. (or convince Jonask to include the lob list in the next release, I don't know why he took that out)
I want to take world map
No.
Poll
Author
Topic: Stonesense - Old Official thread - Now locked (Read 1729538 times)