0.5 uses less RAM

[Nopkar]

[quote=“Kevin Granade, post:38, topic:1214”][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]

sorry for the delay

When I start a new game and wait it begins slowdown about midway into season 2. save and load and the slowness is alleviated for about 2 or 3 waits and it jumps back to previous levels and continues to rise. I’m at year 4 and it’s about 4-5 minutes between waits. I’m in the evac shelter, haven’t moved an inch.

[Reservoir]

So been out for 2-4 days (got loads of stuff to do, exams, got terraria for 4 euros, tried to learn how to code stuff…)
So, did you guys find an actual fix? All I see in the last page is a fight over someone’s thing being something than someone’s other thing.

[size=5pt]Or we could just use Cata 556d as windows version…[/size]

[Soron]

Well, I’ve tried the remaining potentially-standards-compliant bits of LazyCat’s suggested code (removing InvalidateRect and the sleep calls from getch), and it doesn’t seem to have any significant improvement to the lag. That’s even true while reading, despite my suspicion that the many getch calls (for the newly-added interrupt feature) might be incurring some high overhead. Also, for reference, the refresh call in getch (i.e., the bit that’s in contention in LazyCat’s suggestion) is aborted early if the window in question isn’t marked for drawing, so it’s highly unlikely that not removing the refresh call is making much of a difference to lag.

So… I got nothin’.

What we really need, I think, is for someone to write a Windows renderer using tools that they understand well. I know that it’s possible to get much better performance, even with frequent redraws and real-time keyboard input. I mean, just look at any action game. So it’s presumably something about the way we’re doing things in Windows that’s causing issues.

[vultures]

Again, I will politely apologize for talking in a way that is defecting real efforts put in this game’s coming into life, but there are nice examples out there, and it is only natural one’s assuming that there are developers onboard that took time and reviewed those. It is expected to have slowdowns - remember those gaming days when just entering a room, or a small area took some time for game to recover from freeze? Even worse if the loader, or as you refer to it - renderer - copes with drawing the viewfield one instance of farend at a time. To be fair, some things seem to work instantly; frontend, that is - advanced inventory management seems flawless considering what it’s intended to do in the future. So much to say, this ain’t a 3d fps where response is critical, and those gamers that enjoy them surely have their sort of doubts about this game.
I will (figuratively speaking) point out for the last time that there is a bunch of roguelikes that managed to fulfill their aim, assuming that is public judgement. One of them is Dungeon Crawl’s fork tagged Stone Soup and it has, in my own opinion, went far in dealing with issues had here. It has its flaws, needless to point out, such as massive slowdowns when drawing after executing moresome AI behaviors. But, it is respected in the genre nevertheless.

I only hope you have as much fun putting your time into bringing CataDDA to life as the rest of us has when addressing the rights, and the wrongs of the same kind.

[Soron]

That’s a good point, actually - can we just lift rendering code from somewhere else? I know that Angband runs pretty well under Windows with ASCII rendering, and Stone Soup has some fast travel stuff (not teleportation) that probably indicate fast rendering times (and hopefully has a good ASCII Windows renderer).

I’m not sure how easy it would be to just slot those in, but it’s certainly worth investigating. Angband looks like it’s got a nice, self-contained win/ directory, written in C rather than C++.

Both of those are GPL-licensed, whereas we’re (for some reason…?) using CC-BY-SA, but I really hope that doesn’t cause incompatibilities.

[LazyCat]

[quote=“Soron, post:43, topic:1214”]Well, I’ve tried the remaining potentially-standards-compliant bits of LazyCat’s suggested code (removing InvalidateRect and the sleep calls from getch), and it doesn’t seem to have any significant improvement to the lag. That’s even true while reading, despite my suspicion that the many getch calls (for the newly-added interrupt feature) might be incurring some high overhead. Also, for reference, the refresh call in getch (i.e., the bit that’s in contention in LazyCat’s suggestion) is aborted early if the window in question isn’t marked for drawing, so it’s highly unlikely that not removing the refresh call is making much of a difference to lag.

So… I got nothin’.

What we really need, I think, is for someone to write a Windows renderer using tools that they understand well. I know that it’s possible to get much better performance, even with frequent redraws and real-time keyboard input. I mean, just look at any action game. So it’s presumably something about the way we’re doing things in Windows that’s causing issues.[/quote]

I don’t see there is any more lag than before even with the binary you released, except when near overmap borders. You first need to find out what lag are people talking about: what, how, when and where, exactly. I think all the reports are about the lag that happens only near overmap borders.

