In the new .5 when ever i study a book, or go to bed it just gets really slow…
I played the nightly build before this so i know its not what it should be like.
is this problem just me? is there a fix?
Not just you, I have the same problem, whenever I read or sleep it lags out a bit.
It’s a known issue on Windows that we’re trying to figure out the source of. Unfortunately, nobody with enough Windows savvy has stepped forward yet with a good solution.
Honestly, at this point I’m tempted to put up a poll about whether or not to revert it to the less-laggy version where the game just didn’t do anything until you were done reading/sleeping.
[quote=“Soron, post:3, topic:1435”]It’s a known issue on Windows that we’re trying to figure out the source of. Unfortunately, nobody with enough Windows savvy has stepped forward yet with a good solution.
Honestly, at this point I’m tempted to put up a poll about whether or not to revert it to the less-laggy version where the game just didn’t do anything until you were done reading/sleeping.[/quote]
Mod Action: Post Edited to remove hostility - GlyphGryph
I don’t believe this has anything to do with my bugfixes. I think I isolated the problem several days ago, and mentioned it here:
http://www.cataclysmdda.com/smf/index.php?topic=1258.45
The function causing the problem is this one: handle_key_blocking_activity();
Have you tested the revert on windows? Would it actually help?
Mod Action: Post Removed for hostility - GlyphGryph
Oddly, I’m experiencing only half of this issue. For me, reading books lags a minimum of 10-20 seconds between each skill gain notice, but sleep passes without any noticeable lag whatsoever. I’ve found a very noticeable way of observing this effect that could help to locate the cause. If I activate an mp3 player before reading a book I’ve noticed that it will play 8-10 tracks, using the same number of batteries, before the first skill gain notice displays. I’m compiling with vanilla MinGW, instead of CodeBlocks or Cygwin, but I don’t know if this has anything to do with it.
What is the purpose of this function?
Mod Action: Removed responses to above moderated posts - GlyphGryph
Similar thing here. I use Cygwin to compile, and I’m not getting any lag at all so I just can’t help with the problem really. (Though whether this is just my computer, some strange twist of me using bootcamp to run Windows 7 on my Mac, or is due to Cygwin instead of another compiling method I don’t know).
Hmm, that’s rather interesting, i2amroy and Justice. Guess we’ll have to test multiple compilers, as well. Oh, and actually… I wonder if it’s due to debug builds vs. release builds…
i2amroy: just to verify, are you playing in a terminal with ncurses (or similar), or via a stand-alone application? The issue seems to be localized to catacurse-using systems, which you’d only get if you’re playing as a stand-alone application.
Justice: bleh, that’s probably due to reading being interruptible, then :-/. I’d rather not have to remove that (it works just fine on Linux, and can be rather useful), but… may need to, for performance reasons. Or at least make it an option.
What is the purpose of this function?[/quote]
That’s the one that lets you interrupt activities like reading. Which is ALSO something that I’m considering reverting if there’s a need to, although the best independent A/B performance test we have (perhaps the only one) indicates that the animations are, on some systems, causing lag in and of themselves. Of course, your report about lag only during reading, not during sleep, indicates that handle_key_blocking_activity is in and of itself causing excessive lag for catacurse users.
Mod Action: Removed responses to above moderated posts - GlyphGryph
I’m running Cataclysm directly through Cygwin with the “./cataclysm” command (which if I remember correctly does indeed bypass the curses files), not as a stand-alone program.
I do still get the occasional moment of lag if I hold down a directional key while I’m traveling a long distance in a single direction, but it only lasts for a fraction of a second and appears to be more of a simple “print needs to catch up with the game” problem then an actual lag problem.
Yeah, if you’re running it directly in Cygwin (it’s showing up inside the terminal?), and using “./cataclysm” instead of “./cataclysm.exe”, that sounds like a case where I’d expect Linux-style performance. So, hurray, working as intended! (…now how do we fix performance for normal Windows users >_>?)
That is wrong, as I already informed you here:
http://www.cataclysmdda.com/smf/index.php?topic=1258.msg15489#msg15489
… input handling can not be a standard because it is kernel (operating system) specific.
That is the reason why Linux curses and Windows conio are not the same library, and why none of getch()/clrscr() functions are part of C standard library, ISO C, or defined by POSIX. It is not any standard, it’s the opposite. Therefore, in order to achieve the same functionality they must be implemented differently. What part of this fact do you have a problem with to acknowledge?
If you keep refusing to acknowledge that cata[b][i]curse[/i][/b] is meant as a Windows implementation of the parts of (n)[b][i]curse[/i][/b]s that we use, then it's going to be difficult to know when you're just ranting, vs. when you have an actual point.
Your concern about standards is very strange considering your previous implementation does NOT EVEN WORK. You can not implement platform specific code according to their platform specific standards on a different and incompatible platform, you need to emulate it according to functionality, which naturally then requires different implementation and different standards according to its host platform, of course.
Speaking of which, have I ever told you about my arcade emulator for Android? If you want fast and smooth arcade emulator on you Android phone, without video glitches and audio hiccups as the rest of them, it’s CrazyTilt-MAME:
https://play.google.com/store/apps/details?id=com.ctMAME
Just don’t give me bad review if you struggle with tilt sensor without practicing first or if the sensor doesn’t work at all on your phone/OS version. It’s phone specific, hardware and driver specific, so just like in our case with curses some phones need different code to handle the same thing (input), even if they use the same operating system and libraries. So you see, some “standards” do not apply even on the same platform, the only thing that really matters is whether it works or not.
Second, code review is a required part of contributing to the project, as it is with almost [i]all[/i] large open-source projects. To put it bluntly, we [i]do not trust[/i] a coder asserting that their code is bug-free, because far too often they've missed something (which hopefully gets noticed during code review).
You don’t seem to have tried my build:
DOWNLOAD (25. May): MGSmod rev.44
…if you did you would have noticed that in few months I got it from the state of being crashing bag of bugs to the point where it runs fast, smooth, and without crashes or glitches of any kind, while in the same time you have doubled amount of bugs in your build. Apparently your code reviewing process not only fails to catch bugs, it also fails to recognize bug-fixes.
Hell, Kevin and I don't fully trust our [i]own[/i] code, because we know humans are fallible. It's not a good sign when your reaction to a failed initial review of your code is to insist that we take the code anyway, and then start flaming the other devs when the code in question is still rejected.
Computer hardware and software is deterministic and exact, like mathematics. 3+5 is always 8. There is nothing there you need or should “trust”, you either know, or you do not know.
FYI, I noticed the source code is right there in the zip file that he linked. Couldn’t someone simply review his latest implementation and decide it if it’s usable?
You have no idea how vociferously that’s been discussed already, I’m guessing. His codebase has diverged enough from ours that it would be a significant time sink to track down exactly what’s changed. When isolated pieces (which are easier to review) have been put forward, it’s been a mixed bag.
Last time I checked, his version also had graphical glitches under Linux (stuff not redrawing when it should, at a minimum), which is a significant problem.
Which is not to say that others can’t go through the code and put forth vanilla-suitable (i.e., non-MGS) bits for review, of course.
Although… actually, you remind me that there’s a mention of fire being somewhat more sensible in his mod now. THAT I might be interested in.
void DrawWindow(WINDOW *win)
RedrawWindow(WindowHandle, NULL, NULL, RDW_INVALIDATE | RDW_UPDATENOW);int werase(WINDOW *win)
// wrefresh(win);Two lines. Which line is mixing your bag?
All you have to do is remove the first and uncomment the second line to prove to yourself it is irrelevant to this bug.
And to prove to yourself what is causing the lag is indeed function I told you it is comment it out and see for yourself.
Don’t you have a PC at home? Why waste weeks trying to blame my code when it takes two minutes to test it?
Last time I checked, his version also had graphical glitches under Linux (stuff not redrawing when it should, at a minimum), which is a significant problem.
As I told you already:
http://www.cataclysmdda.com/smf/index.php?topic=541.msg12646#msg12646
… my build is optimised for Windows, it is not supposed to work on Linux at all, but I also gave you a link to my original bug-fix proposal which is intended to work on Linux and so it does without any glitches:
It was not merged, so I discarded optimisations and other secondary changes to point out the essence of the problem and how to fix it, which is completely isolated and independent of Linux build, it’s just those two lines:
RedrawWindow(WindowHandle, NULL, NULL, RDW_INVALIDATE | RDW_UPDATENOW);// wrefresh(win);That is what finally got merged and what you were supposed to have tried last. It was discussed and tested before it was merged, it did pass your code reviewing process:
https://github.com/TheDarklingWolf/Cataclysm-DDA/pull/925
I also then explained here:
http://www.cataclysmdda.com/smf/index.php?topic=1213.msg13897#msg13897
… that you still have to address those secondary changes, none of which has anything to do with this bug.
Although... actually, you remind me that there's a mention of fire being somewhat more sensible in his mod now. THAT I might be interested in.
mapdata.h
[code]struct field {
field_id type;
signed char density;
int age;
int lastUpdate;
field()
{
type = fd_null;
density = 1;
age = 0;
// lastUpdate= 0;
}
field(field_id t, unsigned char d, unsigned int a)
{
type = t;
density = d;
age = a;
// lastUpdate= 0;
}
[/code]
field.cpp
case fd_fire: {
//CAT-mgs: fire burn outside view
if(cur->lastUpdate > 10)
{
int trm= int(g->turn) - cur->lastUpdate;
if(trm < 1) trm= 1;
if(trm > 100)
cur->density= -1;
// g->add_msg("TRM: %d AGE: %d", trm, cur->age);
}
cur->lastUpdate= int(g->turn);
.
.What it does is to store the turn count a field was last updated and compares it with the current turn. The difference is supposed to always be 1 as it is updated every turn when in bounds of player’s view. Therefore if the difference is greater than 1 it means it was put on hold, went out of player’s view.
As you can see what I decided to do about it is to check if player spent more than 100 turns away from the fire before it returned to the place, and if so the fire turn off, as if it burned out in the meantime. From players point of view, if you want fire to burn and spread then stay nearby, if you want to put it off go away for at least 100 turns.
This of course can be done to work fully realistically, but it would cause glitches when you suddenly have to get fires up to date for the last 100 or more turns in a single turn, so I decided not to do it, but you can try and maybe the glitches will not be so terrible without need to render all those meanwhile updates but just the last state you end up with.
This fire method actually has quite a bit of merit as best as I can tell. I would suggest two small additions, however.
1)Add a “break;” after the “cur->density= -1;” line, there isn’t any need to keep evaluating the fire field if it’s gone.
2)Increase the needed turn count before it kicks in. Since 1 turn = 6 seconds, 100 turns is only 10 minutes, which isn’t enough time for any sizable fire to burn out (and with realistic burn times many small fires shouldn’t burn out in that time either). Personally I would suggest something around 600 turns (1 hour). Alternatively it could be based on current fire size (and potentially items present in the tile that could be consumed), something like 200 for a small fire, 400 for a medium one, and 600 for a large one.
Ideally the system would also run a quick check through the items of said fire upon reload, destroying any items that would have been destroyed already, though I’m unsure of exactly how much of a lag spike this could cause with large fires and a large number of items.
This fire method actually has quite a bit of merit as best as I can tell. I would suggest two small additions, however.
1)Add a “break;” after the “cur->density= -1;” line, there isn’t any need to keep evaluating the fire field if it’s gone.[/quote]
Yes, but what you really want to do is pull that code out of “case fire:” block so it applies to all fields and not just fire, and there is already some check there to abort the function if the field doesn’t need update.
2)Increase the needed turn count before it kicks in. Since 1 turn = 6 seconds, 100 turns is only 10 minutes, which isn't enough time for any sizable fire to burn out (and with realistic burn times many small fires shouldn't burn out in that time either). Personally I would suggest something around 600 turns (1 hour). Alternatively it could be based on current fire size (and potentially items present in the tile that could be consumed), something like 200 for a small fire, 400 for a medium one, and 600 for a large one.
I tested it with small but intense fire covering around 10x10 grass tiles. I verified it takes about 100 turns for it to burn out when I was standing nearby, so I used that number.
Be aware I haven’t done any other tests, and I think after I played the game later on and put a house on fire then went away for about two hours the house was still on fire when I came back, even though it wasn’t supposed to be. I’m lazy to look it up as I I’m sick of play-testing, I guess some items or tiles might have some flag indicating they are on fire so just turning fire off is not enough for them. If that is the case those items/tiles have to be updated as well, which is what you want to do anyway, so there you go.
Ideally the system would also run a quick check through the items of said fire upon reload, destroying any items that would have been destroyed already, though I'm unsure of exactly how much of a lag spike this could cause with large fires and a large number of items.
That wouldn’t cause additional lag beside the one fires are causing as it is, the code is already checking all those tiles and items that are on fire, so two more lines of code in the same loop will not make much difference. You simply jump to final state, you don’t have to gradually update it to figure out whether item or tile should be destroyed in certain amount of time. The problem, if you want to make it realistic, would be spreading of fire, as you would need to do it step by step through all the missed turns it went by being on hold.