Print

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

[Baughn]

That's reasonable, since RD optimizes based on detected redraw calls. The 2D modes only redraw what has changed; admittedly, so does the opengl partial mode, but the others all redraw the entire window each frame.

However, the TEXT output mode is what is really designed for networked DF. Won't work as a server on windows, though.

[kurokikaze]

Won't work as a server on windows, though.

Nooooooooo!!! 

[Quietust]

Urgh, this is probably just me being stupid, but I can't configure Konsole to work with the ncurses mode. (It is in UTF-8 mode. So it claims.) Help?

Spoiler: Screenshot with broken characters (click to show/hide)

(The same thing happens on the Linux console. Which is also in utf-8 mode.)

(Edit: It works fine with uxterm. !?!?)

Just a guess, but have you tried selecting a different font? It looks like the one it's currently using might not have glyphs for all of the characters present in CP437.

[Noble Digger]

I posted a handful of interface bugs in the bug report forum that are specific to 40d17. The crash bug is just another instance of the null pointer bug with the farm plots so disregard that report (except to note that it happens with trading and the stocks screen as well).

[DDR]

D17: Works perfectly, so far. Thanks.

[Bergelmir]

Hi there,

I have a quite general question now: How do I know that the HEAD is updated and I should fetch it again?

[FatedTemp]

Just thought I'd say d17 works well for me, on Windows; I'm getting FPS pretty much exactly as I did with d16 and the only bug I've seen that I don't think has been mentioned yet is with the zoom toggle; the game doesn't respond to shift+f10 despite SHIFT+function working fine in d16. Changing it to just f10 (swaping with the zoom reset) works though.

[koitsu]

I've had a chance to play around with d17 a bit.  Again, 23 pages of posts, haven't really sifted through them all, so my apologies if these are known problems.

1) Input handler behaves oddly with regards to diagonal movement.  For example: press+hold Up, then as the cursor/screen is panning, press+hold Left -- no diagonal movement.  Yet, if you do the same but press+hold Right, diagonal works fine.  Same with press+hold Down (instead of Up).

2) Input handler has "freaked out" on a couple occasions -- excessive repetitive input when there's no way I was holding down a key.  Admittedly this has only happened over Remote Desktop, so something odd could be going on there.  It's also very, *very* rare.  Seen it happen twice in a couple days of playing.  I'm using the default ms delays in init.txt.

3) Dumping items seems buggy in some ways.  It could be how I've been playing the game, but I've been following some training videos by captnduck so I don't think that's the case.  I marked some sections as dumpable via "d", then "b", and those sections were stockpiles for food.  The sections I selected *did not* have barrels/bins on them -- only stone.  Yet I watched dwarves hauling plump helmets, seeds, bags, etc. from the stockpile area on to the dump zone spot.

4) init.txt feature that I truly, deeply miss from the stable builds: VARIED_GROUND_TILES.    koitsu sad panda... -- EDIT: Oh ho, it's in d_init.txt now!  I didn't think to look there (new file).  koitsu happy panda

