Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

Faster than 40d, no problems

42 (26.1%)

Faster than 40d, problems

72 (44.7%)

No slower than 40d, no problems

14 (8.7%)

No slower than 40d, problems

16 (9.9%)

Slower than 40d, no problems

2 (1.2%)

Slower than 40d, problems

3 (1.9%)

Doesn't work (please explain)

12 (7.5%)

Total Members Voted: 160

[Barag]

I'd just like to give my impression of 40d9, running in osx on a 3.06ghz core2duo, 8800gs, and 2gb of ram, running at 1920x1200 with a 16x16 tileset, at 120:75 grid size.

The best combination seemed to be a tie between no,no,no and yes,yes,no with partialprint at 2. Both options produced an average (almost too fast) frame rate of about 500 at embark on a 6x6. yes,no,no produced flickering and random characters. yes,no,yes displayed a heavily distorted image, or nothing at all.

In the int it says the movies are capped at 100. If you are referring to the intro movie, this is not the case, although I suspect you mean game play recordings which I haven't tried.

As for the interface changes for the os x version, leave alittle to be desired. No longer having command-F as the fullscreen toggle is inconvenient, and messes with some expose features (happen to be bound to f11). Having command-Q no longer shutdown the program I suppose was changed to stop from quiting without saving or abandon, which I understand, although it would be nice to have command-Q function as save and quit. Another problem, which may be unintentional deals with moving the designation cursor, and I assume the building cursor (using the keyboard). When scrolling the "pointer" in a direction, lets say up, by holding down the up key, if you press lets say the left key without releasing up, the cursor will stop after moving left once, as opposed to moving left, then continuing to move up. I hope that last bit made sense, I struggled to put it into words for some reason.

I'll postmore feedback after playing around with it some more.

[Veroule]

In the int it says the movies are capped at 100. If you are referring to the intro movie, this is not the case, although I suspect you mean game play recordings which I haven't tried.

The capping with the movie player never got put back in.  The original code had the handling for it sprinkled into multiple different places, and the changes to the display code rewrote involved rewriting most of one class.  The cap on movies probably won't be back until Toady rewrites some of the other interface classes.

As for the interface changes for the os x version, leave alittle to be desired. No longer having command-F as the fullscreen toggle is inconvenient, and messes with some expose features (happen to be bound to f11). Having command-Q no longer shutdown the program I suppose was changed to stop from quiting without saving or abandon, which I understand, although it would be nice to have command-Q function as save and quit. Another problem, which may be unintentional deals with moving the designation cursor, and I assume the building cursor (using the keyboard). When scrolling the "pointer" in a direction, lets say up, by holding down the up key, if you press lets say the left key without releasing up, the cursor will stop after moving left once, as opposed to moving left, then continuing to move up. I hope that last bit made sense, I struggled to put it into words for some reason.

You can rebind the full screen toggle to command-F.
No specific change was made for command-Q that I am aware of. All I can think of is that the multiplatform library used is intercepting this keypress, where as running the Windows version through emulation couldn't.

I produced a low level rewrite of the keyboard input routines after 40d9.  It has better handling for holding multiple keys.  With your specific example the new code would alternatingly process the up and left until one of them was released, then it would continue processing the other until it was also released.  Holding left then also holding right would demonstrate this very well, as the display could be seen to bounce back and forth.  You can look forward to that when Toady builds it into a new version.

[Barag]

You can rebind the full screen toggle to command-F.
No specific change was made for command-Q that I am aware of. All I can think of is that the multiplatform library used is intercepting this keypress, where as running the Windows version through emulation couldn't.

I produced a low level rewrite of the keyboard input routines after 40d9.  It has better handling for holding multiple keys.  With your specific example the new code would alternatingly process the up and left until one of them was released, then it would continue processing the other until it was also released.  Holding left then also holding right would demonstrate this very well, as the display could be seen to bounce back and forth.  You can look forward to that when Toady builds it into a new version.

Good call about key binding, I completely overlooked trying that after I saw the option gone from the 'Window' menu.  I am still a bit curious and confused about what exactly I am running. Is dwarfort.exe being emulated to run in osx, or is the mac code just inside the package also and being run without a front end? I have also found that all standard methods of closing a program don't seem to work. File:Quit, command-Q, and the close window button do nothing. Force quit works, after a couple tries.

