Cataclysm: Metal Gear Solid

Game Talk The Lab
61

[quote=“kilozombie, post:59, topic:528”]I’ve been checking this thread a lot and I still love what you’ve done.

But please

“That’s all it takes for Cataclysm to top the charts and become the best roguelike of all, almost as good as Cataclysm: MGS itself.”

Do you know how pretentious you sound?[/quote]

You should have seen my song: “I know the best, it’s what I do. I see the future, I know kung-fu. Make no mistake, I’m right, you’re not. I’m super, I’m cool, and I know a lot…” How’s that? Pretentious, humorous? Depends how you look at it. All I know it’s the truth, the song is right. Believe it!!

Fucking Christ, you think your mod for a game is [i]better than the best roguelike of them all?[/i] You think your (somewhat small) coding changes and expansions will ROCKET it to the top of the "charts"?

You don’t believe? I find your lack of fate disturbing. Believe it!!

And please don't get me started on the square font. You, for some reason, think that people can't have opinions (unless it's your opinion). Things like "Square font is 1000x better" and "But how can you?! It's worse!" are not only demeaning, they're downright moronic. People can have their own opinions.

You better believe it, now!!

62

I would like to believe that’s sarcasm, but it’s so butchered and strange that I can’t tell either way.

63

[quote=“LazyCat, post:53, topic:528”][quote=“nadia911, post:47, topic:528”]More buildings please, boats, abandoned cars, rails, trains and stations, airports and aircraft, more more more more!!!

Thanks Lazy[/quote]

Maybe if you will help me to test it, to play it for at least one hour each day and report the bugs. And I’ll make you terrain/building editor so you can design/draw all that stuff and new buildings yourself, and as you make them I’ll put them in the game. Ok?[/quote]

I played almost 4 hours a day, a week ago and have not had a single error, or did not see …
The idea of an editor is excellent, I offer to prove it, work with it and report bugs, if I see them, but my programming knowledge is zero.

64

Alright, I’ve looked into the catacurse.cpp fixes a bit more, in particular the reimplementation of getch() and moving InvalidateRect from that function into the DrawWindow function.

First off, I noticed that you’re redrawing the entire window every time you repaint even a small part of the window. That probably explains some of the flickering you saw when you first made that change. To fix that, you should probably use the second arg to InvalidateRect (lpRect, defines the dirty area), rather than leaving it null. See the MSDN documentation. You may also want to move that InvalidateRect call into the for loop, so that you can target only the areas that have actually changed.

After making those modifications to your version of DrawWindow and getch, I was able to get a Windows user on IRC to test it for me. He was using MSVC, and having it make optimized builds. He reported that in the vanilla build, stuff worked just fine. In the modified build, everything was about the same, except that hit animations wouldn’t complete (it would show the red box, as normal, and then fail to reset to the normal screen state). However, pressing a button apparently fixed it.

That suggests to me that having getch redraw the window may actually be intended behavior, because it works just fine on the Linux version. After all, ncurses is a lot better tested and more robust than catacurses, and afaik catacurses is a Windows emulation of ncurses, so I tend to consider ncurses to be correct in cases where they differ. And… yeah, a documentation page for the ncurses getch implementation indicates that wrefresh is called if necessary. So, refreshing the window in getch() is actually intended behavior, and your catacurses implementation is out of compliance with ncurses :-/.

The changes you made to window refreshes and such are, as I’ve said, demonstrably broken under Linux (possibly due to the non-compliant catacurses emulation of ncurses?), so can’t be merged in as-is. At a minimum, they’d require editing to get back to correct behavior under Linux. I get the feeling that they’ll also be time-consuming to isolate, since the relevant code is strewn all over the place, as you correctly pointed out.

Which, if I’m not mistaken, leaves the missile silo fix, the enhancements that you’ve just mentioned, and assorted miscellanea. The missile silo fix has been submitted to Github, although I don’t know what the status of that is. The enhancements need to contend with other things on peoples’ to-do lists. I’d like to remind people that the Github issue tracker is the first thing that devs tend to go for, followed by the subforums for bug reports and suggestions. So, if there’s something that somebody really wants to see in mainline, it might be a good idea to post something in one of those three places.

So… yeah. Interesting ideas, and some drawing changes that make the game work better on Windows and worse on Linux. Unless someone volunteers to merge in the vanilla-appropriate stuff from this mod, though, the best way to get the good parts into mainline DDA would be to bring it up on the suggestions/bug reports subforums, or the Github issue tracker.

65

It’s not me who wrote that, it is the same call you have in your code. It makes no visual difference and performance could actually be worse with background erasing disabled. Have you tried it, have your tested it and measured performance? Why are you suggesting me assumptions pulled out of your hat?

If you look more carefully dirty area redraw, the one that actually matters, is handled elsewhere. You should also see many redundant refresh calls around there, as well as in many places in game.cpp and everywhere, that is what you need to look at if wish to optimise.

I have nothing to fix, everything works fine in my build, there is no any flickering. You are talking about my code and you never even tried it out properly, on Windows. You shouldn’t be imagining bugs in my code when you have actual bugs to worry about in your code.

After making those modifications to your version of DrawWindow and getch, I was able to get a Windows user on IRC to test it for me. He was using MSVC, and having it make optimized builds. He reported that in the vanilla build, stuff worked just fine. In the modified build, everything was about the same, except that hit animations wouldn't complete (it would show the red box, as normal, and then fail to reset to the normal screen state). However, pressing a button apparently fixed it.

You should not modify my code, it works exactly as it should like it is. Vanilla DDA Windows build does not work just fine, it doesn’t work at all. Try to drive a vehicle or explode C4, try to fire a shot or burst, try to wait or sleep, and you will see nothing but freezes and glitches. You will see no bullets, no explosions, no shrapnel, no animation at all. Also notice how driving actually takes more real time to get you from A to B than walking on foot, it’s horrible.

That suggests to me that having getch redraw the window may actually be intended behavior, because it works just fine on the Linux version. After all, ncurses is a lot better tested and more robust than catacurses, and afaik catacurses is a Windows emulation of ncurses, so I tend to consider ncurses to be correct in cases where they differ. And... yeah, a [url=http://linux.die.net/man/3/getch]documentation page for the ncurses getch implementation[/url] indicates that wrefresh is called if necessary. So, refreshing the window in getch() [i]is[/i] actually intended behavior, and your catacurses implementation is out of compliance with ncurses :-/.

If so then it is obviously refreshing under some conditions catacurses does not emulate properly. What would you rather have, compliance with ncurses or properly working game? You can have both, but I can’t be bothered with it.

The changes you made to window refreshes and such are, as I've said, demonstrably broken under Linux (possibly due to the non-compliant catacurses emulation of ncurses?), so can't be merged in as-is. At a minimum, they'd require editing to get back to correct behavior under Linux. I get the feeling that they'll also be time-consuming to isolate, since the relevant code is strewn all over the place, as you correctly pointed out.

Nothing is broken, just extra optimised for Windows. Around dozen lines need to be changed to make the same source compile into properly working binary on both Linux and Windows. Time consuming and all over the place, yeah. But it was not me who put those bugs there and everywhere. It indeed took me some time to fix it, so now it should be much easier for you.

Which, if I'm not mistaken, leaves the missile silo fix, the enhancements that you've just mentioned, and assorted miscellanea. The missile silo fix has been submitted to Github, although I don't know what the status of that is. The enhancements need to contend with other things on peoples' to-do lists. I'd like to remind people that the Github issue tracker is the first thing that devs tend to go for, followed by the subforums for bug reports and suggestions. So, if there's something that somebody really wants to see in mainline, it might be a good idea to post something in one of those three places.

So… yeah. Interesting ideas, and some drawing changes that make the game work better on Windows and worse on Linux. Unless someone volunteers to merge in the vanilla-appropriate stuff from this mod, though, the best way to get the good parts into mainline DDA would be to bring it up on the suggestions/bug reports subforums, or the Github issue tracker.

Those changes make the game run better on both Windows and Linux. To make it compatible with Linux extra Windows optimisation needs to be disabled.

66

Is this updated to 0.4? Getting the sinew bug again.

67

Lazycat, honestly you don’t need to fucking bloat about how great your “new” graphics are and such. We get it. You think it’s 100% better in every way. Too fucking bad, we have to fix the bugs, not feed your ego.

By the way, cars are faster in vanilla. They save you in-game time. While I would like it to look better (and the camera following in front of vehicles is a start) they are not slower in the vanilla game.

68

The entire purpose of catacurses is to be a Windows implementation of the curses API, or at least the parts we use. Mind you, most of the top devs use a well-tested, compliant implementation of the curses API. Hence, most of the top devs will probably continue to work on the standards-compliant version.

If you want to use it in a project you’re claiming ownership of, one where you don’t care about matching standard implementations? Sure, go ahead. Again, that’s what forks are meant for: is cases where someone wants to make changes that are incompatible with the parent project.

Good luck with your project.

69

Not everything. What’s the bug with sinew?

70

My full name is “The Amazing Lazy Cat”, but you can call me just Cat, or lazy, because I already know that I am amazing.

By the way, cars are faster in vanilla. They save you in-game time. While I would like it to look better (and the camera following in front of vehicles is a start) they are not [i]slower[/i] in the vanilla game.

Cars in vanilla Windows build are not traversing any distance in between two turns, instead the game freezes and glitches until finally just displays the car in final position at the end of the turn. As if that wasn’t bad enough there is also a part of the code that intentionally slows down this non existing animation making driving slower in real time than walking on foot.

71

The entire purpose of catacurses is to be a Windows implementation of the curses API, or at least the parts we use. Mind you, most of the top devs use a well-tested, compliant implementation of the curses API. Hence, most of the top devs will probably continue to work on the standards-compliant version.[/quote]

Your current implementation doesn’t even start to begin to qualify to even be considered for any compliance or standards, it does not work. No bullets, no explosions, no shrapnel, no sleeping, waiting or driving animation at all, just glitching. What kind of standard is that?

If you want to use it in a project you're claiming ownership of, one where you don't care about matching standard implementations? Sure, go ahead. Again, that's what forks are [i]meant[/i] for: is cases where someone wants to make changes that are incompatible with the parent project.

Good luck with your project.

Only working code can follow or not follow standards, not working code breaks all standards by not doing what is supposed to do. My changes are compatible with the parent project, just extra optimised for windows.

So you are just going to ignore the game is not working properly? And they call me lazy?! Sheesh, mamma! All you have to do now is realize where the problem is and you can easily make it compatible with Linux by only changing two lines of code, and if you don’t wish to optimise simply forget about the rest.

STEP 1.

In catacurse.cpp, function: void DrawWindow(WINDOW *win)

  • place this line at the very end of that function:
    RedrawWindow(WindowHandle, NULL, NULL, RDW_INVALIDATE | RDW_UPDATENOW);

STEP 2.

In catacurse.cpp, function: int werase(WINDOW *win)

  • comment out this line, like this:
//    wrefresh(win);

STEP 3. (bonus)

In map.cpp, function: bool map::vehproceed(game* g)

  • comment out this block, like this:
/*
   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, 0);
   }
*/
72

I sense much bickering within this thread. I am displeased.

73

Not everything. What’s the bug with sinew?[/quote]

Getting a single stack of 6 sinew out of a butchered animal instead of 6 stacks of 10 as intended.

It was in 0.3 and fixed in 0.4.

74

[quote=“Morrigi, post:73, topic:528”]Getting a single stack of 6 sinew out of a butchered animal instead of 6 stacks of 10 as intended.

It was in 0.3 and fixed in 0.4.[/quote]

So when you examine to pick them up sinew should take up six letters, but if you select to pick up only one letter with sinew you will get a bunch of 10, so 60 sinew all together if you select to pick up all six letters? Isn’t that too much? What do you need that much sinew for?

75

(Had to do it).

(Edit and yeah this is a joke, lazycat has a point that stuff should work. But sadly it applies to both him with the version not working in linux, and the main version not having animations in windows).

76

Sinew = Thread

6 sinew from one animal is not enough, 60 for a deer is accurate, rewarding and not OP.

77

I just explained in previous post how to make animations on Windows work in easy two steps. Modification is within catacurse.cpp so of course it works on Linux as those changes make no difference for Linux binary at all. Everything else works on Linux naturally since it’s completely platform independent.

78

[quote=“kilozombie, post:76, topic:528”]Sinew = Thread

6 sinew from one animal is not enough, 60 for a deer is accurate, rewarding and not OP.[/quote]

79

Animations work perfectly fine on my Windows laptop

Also, I have been experiencing a bit of gun-related oddities lately. Whenever I try to shoot, the aiming cursor tends to move to the ammo type’s maximum range (which is normally between 14-57 tiles) to the northwest of me. Often times, the view-port goes black, the game freezes at 100% CPU usage, and I’m forced to CTRL-Alt-Delete out of the game–I always save before actually firing to avoid losing progress.

The guns and ammo I’ve been using are:
Savage 111F & 7.62x51mm
Ruger Mini-14 & .223 Remington
H&K UMP-45 & .45 FMJ
SIG Pro .40 (which should actually be called SIG P226) & .40 S&W

Has anybody else noticed these types of problems with their firearms?

80

Perhaps you’d be interested in something like this, LazyCat.