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

[Baughn]

What?

Why would you *want* to see the cursor, if you're not using it?

[Vicomt]

I've found this as well.... I tend to use a lot of mouse designation, and while I'm thinking about the next bit of designation, the mouse cursor disappears, I assume timing out. when I move the mouse to designate again, it recenters to the middle of the screen and I have to move it to where I want it again.

at least I think that's the same problem Bacu's talking about

[edit] it actually happens after you use a keyboard command or two, not a pure timeout

[Baughn]

Right. It disappears after (a) some seconds have passed, and (b) you press a key. This way, it doesn't get in the way.

I could increase the timeout, if you like.

[quinnr]

Running wonderfully. gives me 5-10 more frames in general, 25 more when I'm not looking at any dorfs.

Though, would it be too much to ask for the cursor to not be hidden if I've got mouse controls off?

Agreed.

[Xandrin]

Hello,

Just tried 40d16 out today and found an issue.  It seems to be improperly loading some tiles.  I am using a custom-made tile sheet, and I am getting tree tiles in my rocks, musical notes for creatures and other scrambled tiles.

My tileset is an amalgam using Sphr's set as a base, and it seems to work fine in 40d.

I've uploaded a copy of my tilesheet for your debugging pleasure.

Spoiler (click to show/hide)

[Footkerchief]

Xandrin -- what you uploaded is a JPEG.  Did you convert to JPEG when you uploaded it, or is the tileset itself a JPEG?  If so, that would probably cause problems, as JPEG is not supported (because your sprites get filled with crappy artifacts).

[numerobis]

Right. It disappears after (a) some seconds have passed, and (b) you press a key. This way, it doesn't get in the way.

I could increase the timeout, if you like.

I'd vote to either leave as is, or have it be an option to leave the cursor always on.  The cursor just gets in the way, and lots of programs hide it under the same conditions you use.

[Footkerchief]

Bug report concerning a problem that's apparently unique to the 40d# branch:

Found another crash:
Under Win7, crashes on "View thoughts and preferences" when the window's width approaches 1680.

I have 2 monitors, one @ 1440x900, the other at 1680x1050.  On the smaller, with DF maximized, I have no trouble using the above menu. On the latter, if the window is wider than 1600 px, DF will lock (narrower windows do not crash).

Height does not appear to have an effect (up to 1050).

However, if there's spillover between the monitors, there's no error regardless of the width of the window.

At present, I've the most recent Catalyst drivers

Viewing an artifact's description will trigger a crash under those same conditions.

Could you see if this also happens on your machine in 40d?

No issues using 40d.  Ran that at 1680x1020 (had to manually set a grid of 210x85).

Since 200 is the supposed max dimension for the grid, and that occurs at 1600px (given the stock tileset), it could be that the grid auto-resize code is setting a resulting grid width of 210, which the code that displays a simple "block o' text" craps out on (expecting a max of 200).  All of the menu locations I've had issue with output that same "block o' text" style window.

[TBeholder]

One more tip for those who don't know such tricks already: [PRIORITY:NORMAL] may be good for Windows, but if you want DF to run smoothly without resource hogging on Linux, you may need in your df (shell script file) something like

# ./dwarfort.exe $* # Go, go, go! nice --adjustment=8 taskset 02 ./dwarfort.exe $* # Go, go, go, just don't grab all the CPU!

nice drops priority, or taskset sets CPU affinity for machines with several processor cores.
In my case, both nice and taskset are used, because i lock Xorg in CPU-2 too (my driver has a healthy appetite). DF and Xorg run there without having any noticeable impact on anything, while CPU-1 is left for system and mundane tasks. Good PRINT_MODE is still very adviseable, of course.

[quinnr]

One more tip for those who don't know such tricks already: [PRIORITY:NORMAL] may be good for Windows, but if you want DF to run smoothly without resource hogging on Linux, you may need in your df (shell script file) something like

# ./dwarfort.exe $* # Go, go, go! nice --adjustment=8 taskset 02 ./dwarfort.exe $* # Go, go, go, just don't grab all the CPU!

nice drops priority, or taskset sets CPU affinity for machines with several processor cores.
In my case, both nice and taskset are used, because i lock Xorg in CPU-2 too (my driver has a healthy appetite). DF and Xorg run there without having any noticeable impact on anything, while CPU-1 is left for system and mundane tasks. Good PRINT_MODE is still very adviseable, of course.

THANKS! I was wondering how to do that in Linux!

[Baughn]

You pretty much don't need to do that in Linux.

The Linux scheduler is much clever than windows' one, what with actually accounting for the cost of switching a program between cores. Nice is, well, nice - but taskset is more for preventing malicious behaviour than for performance.

[gr0gmint]

Can I kindly ask why it needs to hog up ~50% CPU when the game is on pause, or it's idling in the menu?
Is it some main game loop, that just has to run all the time? 

[Footkerchief]

Can I kindly ask why it needs to hog up ~50% CPU when the game is on pause, or it's idling in the menu?
Is it some main game loop, that just has to run all the time? 

Did you raise your FPS cap to something really high?

[Baughn]

Legacy interfaces in the code. A lot of that may be getting cleared up now, as the interface changes going into d17 required Toady to rework them anyway. I haven't actually checked yet, though.

[quinnr]

You pretty much don't need to do that in Linux.

The Linux scheduler is much clever than windows' one, what with actually accounting for the cost of switching a program between cores. Nice is, well, nice - but taskset is more for preventing malicious behaviour than for performance.

That's alright, I've only got one core...I was talking about the Nice part.