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]

..no. Just no. You people aren't at all sane.

This way works perfectly fine; if you want something that small, specify the grid size. Somehow I doubt you'd want the quality loss from a non-blackspace, non-exact grid anyway.

[CobaltKobold]

..no. Just no. You people aren't at all sane.

Well, it's not unreasonable, and it's more readable.
[GRID:TILES:80:25] or [GRID:PIXELS:1280:400]

[SCALE:1:1] >_> and perhaps restore an old feature in a new way

Also, something (it might not be in df) does not like tiny windows. lemme confirm this actually.

Nah, cancel that, 320x100 window (80x25 for 4x4) works. Though, I'm still getting Mysterious Antialiasing on ACCUM_BUFFER/YES, which is best setting fpswise. But it makes 4x4 unplayable since it mangles most tiles.
under good/standard:

[Baughn]

Well, let's see what happens with the 2D modes in 40d17.

One of those might be as fast. Accum-buffer is normally horribly slow, so if it isn't for you.. it's because everything else is too. 

The 2D modes are definitely pixel-perfect. Zooming isn't supported, though.

[jpwrunyan]

..no. Just no. You people aren't at all sane.

This way works perfectly fine; if you want something that small, specify the grid size. Somehow I doubt you'd want the quality loss from a non-blackspace, non-exact grid anyway.

My point wasn't to enable a 256x256 pixel view... merely to make the interface configuration explicit.  Having 256 (or whatever) be a magic number is... well, against my instincts.  Also, I guarantee that someone will not get it.  "Is this supposed to be 400 pixels or 400 tiles?  Der..."  Or "I'm gonna pimp my DF!  I have 3 monitors lined up horizontally!  I wanna 300 tile wide window to stretch across them all!  Wait... pixels???  I don't know how many pixels that is!  Uh, 1440 plus..."

Anyway, it was just a suggestion.  If you're not worried about stupid settings or stupid people then it is sorta moot.  For me these sort of considerations are just instinctual.  I have to make any application I program fool-proof... because the end users are fools.

[CobaltKobold]

actually, as I understand it there's a hard-coded 256x256(off-by-one?) maximum display, which would need fixing in the backend(Toady's) before it would be possible.

[Baughn]

Not "need fixing", actually; they're #defines, and could be changed in an instant.

But there are no doubt a bunch of datastructures that allocate that much memory statically. I've tried to avoid it, but I think even I've got a few. So that should be cleared up before it can be set to something like 5000.

And point taken. I'll use [WIN_GRIDSIZE:x:y] and [WIN_RESOLUTION:x:y] instead. You get to use one, or the other, or quite possibly both if I can figure out how to do that cleanly.

[Ornedan]

Until someone manages a 3xSomething tileset, the smallest available is 4xSomething which has a 320px horizontal width. So unless you know of a method of getting a tileset to only 3 pixels wide while still usable, and you would want a width between 81 and 84 tiles, I think it is safe to assume this is a non-issue. 

It's more an issue of magic values (or value-ranges in this case) being bloody ugly.

Edit: Oh, hey, new page where I got ninjad by several hours. Succes!

[Daman]

so uh is the input not responding on adventurer death going to be un-fucked in d17?

[Baughn]

Yes.

[Daman]

Yes.

cool sounds hot hope it's out soon


you should put up an SVN or sth

[Footkerchief]

you should put up an SVN or sth

There's a link in the OP for the 40d16 HEAD, although I don't know if it's still getting updated: http://brage.info/~svein/df-40d16-head.tar.bz2

[Baughn]

It isn't, because my current point of development does not include a working DF.

Well.. it starts, you can generate a world, but you can't play. Toady'll have to fix whatever causes game-start commands to be ignored.

Once d17 is out I'll have an easier time.

[CobaltKobold]

You are aware of the strange character-exclusions in the note-taking paraphernalia, both at embark and fortress mode? Just something to watch out for.coded

[Konpeito]

Hoping I can get a quick assist on this... I'm on my Windows XP install, because my fort has gotten so big that managing it without the help of utilities that have no OS X counterpart (which is to say, all of them) is almost more trouble than it's worth. Here's the problem: when I try to resize the window, even by so much as a pixel, the entire thing goes black. Careful experimentation suggests that if I can get the window EXACTLY back to the size it started, it comes back. The Mac version of 40d16, which I've been running this fortress on until now, has never displayed this resize glitch. I am really quite confused, but I'm sure I've managed to innocuously screw up some otherwise unimportant variable somewhere. I have a knack for that sort of thing. Any suggestions for how to fix this so I can get on with my farewell-to-the-current-version fortress would be greatly appreciated!

[CobaltKobold]

Based on my experience:
1. You're using something other than [PRINTMODE:STANDARD]
2. There is a bug that makes it think that it needs to do a redraw, but only manages to clear the window. Do something else that actually forces a redraw (the easiest is changing the zoom level and resetting it)