Print

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

Faster than 40d, no problems

42 (26.1%)

Faster than 40d, problems

72 (44.7%)

No slower than 40d, no problems

14 (8.7%)

No slower than 40d, problems

16 (9.9%)

Slower than 40d, no problems

2 (1.2%)

Slower than 40d, problems

3 (1.9%)

Doesn't work (please explain)

12 (7.5%)

Total Members Voted: 160

[tdittmar]

I can see how /that/ code would cause trouble. But the thing is, that commit's post-d13; d13 corresponds to commit b2dfeec69a0a19da9c77bb4350d3eebdb0c795c8, two days earlier.

Also, I later fixed the one bug in that commit that I could see causing this, but I could have missed something. Still, you may have been using an outdated 40d13-head; since you've got the git bit downloaded anyway, checkout master and see if the newest version still has the problem.

That aside, are you sure plain, non-head 40d13 still has the problem?

Hi Baughn,

plain 40d13 does not show this problem.
Only the 40d13+head versions after 478359cfd0b0634bdf2ee2a76aed2833e78ca9e0

I was allways refering to the 13d40+head version.

I re-read my first post and it is a little bit ambiguous due to the space between the '40d13' and the 'head'. Sorry about that. I think later mentioned it a few times that I run head, but did not make a clear distinction between 40d13 and 40d13head. (This is mainly because I consider plain 40d13 broken and unusable due to  the designation/mouse bug and did not consider to test plain 13d40 further)


Nevertheless, I still find the error both in the the latest version I can get from github (which is :1f0219def8acb057d733a891e42f023197948d22 Add -mfpmath=sse to optimization flags)

and also from the head version provided in this thread (head version: today 13:xx).

Hoping that I did not create to much confusion and useless work and that everything is a a little clearer now,

Timo

 

[virus_found]

I've just compiled it again from the latest commit (1f0219de). And that freeze-while-unpaused bug ceased to exist! Interesting I've made few updates in that period of time, maybe it's after libelf (0.8.10 -> 0.8.12) update? *shrugs*
EDIT>
But symbol-flickering-when-mouse-moves bug still exists (for modes other than STANDARD and VBO, as I already mentioned before in the issue tracker):
406255e0e (COmpile with -march=pentium3) - WFM
bc6415246 (A variety of changes to rendering and zoom blahblahblah) - broken

[Baughn]

There was some memory corruption in.. well, probably d12 and up, that caused graphical glitches and occasional crashes. Those are now fixed - if DF has been crashing for you, go get d13-head.

[tdittmar]

There was some memory corruption in.. well, probably d12 and up, that caused graphical glitches and occasional crashes. Those are now fixed - if DF has been crashing for you, go get d13-head.

Ok tested head from 14:July 17:14, same procedure as every time: no screen update, while unpaused, flickering mouse movements.

Am I correct that the newest changes are not yet (17:20) on github, or is there a problem on how I use git?

I've just compiled it again from the latest commit (1f0219de). And that freeze-while-unpaused bug ceased to exist! Interesting I've made few updates in that period of time, maybe it's after libelf (0.8.10 -> 0.8.12) update? *shrugs*
EDIT>
But symbol-flickering-when-mouse-moves bug still exists (for modes other than STANDARD and VBO, as I already mentioned before in the issue tracker):
406255e0e (COmpile with -march=pentium3) - WFM
bc6415246 (A variety of changes to rendering and zoom blahblahblah) - broken

Mhh. Interesting. I still have both problems, even with 1f0219de....

Dwarffortress does not use libelf (according to ldd, not sure if it creeps in at some other point.)
What else did you update?

Does anybody know an easy way to get the actual version (not just major version) of all the libs df uses? Then we could compare the versions and see if that sheds new light into some dark, dusty corners.

Timo

[tdittmar]

OK. There it is.

I pulled newest version from github, still same problem.


Timo

[Baughn]

Well, yes, the fixes fixed memory corruption issues, not your glitch.

There was a bug at one point that would cause exactly the behaviour you're seeing; I noticed, and fixed it pretty quickly. To make sure, though:

run scons -c, and make sure libgraphics.so is deleted.
Check g_src/enabler_sdl.cpp; make sure that there's a mention of do_render in there somewhere. Just grepping it is fine. I added that variable to fix said bug.
Run scons again.
Run df. See if the problem is still there.

[Deon]

Ehm, I have a weird problem with ">". It's working when I change z-level down, but I can't use it to enter a location on adventure map. Which bind option is it?

[Baughn]

Deon: Sorry, can't help with the keyboard stuff, but Veroule will probably be along eventually.

Others: I've fixed the graphical glitches associated with moving the mouse (or zooming) in partial-printing mode; have a look. d13-head, again.

[Baughn]

Frame-buffer mode is currently broken, in d13-head at least.

Now, I could fix it, but only at a (very slight) performance cost in the other modes.

Therefore, question: Was frame-buffer noticably the fastest mode for anyone, when comparing to modes including VBO?

EDIT: ..is what I'd like to ask, but VBO does /not/ turn on partial-printing right now. It should. Hmm.

[virus_found]

Others: I've fixed the graphical glitches associated with moving the mouse (or zooming) in partial-printing mode; have a look. d13-head, again.

Yes, I can't see those glitches with PARTIAL now. Yet, there are some screen flashes from time to time when moving mouse, but they become minor now.
But that bloody freeze bug happens again -_- I'm sure it depends on something different, that just a code issue. System libraries are involved for sure.

[Baughn]

I noticed the flashes.. they should not be happening either.

I'll squash them soon enough. *sob*

[tdittmar]

• run scons -c      -> checked
• and make sure libgraphics.so is deleted.   -> checked, not a bit left
• Check g_src/enabler_sdl.cpp; make sure that there's a mention of do_render in there somewhere.  --> checked, found it a few times. I did not try to understand the code though :-)
• Run scons again.  -> checked, no errors but a few screens of warnings about deprecated conversions from string constant to 'char*' in keybindings.cpp - maybe this will be a good starting point for the next input handling error :-)
• Run df. See if the problem is still there. -> checked, still very  close to 0 Kelvin when the game is unpaused.

There has to be a system component/ compiler component since Baughn can not reproduce this freeze in his build environment.

Unfortunately my two day vacation ends tonight, so my answering time will definitely increase.

Timo

[Veroule]

Ehm, I have a weird problem with ">". It's working when I change z-level down, but I can't use it to enter a location on adventure map. Which bind option is it?

A_END_TRAVEL, the text description in the bindings view is "Adventurer: Travel, Visit Site".  Changing it to something else that is not used in the the travel screen does work.  Also it should be fixed for the D14 version.

[Baughn]

The latest d13-head now has Veroule's input fixes, as well as mine for various graphical glitches.

Overall, frame_buffer and single_buffer are the only broken bits, and I'm pondering the proper fix for the former. (The latter is a very simple fix on toady's part, but must wait for d14.)

In any case, I'd appreciate input on how this works.

[Michael]

One other bug with zoom (which I noticed early, but didn't notice as a bug until I thought it through).  If I use the mousewheel up, the display zooms out as expected.  But if I use the mousewheel down, it doesn't zoom in -- rather the display simply shrinks.  The gridsize decreases while the font size is approximately constant.  (Some steps are crisper than others.)

Also, I have a follow up to the F12 not snapping to a crisp view.  While tinkering with my configuration file, I realized I had FULLGRIDSIZE incorrect.  My font is 9x16 and my display is 1400x1050.  1400 / 9 = 155.555 and 1050 / 16 = 65.625, so the correct gridsize should be 155x65.  But when I input the corrected value, I got scaling artifacts.

Going back to my earlier value, 154x65, was perfectly crisp.  So perhaps F12 is correctly snapping to 155x65, but another bug causes distortion at that setting.  This other bug can apparently be suppressed by claiming one less column than ideal.

(Side note: check out my post "Multiple Fonts" in the suggestion forum.  It's a suggestion for the output code, but I've seen no comments from the people here.  Just some me-toos and one person chiding me for being too candid about my opinion of zoom as presently conceived...)