Dark Pulse

That would literally fly in the face of how BSP works, so no. It doesn't matter to the node builder that it's decoration - it's still a line, its visibility must be tested and accounted for, splits may need to happen because of it, and so on. So basically, you'd need a completely different rendering method to make it work.

Are you trying to run this in vanilla, or something like Chocolate Doom, or something else? The vanilla engine actually can't handle new sprites normally. Back in the day there was a utility called DeUSF which would merge the new graphical assets into the original IWAD (creating a modified IWAD in the process). If you're trying to play under Vanilla, this is still pretty much the only option. If you're using something like Chocolate Doom, that's a little more flexible - but instead of using -file to load your WAD with the graphics lumps, you'd use -merge instead, which will act like the addon WAD is as if DeUSF had merged the graphics into the IWAD, without actually doing so. If you're using something else, then the problem is more on your sprites than anything.

That's exactly the price I am quoting, yes. And keep in mind this is in mid-90s money, which was worth a lot more. This cartridge would've been about half of the price of the hardware, perhaps even two-thirds.

Certainly. It also would've made the cartridge about $100/£70.

Don't exactly see what the difference is between that and launching with a batchfile since you're still typing it into a file anyway, but hey, whatever. You're the man, apparently. Try the following in autoexec.cfg. No guarantees this works, because again, the commandline arguments are a way fucking better way to do this. set skill <0-4> (0 = ITYTD, 4 = Nightmare, figure the rest out) map e1m1 (or map01, whatever is relevant to the IWAD) There's definitely no way to do it from gzdoom.ini. That stores CVARs and the like, it's not meant for stuff like this. So if this autoexec.cfg way doesn't work, get a launcher or write a batchfile, or do the awfully difficult thing of selecting your difficulty whenever you're loading up a new set of maps.

Fucking phone autocorrect strikes again. Thanks Gez.

Because it's a commandline argument. You have to launch it from a batch file, launcher, or command prompt, like the old DOS days. A launcher/frontend would probably be the easiest way if the sound of commandlines and command prompt are scary black magic to you.

You could throw the -skill commandline argument. 0-4 in order of increasing difficulty.

Chex Quest is actually extremely naughty: It's actually a modified Ultimate Doom IWAD. While most of the graphics, sounds, etc. have been altered or stripped, if you open it up in something like SLADE, you will actually see the remaining maps for E1M6-E1M9, plus all the maps for E2, E3, and E4, completely unaltered. The WAD was modified with DEUTEX, and the executable was hacked to end the game after the fifth level. You can even use level warp cheats and play "Chexified" versions of these levels, but be warned, you will encounter invisible and silent enemies and the like eventually! So theoretically, everyone who had Chex Quest had an (illegal) copy of Ultimate Doom. I've heard rumors that id Software was aware of this, but the optics of suing Chex would be quite bad, so they never did. To get back to your question regarding HocusDoom, it could well still be using something. Even if it's using only the PAYPAL, it could count as needing doom2.wad. Or it could simply be that the modder has no idea you could make an entirely standalone mod.

I believe you would have to code up a modded weapon that basically would function entirely the same but ditch the flag for snapping to the target. The original games had the snap, and so while you may not like it, it is accurate behavior.

Right, but again, OpenGL ES is still a very scaled back version of the full thing. The fact they look the same doesn't matter, there's some things it simply does differently. Maybe precision is different, maybe the method of doing this trick is something that works in most cases but could break in others, etc. It's basically like how Glide was a subset of OpenGL, but wasn't OpenGL itself (back when full OpenGL was too difficult to run on mid-late 90s PCs). You can try DirectX and see if that does better for you, but if not, the simple fact is that you are on hardware that really can't hold up to modern demands, and one of the big mistakes a lot of people make with Doom source ports is that since Doom is such an old game, every source port should run at 5000 FPS and every new feature should be miniscule impact. Nothing could be further from the truth - adding them is hard, and BSP traversal is actually what is holding a lot of performance back. This is why source ports like Helion are revolutionary - they ditch that entirely, and so get ludicrous performance on known performance hog maps, but the tradeoff is that there are still some rendering quirks and so on they are working out and a lot of cases that will only get stamped out as they are found, because level designers literally abused engine quirks and bugs to do stuff.

Fine and dandy, but if they haven't done it in the last 15-odd years of GZDoom's existence, I doubt they are going to pick it up, and considering there are alternative ports more focused on demo compatibility, odds are slim that it will happen. Usually features to the engine come along when someone is willing to do the work and put in the code - this is how we got stuff like portals, Doom 64-style lighting, even ZScript. It's basically a solution that doesn't really have an audience, as the audience you are looking for basically "I like GZDoom, but I want demos too, but I don't want to use a source port that is more friendly to them or give up GZDoom features." Nothing wrong with posting the idea, but that's a pretty narrow segment. Most people who want features don't really care about demo compatibility, and most people for whom demo compatibility is important aren't going to be using GZDoom in the first place.