Was anything changed to break (used lightly) the cursor compared to 40d, or was it just a casualty of new code?

EDIT:  Doesn't seem to allow binding command+f, but any button will do.
EDIT2: In true windows fashion I just had to bind it control+f.

[Baughn]

Oh, and I found yet another way to accomodate partial printing, by using the accumulation buffer.

It's significantly slower than a framebuffer object on my hardware, but it's also a very small amount of code to add, and it might be useful to *someone*.

[Mel_Vixen]

14/03/2010: Used buffer of keyboard to make DF graphics faster. Touchscreen input nearly done

  nah seriously everything that makes DF more efficient is pretty nice and your work is awesome. I have no clue on graphics (only a bit on Ai and such) so how does that accumulation buffer work and can you combine it with the other code to get a still better result?

[Baughn]

Nothing special; it just makes partial printing work better.

See.. partial printing is good, but it requires the contents of the screen to *stay around* for the next frame, or it won't work right.

There are about four ways to do this. In decreasing order of preference:
- Tell the OS that we only want a single buffer, so we can keep overwriting what we drew earlier.
- Ask for double-buffering and get buffers that get swapped without being cleared, so we can get away with just drawing every update a small number of times. That's what plain 40d does.
- Use an off-screen frame-buffer object in the GPU; draw to that, then draw it to the real screen once per frame. Blindingly fast on modern GPUs, but badly supported on older or slower ones.
- Use the (very old) accumulation buffer; you can't draw directly to this, but you *can* copy the content of the screen buffer to the accumulation buffer after you're done drawing, and then copy it back before you start drawing the next time. This is slow.

Honestly, I have my doubts that using the accumulation buffer would ever be a good idea, but it's a very simple thing to add, and there's a lot of weird hardware out there.

[Footkerchief]

Is there any possibility of auto-detecting the hardware so that the best buffering option can be selected automatically?  That could substantially streamline things for new players who just want the damn thing to run, but I have no idea whether it's feasible.

[Baughn]

It's not feasible. We can ask the driver whether a given extension exists, but not how fast it is; worse, on some cards (read: older ati ones) turning on the framebuffer extension will outright corrupt the GPU driver state, crashing the machine or at least DF.

So we can't decide in advance what is best to use, we can't just run a benchmark at startup without risking a crash, and we can't afford to tell users to use newer cards like the other games on the market.

The only real option is what we do now, which is to ship with a widely compatible, if slow setting, and allow players to experiment.

If toady takes my advice the settings should be simplified somewhat for the next release, though.

[Andir]

Maybe we could make up a GUI configuration editor and let them choose one of the 4 settings from compatible (slow) to fast rendering and let them select it the first run.

[alpha]

Warcraft 3 never lags at 100+ units on "sort-of-3d" map... DF does, badly. *sad face*

[Mel_Vixen]

Warcarft is has a 3d Environment but does only 2D pathing (iirc). 3D pathing like in DF needs some potences more cputime then 2D algorithms.

Comparing WC3 with DF is like comparing Apples and Peas.

[Footkerchief]

Warcraft 3 never lags at 100+ units on "sort-of-3d" map... DF does, badly. *sad face*

The reasons for this are probably both good (DF is more complicated in many ways) and bad (not well optimized).  But graphics isn't one of those reasons anymore, so this is a little off topic.

[zagibu]

Warcraft 3 never lags at 100+ units on "sort-of-3d" map... DF does, badly. *sad face*

That's not true. I've edited WC3, and it has tremendous problems with pathfinding. The game doesn't lag, granted, but the units will stop moving, when they collide. This is the main reason most TD maps disable unit collision.

[alpha]

Warcraft 3 never lags at 100+ units on "sort-of-3d" map... DF does, badly. *sad face*

That's not true. I've edited WC3, and it has tremendous problems with pathfinding. The game doesn't lag, granted, but the units will stop moving, when they collide. This is the main reason most TD maps disable unit collision.

I've played WC3 a lot and never seen units stop like you're saying, ever.

[bombcar]

Anyone have recommended settings to try for the Mac version? I'm on an original Mac Book Pro and am getting 50-60 just after embark.