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

[JoystickHero]

One minor feature request:

If WINDOWEDX and WINDOWEDY are set to zero, make the actual window size enough to give 80x25 in the selected font.

This would make it a little more convenient to test fonts of diverse sizes.

You know you can just drag the corner of the window to resize it, right?

I love this. I've been using it for a while now, after the friend who introduced me to DF showed me it. (I was complaining about how much of a pain it is to resize while installing a custom font. In retrospect, a rather petty complaint.) I love it. Here's hoping that these features make it into DF proper!

[Shurhaian]

Since the game is not properly playable at a tile dimension lower than 80x25, having it default to that size rather than squishing the tiles would be a useful option to have. Resized tiles can look rather hideous, and getting the size just right by window-shaping can be an exercise in frustration.

[Toksyuryel]

I would like to humbly request that Python be used instead of Lua. That is all.

[Baughn]

It's easier to correct for missing libraries than missing language features, and Python fails horribly at functional programming, apparently by design. That is all.

That said, which extension language ends up being used is very much up to Toady; I don't really have any say in it.

[Shoku]

Since the game is not properly playable at a tile dimension lower than 80x25, having it default to that size rather than squishing the tiles would be a useful option to have. Resized tiles can look rather hideous, and getting the size just right by window-shaping can be an exercise in frustration.

Dude: blackspace. Just have your opening window size be huge and you'll have plenty of big black border to buffer to whatever practical size.

[Andir]

It's easier to correct for missing libraries than missing language features, and Python fails horribly at functional programming, apparently by design. That is all.

That said, which extension language ends up being used is very much up to Toady; I don't really have any say in it.

It's the fact that inconsistent whitespace can literally kill a program that gets me.  The whole tabs vs. spaces takes on a whole new meaning in Python.  Especially, if we are talking about sharing scripts, which we would be.  Yeah, I know most compilers handle conversion, but you have to know whether the author uses 1, 2, 3, or 4 spaces per indent and all that jazz.  It's almost as if Python was designed to be horrible to share code.  Also, the choice of implementing Python over Lua because of the library selection is quite pointless since the script will mainly be dealing with DF objects and not having to connect to a remote server or something odd like that.  Sure, I can see some utility in it, but it's not a staple requirement.  (Also, I read that LUA is much easier to integrate with C++ than Python...)

That being said, I have played a bit with Python and merely only read about Lua, so my support for Lua seems a bit odd seeing that I haven't actually used it, but I still think it's a better choice (if there were a vote.)

[Ornedan]

The whitespace for structure thing in Python only really amplifies existing problems. Which I don't consider a particularly bad thing, since then you have to fix the real problem, being that your code is an unreadable mess of randomly indented crap. As far as sharing goes, there are these things called coding conventions.

Lua is however a better choice, because it's tiny compared to Python yet still has an adequate base library. About the only advantage Python would have is an enforced base standard of readability on that "shared code".

[Rafal99]

I vote for Lua. It is very flexible and great for all kinds of scripting. There are many both commercial and open-source projects that have proven the usefulness of it.

[CobaltKobold]

Having converted my isominerals to the superior transparency-instead-of-magenta, It is painful to try to draw on alpha channel accurately.

Something that just used "R" and "G" channels for FG/BG would be much much easier to work with...as well as easier to understand.

If we had some common image format with six channels I'd suggest that instead, but I don't know of any. Then again, just doubling tileset would make that feasible.

[Shurhaian]

Since the game is not properly playable at a tile dimension lower than 80x25, having it default to that size rather than squishing the tiles would be a useful option to have. Resized tiles can look rather hideous, and getting the size just right by window-shaping can be an exercise in frustration.

Dude: blackspace. Just have your opening window size be huge and you'll have plenty of big black border to buffer to whatever practical size.

This is what I would call a workaround.

That there is a way to get around a problem doesn't mean the problem should be left alone; that there is an ugly alternative to a suggestion doesn't mean the suggestion is without merit.

Personally, I wouldn't want the window frame to take up any more space than it must. The person who suggested that 0 dimensions instead make for an 80x25 tile default size hit on a possibly-useful special case, which might or might not be less irritating to implement than a way to determine whether the view will squish, or automatically scale to a minimum, for any size that doesn't allow 80x25 tiles to fit.

Come to think of it, a way to specify starting resolution by (unscaled) tiles rather than pixels might itself be useful... but that's getting off course.

[DrazharLn]

Come to think of it, a way to specify starting resolution by (unscaled) tiles rather than pixels might itself be useful... but that's getting off course.

You can do that just now with a little maths. Find the width and height of a tile in your tileset in pixels. Multiply that number by the number of tiles you want horizontally and then by the number of tiles you want vertically. That is your window size.
You used to have to fiddle with a GRID setting, but I think that's redundant now.

[Baughn]

Sounds reasonable. So, in d17 or at least the final release:

If you specify 0x0, it'll autodetect a window size for 80x25. If you specify NxM, where both N and M are <256, it'll interpret that as grid size, and calculate the window size accordingly.

If you actually want a 255x255 window for some reason, you're SOL and I'll cry a crocodile tear for you.

[jpwrunyan]

Sounds reasonable. So, in d17 or at least the final release:

If you specify 0x0, it'll autodetect a window size for 80x25. If you specify NxM, where both N and M are <256, it'll interpret that as grid size, and calculate the window size accordingly.

If you actually want a 255x255 window for some reason, you're SOL and I'll cry a crocodile tear for you.

Why not take a CSS approach and have it suffix with either "px" for pixels or "tile" for tiles?  The default (no suffix) can be pixels.  Dunno how easy that would be to implement...

But honestly, I don't see the merit in setting size by pixels as opposed to tiles.  Not until variable width fonts are ready.

Anyway, really looking forward to the new features you guys are working on!  Thanks!

[qwert]

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. 

[CobaltKobold]

Sounds reasonable. So, in d17 or at least the final release:

If you specify 0x0, it'll autodetect a window size for 80x25. If you specify NxM, where both N and M are <256, it'll interpret that as grid size, and calculate the window size accordingly.

If you actually want a 255x255 window for some reason, you're SOL and I'll cry a crocodile tear for you.

Why not take a CSS approach and have it suffix with either "px" for pixels or "tile" for tiles?  The default (no suffix) can be pixels.  Dunno how easy that would be to implement...

seconded.

Well, I and a few others made 4x4 tilesets which are readable, and,while a 4x2 tileset would be theoretically usable in monochrome (8 bits to distinguish 256 tiles) it wouldn't be readable.

...hmm, I thought there had been multiple 3x5 tilesets, those're not that bad to create or read. Probably just not on the wiki repository.