You can of course re-write the whole thing and improve performance hundreds of times. You just need OpenGL or whatever other API to gain access to hardware accelerated texturing. You then simply print your font in the texture grid or use some pre-drawn tile map image, and all you have to do then is to replace you current printchar() function and its friends with equivalent OpenGL calls that will blit ASCII symbol corresponding sub-texture to the back buffer. That way everything stays in video memory and doesn’t leave graphic card, hardware accelerated, lightning fast, and taking the whole drawing load off of CPU.

But, it was not lagging before, so it is something that can be fixed to be at least as good as before.

Tell you what, you put in my above ground z-levels in the game so Acidia can design more and I’ll give you lightning fast drawing code where you could use any ASCII symbols or whatever tile graphics just the same, with mixed font/tile sizes and arbitrary rotation, millions of colors, particle effects, transparency, motion blur… and what not. And I’ll do it in a week, it’s my expertise after all. Do we have a deal?

[Soron]

Two-part response to LazyCat, since I’ve got multiple roles.

As a developer:
People have been explicitly complaining about lag while reading and sleeping, and the original post in this thread specifically mentions those two activities. We have explicit reports that it’s not just the overmap border lag.

I also won’t ignore bugginess in submitted code just because you’re trying to bribe or sweet-talk me (although… good job trying something other than insults - I really do mean that, it’s nice to see some variety!). Each submission stands on its on merits.

As a moderator:
I’m going to ask that you stop trying to drag up the z-level discussion again, at least as long as you’re unwilling to listen to other people’s opinions. In particular, stop derailing other threads with your pet code that has already been rejected by 3 core devs.

[LazyCat]

[quote=“Soron, post:47, topic:1214”]As a developer:
People have been explicitly complaining about lag while reading and sleeping, and the original post in this thread specifically mentions those two activities. We have explicit reports that it’s not just the overmap border lag.[/quote]

Then you should have known from the start it has nothing to do with animations and my code.

