0.5 uses less RAM

[Soron]

Awesome, thanks Nopkar :).

[Nopkar]

alright, i’ve tested it just a bit but so far certain things seem to be a little smoother (reading, sleeping and repeating crafting in the same spot)

I’ll test it more rigorously as I go as I eliminate variables and all that, haven’t been home very long!

if anyone can mirror my tests it’d help us out! right now i’m just reading books over the course of an entire day in small rooms, small rooms with multiple exits, medium rooms, large rooms, outside, during the rain etc etc.

basically testing the extent of the new scent code

[vultures]

After some testing related to a different issue: wow, the Windows version is slow. I can only assume that it's due to inefficient rendering, because rendering is presumably the main difference between the two versions. So... anyone know anything about efficient rendering under Windows? Or do we need to rewrite all this for SDL or something?

I don’t mean to pry, but as for now all I can see is the common limitation regarding windows-base systems, called CPS (character-per-second) which is used for relying on drawing the screen. The system is simply using too much text at a time instance, rather than accessing a full graphic library and its functions.
Regarding testing request, I am using a slow (that is, very) machine and my judgement would go highly irrelevant considering the game is just calling for CPU time and writing disks.

[Soron]

Awesome Nopkar, that’s enough for me to consider the scentmap optimization a moderately high-priority pull request.

I don’t mean to pry, but as for now all I can see is the common limitation regarding windows-base systems, called CPS (character-per-second) which is used for relying on drawing the screen. The system is simply using too much text at a time instance, rather than accessing a full graphic library and its functions.

So, our current text-based rendering method is inefficient? Do you know if Windows has a more efficient method for rendering text in a grid? Or, for that matter, do you know of anything that doesn’t require a full port to SDL? (granted, we probably want to use SDL eventually anyway)

[Narc]

[quote=“Soron, post:24, topic:1214”][…]do you know of anything that doesn’t require a full port to SDL? (granted, we probably want to use SDL eventually anyway)[/quote]libTCOD emulates a character console rendered by SDL (or, alternatively, GLSL or OpenGL, with slightly fewer features, IIRC).

[Nopkar]

alright, spent a couple hours testing the scent map and it’s got my approval. after 2 or 3 seasons in the same spot however the game slows back down to before I applied the workaround.

How far does scent extend on the map? even with a completely undiscovered map it seems like it leaked out of my vision range and just kept going, increasing the calculations exponentially.

[LazyCat]

[quote=“Nopkar, post:3, topic:1214”]I’m not having these slowdowns really, apart from the short tick (2-5sec) between book readings and a bit longer (4-8sec) for sleeping

what are you considering substantial lag?

the worst for me is the 2-5 sec delay when at speed in a vehicle…I’d like THAT to be smoother but meh.[/quote]

Open ‘map.cpp’’, find this block of code and delete it:

/*
   if (pl_ctrl && veh->velocity) 
   {
      // a bit of delay for animation
      // total delay is roughly one third of a second.
      int ns_per_frame = abs ( (BILLION/3) / ( (float)veh->velocity / 1000) );
      if (ns_per_frame > BILLION/15)
         ns_per_frame = BILLION/15;
      timespec ts;   // Timespec for the animation
      ts.tv_sec = 0;
      ts.tv_nsec = ns_per_frame;

      nanosleep(&ts, NULL);
   }
*/

[LazyCat]

Right, so… until someone decides to actually do Windows rendering right… do we care more about animations under Windows, or the ability to have stuff open in the background? Because the animation-enabling fix apparently still has some lag, albeit less than when it was first proposed :-/.

Animations have nothing to do with it, plus you didn’t merge all of it. Of course animations are what is right, and disabling them will not help you have more “stuff open in the background”, whatever purpose is that supposed to serve.

How do you imagine my build runs without glitch, freeze or crash, and 30% faster if I’m not doing it right?

[Soron]

Removing (or at least reducing) that vehicle animation delay actually seems to improve the experience under Linux, which is unusual for LazyCat’s performance suggestions. It seems a little fast when I’m driving at speed through crowded streets, but that might just be because I’m not used to the zombies zipping past like that.

Can anyone think of a reason why that animation delay is beneficial? Because I am actually tempted to open up a pull request which removes that bit of code as being detrimental.

Animations have nothing to do with it, plus you didn’t merge all of it.

We’ve identified your code as causing slowdown (fixed a rendering bug but caused performance issues), by comparing behavior just before and just after your code was merged in.