You can have all the resources in the world, but if the interest in doing it and maintaining it isn't there, that simply does not matter. None of the current devs seem interested in this, but if you know how to code or are willing to learn how to code, if it's important to you, by all means, get in there and start cracking away at it. Ideas like that are easy to say but hard to keep maintained and reliable, and considering the significant changes GZDoom has every engine revision, that would always be the catch. id didn't even try to keep demo compatibility between engine revisions, and compared to GZDoom, that code was far simpler.

Yeah, I get that, but what I mean is that basically demos rely on setting the engine to a fixed state and that it doesn't store any sort of info about the playsim at all - no positional information, no level information (other than what map to run on - I'm talking stuff like "enemies are here," etc.) and the RNG stuff is reliant on the fixed state and the fact there's an RNG table (since true RNG would make correct playback impossible without storing what the RNG-rolled values were in the demo file). Obviously there's little to no element of randomness to a fighting game or an RTS, or indeed, almost any other shooters. Even by the time we got to Quake, player shots did a fixed amount of damage. That's absolutely not the case in Doom, and so without that fixed start state, since it's not stored in the demo file itself, there'd be no way to know if this pistol shot should do 5 damage or 15, because it's the RNG table that determines that, or if a Revenant missile is homing or dumb, because it's the current tic that decides that. Naturally, this is also a large part of why ZDoom (and GZDoom) can't play vanilla demos, especially since some of those key elements, like the RNG table, are missing, while others such as the movement logic got changed entirely. Hence, while on the technical side there's nothing unusual about it, in other games, demos can store values like that - Doom's does not. That's why I consider Doom demos as something of a hack in that they work by relying on assumptions, rather than "simply working," especially between engine revisions, whereas a more robust demo format would be able to avoid this to some degree. To be fair though, I guess it's not really all that different if the engine is set to a fixed state versus if the demo itself set it to a fixed state other than what is doing the setting.

