- Sep 8, 2019
- 523
- 871
Oh yeah, I can't even imagine the sort of effort that went into those kind of games. I try to keep my stuff light and fast whenever I can, but that's like a whole different level, lolHave you ever seen a more or less complex program/game that runs on stack completely?? Well, mario probably and other (s)nes/sega games. But they are more like historical curiosities than actual software now. Putting a code with sounds and graphics in so little space that even screenshot of a game have bigger size that whole package...wow, cool how did you make it? Not that I ever would do that...
Nah, as doniwil mentioned it's actually limiting the size of the event viewer in the lower-right. That's a pretty huge improvement, as it both reduces the size of the object that holds the event text as well as the overhead from the GUI control itself. That event log can get pretty long after a long game session.Is it capping event LOGS at 50 while the processes its supposed to log can go on infinitely?
Because that almost sounds like pasting an opaque sticker over a digital display and calling it fixed...
I kinda doubt it fixes the error.log issues, though. :/
Wouldn't be the first time I saw someone do something like this:Why the fuck would anyone write error logging to work that way. In what world would you ever want to completely copy a log and add it to the same log. That's just like, incredibly dumb. There's no way that would ever be useful.
C:
string ErrorList = "";
void LogError(string str) {
ErrorList += str;
WriteToLog(ErrorList); // should be str
}