I also won't ignore bugginess in submitted code just because you're trying to bribe or sweet-talk me (although... good job trying something other than insults - I really do mean that, it's nice to see some variety!). Each submission stands on its on merits.

There are no bugs in my code.

As a moderator: I'm going to ask that you [b]stop trying to drag up the z-level discussion again[/b], at least as long as you're unwilling to listen to other people's opinions. In particular, [b]stop derailing other threads with your pet code that has already been rejected by 3 core devs[/b].

Does that mean you do not want lightning fast drawing code where you could use any ASCII symbols or whatever tile graphics just the same, mixed tile size & arbitrary rotation, millions of colors, particle effects, transparency, motion blur… and what not. Yes, no?

[Soron]

sigh The OP confirmed, in the first page of this thread, that your animation-related code was causing the lag we’re seeing. That’s twice in two posts that you’ve ignored important information from the first page of the thread; I would really appreciate it if you would actually read what other people write.

Moderator-mode again.
Also, last warning: Drop the unproductive z-level discussion, or I will moderate posts as necessary to keep the thread on-topic. I’m also going to ask that you try to contribute productively to this thread, if you keep posting in it.

[Nopkar]

I am assuming this game has been developed for a single core environment, but i’m wondering how difficult it would be to add in multi-core support? just a question

I also see complaints from the core devs about the state of the code base and the way things are written. GlyphGryph stated at one point about a code rewrite am I correct? I figure this would be a good place to mention that and figure out how (if at all) well that can resolve some of the issues with lag we’re facing?

clean code is efficient code! (former programmer back in the day used that as his motto, dunno how it holds up though)

[Soron]

Having the game take advantage of multiple cores would be useful for users on multi-core systems, yes. However, I know that Kevin’s got a fairly low-powered machine, and has said that he wants to make sure that his machine still runs Cataclysm decently. But that’s not to say that we can’t go multi-core when appropriate (and actually, running the catacurse stuff in a separate thread might help immensely…)

Wait. We’re running the low-level window rendering code in the same thread as the game logic. …Is that normal? I kind of get the feeling that THAT might be contributing to our problems… although I don’t know if the repaint happens in the same thread or not.

I also see complaints from the core devs about the state of the code base and the way things are written. GlyphGryph stated at one point about a code rewrite am I correct? I figure this would be a good place to mention that and figure out how (if at all) well that can resolve some of the issues with lag we’re facing?

Yeah, we’re updating stuff piecemeal, because (a) handling little bits is hopefully less likely to break things, and (b) rewriting from scratch can take a looong time. GlyphGryph started rewriting the item system pre-0.4, and we’re still not done with it.

Mind you, if there’s a practical reason to rewrite something, then yes, it’s worth doing.

[Nopkar]

Wait. We’re running the low-level window rendering code in the same thread as the game logic. …Is that normal? I kind of get the feeling that THAT might be contributing to our problems… although I don’t know if the repaint happens in the same thread or not.

so that could be a source of our problems?

and adding multi-core support wouldnt put single cores at a disadvantage, just help those of us with a larger multi core processor clocked at a lower speed per-core than the single ones.

again, i don’t know how hard that is to code but might be an idea. and maybe the efficiency of cpu usage might need to be looked at? I know running lots of information across a single thread is bad practice.

[Soron]

I honestly don’t know whether running rendering in the same thread as game logic is causing our issues or not, but now that you’ve mentioned it, I AM leery about running the low-level rendering stuff in the same thread as the game logic (since it could mean that game logic ends up being FPS-capped).

And yeah, I’m aware that multi-core support doesn’t disadvantage single-core computers. Just pointing out that we want to ensure some degree of playability on single-core, where possible.

[LazyCat]

sigh The OP confirmed, in the first page of this thread, that your animation-related code was causing the lag we’re seeing. That’s twice in two posts that you’ve ignored important information from the first page of the thread; I would really appreciate it if you would actually read what other people write.

bool game::do_turn()
{
.
.

 if (u.has_disease(DI_SLEEP) && int(turn) % 300 == 0) {
  draw();
  refresh();
 }

void game::process_activity()
{
.
.
  if (int(turn) % 150 == 0)
   draw();

During activities screen is updated only every 150 turns, and 300 turns when sleeping. Do you understand now why my animation code can not possibly be cause of any lag there? How is it not clear to you the game would be lagging all the time if it was animation code that is causing the lag? Ughh.

Moderator-mode again. Also, last warning: Drop the unproductive z-level discussion, or I will moderate posts as necessary to keep the thread on-topic. I'm also going to ask that you try to contribute productively to this thread, if you keep posting in it.

I take that means you do not want that super fast drawing code I offered to make for you. Never mind.

[LazyCat]

I honestly don’t know whether running rendering in the same thread as game logic is causing our issues or not, but now that you’ve mentioned it, I AM leery about running the low-level rendering stuff in the same thread as the game logic (since it could mean that game logic ends up being FPS-capped).

No, this is turn based, single player, no network game. Having more than one thread on single CPU could only slow this game down. You can not draw anything until you have processed the logic for the turn anyway.

As I explained before one of performance related problems in you code are simple redundancy, you are drawing, erasing and refreshing screen in many places where you shouldn’t. The other performance killing thing is that you have interleaved drawing and logic code. You need to do all the logic first and then draw everything at once, not mix it all together.

[Soron]

As per this post, we have a report that the lag was not present just before your animation code was merged in, and was present just after your changes were merged in. Hence, the obvious explanation (not necessarily the correct one, but the obvious one) is that your code is related to the lag. Now, we LIKE having animations under Windows, so we’d prefer to fix your code rather than revert it, but it still remains that there’s pretty strong evidence your code is related to the lag.

[LazyCat]

As per this post, we have a report that the lag was not present just before your animation code was merged in, and was present just after your changes were merged in. Hence, the obvious explanation (not necessarily the correct one, but the obvious one) is that your code is related to the lag. Now, we LIKE having animations under Windows, so we’d prefer to fix your code rather than revert it, but it still remains that there’s pretty strong evidence your code is related to the lag.

I’m informing you of the facts, I tested it myself many times in both vanilla and my build. You keep assuming and relying on random people opinions while you never tested it yourself. If you are unable to test it you shouldn’t be concerning yourself with this problem in the first place.

I don’t see any lag in either version. I suppose people who never saw animations before got used to see only one screen update at the end of activity, and now when they see several updates in coarse steps of 150/300 turns it appears to them as the game is glitching.

I changed drawing updates in my mod to be every 10 turns, and it works smooth and fast, therefore drawing function is not even the bottleneck there. Try it, test it.

I’ve seen some people even said they would like to turn driving animation off, completely oblivious that is actually taking the same time, but somehow one update where a car jumps all the way after long pause appears to them smoother/faster than gradual movement even if it takes the same time to complete.

[LazyCat]

I tested wrong binary. Studying book is actually terribly slow, and the whole game is slower, but waiting and sleeping seem slow the way they are supposed to be.

[LazyCat]

Offender function:
handle_key_blocking_activity();

[GlyphGryph]

Mod Action: Removed arguing and insults tangent. Keep it civil.