Okay, you once more mention the "creator intent" again. But that is not what GZDoom is about, it is about expanding beyond what the creator intended, so in that sense, one is barking up the wrong tree if they are expecting that. It's an engine that can play games made for the Doom engine, but its primary purpose is to do more than just that. In a sense, the fact it can play those games is somewhat more of a "it can also do this." If you want something close to vanilla, simply put, you don't play GZDoom, you play something like Chocolate Doom if you really want things close, or if you want something a little more expanded, PrBoom or something based off that. But even those will have some differences, and not just under the hood, but rendering as well. We are no longer in an era where the CPU renders the game scene in software; we really haven't been doing that for easily 25 years now, and the last game I can specifically remember that had software rendering even as an option (and it was an addon, not the default) was UT2003/UT2004's Pixomatic Renderer. Everything nowadays is assuming hardware acceleration (even the internet - WebGL!), and that means that how it is experienced can differ. Furthermore, once we hit the 2000s, games would start having multiple rendering paths - DirectX was the standard for years on Windows, OpenGL was often also supported and occasionally the main renderer, and nowadays Vulkan is definitely upending things. Each of those could render the scene with subtle differences - ideally they don't, but in practice, the pipeline does vary, and the only true way to be 100% sure what you put in is what you get out is to renderer it in software (hence why MAME, for example, isn't hardware-accelerated). So basically, "as the creator intended" sailed a long time ago - long before GZDoom, in fact, considering ZDoom was doing all this (and indeed, rendered in 8-bit software!) back in the early 2000s. The engine has simply diverged, and it is no longer in a state where it would be vanilla-compatible enough to run demos. It hasn't been since... well, ever, as far as I know. Then... GZDoom does that just fine. You can play those games in them, you can beat those games with them, and you can turn off the bells and whistles like SSAO or texture filtering. I believe the only thing you can't do is to make it run in 320x200 (well, maybe in a window), although given that would be quite small on a 1080p monitor, much less a 1440p or 4K one, a scale just might have to be acceptable. The simple fact is that most casual players can't even tell that anything changed. They have no idea about wallrunning or thingrunning (GZDoom has compatibility options to re-enable stuff like this). They have no idea about the various bugs and quirks of the engine. Unless you know things on a deeply technical level, deeper than most people do, the simple fact is that GZDoom... plays Doom, and plays it just fine. By that logic, if you can do 95% of what the original game did and not notice a difference, you are very much playing it "by the creator intent." Especially when most of that remaining 5% is still stuff you can manually toggle if you really need to get closer. Because some of the changes are fundamental. For example, the vanilla engine, coordinates are fixed-point, where a 32-bit value is split into a 16-digit integer and a 16-bit fraction. Thus, the vanilla engine can only express values between -32767 and 32768, inclusive, with up to 16 digits of a fraction - but anything that is outside of those literally cannot be possible. This fixed point coordinate system, for example, is also why slime trails happen in the original engine: The only way this would be solvable would be if you could make vertexes placed on fractions of a unit, but the original engine does not allow that. If you change it (as GZDoom has, moving to floating point coordinates), you just broke demo compatibility, because you changed a fundamental, underlying assumption of the engine - movement now completely differs, so the old assumptions no longer work properly. Hardware rendering also solves this as a simple fact of necessity (all polygons must be closed for a valid hardware renderer to even work), but of course, that is also away from what the original game did. As I said earlier, demos in Doom are really a very ugly hack. Basically, they only work because the vanilla engine does the following whenever a demo is recorded or played back: Set the game tic counter to 0. This will affect things like Revenant tracers, which choose which firing mode happens based upon if the tic in which it is fired is odd or even. Set the RNG table to start at its first entry. RNG calls naturally happen a bunch, both from the player, the monsters, and the level itself (light blinking, etc.). If recording, start storing keypresses; if playing back, play back the stored keypresses from the demo LMP. That's it. That's all demos are - a series of keypresses (and it can't even record every possible input - accessing the menu is a 100% surefire way to cause a desync, for example). Enemies only move the exact same way and do the exact same actions, damage rolls happen the exact same way, and anything that is RNG-based happens identically only because the engine starts from a fixed state every time you record or playback a demo. Indeed, the demo doesn't store information about what enemies do, what projectiles are active, or the level state at all! They do store some info (game version, episode/map, skill level, if the game is multiplayer or not, some parameters like -fast, -respawn, or -nomonsters), but otherwise all a demo in Doom is, is literally a keypress log that the engine plays back. This is why it's not really possible to "temporarily disable every feature." The underlying engine is fundamentally different, and demos are literally just a keypress log. If everything is not EXACTLY the same - and they wouldn't be (for example, the aforementioned change to floating point coordinates, or the fact that GZDoom no longer uses an RNG table of any sort) - the demo will simply not work right. Graf decided that's simply not a priority he wishes to pursue or deal with since that would force him to not be able to do other features he would like to do, but other engines can and do indeed do that. Personally, I agree, but Graf does not. And considering that there ARE plenty of people who would otherwise complain about Doom's blocky, pixelated graphics, it's kind of a "damned if you do, damned if you don't" scenario. Turn it off and you please the purists but then people less used to such old games will complain it looks like crap. Turn it on and generally those people will not notice that nearly as much, but older fans may start screaming it's sacrilege. There is no one setting that will please everyone out of the gate, but thankfully, it's a relatively short hop, skip, and jump to set it to whatever filter your heart desires, or turn it off completely.

Yeah, this wasn't a knock at you guys at all (personally I can't stand Quake without smoothed model animations). It's me saying that unless one is going to take a absolute purist approach with no improvements at all, making an argument of "there is a way it was intended to be experienced" is silly, especially once you get up to stuff like Quake, and it was directed at banjiepixel's assertion, not intended to be a criticism of the remaster. I mean, if we really got into the weeds of it, Chocolate Doom isn't purist either, thanks to stuff like that magnified screen resolution, reliance on SDL, and so forth. For example, in terms of Quake, which is the "true" experience - the original DOS executable? WinQuake? Quakeworld? GLQuake? Different people would say all of these options. By a purist logic, 75% of them are automatically wrong. One can make an argument that this way or that way is right, but to me, whatever makes the game enjoyable for you is the right way to play. Even if that means high-rez texture packs and 3D models.

Unless you like playing Quake with 10 Hz monster animation, I really am not going to buy arguments like this. Sure, there is a way that is the default, but that is to act like watching a movie at home "doesn't count" compared to watching it in a theater with the idiot who won't stop talking on his phone. Both are different experiences. Both are also valid. The key is that you have a choice, not that there is only one way to do it.

You thoroughly missed the point. To him, that's what Doom is. To you, that's what Doom is. Sure, Graf has some extra pull you don't because he helms the port, oversees its direction, and moves in a way that he feels is the best way forward, but it's not like he's actively blocking you from going as crispy and strict as his engine will permit - he's just not going to make it purist, and that's a fair thing to do for an engine focused more on expanding capabilities while still being able to run Doom-engine games. But he's certainly got a right to think that what you like is ugly, just like you've got a right to think that what he likes is a blurry and smeary mess. Welcome to the world of personal preferences. One does not invalidate the other.

