Print

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

Higher speed, no problems

Higher speed, problems

Same speed, no problems

Same speed, problems

Lower speed, no problems

Lower speed, problems

[kenji_03]

I booted this up in windows and compared the exact same save file to each other.  The only changes I made to the Init files of DF 40d and your 40d16 were to turn FPS on and sound off (to maximize frame rate).

At the default resolution I was getting about 60-80 FPS on windowed with DF 40d.  Your 40d16 got me around 120-170FPS windowed.

It wasn't as drastic a change when full screen though.  I'd get about 50-70 on DF 40d and 80-100 on your 40d16.  So it works good on windows Vista 32 bit.

I'm running Ubuntu and want to test it out on my linux machine, so since there is not an official DF 40d for linux (I think our first was 40d3) what version should I compare to for linux machines?

Also, do you know of a linux OS that runs DF better than ubuntu?

Edit: I think this next problem is more a DF probem at large.  When resizing the window (it covers 1/3 my screens height, but it's entire width) to something close to square as opposed to rectangular, it slows down considerably.

[cooz]

Hey,
i have some kind of zooming problem,
i'm using 16x16 charset (1280x400) on 1280x1024 monitor resolution, when i start DF everything's ok, but after i move its windows (which i have to do cause half of it if not visible) there's some effect similar to jpeg enlargement or something - pixels aren't sharp but somehow blurred...

Is it possible to force zoom to stay turned off, or maybe init.txt parameters setting window x/y position so i won't have to move it.

[CobaltKobold]

change the texture setting from LINEAR to NEAREST, it might help keep things sharp. It shouldn't be zooming if you're just moving the window- resizing though..

[Baughn]

There are absolutely no code paths that trigger if you move the window; there is therefore no way that should, or could, trigger a bug that would cause unsharpness.

Try pressing F12, though; that will force a zoom reset to 1:1, and incidentally recalculate the black space. I can only see your description as being a window system or driver bug, but that doesn't mean it can't be worked around; if pressing F12 helps, then I could simply make DF do that automatically every time the window is moved.

[Gorjo MacGrymm]

Well, my asking for advice wasnt necessarily concerning my browser, but i am grateful for the information presented.

I was actually hoping for some information on my still having a problem with my mouse designating things exactly 10 places "south" of my pointer.

As I saw in Baughns d15 presentation, that was supposedly fixed, but I am still having that issue.  I finally got onto the bugs list page, didnt see anything.

So, any advice......about my mouse problem?  (this isnt an invite to say "CATS!")   

[CobaltKobold]

Well, when you move the window, it needs to redraw, period. There may not be code paths through YOUR code triggered, but the window needs to update, so it needs to re-blit.

Actually, I think I just figured out why it does the blanking thing- it ISN'T going through your code(I speculate), but it's clearing (for some reason or other) and the last memory the graphics modules have is of an only partially-updated frame. Therefore, when the code is deciding what to put up when no signals have been sent to DF to update, it just puts that up and nothing else, and DF doesn't redraw because it's none the wiser.

So yeah, while f12-ing each move is probably not the best idea, forcing a (real) redraw might be, as I can imagine a window manager sending the signal to clear and assuming that it would take the hint and redraw. (Or, just figure out how to actually get the refresh to path through your code )

[cooz]

Sorry for interference, but it's quite weird thing, yesterday i was restarting DF more than 10 times with different init settings trying to get rid of this.

And today it's all sharp and clear, and i don't have a clue why. Maybe it's because windows 7 has borders quite thicker than good old xp and it's trying to fit whole window on screen - but hey, it's still release candidate, who knows...

Al least if this happen again i have couple more ways to fix it


EDIT:

ok, i got it again, on idea what triggers it >_<

F12 doesn't do much, changing [TEXTURE_PARAM:NEAREST] do the trick - but there are few "missing lines of pixels".

It looks like DF can't set right tiles size cause window got horizontally narrower,
it's size without borders is now 1276 px. I can shrink it more but there's limit on making it wider - is OS or program itself limit?

[Baughn]

DF itself does not limit window size in any way, so it's the OS.

From what you're saying, the OS is changing the window size - without informing DF of the fact. That's not going to work. Hm, what happens if you then jiggle the window size a bit - resize it yourself?

(I am, of course, assuming that you have black-space on. You do, right?)

CobaltKobold: No, the window doesn't always need to be redrawn when it's moved. In some cases (compositing window managers, etc.) that's unnecessary, so I don't do that; instead, I'm more properly using the event hook for the windowing system telling DF that it needs to redraw.

Which would be fine and all, except the force-redraw code doesn't work. 

[Baughn]

Having the mouse off by that much should be impossible. Can you screenshoot the DF window? I might notice something.

Also, is it off by the same offset in all areas of the window? What about the top/bottom?

[cooz]

Yes, black-space is on,
i can resize window, but not to initial horizontal width, it must be some stupid windows 7 size restriction, as with smaller tileset (for example 14x16) everything's ok.

Could you add somewhere parameters to set initial window position to eg: x:0, y:0? As it's only solution i can think of for fixing it.

[Whitney]

When I die in adventurer mode, I am unable to press ESC to "finish". I must CTRL-ALT-DEL out.

[Michael]

Heads up, I've submitted a more limited version of my multi-font request to DF Suggestions (Alternative font for...)

On another point, is there any hope in 40d# of fixing the problem that certain in-game menus won't use the full vertical gridspace available?  For example, the labor-preference toggles are always split into five pages so as to fit a 25-line screen, even when there are far more lines than that actually available.

[Footkerchief]

On another point, is there any hope in 40d# of fixing the problem that certain in-game menus won't use the full vertical gridspace available?  For example, the labor-preference toggles are always split into five pages so as to fit a 25-line screen, even when there are far more lines than that actually available.

No, those won't be fixed by a 40d## release.  Toady has to rewrite the menus.

[Angellus]

I do not know about you all, but the d## versions all seem to have a bug on fist boot, they never boot for me, only if I reopen the same .exe several times.
Even that is not working for me anymore, does anyone know what to do about this?
(I have a d14 version that seems to work fine, same problem, but it booted after several times, all the games log can tell about this is ***Starting new game***)

[Deon]

Excuse me, I've noticed someone used a huge version of tiles (64x64) so I tried to set up the game this way, but I am obviously missing something.

I've resized the tileset to 64x64, but I still cannot zoom with mouse more than it was possible before. Where do I define the maximum tile size possible or something?