Print

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

[koitsu]

I can't really do a speed test since the FPS number get totally messed up.  However I can obeserve that with the default init settings and SOUND:OFF; D17 causes 99% CPU usage at the main menu. D16 is only 20%, it looks like the timer got broken again and it is not sleeping properly.  Testing D17 with FPS_CAP:10 and G_FPS_CAP:5 yeilded the same 99% usage.

Can you try using PRINT_MODE:2D, 2DASYNC, or 2DHW (try each in a row and report back the results) in init.txt?  Be sure to put FPS_CAP and G_FPS_CAP back to what they were originally (100 and 20 respectively).

[Noble Digger]

When running 40d16, I get the best FPS using using PRINT_MODE:STANDARD.

In 40d17 I seem to gain 4-6 average FPS using PARTIAL:5 but the flickering bothers me and I'm not entirely sure this isn't just temporary lapse in business at the fort. In any case, the fact that 40d17 runs well (aside from these bugs) in STANDARD is a good sign to me. This is a really really huge fort and both versions keep me up in the mid-20s for FPS even during dumping. I'll test the fort out in 40d18 when it's ready but for now I'm going back to 40d16.

Thanks a ton, Baughn & friends.

[Baughn]

The opengl-based modes in 40d17 are totally broken; if they work, it's basically luck. I do the GLEW initialization before grabbing an opengl context, see. Not good.

40d17-head/40d18 work fine; 40d17 only works by accident, and then inefficiently.

[CobaltKobold]

Oh, hey. Are you perma-out of this?
I'm still not sure why Baughn completely (re-)re-did the input stuff from d16...

[Andir]

I expect the .length() call to get inlined, and optimized to where it's nothing but a struct lookup. So far, C++ hasn't disappointed me. I could use an iterator, but I'm very used to the indexing pattern.. I don't think it matters.

I've also profiled the code with callgrind, and I'm pretty sure I'd have caught any problems like calling strlen a lot.

You are fine... I haven't tested the iterator method against the length loop to actually see if there's a performance difference, but I'm sure it's marginal.  I was just throwing out some knowledge (and [backing you | explaining why it's not an issue] on your choice of using .length() in the for).

[Andir]

Oh, hey. Are you perma-out of this?
I'm still not sure why Baughn completely (re-)re-did the input stuff from d16...

Wasn't d16 the one where everyone complained about the old key handling done by __forget who__ not working properly?

[CobaltKobold]

It had already been completely rewritten once; was it still screwing up on different kbd layouts?

I'm just curious (and a little memory-deficient in this case) really.

[brainfire]

I have no "K" (capital kay) keybinding, so I have to assume you mean "k" (lowercase kay).

Yeah, that's what I meant.

The way the dump/hide designator has worked for me has always been to affect everything on the square, rather than just the top item. If there's a dwarf in the area I think it even marks the stuff they're carrying...

[jfs]

You are fine... I haven't tested the iterator method against the length loop to actually see if there's a performance difference, but I'm sure it's marginal.  I was just throwing out some knowledge (and [backing you | explaining why it's not an issue] on your choice of using .length() in the for).

My own tests with VC++ 2008 has shown that, with full optimisation, using std::vector::iterator is somewhat slower than iterating the std::vector with an int counting up to .size(). (It does matter in inner loops in graphics routines, which was exactly what I was writing at that time.)

[Veroule]

Oh, hey. Are you perma-out of this?
I'm still not sure why Baughn completely (re-)re-did the input stuff from d16...

Yes I am. Baughn did the rewrite because I was unreachable for 2 months, the display code I wrote was crappy, and the readability of my code wasn't great.

I expect the .length() call to get inlined, and optimized to where it's nothing but a struct lookup. So far, C++ hasn't disappointed me. I could use an iterator, but I'm very used to the indexing pattern.. I don't think it matters.

I've also profiled the code with callgrind, and I'm pretty sure I'd have caught any problems like calling strlen a lot.

You are fine... I haven't tested the iterator method against the length loop to actually see if there's a performance difference, but I'm sure it's marginal.  I was just throwing out some knowledge (and [backing you | explaining why it's not an issue] on your choice of using .length() in the for).

Thanks to everyone for letting me know that this was finally fixed in some version of the C++ STL.  Old habits die hard, and has been a long time since I looked at the specifics on that.

I haven't looked at the code in question, but I imagine that the said strings can be dynamically allocated, change and contents etc., which means that using C-style char pointers instead means lots of manual memory management with greater risk of leaks or premature free-ing.

The specific strings I am referring to are the constants for binding names and interface.txt tokens.  They never get changed.

It's true that using a reference-counted string type that copies on change would save me.. oh.. a couple hundred kilobytes.

Yeah, here is to hoping that the STL string class gets updated that way.  Until then you might consider the old saying, "Waste not...want not."

[koitsu]

I have no "K" (capital kay) keybinding, so I have to assume you mean "k" (lowercase kay).

Yeah, that's what I meant.

The way the dump/hide designator has worked for me has always been to affect everything on the square, rather than just the top item. If there's a dwarf in the area I think it even marks the stuff they're carrying...

Ahhh!  That would explain it then (dwarf went to drop something off on one of the tiles for food, tile was marked Dump, and thus took it there).  Not a bug, you're absolutely right.  I've gotta be more careful next time.  Thanks!

[Sizik]

The default key for toggling between resizing the tile grid and zooming in on the current grid is still Ctrl+F10, and not the mouse wheel (which it was listed as in the new features section of the 40d14-16 thread).

[bombcar]

I seem to be able to get it to crash on XP by hitting keys too fast. Next time it happens is it worth saving a crash dump?

[Baughn]

Not really, I wouldn't be able to do anything with it.

It's odd, though. There is no pointer-handling code anywhere in the input code; it's all STL lists and maps.

[calrogman]

Okay, first off, I didn't read the known bug regarding segfaults and d17-head.  Second off, darn you libjpeg.so.62.

Once that was sorted out, running df showed me the wonderful intro movies, with no sound, it claims the .ogg files in data/sound/ don't even exist, before presenting me with a black box which I had to send sigkill to close.  Changing the display mode fixed the black box (no it didn't, this was fixed by disabling the intro), still no sound.