Print

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

[Lagg]

I didn't even want to make a bug on the tracker for this yet, because I'm honestly not sure if this is just something I've caused (though nothing in the config files would do it from what I can tell). Whenever I start the game I'm finding that the window moves 50 pixels or so diagonally downward from where I had it last time I played. Naturally this is annoying as I have the window large but not too large so I can multitask while playing, so I can't do fullscreen either. Has anyone else had this problem, and if so could you workaround it?

Apologies for posting it here if it wasn't appropriate but it seems that the bug section is locked now and there are no other sections for questions.

[lazygnome]

This is a function of Windows (assuming that's what your OS is).  Paint, Minesweeper, etc also do this.

[Wellincolin]

This is very likely a problem with your Operational System.
What OS do you use? 50px down every time you RUN the game or minimize it and restore?

If the answers are: Windows and run, I seriously recommend you to get over it, because windows problems are a pain.

Alternatively, you can backup your important things and download a new client. If this doesn't solve, it's clearly a problem with your operational system.

[Lagg]

99% sure this isn't Windows itself as I wrote something using the Windows API just a few days ago. I did try a fresh copy of DF but no luck. I can't remember this happening before 0.34.11, but then this is the first time I'm adjusting the window size in the config from something larger than 80x25 tiles, so maybe it's just more noticeable now.

I might not be explaining it properly. What happens is I start the game, and let's say it's at the top left corner of the display. I close it, then immediately start it again and it is now slightly (but noticeably) moved further left and down from the top left corner. This happens more and more each time it's started, so that after 3 starts or so, if I don't manually move it back it starts to go off the display.

[knutor]

You explained it perfectly fine.  Happens here, too.  Windows can't remember where it last put windowed, DF.  I prefer windowed DF, this is not a problem for peoples who play fullscreen.

I was also told here when I asked, last year, that it was Window's fault.  But the odd thing is, none of the other windows do it.  Just DF.  Dwarf Therapist, Eudora and Opera reopens where I last closed it.  Not only do they work, they also reopen at the same size.  DF doesn't however. 

I think it has something to do with the game, and not Windows to be honest.  If it were Windows there would be a fix.  Good question, I'm listening to this to get an answer too.  It is annoying to keep moving DF, each and every restart. 

I think in order to make it crossplatform compatible, some frills had to be snipped.  This prolly was one.  Doubt we'll get an answer.  *fingers crossed*

[Lagg]

Indeed, I'm not sure where people are getting the idea that it's Windows itself. There is really no reason for it to be like this except for a bug in the window creation code somewhere if he's storing window positions or they are otherwise not static, because for SDL creating a window is as easy as a function call with four arguments. Them being horizontal offset, vertical offset, width, and height. I'll poke around a bit if I get some time. I would really like to see if there is a workaround.

[pixl97]

>Whenever I start the game I'm finding that the window moves 50 pixels or so diagonally downward from where I had it last time I played

From everything I see DF stores no windows position in the registry, so the window position is being placed by Windows. Open your CMD prompt, now open another copy, and another. Exact same behavior. This is not a bug*.

Something along the lines of this may help you. http://stackoverflow.com/questions/7977322/set-the-window-position-of-an-application-via-command-line

*As to why Toady didn't add code for this... It's different on each platform, and possibly operating system releases. Also, when you save position code you run in to the issue of people closing the game when it is off screen, then it reopens off screen.

[Lagg]

We know that it is a standard behavior in Windows, but there is a reason only some programs do that. cmd.exe is poorly written in various ways in the first place so may not be a suitable example. Remember that a bug is unexpected behavior, this is certainly an example of that. Regardless of system that it's running on, and regardless if it's actually saving them. There should always be a sane default for window positions when creating them.

http://wiki.libsdl.org/moin.cgi/SDL_CreateWindow (I'll wager that DF uses the undefined position flags.)

As you can see it's a fairly simple matter to create a window with SDL, and most if not all of the other programs I've ran that use it have some sort of position management. Including things I've done myself in the past. In any case I'm going to see if the usual environment variables work here.

Edit: Well, I can't remember them and there are no references still working. I guess we wait and hope that toady doesn't use SDL's constants and instead gives us a few config lines for positions. Of course I'm making a lot of assumptions here, seeing as I haven't actually read any of its code. Also I'm pretty unfamiliar with Vista and 7's new WM stuff. It's the only thing I can think of though. I'll just try out fullscreen for a while. I alt-tab to Dwarf Therapist just the same. Not too big of a deal.

[Trif]

If it's an SDL problem you could ask Baughn about it, he ported DF to SDL. Does the problem occur in the Legacy version of DF, too?

[Lagg]

I wouldn't think so. The legacy version just writes characters to the terminal emulator it's ran in rather than making a GUI.

[pixl97]

If it's an SDL problem you could ask Baughn about it, he ported DF to SDL. Does the problem occur in the Legacy version of DF, too?

Legacy appears to open at the 0,0 position of the operating system each time.

The SDL version appears to be using the same functionality of cmd.exe, with cmd this functionality can be disabled by right clicking the cmd window, click on properties, click the layout tab, and uncheck 'let system position window'.

[knutor]

The SDL version appears to be using the same functionality of cmd.exe, with cmd this functionality can be disabled by right clicking the cmd window, click on properties, click the layout tab, and uncheck 'let system position window'.

Yup, good to know.  Thanks for sharing how to do it in CMD prompt. Never knew that.  Looks to be the same in other shells, too.  Like Windows Powershell, maybe this is the typical location to fix it, except DF hasn't got these settings it appears.

It does have some compatibility tweaks, which doesn't free up window positioning.  I've just tried all three of the compatibility checkboxes:

Disable vis themes
Disable desktop comp
Disable display scaling

Back to drawing board.

[Quietust]

I wouldn't think so. The legacy version just writes characters to the terminal emulator it's ran in rather than making a GUI.

You have no idea what you're talking about - the Legacy version uses OpenGL to render its graphics to a custom window (and has been that way ever since the very first Dwarf Fortress release over 6 years ago). The only version which can output raw characters to a terminal emulator is the Linux version when using [PRINT_MODE:TEXT].

[edit] I've just checked a disassembly of both 23a and 40d, and they both call CreateWindowEx() with the 'x' and 'y' parameters set to 0 (i.e. upper-left corner of the screen), and version 0.34.11 is letting SDL create the window, which likely passes CW_USEDEFAULT for both (which would cause the behavior you see in many other programs).

[Lagg]

You have no idea what you're talking about

Ouch

I'll assume you have something to contribute besides throwing insults, but it is pretty funny that you insult my intelligence then proceed to look at a disassembly to confirm something that was both already mentioned above and can be inferred by looking at SDL's function definitions for Windows' windowing stuff. I'll give you that.

- the Legacy version uses OpenGL to render its graphics to a custom window (and has been that way ever since the very first Dwarf Fortress release over 6 years ago). The only version which can output raw characters to a terminal emulator is the Linux version when using [PRINT_MODE:TEXT].

[edit] I've just checked a disassembly of both 23a and 40d, and they both call CreateWindowEx() with the 'x' and 'y' parameters set to 0 (i.e. upper-left corner of the screen), and version 0.34.11 is letting SDL create the window, which likely passes CW_USEDEFAULT for both (which would cause the behavior you see in many other programs).

I've never actually used the legacy version, but it seemed like a good educated guess given the past posts I've seen where toady mentions having to switch over to using the sprite method despite not wanting to. Oh well.

and yeah the undefined constants in SDL are basically doing that for Windows if I recall correctly. No idea what it does on systems running X.

Edit: Well, saying I haven't used it might not be entirely accurate. But there was a time when someone first pointed me to DF, and I wasn't interested. (As crazy as that may sound) It would explain a few things though, considering my primary system is one running linux. These days not so much.