Yeah, going forward, the CPU and GPU matter far more than the RAM does. The RAM can usually be upgraded, even on a laptop - but the CPU and GPU are gonna be there for the life of the device, pure and simple. More (and faster) RAM is always better, all else being equal, but it's generally better to take a hit on RAM if the CPU and GPU are considerably better.

Brevity is not something I am good at, but I also wanted to make sure that my thoughts were explained. Got to try not to pay more attention when I'm tired from work.

The way it was worded and put front and center kind of made it seem like he was highlighting those rumors of decades past, and as I said, there ARE still plenty of people active on this site who were here when that all went down too. To his credit, the OP has elaborated more on what his WAD idea was, my assumption was mistaken since he is doing more than just a school recreation, and I have no problem owning up to that fact. At the same time, without the context that was provided later on, it is very easy to see "I'm making a map that has the layout of my high school" and a video that references something that left a legitimate mark on this community and make an assumption. Decades later, to me, doesn't matter. I was entering high school the following September myself at the time that happened, and needless to say, it scared the shit out of me. Many of the victims would have had children by now, and it's important that inspiration from events like that - even if seemingly innocuous - not be rewarded with "Yeah, go for it" simply because it happened almost 25 years ago. As I said before, with that context in place, it is clear you are angling for something very different, and in that case I withdraw my earlier worry. I would definitely say that it paid to point out that the school segment was just a phase of the WAD and there was more to it than that. That makes it much more clear you are going through time in this story and the fact it is a recreation of a real location is more just you using a location you know as opposed to what it could be mistaken for at first glance. The event that was shocking to me and many older members of this community is now something the younger generation has to anticipate and do drills for and be subconsciously worried about, and it just saddens the hell out of me and hits on one of my nerves. We've learned nothing over the past 25 years, it seems, and the fact schools have metal detectors and armed security guards isn't a solution to the problem - it's a band-aid on a bleeding wound that isn't stopping. It's an attempt to stop the symptoms without addressing the cause. Anyway, sorry for my mistaken assumption and this rant. This is just one of those things that really sucks that today's teenagers have to go through and worry about, and to me it's important that we all don't mislabel what happened, or anything associated with that person, as "okay" simply because we are decades removed from the heinousness of it - because it's, sadly, still happening, now to the point where people are almost becoming numb to it until it happens to their kid, their niece/nephew, their grandchild. And that just saddens me so much.

He did say Vulkan kept kicking him to OpenGL, so I'm presuming his is the rebadged Fermi, but yes. And yes, that whole thing I mentioned earlier with saying if the laptop maker had proper support for it - if his is soldered, then yeah, obviously he's not getting a replacement, and even if his is MXM, odds of replacement still aren't great since there was practically no standardization of where the GPU die was on the module, etc.

Call me crazy, but I'd say being inspired by a highly notorious WAD in the community made by a person who killed actual people is probably not the best sort of thing to take inspiration from. There's plenty of ways to do such a horror-based mod that don't rely on, y'know, one of the darkest episodes this community has ever had, and there are plenty of people around here still from when that whole thing did go down.

Yeah, there's absolutely no way to add capabilities like that to OpenGL ES. It is a graphics specification, and if something is out of spec, it just can't be done. This is like saying you can "add" capabilities to DirectX - it just don't work that way. And all ReShade is is, well, a shader modification - it can't add anything a shader can't do. As for that GT720M, that is a decade-old GPU, so yeah, you are generally out of luck and that doesn't support Vulkan (just DX12 and OpenGL 4.6) - however, that does come on what's called an MXM Module, and those ARE nominally replaceable. But any replacement you get would likely be bottlenecked to some extent - the GPU isn't even PCI Express 3.0, much less the 4.0 that is starting to happen in more recent desktops and laptops. And it would hugely depend on the laptop manufacturer and if they have proper support for that stuff - if they don't, you're out of luck. The only real long-term solution is to not be trying to run a program coded for 2023 systems on a laptop that was made in 2013, basically. Eventually even OpenGL ES will be a very pared-down experience compared to the Vulkan backend, and even the "full" OpenGL spec might be unsupported one day.

The whole point of OpenGL ES (short for "Embedded Systems") is that it's a limited subset of OpenGL features that can still run well on weaker hardware, so no. You've either got hardware that can do it, or you don't. That said, Vulkan is definitely the better (and faster) option, and I'd be very surprised if your GPU can't run that renderer, as it's been a thing for about seven years. If you have a GPU made even remotely recently, it supports Vulkan in some form. Granted, I'm not sure what version of Vulkan GZDoom requires. 1.1, I think? In which case that's a little newer, but still on pretty much every GPU ever made in the last five years or so.