sheridan

I apologize for being misleading. I had no idea my information was so out of date. The last time I made serious attempts optimizing 32-bit software drawing, MMX was still the word of the day. Having since moved away from software rendering, it makes sense that my "knowledge" was obsoleted. At any rate, your comment was enlightening. Thank you.

QZDoom's lack of performance may have something to do with the fact that 32-bit blitting/blending has never been particularly well optimized by any C/C++ compiler. To unlock reasonable speed there you have to get back into inline assembly optimization with the MMX instruction set, which is obscure knowledge to say the least... Going forward, I've always felt that GZDoom had the right idea by embracing OpenGL for the backend... though even that is in danger of falling out of fashion as OpenGL gets left behind for Vulkan by all the hardware vendors. Somebody might want to start a Vulkan ZDoom port sometime, if they haven't already...

^ indeed. You will get a far better experience with that than you will with a 4k monitor.

Easily my biggest cause of death in UNM as well, which is supremely frustrating.

Corpses are removed to reduce draw calls, not polycounts. It used to be that render times increased somewhat linearly with the number of polys in the scene, but this is no longer the case. Modern gpus can render millions of polygons a second before they even begin breaking a sweat. Trouble is, when you've got literally thousands of distinct objects populating your scene, each with dozens, hundreds, or thousands of polys to render, sending a draw call for each of these polys from the cpu to the gpu literally causes the bus linking the two systems to become the bottleneck in your app. So, you have to get clever and learn to store the geometry for whole meshes on your video card so you can render entire objects with one draw call rather than force-feeding your gpu one poly at a time, but even that only helps somewhat, since modern games often have up to 2000 distinct objects that must be drawn in any given scene, causing the bus from cpu->gpu to remain a bottleneck even with these improvements. It's worth mentioning that back in the days of the original doom, the weakness of the cpu, plus the fact that all the drawing happened there rather than with a split architecture, plus the relative simplicity of the scenes in doom, meant that orders of magnitude more time would be spent rendering objects than passing them off to get drawn on the screen. So this modern draw call bottleneck wouldn't become the real problem for another 10-15 years, when 3d cards were popular and scenes were starting to get really complex. So, yeah. Like others have said, the bodies in doom unfortunately must disintegrate for technical reasons, and you likely wouldn't enjoy having them stay as much as you think you would. But that isn't necessarily because your gpu is too weak in and of itself. Literally the way cpu->gpu architecture works is the biggest source of the problem there, and until we can afford to unify the cpu->gpu arch for a majority of computers (or just invent a better division of work between the two units), this is probably the way it's gonna be for a while.

I'd be surprised if you can efficiently program regular expressions with snapmap. I'd suggest instead that you have one variable ("experience") which you increment by a "hard-coded" amount on every monster kill (or whatever), and after you increment, you also check if the value of "experience" exceeds another "hard-coded" amount before you then proceed to do a "level up" action. If you want an "experience remaining" counter, just decrement it by the same amount that you increment the "experience" counter. But you know, you're always free to experiment and find a better solution. I've been surprised by a few things people have managed to do with snapmap.

They likely don't allow volumes to block AI characters because it would mess with their pathfinding data/algos.

OP, you are mistaken on two points: A) we will not have access to any source code or advanced modding tools, ergo, we could not "change the game to our liking" even if we wanted to B) even if we did have said tools, nobody would want to follow the leadership of someone who does not even know how to program himself (lol)

Well apparently the competition involves deathmatch, so cheats like IDDT will presumably be disabled.

Pleased to see some news here that's not just another multiplayer digest. :)

They are, actually. Doom's record minimum to my knowledge was 35% but it's since climbed to 37%. The worst of the backlash seems to be over. :)

The publisher analogy isn't perfect because Zenimax (which is basically Bethesda management) owns id and if they don't like how Doom is turning out, they can order id to change it. In fact they already did that once, that's how "Doom 4" got canned and rebooted as the new "Doom". On topic, a cool cinematic intro that sets up the game without wasting the player's time would be nice. I think Doom3's protracted, exploration-based intro was fine, but that was a different game. Something shorter and to the point like a quick cinematic would fit the new Doom nicely.

Ha shit, now I know I've played with some of you. I recognize your characters. Here's my dude, along with my stats (took the picture yesterday and realized it's perfectly usable for this thread too)

You raise an interesting point, and my mind actually goes to some John Romero interview I remember reading a while ago where he said roughly that his vision for multiplayer in Doom3 (provided he had designed the game) would've been a large-scale battlefield-esque type game, which for the time (early 2000s) was clearly a bit ahead of the curve. I wish I could find that interview so it wouldn't seem like I was talking out of my hat, but when you mentioned open worlds and other playstyles I just thought it was worth mentioning.

You're right, it's more accurate to say they're preparing to ship than to say they've shipped already, but the point stands that if they're a sane group of developers they won't make any fundamental changes to the product before it lands in the consumer's lap next month. Problem with you mentioning haste is that if the player's default movement speed goes up 50%, then the haste powerup will have to increase in potency too, so there's still an opportunity for things to go wrong that you wouldn't expect. It's easy even when you're in the design seat to make hand-wave judgments and say, "this change couldn't possibly break anything, and I know it will result in a net-positive addition to the game!" but in practice, the change often does break something, and then everybody on the team has to scramble to put the game back together so it can ship in a working state as originally planned. You do make a fair point with the asynchronous update model, as we saw Bethesda use that a lot post-release for Skyrim. For example, horse combat and a ton of other cut features ended up worming their way into that game after release because the developers were basically given free reign to work on whatever they wanted once the game had shipped and cemented itself as a successful title. But even they refused to let their team make any serious changes in the days leading up to release because they needed everybody's concentration to ensure that the game hit its mark on day 1 of public release.