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

[Vince]

3GB. I could try it, but VBOs in general work on my system (I use them myself) - I only have that problem with DF.
32 bit here btw.
I'll try it with 1 bar less now, wish me luck

EDIT: Nope. Didn't work either - and to be honest: I wasn't surprised.
I mean, VBOs work in other applications on my machine, too. And modifying my hardware to fix this problem... Are you sure it isn't just a coding issue? Maybe there are some win32-specifications that aren't met?
I don't really want to search for my Ubuntu-disk to try it under linux, but if you insisted, I would do it and try it there

[SirPenguin]

I really enjoyed the explanations for the various modes, so do you think you could do the same for the different "levels" of Partial Print? I'm kind of blindly increasing/decreasing that number and I'm hard pressed to find any sort of effect...adverse or otherwise. Is there a number range I should be aiming for?

[Baughn]

Vince:
This should not be the case. I followed the relevant OpenGL specification; windows-specific requirements are a big no-no, although I certainly wouldn't be very surprised if one exists.

Lacking (hard/soft)ware that does this, however, there really no useful way I can debug it. It would be nice if you could figure out what's going on, but really, standard mode should be more than good enough on that hardware.

Sir Prinny:
The partial-print number is the number of times a given tile is redrawn before we stop, after it has been changed.

The reason it exists is that the SDL window DF asks for is, by default, double-buffered. This means there are two areas in video memory for it; we draw to one, while the other is displayed, and they are then swapped.

Turning on single-buffering changes that to, well, a single buffer; if this works (which it very often doesn't, except on old hardware), only one drawing is required, which you get by setting redraw count to 0.

You should normally not need more than 1. However, for situations such as triple buffering, 2 may be needed. That said..

Modern GPUs often have far more than three buffers, and old ones may be overwritten with random data before going back on the top. In that case, you may need a large number - in which case the performance goes to hell - or partial printing simply won't work at all. Dealing with this problem is what the Accum and Frame_buffer modes are for, as both emulate single buffering.

[Vince]

Vince:
This should not be the case. I followed the relevant OpenGL specification; windows-specific requirements are a big no-no, although I certainly wouldn't be very surprised if one exists.

Lacking (hard/soft)ware that does this, however, there really no useful way I can debug it. It would be nice if you could figure out what's going on, but really, standard mode should be more than good enough on that hardware.

Thanks for your efforts, nevertheless!

[MechaSaurus]

I have a problem with the newest version.

When I died in adventure mode, i wasnt able to press escape to finish the game. No other key responded either.

I had to close the game with strg+alt+del.

Oh and sorry for my clumsy english i'm not a native english speaker.

[Footkerchief]

I have a problem with the newest version.

When I died in adventure mode, i wasnt able to press escape to finish the game. No other key responded either.

I had to close the game with strg+alt+del.

Oh and sorry for my clumsy english i'm not a native english speaker.

It's a known bug that's been widely reported in this thread and others.  It should be fixed for the next 40d##, although nobody knows when that'll be.

[Urist McDepravity]

I'm sure i did see report on this bug before, but couldn't find it, and its damn annoying, so will report again.
In build menu's it considers single 'enter' button hit as repeated.
Ex. [b] - [C] - [w], designate area, hit 'enter', get some gold bar already selected, as 1/99. With single element designations it makes it impossible to select correct material.
For smaller forts i just increased hold repeat time in init to 250 ms, but now it did strike again, and increasing it even more isn't desired, since it start to lag on movement keys.

I noticed this effect appears from abundance of materials, more i have, more it 'lags' between ... - [w] and showing me the list. So I believe 'key down' event is incorrectly get stuck till it finishes materials calculation.

My init:
[KEY_HOLD_MS:250]
[KEY_REPEAT_MS:150]
[MACRO_MS:250]

Linux 2.6.30, bug exists in all 40dx versions

[shadow_slicer]

I'm also seeing the problem Urist McDepravity mentioned. When placing building in the build menu, (most of the time) the enter key press is doubled, resulting in the first item in the list being picked. Note that this doesn't happen every time, and it doesn't appear to be related with keypress duration or anything else I've tried. This has been happening to me since at least d14 (possibly d13). I don't think I had this problem with some the earlier ones (I think d11 was okay, but I'll have to check).

I'm using Ubuntu 9.04 (linux 2.6.28 x64, SDL version 1.2.13).

[DrazharLn]

I'm using Ubuntu 9.04 and 40d16, I do not get the error mentioned by the above two posters.

All the timings are as default.

[CobaltKobold]

I'm using Ubuntu 9.04 and 40d16, I do not get the error mentioned by the above two posters.

All the timings are as default.

That. (It's slow to bring up the build pick menu, thanks to tens of thousands of mats, but it doesn't autopick any.)

[DrazharLn]

I just stumbled across this. Could the new support for transparent tilesets make this easily implemented?

If it could be, it would certainly be a nice little improvement.

[Footkerchief]

I just stumbled across this. Could the new support for transparent tilesets make this easily implemented?

If it could be, it would certainly be a nice little improvement.

Unfortunately, no.  It's outside the scope of this project, as it would require new logic within DF to handle what gets drawn.  The person who created that demo also posted a thread here about it.

[DrazharLn]

Nevermind, perhaps it will be implemented officially at some time.

EDIT: Scratch the officially, I just meant outside this particular project. Forgive me, it's late here

[HAMMERMILL]

Right, quick explanation.

Good stuff. I've been really scratching my head with these options.

This should be put on the top post so people don't have to dig through the entire thread to find out what the various functions do.

[nagual678]

First of all, thanks for all the work you guys have been putting into this!

But, DF crashes after the embark screen (right after the "Strike the Earth!" message) if I try to put fullscreen on. My resolution is 2560 * 1440 (latest 27" iMacs). Windowed mode won't let me resize up to full capacity.. See enclosed screenshot for what it looks like beyond that (it just adds black bands).

http://imgur.com/O6qNy.jpg