And we will NOT be merging in your change to getch() that breaks compatibility with the curses standard, we’ve been over this before >_<. It will just lead to more bugs on Windows down the line, due to ncurses-based devs implementing standards-compliant code which your proposed change isn’t built to handle.

[LazyCat]

We’ve identified your code as causing slowdown (fixed a rendering bug but caused performance issues), by comparing behavior just before and just after your code was merged in.

Obviously then you have identified it wrong. In any case, if you have performance issue you need to optimize, not to get bugs back in the game.

And we will NOT be merging in your change to getch() that breaks compatibility with the curses standard, we've been over this before >_<. It will just lead to [i]more[/i] bugs on Windows down the line, due to ncurses-based devs implementing standards-compliant code which your proposed change isn't built to handle.

No, it does not break any getch() compatibility. You are simply oblivious Linux have different rendering pipeline.

Why do you keep thinking I care whether you will merge any of my code or leave your game lame? You need to help yourself, not me, my build is working without any glitch, freeze or crash, and it’s 30% faster. Wake up.

[Soron]

[quote=“Soron, post:29, topic:1214”]We’ve identified your code as causing slowdown (fixed a rendering bug but caused performance issues), by comparing behavior just before and just after your code was merged in.

Obviously then you have identified it wrong.[/quote]

Re-read the bolded bit.

And yes, I agree that we need to optimize. The question is whether people prefer slow, less-buggy code; or faster, buggier code.

No, it does not break any getch() compatibility. You are simply oblivious Linux have different rendering pipeline.

I pointed you to the specs in question last time, and left a comment in the function pointing to the specs. If there is a compelling reason why we should break standards compatibility with the Windows build, we might consider it, but you need to actually provide evidence.

Why do you keep thinking I care whether you will merge any of my code or leave your game lame?

Most recently, because you started a lengthy argument where you basically demanded that we merge in your z-level code >_>.

[deadmerits]

I hate to speak out of turn but maybe it’s come time to find out whether we have more Linux users or more Windoze (I know I know so 1999) users. I don’t know anything about coding but if we need to take two different forks for the operating systems it’d be better to find out sooner then later.
I don’t really know, I’m just a regular windows user who plays this game like its real life and my life is a game I have to play

[LazyCat]

Re-read the bolded bit.

Merge it properly and re-do your profiling. If you do what I explained here:

http://www.cataclysmdda.com/smf/index.php?topic=1213.msg13786#msg13786

…with the version current at the time of that post, you can only find out that it is a bit faster, not slower.

I pointed you to the specs in question last time, and left a comment in the function pointing to the specs. If there is a compelling reason why we should break standards compatibility with the Windows build, we might consider it, but you need to [i]actually provide evidence[/i].

That’s not standard, that’s kernel specific. If it was broken it would not work, it would not enable animations. Having glitches and freezouts is what is not standard, or is it now? Just because specs say getch() may invoke screen redraw on some particular platform in no way means you need to put refresh() call in your function for reading input. You should never, ever do that, it does not belong there, especially when using Windows API which has its own machinery and timing rules when to process input and how to synchronise screen refresh.

Most recently, because you started a lengthy argument where you basically demanded that we merge in your z-level code

I’m simply trying to help, but I don’t mind if you don’t listen, it actually makes it more interesting.

[i2amroy]

[quote=“Soron, post:29, topic:1214”]Removing (or at least reducing) that vehicle animation delay actually seems to improve the experience under Linux, which is unusual for LazyCat’s performance suggestions. It seems a little fast when I’m driving at speed through crowded streets, but that might just be because I’m not used to the zombies zipping past like that.

Can anyone think of a reason why that animation delay is beneficial? Because I am actually tempted to open up a pull request which removes that bit of code as being detrimental.[/quote]
I’m fine with removing it. I was a bit puzzled at the animation delay myself when I first found it in the code, and there recently was a forum post in the Bay12 Cataclysm thread with a poster who was requesting how to remove that particular animation since they didn’t want it slowing down their game, so I’m all for it.

Also while I don’t agree with some of LazyCat’s other stuff, I do agree with the fact that we should probably make it so that rain stops when the player isn’t doing anything (though I might not agree with his implementation, I haven’t checked it out yet). It’s a little akward to watch the rain change speeds as I draw upon more game power and then speed back up again while I’m not moving and time is supposedly stopped.

[Soron]

