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

[ungulateman]

The download link hates me. Anybody else have problems?

[Shurhaian]

...Right. I was hoping that an init option to turn off zooming would be a fairly quick way to get around requiring either a moderately ugly hack on the user's part or using a nonoptimal render mode that's already been stated as being slower, but apparently I was mistaken. Sorry for bothering.

Geez. Well, what about setting the zoom setting to 1 in init.txt? That should turn it into a no-op.

This thought occured to me, but:

Use this to set how fast the game zooms.  The default corresponds to multiplying by a factor of 1.1 each time the zoom action occurs.  You can set it anywhere from 1.001 to 1.999.

I didn't know how it would respond to an input out of those bounds. If it indeed handles it as a no-op rather than wigging out(or using the minimum factor of 1.001) that's acceptable.

In general I think a 1.0 - 2.0 range would be good; 2x scaling is likely to be clean, a decimal might not yield an acceptable result depending on display and tileset.

[Baughn]

It isn't clamped. I must admit I don't quite understand toady's hand-written decimal parser (and don't care to; I'm replacing that now), but a 1 should get read as simply a 1.

It won't be a no-op, exactly, but multiplying by 1 is a no-op, so the effect is the same. Floating-point isn't unreliable, just different; if you understand it, it's perfectly predictable.

[Shurhaian]

Well, yes, that's what I meant; a mathematical rather than a programming no-op.

All right, good to know, thanks.

[CobaltKobold]

Well, yes, that's what I meant; a mathematical rather than a programming no-op.

All right, good to know, thanks.

"identity operation"

[DDR]

Well, hm, after playing the *official* release from the df website, I must say this is a _stunning_ improvement.  It works much faster, and it seems... better.

However, I prefer the 'tiny' font, magnified by two so I can see it. What is tha... It's a beard, right. Anyhow, there are stray lines where it has scaled poorly if I try to re-size the window. I can zoom in, everything is dandy, but it is odd with any other window size - no matter how much I tweak it, something is off. Could we please make a 'pad' around the edges, so that individual tiles are not stretched in relation to other tiles? If the tiles were 8x12, then the pad could be 0 to 11 wide, and 0 to 7 high.

I'm sure this is a fpi after 50-odd pages of discussion, but I can't find it in a search.

[CobaltKobold]

[BLACKSPACE:YES] should be the answer.

[DDR]

When you try to zoom in with blackspace enabled, the tiles do not grow larger - the number of tiles shrinks, and what is left at 2x zoom takes up 1/4 of the screen.

Did I describe that clearly, or should I take screenshots?

[Footkerchief]

Baughn -- a couple people running 40d16 on 64-bit systems have reported that they can't run in windowed mode.  They both say their drivers are up to date.  I'm currently trying to find out what video cards they have, but meanwhile, any ideas?

http://www.bay12games.com/forum/index.php?topic=47074.0
http://www.bay12games.com/forum/index.php?topic=47672.0

[smirk]

Odd happening with 40d16 vs 40d.

I'm making a huge tileset. Original plan was for it to be 8800x8800 pixels, but that crashed DF. After some experimenting, I found that 2831x2831 pixels was the maximum size I could make the tileset. At 2832x2832, I got this message:

Code: [Select]

GPU unable to accomodate texture catalog. Retry without graphical tiles,
update your drivers, or better yet update your GPU.Using irregular dimensions (2832x2831 and vice versa) gave the same error. The odd thing is, this appears to be a pixel-dimension thing, not a file size one. Using a BMP rather than PNG gave the exact same results. BMP was 22.9 megs to the PNG's 670 KB.

Then, just for kicks, I made a BMP of the 8800x8800pixel version and tried to load that in 40d AND IT WORKED. Except I couldn't zoom in, so the tileset looked like crap. Ah, the bitter irony, it stings so.

My graphics card is a GeForce 7900 GS, not the newest but not terrible either. Its drivers are updated.

So what happened between 40d and 40d16? I'm all for the new changes; 40d16 is faster and I wouldn't even be considering such a ridiculously sized tileset without the awesome zoom feature. It just seems odd that this is happening.

tl;dr: 8800x8800pixel tileset loads in 40d, crashes 40d16.

[CobaltKobold]

550 pixels wide per tile?...um. Why? I'm curious. (hmm, real dimension of 80x25 is 44000x13750.)

*does some math* 2832x2832 is  ~8M, but still has about 300k before 8Mi, so that's a little odd as boundary. 2832 isn't any sentinel I know of on its own...it's 11*16*16...

Anyway, someone's code (or your card) has a definition of "reasonable" that probably clashes with your own. Funnily, Tarn's does not.

[SimRobert2001]

Baughn -- a couple people running 40d16 on 64-bit systems have reported that they can't run in windowed mode.  They both say their drivers are up to date.  I'm currently trying to find out what video cards they have, but meanwhile, any ideas?

http://www.bay12games.com/forum/index.php?topic=47074.0
http://www.bay12games.com/forum/index.php?topic=47672.0

Could that be what happening with my game? it says it can't find the matching GLX visual.

my graphics card is an nvidia 6400.  in addition, i'm using ubuntu.

[smirk]

550 pixels wide per tile?...um. Why? I'm curious. (hmm, real dimension of 80x25 is 44000x13750.)

*does some math* 2832x2832 is  ~8M, but still has about 300k before 8Mi, so that's a little odd as boundary. 2832 isn't any sentinel I know of on its own...it's 11*16*16...

Anyway, someone's code (or your card) has a definition of "reasonable" that probably clashes with your own. Funnily, Tarn's does not.

Reason being my tileset; I need more detail per tile, darnit!  http://www.bay12games.com/forum/index.php?topic=47474.0

It's an odd boundary indeed; it probably is some odd interaction between my card and d16's OpenGL I guess. The 8800x8800 BMP I put in 40d was 221 megs, and that loaded without even an extra-long startup 0_o  Maybe when Toady merges things for the next release, my problems will magically disappear. I can always hope =D

[CobaltKobold]

Interesting.

[Rose]

I'm pretty sure it's due to the fact that 40d16 uses hardware acceleration, while 40d was software. GFX cards probably have some kind of limit on the size of textures they can keep in memory.