Though my week off from work is almost at its end now, I haven't had much time to enjoy actually playing any games.
The week began with me ready to once again immerse myself in Oblivion, only to discover that one of the mods I was playing with (which still remains unidentified, by the way) was making the game instantly crash to desktop whenever I attempted to remove a specific vanilla item from defeated enemies. I could systematically open each active plugin with one of the editing tools and look for anything modifying that item, but instead I first chose to try the process of elimination method and in the process somehow borked the game so that now I can't even start a new campaign.
So I decided to turn my attention to one of my old favorites, classic Doom -- more specifically, Doom run with the source port GZDoom. With the latest version of my favorite source port I had only been running the game for about 45 minutes when suddenly the framerate deteriorated so drastically that I could progress no further. So what's the first thing I do in this situation? I go make a fool of myself in their bug report forum, of course. After a bit of posting and simultaneous testing, I came to the conclusion that there wasn't anything wrong with the source port but instead that the problem was somehow being caused by the mapset I was trying to play. So I switched to another megawad and, by the third map of the set, the framerate again went to crap -- worse, whatever is causing the problem is apparently preserved in the saves so restarting the executable in hopes that the issue will clear out of the RAM and GPU is ineffective.
I've read that the openGL support of AMD/ATI/Radeon video cards is becoming increasingly atrocious with each new series of GPUs they release, so I began to investigate further along that avenue. I tried several different versions of the drivers for my current video card, to no avail, then I went so far as to actually pull the hardware out of the tower and stick my older Radeon GPU back in. Still the problem persisted. In the end I decided that if I was going to get to play the game at all this week I'd have to switch to ZDoom, which is of course the source port that the openGL version is based upon.
But that wasn't the end; when things on the computer go good for me they go great, but when they go bad they go straight to hell in the proverbial handbasket.
I was playing Armadosia with ZDoom and by the time I was halfway through the second map the framerate again went straight to crap. WTF? It's not even openGL! I've been playing games like Oblivion at 1600x900 resolution with the details maxed! This should run like a racehorse! WTF?
I was only running the game with one other mod. The mod had never given me any trouble before so I had by default ruled it out as a possible cause of the issue... but just for the sake of being thorough I decided to disable the mod and launch the game one more time. Without that remaining mod the game ran without the slightest stutter, even in the openGL version; with the mod enabled again the stuttering returned and soon the game was unplayable. Anyone care to guess which mod was causing the problem?
Herculine's Doom Upgrade.
Now my critics can rejoice; my randomizer mod actually does make the game unplayable.
This of course has me very frustrated. I've been developing the mod and playing with it for over two years now and have never had such issues until now, though during that time the mod has steadily grown in its size and scope. Apparently it has finally reached a size where the source port engine can no longer handle the amount of information that needs to be processed, even if I enable the executable to take advantage of all my system's RAM. Again my critics can rejoice; all along they've said that the mod has too much stuff in it and now it seems that they're finally correct.
Readers familiar with ZDoom modding might ask: "Herc, what if it's just one item that you've recently added that's causing the problem?" While there's always a slim chance of that I suppose, I doubt that it's likely because the coding for all these things is basically the same. When something goes wrong in said code usually the worst that can happen is a sprite won't show up when it's supposed to or a monster won't do something when or how exactly it was intended. I really don't see how one could code a single monster or item to produce such a drastic impact on the graphics processing unless it simply had a ton of visual effects crammed into it, and even then the problem would have been abated by adjusting or even totally disabling the openGL options as I did while I was trying to locate the problem. Also, I think it would be safe to assume that the bug would only manifest itself when said object was actually spawned in a map, while this bug is persistent as long as the mod is active in any case. The only conclusion I can reach at this point is that the issue is the result of the sum of all the parts; too much data is being loaded at one time to be processed.
Thus the title of this post. The only option I see left to me at the moment is to create a version of the mod in which the content is at least halved. The easiest way I can think of to do so is to start a new mod from scratch and systematically add to it only the content that I refuse to omit and then work from there. That's not as bad as it sounds, though; in a way my critics are right in that the mod does contain some things that aren't really necessary. For example, of the array of weapons that are in the current version I only actually ever use about half of them, so logic dictates that I should only keep about half of them. Perhaps there really isn't any need for four different kinds of shotguns, after all. The list of monsters and power-ups that won't make the cut will likely be long in the end; things like the Time Imp and the Time Freeze Sphere, for example, are really cool but they depart from the original gameplay style drastically enough that they can be cut without really detracting anything from the ultimate purpose of the mod. Time to trim the fat.
However, fans of the mod up until this point need not despair; I'm not throwing it away. It will remain here in my DropBox folder, patiently awaiting the day that a version of the source port will be developed capable of handling it smoothly. But in the meantime, I'll be diligently working on a "lite" version of the mod and when it's ready for release you'll hear it here first. Until then I'll either have to play "vanilla" Doom or just go back to another game; hopefully the game I pick next won't be a crash-happy mess as well.
The week began with me ready to once again immerse myself in Oblivion, only to discover that one of the mods I was playing with (which still remains unidentified, by the way) was making the game instantly crash to desktop whenever I attempted to remove a specific vanilla item from defeated enemies. I could systematically open each active plugin with one of the editing tools and look for anything modifying that item, but instead I first chose to try the process of elimination method and in the process somehow borked the game so that now I can't even start a new campaign.
So I decided to turn my attention to one of my old favorites, classic Doom -- more specifically, Doom run with the source port GZDoom. With the latest version of my favorite source port I had only been running the game for about 45 minutes when suddenly the framerate deteriorated so drastically that I could progress no further. So what's the first thing I do in this situation? I go make a fool of myself in their bug report forum, of course. After a bit of posting and simultaneous testing, I came to the conclusion that there wasn't anything wrong with the source port but instead that the problem was somehow being caused by the mapset I was trying to play. So I switched to another megawad and, by the third map of the set, the framerate again went to crap -- worse, whatever is causing the problem is apparently preserved in the saves so restarting the executable in hopes that the issue will clear out of the RAM and GPU is ineffective.
I've read that the openGL support of AMD/ATI/Radeon video cards is becoming increasingly atrocious with each new series of GPUs they release, so I began to investigate further along that avenue. I tried several different versions of the drivers for my current video card, to no avail, then I went so far as to actually pull the hardware out of the tower and stick my older Radeon GPU back in. Still the problem persisted. In the end I decided that if I was going to get to play the game at all this week I'd have to switch to ZDoom, which is of course the source port that the openGL version is based upon.
But that wasn't the end; when things on the computer go good for me they go great, but when they go bad they go straight to hell in the proverbial handbasket.
I was playing Armadosia with ZDoom and by the time I was halfway through the second map the framerate again went straight to crap. WTF? It's not even openGL! I've been playing games like Oblivion at 1600x900 resolution with the details maxed! This should run like a racehorse! WTF?
I was only running the game with one other mod. The mod had never given me any trouble before so I had by default ruled it out as a possible cause of the issue... but just for the sake of being thorough I decided to disable the mod and launch the game one more time. Without that remaining mod the game ran without the slightest stutter, even in the openGL version; with the mod enabled again the stuttering returned and soon the game was unplayable. Anyone care to guess which mod was causing the problem?
Herculine's Doom Upgrade.
Now my critics can rejoice; my randomizer mod actually does make the game unplayable.
This of course has me very frustrated. I've been developing the mod and playing with it for over two years now and have never had such issues until now, though during that time the mod has steadily grown in its size and scope. Apparently it has finally reached a size where the source port engine can no longer handle the amount of information that needs to be processed, even if I enable the executable to take advantage of all my system's RAM. Again my critics can rejoice; all along they've said that the mod has too much stuff in it and now it seems that they're finally correct.
Readers familiar with ZDoom modding might ask: "Herc, what if it's just one item that you've recently added that's causing the problem?" While there's always a slim chance of that I suppose, I doubt that it's likely because the coding for all these things is basically the same. When something goes wrong in said code usually the worst that can happen is a sprite won't show up when it's supposed to or a monster won't do something when or how exactly it was intended. I really don't see how one could code a single monster or item to produce such a drastic impact on the graphics processing unless it simply had a ton of visual effects crammed into it, and even then the problem would have been abated by adjusting or even totally disabling the openGL options as I did while I was trying to locate the problem. Also, I think it would be safe to assume that the bug would only manifest itself when said object was actually spawned in a map, while this bug is persistent as long as the mod is active in any case. The only conclusion I can reach at this point is that the issue is the result of the sum of all the parts; too much data is being loaded at one time to be processed.
Thus the title of this post. The only option I see left to me at the moment is to create a version of the mod in which the content is at least halved. The easiest way I can think of to do so is to start a new mod from scratch and systematically add to it only the content that I refuse to omit and then work from there. That's not as bad as it sounds, though; in a way my critics are right in that the mod does contain some things that aren't really necessary. For example, of the array of weapons that are in the current version I only actually ever use about half of them, so logic dictates that I should only keep about half of them. Perhaps there really isn't any need for four different kinds of shotguns, after all. The list of monsters and power-ups that won't make the cut will likely be long in the end; things like the Time Imp and the Time Freeze Sphere, for example, are really cool but they depart from the original gameplay style drastically enough that they can be cut without really detracting anything from the ultimate purpose of the mod. Time to trim the fat.
However, fans of the mod up until this point need not despair; I'm not throwing it away. It will remain here in my DropBox folder, patiently awaiting the day that a version of the source port will be developed capable of handling it smoothly. But in the meantime, I'll be diligently working on a "lite" version of the mod and when it's ready for release you'll hear it here first. Until then I'll either have to play "vanilla" Doom or just go back to another game; hopefully the game I pick next won't be a crash-happy mess as well.
I don't think I've ever actively modded DOOM or its engine (let alone a port thereof) so take this for what little it's worth: have you tried just undoing/removing the last additions you made?
ReplyDeleteIf this were Gamebryo; and I was sure nothing I'd added was corrupt or otherwise crashy, I'd call it one-straw-too-many -- the engine may be overloaded, but remove a couple straws, and it usually goes back to behaving. All that will have happened is you learned where your ceiling is, and that if you want anything new from there on out, something old has to go.
Or at least so my armchair supposition goes; not having modded DOOM, it may be more involved than that to extract the engine's head from an unnamed orifice and get things running again.
I had something slightly more witty planned in my head to say... but I sort of got distracted reading a forum post on dissimilar metal corrosion in chambered rounds of ammunition; and it destroyed my previous train of thought once I started turning that problem over in my head. One of these days I'm going to learn to read one site at a time.
That's good advice, which is why I'm not scrapping the mod as it is. Still, I think it's time to rethink a few aspects of the mod anyway and this is just a sign. Similar to my habit of drawing up hundreds of Gamebryo companions when I can only practically travel with two or three, I've gotten into the habit of trying to cram into this mod every new idea whether or not it really needs to be in there. I need to learn to do things in more of a semblance of moderation... at least where my modding is concerned.
ReplyDeleteThis may be one of those times when "less is more" is a very appropriate turn of phrase. On the bright side (maybe?), you caught this yourself, and can now correct it, without enduring any more of the usual crap your critics throw at you.
ReplyDeleteThat might not have turned out sounding quite the way I intended it to...
Oh, there's no need to worry about that; I stopped updating the upload in the archives long ago. In January of this year I actually requested that it be removed entirely; you can see how well that has gone...
DeleteBut yes, I needed this to remind me that I've vastly departed from my original mission statement. I distinctly remember myself saying that I was trying to create a randomizer that would hold close the original feel of the gameplay, but lately I guess I've been adding everything I could to the mod just because I can. Now it's time to rewind.
I can understand how one can go overboard with a mod. One of my on-again/off-again projects for FO3 (and eventually New Vegas) is a resource mod that contains just about every armour/clothing/race mod that I have. It goes without saying that, despite the time and effort I put into fixing errors in it, it explodes on me more often than I care to admit...
Delete