Actually, wait… we only know that the refresh() call in getch is mandated by the curses standard, and only sometimes. But that InvalidateRect call is Windows-specific, and might explain why reading has slowed down. Can someone remove that, and see what it does for performance? Possibly also the sleep call.

And LazyCat, this is why I really wish that you would actually listen to criticism of your code. We would likely have tested that a lot sooner if you had actually accepted that part of catacurse’s job is to implement the curses standard (which sometimes requires refresh(), but doesn’t say anything about platform-specific stuff like InvalidateRect).

[quote=“deadmerits, post:32, topic:1214”]I hate to speak out of turn but maybe it’s come time to find out whether we have more Linux users or more Windoze (I know I know so 1999) users. I don’t know anything about coding but if we need to take two different forks for the operating systems it’d be better to find out sooner then later.
I don’t really know, I’m just a regular windows user who plays this game like its real life and my life is a game I have to play[/quote]

Well, the plan is to target ALL platforms, or at least as many as we’re able to. And although most of the core devs are Linux users, we do have one Windows user. IMO, the issue is that LazyCat seems to be the only one who’s investigating performance issues under Windows, but he doesn’t care whether his stuff works under Linux, and seems to favor shotgun debugging (which is not the best method of fixing things). And has attitude issues, but honestly, if he gave us code that was a significant and obvious improvement without breaking Linux compatibility, I wouldn’t mind the attitude so much.

[LazyCat]

Actually, wait… we only know that the refresh() call in getch is mandated by the curses standard, and only sometimes.

You are confusing standards with functionality and platform specific implementation.

There is a reason why Linux and Windows don’t use the same libraries for low level keyboard access and screen buffer functionality, and why none of getch()/clrscr() functions are part of C standard library, ISO C or defined by POSIX. It’s not any standard but kernel specific. It is why “curses” getch() and “conio” getch() must be implemented differently in order to achieve the same functionality.

...and only sometimes.

What times?

But that InvalidateRect call is Windows-specific, and might explain why reading has slowed down. Can someone remove that, and see what it does for performance? Possibly also the sleep call.

Having it is surely not improving performance, but the reason you want to remove it is because it serves no good purpose, and as such it can only cause problems.

And LazyCat, this is why I really wish that you would actually listen to criticism of your code. We would likely have tested that a lot sooner if you had actually accepted that part of catacurse's job is to implement the curses standard (which sometimes requires refresh(), but doesn't say anything about platform-specific stuff like InvalidateRect).

Your code does not work, my code works and it does not impair performance, it improves it. You are not in position to criticise my code, especially when there is nothing to criticise. Your assumptions about what is required or not are unnecessary, you only have to try it out to see what works and what doesn’t work.

[i2amroy]

Your code does not work, my code works and it does not impair performance, it improves it. You are not in position to criticise my code, especially when there is nothing to criticise. Your assumptions about what is required or not are unnecessary, you only have to try it out to see what works and what doesn’t work.

Just because a particular method works when the current one does not does not mean that said method is above criticism. If my current goal is to get from point A to point B quickly and somebody creates a method that involves a giant catapult flinging me through the air to my destination, yes, said method works when the current one (walking) would fail, but that doesn’t mean that the catapult idea is above criticism (personally I can think of much better ways to move quickly from point A to B then a catapult and would happily criticize said catapult method).

Also when said method is an integral part of a whole (say I was trying to make a public transport system to connect several points) it is important to consider several other factors as well. Does the catapult comply with current transportation safety regulations? Can the catapult interface with current systems? Will a system based on catapults be able to be easily expanded to deal with future traffic? If something is changed in the other parts of the system will the catapult misfire and kill whoever it was launching? Can people even survive the catapult trip unharmed?

While the fact that code works is a major concern for implementing code, but it is by far from the only concern. To quote several of the computer professionals I have talked to “whether a programmers code is readable, easily understood, follows standards, and is able to be modified to work with past, present, and future systems is much more of an important hiring factor then whether or not their code actually works”. Just because a giant catapult moves me quickly from point A to B is not necessarily a reason why we should start using giant catapults for public transit, especially when through a little effort a method that accomplishes the same task that doesn’t have the same problems may be created (say a train system), and in the long run you may end up spending less time by taking the required time to actually look at several possible solutions prior to just implementing the first one available.

[kevin.granade]

[quote=“Nopkar, post:26, topic:1214”]alright, spent a couple hours testing the scent map and it’s got my approval. after 2 or 3 seasons in the same spot however the game slows back down to before I applied the workaround.