5) init.txt feature change: MOUSE:NO actually hides/disables the system's mouse cursor entirely when placed or moved inside of the DF rendering window.  This is awkward/unintuitive (IMHO).  It'd make more sense to just disable the relevant WM_MOUSECLICK (or whatever the WM_* messages are called) handlers (please don't mess with the mouse cursor bitmap/mask, or disable/hide the mouse cursor at all).  :-)

HTH!

[Veroule]

Just got the first blush with D17. Kudos on getting the init.txt split up properly!

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.

Memory usage is up by 400k at the main menu.  That one is really obvious, it is how much gets allocated by keybinding_init().  The C++ string class is not Delphi's string type.  Each of those arrays of char gets copied during the bimap.insert, and since the string class doesn't know how much space is needed it allocates extra space.  Switch from string to char* in your definitions and the code that uses them and the memory will drop.  Switch it back to the const array of struct that was in D16 and it will drop even more.

When will I see the end of this mistake?

Code: [Select]

string abc;
....
for (int i=0; i< abc.length(); ++i) {Again the C++ string class is not Delphi's.  Each time you use string.length it is counting the length of the string.  You are doing that all over the place, but thankfully it doesn't tend to be in speed critical code.  That is a very common mistake.  There are a few such in graphics.cpp that never got fixed.

I do see a problem in how bindings are recorded.  In order to specify the modifier flags you have to use an SDL key, for example Alt+b.  If the key, 'b' in the example, is one of those that moves with a different layout then it will respond on the wrong key.  You need to be able to set Ctrl and Alt to be tested with unicode bindings.  Also you may want to apply a conversion for unicode keys 1 to 26; these are mapped by standard rule to Ctrl+a through Ctrl+z and should be displayed that way.

[brainfire]

3) Dumping items seems buggy in some ways.  It could be how I've been playing the game, but I've been following some training videos by captnduck so I don't think that's the case.  I marked some sections as dumpable via "d", then "b", and those sections were stockpiles for food.  The sections I selected *did not* have barrels/bins on them -- only stone.  Yet I watched dwarves hauling plump helmets, seeds, bags, etc. from the stockpile area on to the dump zone spot.

Did you doublecheck with [K] that there wasn't stone *and* food/barrels/etc?

[jfs]

Memory usage is up by 400k at the main menu.  That one is really obvious, it is how much gets allocated by keybinding_init().  The C++ string class is not Delphi's string type.  Each of those arrays of char gets copied during the bimap.insert, and since the string class doesn't know how much space is needed it allocates extra space.  Switch from string to char* in your definitions and the code that uses them and the memory will drop.  Switch it back to the const array of struct that was in D16 and it will drop even more.

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.
I'd rather use another 10 MB of memory constantly than leak 1 kb every minute, or crash because a block was free-ed too early. (Of course the proper solution here might be to implement a custom type with reference-counted CoW semantics for whatever purpose this is, or just wrap the string type with something like that.)
Memory is cheap today, I think DF uses too little in fact. I see it using 120-180 MB when playing it, and I could easily afford it using 500 MB or there about, and certainly wouldn't mind it using more, especially if it meant general speed-ups, due to things like caching. (Spend more memory caching data to avoid having to spend CPU re-calculating them constantly.)

When will I see the end of this mistake?

Code: [Select]

string abc;
....
for (int i=0; i< abc.length(); ++i) {Again the C++ string class is not Delphi's.  Each time you use string.length it is counting the length of the string.

I present to you, the std::basic_string<T>::length() implementation of Dinkumware STL, the one shipping with Visual C++ 2008. I imagine that every other STL implementation also does something similar.

Code: [Select]

size_type __CLR_OR_THIS_CALL length() const
{ // return length of sequence
return (_Mysize);
}Notice the heavy lack of counting characters in the string, and the strong use of a stored size_type value that contains the number of characters in the string, updated when the length of the string is changed in one way or another. Also, I'm pretty sure that std::basic_string<T> is required to be binary-safe, i.e. be able to hold embedded '\0' characters.

[Andir]

When will I see the end of this mistake?

Code: [Select]

string abc;
....
for (int i=0; i< abc.length(); ++i) {

At least they are using ++i instead of i++ :p  That's always been a pet-peeve of mine.  Depending on the length of abc though and how many times the length will be used, it may be just smarter to get the length instead of having the compiler allocate memory for that one loop...  On that note, C++ strings are not guaranteed to end in \0 so it stores string length (compared to C that \0 terminates strings) and allocating space to store the length is fairly redundant since checking the length() ( or size() ) can be a very lightweight operation.  Looping over a string actually can be done using the built in iterator as well...

Code: [Select]

string::iterator iter; for(iter = abc.begin(); iter != abc.end(); ++iter) {

[Andir]

I present to you, the std::basic_string<T>::length() implementation of Dinkumware STL, the one shipping with Visual C++ 2008. I imagine that every other STL implementation also does something similar.

Code: [Select]

size_type __CLR_OR_THIS_CALL length() const
{ // return length of sequence
return (_Mysize);
}Notice the heavy lack of counting characters in the string, and the strong use of a stored size_type value that contains the number of characters in the string, updated when the length of the string is changed in one way or another. Also, I'm pretty sure that std::basic_string<T> is required to be binary-safe, i.e. be able to hold embedded '\0' characters.

That works too, I guess it was more concise than my ramble.   C++ stores string length opposed to C.

[Baughn]

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.

It's true that using a reference-counted string type that copies on change would save me.. oh.. a couple hundred kilobytes. That's something to consider for later - the same code would work. Before that, I'm going to replace my own hacked-up bimap with boost's version.

The mouse disappearing if you use MOUSE:NO is a valid complaint. It's supposed to disappear if you're not using it, but with the mouse code disabled it never reappears. Fixing that now.

The timer didn't get broken, but some other stuff did, to approximately the same effect. This, and the various other bugs mentioned on this page, have all already been fixed for d18. Or d17-head, if you're on linux.

[koitsu]

3) Dumping items seems buggy in some ways.  It could be how I've been playing the game, but I've been following some training videos by captnduck so I don't think that's the case.  I marked some sections as dumpable via "d", then "b", and those sections were stockpiles for food.  The sections I selected *did not* have barrels/bins on them -- only stone.  Yet I watched dwarves hauling plump helmets, seeds, bags, etc. from the stockpile area on to the dump zone spot.

Did you doublecheck with [K] that there wasn't stone *and* food/barrels/etc?

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

In some cases there are food and barrels on the same tile/square, however only the stones were marked with a purple/magenta "D" (for Dump).  I ended up working around the issue by entirely removing the area marked as dumpable (e.g. removing all of the tiles which were marked with a purple/magenta background) and instead using "k" to move around + select every item on every tile I wanted to dump.