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]

Is that so? You're sure it's the drivers?

I suppose I'll have to test that for myself once I find a windows machine, but it sounds rather odd on the face of it. The window is created before any opengl calls are made (obviously); thus, a problem with the drivers shouldn't really affect the window creation.

I wonder what they're doing this time.

[Baughn]

Toady's planning to release 40d15 sometime over the next three days (maybe), and I've just finished a marathon session to fix (or, in one case, paper over) the outstanding bugs.

So, to make sure I don't forgot any (there may still be time to send him patches), here's a list of what I've fixed. If something isn't on this list, I've forgotten about it; be sure to tell me.

Also, all the fixes below are available in the latest 40d14-head, for those of you on linux; be sure to test.

Fixed
- Aspect rate not being maintained when resizing to a very small window, even if black_space is on.
- FP inaccuracy sometimes making it impossible to reach 1:1 zoom using the wheel. (F12 always worked)
- Flickering when moving the mouse over the window in some rendering modes. This is a manifestation of a deeper bug, which I have not fixed; as a result, it will still flicker if you are using viewport (not standard grid) zoom.
- Screen not refreshing under load. Very fixed.
- Mouse not registering correct position for designations under some circumstances. Code rewritten from scratch.
- 800x600 tileset looking squashed. Fixed by having toady double its height. 1:1 aspect ratio is the only one supported now, and probably always.

Not fixed
- DF window not showing up at all on some windows configurations. Still haven't reproduced that one.
- Global tension between the secular world and religious sects. Will have to research genetic engineering first, do some experiments.
- ESC key registering extremely slowly in adventure mode. Complain to Veroule if it's still in d15, it's out of my hands.

[Mike Mayday]

- Aspect rate not being maintained when resizing to a very small window, even if black_space is on.

Hey, my aspect rate isn't maintained even just after I start the game. (in d14 that is)

[Pato2747]

I think I forgot to say that I am currently running on a 32-bit Windows XP - I'm not sure whether or not that helps in the troubleshooting, but as I have noticed with QuinRiva's post it seems that the bug affects both 32-bit and 64-bit Windows computers.

[Baughn]

- Aspect rate not being maintained when resizing to a very small window, even if black_space is on.

Hey, my aspect rate isn't maintained even just after I start the game. (in d14 that is)

That happens if the minimum resolution for your selected tileset (with an 80x25 grid, that is) is larger than the initial window size.

Or if you use the "800x600" tileset. See the fix list for that one.

[Mike Mayday]

Well, but shouldn't it NOT be happening?

I'm playing with a 64px tileset. The game starts in fullscreen, with resolution set to 1280x1024.
Instead of 80x64 however, the initial tilegrid size is 80x25. No matter if I enable blackspace or not, the display is vertically stretched to the whole screen, so I don't get square tiles.
Once the game starts, I scroll the tilegrid until the tiles are square. Since it takes quite a bit of scrolling I usually go further than 80 tiles horizontally. Once I scroll back to 80, I can't go further- the tiles remain square as it should be- which means the algorithm to calculate proper tilegrid IS there and it's working, it just doesn't fire up initially.
Pressing F11 sets the tilegrid back to 80x25, which is an additional annoyance.


So my two biiiiig requests:
-make the game properly calculate the initial tilegrid size to retain aspect ratio
-allow for larger zooming increments (preferably 200% with one scrollwheel move).

[jaked122]

This makes me curious. What do you run? You seem like a tiling WM person to me.

XMonad, reasonably reconfigured. I don't believe I have any graphical file managers installed, but if I did, I wouldn't know how to start them.

As you'll find out if you hang around me long enough, I'm a big Haskell fan.

haskell eh?
how does that work, I know it's functional, lazy interpreted and fairly concurrent, but I can't ever make it work

[Baughn]

Mayday:

- I already fixed the aspect thing. It's on the list. However, that's assuming that your "64px" tileset is in fact 16x16, and not the 8x8 the 64px figure woudl require; that's the only thing that fits with your other numbers. If it isn't, then there's another bug somewhere.
- I've asked Toady to make the zoom factor configurable. We'll see what he does. Personally, I'd think 200% was way too much, so it can't be hardcoded.

jaked122:

Look me up in IRC sometime; freenode, rizon or #bay12games, and I'll try to give you some hints. I've got the same nick there. Or just show up in #haskell on freenode; they're very helpful.

[Mike Mayday]

Uh, no, sorry. I meant 64x64 pixels per tile.
As for the zoom I did some testing and yeah, 200% would be too much... silly me Still, the current zooming speed is just unnecessarily slow.

BTW, would adding a RMB view panning pose a big problem? It would go extremely well with the zoom feature.
The current "click-to-move-the-view" is unwieldy and only works when issuing commands. (yeah, this is probably a question to Toady...)

[Baughn]

..64x64? Are you insane, man? 

Oh well, bug is in any case fixed. It should work nicely in d15.


Right-click panning would be nice, but that is indeed a question for toady; you should post in the suggestions forum for that one.

[Mike Mayday]

..64x64? Are you insane, man? 

I have a zoom function and I'm not afraid to use it!

[JoeCarrot]

Am I missing something? I am on os x 10.4, but the df 'script' is just a black terminal with an exec in it. No clear way to run it.

Thanks,
Joe

[Calitar]

I'm experiencing a bug that isn't on that list. Whenever I'm entering text (like with naming dwarves) I can't seem to delete the text. Both backspace and delete don't work. Makes it very annoying when I make a typo. I'm using an intel mac running OS 10.4

EDIT: Also, this bug does not appear in vanilla Dwarf Fortress.

[Calitar]

Am I missing something? I am on os x 10.4, but the df 'script' is just a black terminal with an exec in it. No clear way to run it.

Thanks,
Joe

Double-clicking on the df script should work, but if not try this:
Right-click on df -> 'open with' -> 'other' (assuming terminal isn't on that list) -> switch 'Recommended Applications' to 'All Applications' -> scroll through your Applications list and open up the 'utilities' directory -> select Terminal (you can also check 'Always Open With' if you like) -> click 'Open' and you should be good.

I hope that helps you. I tried to be as clear and as descriptive as possible.

Also, sorry about the double post. I wanted to make this separate from my bug report post.

[Baughn]

I'm experiencing a bug that isn't on that list. Whenever I'm entering text (like with naming dwarves) I can't seem to delete the text. Both backspace and delete don't work. Makes it very annoying when I make a typo. I'm using an intel mac running OS 10.4

EDIT: Also, this bug does not appear in vanilla Dwarf Fortress.

OS X uses a different keycode for backspace than the rest of the universe, which confuses DF. It's fully fixable, but I can't fix it since I don't have an OS X machine.. there are instructions for how to do it somewhere in the thread, though; use the thread search function.

On that note, I'll try to get the default fixed in d15.