How far does scent extend on the map? even with a completely undiscovered map it seems like it leaked out of my vision range and just kept going, increasing the calculations exponentially.[/quote]

The scent map is only tracked in a radius 40 square centered on the player, and it never grows beyond that. If a monster checks the scent while outside that area, there’s an override in the access method that returns 0. If there’s something that’s slowing down over time, I’m pretty sure it’s not the scent code. Does the slowdown you’re seeing persist across save/load cycles? In other words, can you start a game, wait through several seasons, see the slowdown, save, exit, restart the game, load, and the slowdown is immediately present?

[quote=“i2amroy, post:34, topic:1214”][quote=“Soron, post:29, topic:1214”]Removing (or at least reducing) that vehicle animation delay actually seems to improve the experience under Linux, which is unusual for LazyCat’s performance suggestions. It seems a little fast when I’m driving at speed through crowded streets, but that might just be because I’m not used to the zombies zipping past like that.

Can anyone think of a reason why that animation delay is beneficial? Because I am actually tempted to open up a pull request which removes that bit of code as being detrimental.[/quote]
I’m fine with removing it. I was a bit puzzled at the animation delay myself when I first found it in the code, and there recently was a forum post in the Bay12 Cataclysm thread with a poster who was requesting how to remove that particular animation since they didn’t want it slowing down their game, so I’m all for it.

Also while I don’t agree with some of LazyCat’s other stuff, I do agree with the fact that we should probably make it so that rain stops when the player isn’t doing anything (though I might not agree with his implementation, I haven’t checked it out yet). It’s a little akward to watch the rain change speeds as I draw upon more game power and then speed back up again while I’m not moving and time is supposedly stopped.[/quote]

How about adding an animation delay option? setting to 0 would disable the delay, and otherwise it would scale all of the animation delays.

We can either disable the animation, or perhaps throttle it when doing something that takes a long time, like we do with map redraws.

[LazyCat]

[quote=“i2amroy, post:37, topic:1214”]Just because a particular method works when the current one does not does not mean that said method is above criticism. If my current goal is to get from point A to point B quickly and somebody creates a method that involves a giant catapult flinging me through the air to my destination, yes, said method works when the current one (walking) would fail, but that doesn’t mean that the catapult idea is above criticism (personally I can think of much better ways to move quickly from point A to B then a catapult and would happily criticize said catapult method).

Also when said method is an integral part of a whole (say I was trying to make a public transport system to connect several points) it is important to consider several other factors as well. Does the catapult comply with current transportation safety regulations? Can the catapult interface with current systems? Will a system based on catapults be able to be easily expanded to deal with future traffic? If something is changed in the other parts of the system will the catapult misfire and kill whoever it was launching? Can people even survive the catapult trip unharmed?

While the fact that code works is a major concern for implementing code, but it is by far from the only concern. To quote several of the computer professionals I have talked to “whether a programmers code is readable, easily understood, follows standards, and is able to be modified to work with past, present, and future systems is much more of an important hiring factor then whether or not their code actually works”. Just because a giant catapult moves me quickly from point A to B is not necessarily a reason why we should start using giant catapults for public transit, especially when through a little effort a method that accomplishes the same task that doesn’t have the same problems may be created (say a train system), and in the long run you may end up spending less time by taking the required time to actually look at several possible solutions prior to just implementing the first one available.[/quote]

Can you actually point any problem with my code or not? There is only several lines worth of changes, so what line(s) do you have a problem with and what do you suggest is better?

[i2amroy]

I’m not criticizing your code. I’m responding to the fact that you are automatically assuming that your code is above criticism or potential problem consideration simply because it “works”.

To tell the truth I don’t have a problem with the coding that you have presented, the problem I have is with your attitude towards other devs. If you wish, then imagine this statement as a kindly request to no longer make statements that automatically assume your solution is the only method that should be utilized without having made an effort to consider the other opinions presented, or that the ideas thrown out by other devs are worthless without explaining why said options are not useful ideas.

If you wish for a more in-depth examination of my particular view on your attitude, I will be happy to provide you with one through the PM system, all you need to do is send me a PM requesting it.

[hr]

How about adding an animation delay option? setting to 0 would disable the delay, and otherwise it would scale all of the animation delays.

I can see an option, but I’m not sure we need much more then a On/Off option (Maybe with a “Fast” option as well that halves them). As is I don’t really see any need to create options for increasing the animation delay, only shortening it.