Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Spectre01

What are your thoughts on the new Brutal Doom release? (no haters)

Recommended Posts

I think the community should just remake a Brutal Doom like engine that is more mod friendly and optimized.  That would be nice.

Share this post


Link to post

I haven't played it but I do like the idea of the map enhancement script. When it officially releases I would love to make a file that only does the map enhancements without needing Brutal Doom at all, as to play with other mods or vanilla.

 

Should be easy enough to do:

1. Make a list of all actors spawned by the scripts (with the vehicles as the exception).

2. Copy only the code which does the spawning and modifying work, removing lines that add the vehicles.

3. Copy the actors spawned by it into DECORATE.

4. Copy any other lumps like sprites for the actors and new textures, along with any sounds (like if a prop can be destroyed).

 

I wouldn't mess with the CVARs though. In this use-case, it would be "always on" when the individual file is loaded.

Share this post


Link to post

Well, it's cool.

 

It has bugs up the ass, but that's to be expected from a beta.

 

There are some weapon and artistic changes that I don't like, such as the new liquid fall textures.

 

A lot of the stuff was a bit overhyped.  The water physics are just a better-looking development of the existing liquid ripples in v20b, and the tanks were much clunkier than I expected.

 

Still, these are just my first impressions after a long day of school. The weekend's coming up soon, though. I'll have more thoughts about it then.

Share this post


Link to post

Had a quick play though, and it seems pretty good, with a more focused balance than previous versions. I'm not sold on the level enchancements but there's more than enough options to tailor things to your liking.

Share this post


Link to post

I played the first level. I'm happy it comes with its own set of levels and maybe it did before, but I never noticed. There was always Brutal Doom starter pack, but that was an add on. The light shooting feature feels nice and a subtle feature that will go unnoticed. There were a lot of updates I had forgotten about from the videos. More options too that I'll never dig through, but having 4 start classes is always good.

Share this post


Link to post

Here, Im one of those who play BD mainly, I am a big Doom fan for some time, I knew Brutal Doom maybe in 2012 or 2013, I have to say that thanks to this mod it is now one of my daily games. My favorite part of the game itself is not so much the gore, but I feel that the gameplay is even more suited to my style (Frenetic, versatile, constant, fast, entertaining, exciting) and the graphic touch-ups are something I appreciate. I know that the main premise of the game is the '' Gore '', which I also enjoy, however I put Gore's options in '' Realist '' mode, with this I can tell you that the main reason I use BD is for the refinement of the gameplay (It moves away from the vanilla, I know) and the graphic retouching. Actually I think it's an excellent Mod, and I enjoy it every day. Although the mod is already more than 5 years old (I think), it still has constant work and updates that make it more immersive, optimized and entertaining. With that I am satisfied.
 

Share this post


Link to post

I ran this on a little $350 Walmart Acer. At 1900x900 fullscreen, OpenGl effects(Dynamic lights, etc), Janitor off. All of the bell and whistle I can think of really.

I have no issues at all really with this hardware. There is a little bogging when exploding like 20 plus monsters at once, but that is it for me.

 

Spoiler

Specs.png.62c73dd07bd65a79f985a8b6abd2800c.png

 

Share this post


Link to post
4 hours ago, Praetor said:

For some reason GZDoom really lags now with those mods.

I also get low performance in GZDoom with these kind of mods, but they work fine in Zandronum. Especially noticeable regarding dynamic lights, which tank my frames in GZ, even with no mods, but run smoothly in Zandro. Also, nice to see some discussion on the new features. I was wondering what I'd be in for when checking the thread again. :P

Share this post


Link to post

It's... okay.

 

I seriously have issues with only having 2 rifle magazines when you start as the Rifle Start class. I mean, even just tapping mouse1 really bogs down ammo pretty quickly at E1M1/MAP01, especially if you're like me and lose control at some point and start injecting bullets into imps like a syringe. It doesn't help that the firing rate's been so drastically increased.

 

Not sure how I feel about the map enhancement. I mean, I think it makes vanilla maps look much more lively, but sometimes it feels way overdone (and it doesn't improve my already-extremely-negative opinions on Doom II's maps). Especially with the vehicles.

 

despise the arms in the punching animations. If they're supposed to be POV-based, they look more like the arms of a fat Doomguy.

 

The new guns do feel rather punchy, which I like. The autoshotty/AA12(?) takes ages to reload, though. I'm not a fan of the new SSG design, however. I think it's brilliant to be able to switch to a new weapon right after firing it. I've found myself to be a bit more effective with it than I thought.

 

But do we need to have GZD/Zandro reflect the gender change? I appreciate the effort, but it honestly doesn't feel too necessary to me.

 

I know I'm giving v21 a lot of shit, but this is one of those moments where I'm enjoying it much more than it seems. There are a few features I'd like to see added (like ledge grabbing), and some I'd like to see removed (like the vehicles), but v21 is still a blast. At the end of the day I'd still prefer vanilla Doom or mods like Project Brutality and Death Foretold, but I'm more than willing to give credit where credit is due.

Share this post


Link to post

I found it kind of cool, the effects were neat, and the map enhancements... ehhh...

But i still found that the use of voxel models in the maps was an okay idea.

EDIT: i forgot to mention, this mod fried my computer, so the one downside i have to give to it is that it requires some optimization.

Edited by EmotionalFelineinaMadstate

Share this post


Link to post

I've never played BD before myself but i would certainly be willing to step up to the plate and make a BD compatible mod/mapset, at least if I wasn't already working on multiple maps, one of them already being a gzdoom one :/

Share this post


Link to post
3 hours ago, Pyrolex said:

I seriously have issues with only having 2 rifle magazines when you start as the Rifle Start class

 

Have you heard of taking aimed headshots and not going full auto like a maniac? Saves a lot of ammo when I used to play a couple years ago.

Share this post


Link to post
5 hours ago, Spectre01 said:

I also get low performance in GZDoom with these kind of mods

I get low performance even without mods in GZDoom. I'm still going to blame my GPU.

Share this post


Link to post
7 hours ago, Praetor said:

Is GZDoom just unoptimized then, or is it Brutal Doom, or both? I don't have any trouble playing current generation games at all. Surely to god if I can handle Doom 2016 I can handle a mod for Doom, hm? 

No time for a deep explanation, sorry. But your comparison is a bit unfair, I think (apples vs. oranges).

 

Think of this: If you toned down Doom2016's prettiness, simplified/removed the complex 3D models, and then added back some GZDoom CPU physics and scripting, and a "Brutalized" multi-hundred monster map, which game would win? An accurate guess gets a bit more difficult to make. But, that's what you'd have to do (and more) to have a fair comparison.

 

6 hours ago, Edward850 said:

Brutal Doom is hilariously unoptimised, yes. It mostly spaghetti code cobbled together from other people's work, and sgt mark doesn't understand enough programming theory to keep it held together sane.

Wow. This guy can take a bunch of different peoples' script code, and cobble it together in a pasta-like fashion, without a grasp of "programming theory", creating an award-winning game, obviously loved by many. He sounds pretty smart to me... [/Hilarious]

 

Ok, so, joking aside, what is it that's so unoptimized? As you know, there's lots of smart ZDoom script folks out there. Maybe a small team could form to help turn linear searches into lookups, add 1 and 2 tic DELAYs to critical scripts, etc, unspaghettifying Sgt. Mark's creation?

 

Again, let's face it: Brutal Doom is loved by many, for better or for worse. Furthermore, it's a great test case for the engine and the script executor. Maybe, some volunteers?

 

6 hours ago, Graf Zahl said:

The problem is not lack of optimization but higher complexity of engine code. You cannot have all those features with no price to pay.

If a function like PIT_CheckThing is 4x as long as the original id version it will inevitably cost some performance. But even then, you got to have several 1000 of monsters being awake all at once for this to become a problem.

 

What happens here is something entirely different: It's not just unoptimized script code but mostly all the stuff flying around that all calls more script code that spawns even more stuff. If a single dying monster can create up to 100 pieces of debris you can do the math if that gets called multiple times in parallel.

I can back that claim. Each little piece of debris is a full-blown object, conditionally susceptible to a great many conditional checks. GZDoom is up to five 32-bit

actor flag variables, right, anyone? Even if 2 of those are not used as boolean arrays, that's still 32*3 = 96 conditions, which translates to a LOT of checking going on per tic. And, like Graf suggests: If any of the debris is on a lift: LOOK OUT! Big performance drop.

 

In a video clip on Rage development, Carmack mentions that a BIG frame drop was these little clumps of grass. He's showing this beautifully complex ride through Rage-ville, with floating structures, piles and piles of overturned, burnt cars, abandoned buildings, massively detailed cliffs with individual pebbles, unique tire tracks, etc..., and the big slowdown was these tiny clumps of grass?? CLUMPS OF GRASS??!!

 

Without proper profiling, there's no telling exactly what causes slow down. Calling it a "lack of optimization" usually totally misses the point.

 

6 hours ago, Praetor said:

Hogwash.

You can have tons of features, it's just you have to extend your engine to properly allow for it, and you can't have tons of shitty code lying around to make things worse. Also, the engine/base has to be made with these features in mind. You can't just throw new features on top of it.

 

But really though, if what GZDoom is doing is just throwing all these new features on top of IDs engine, then maybe the answer here is to just take the Morrowind modding community route and just create an entire new engine with current hardware in mind.

Hmmm. Gee, I just learned C... so, hey 25-year code vet: "hogwash!". You can have tons of features. But, you can't just throw new features on top of it. I know, let's make a totally new engine...and...

 

Heh. heh heh heh.

Share this post


Link to post
1 hour ago, kb1 said:

Wow. This guy can take a bunch of different peoples' script code, and cobble it together in a pasta-like fashion, without a grasp of "programming theory", creating an award-winning game, obviously loved by many. He sounds pretty smart to me... [/Hilarious]

 

Ok, so, joking aside, what is it that's so unoptimized? As you know, there's lots of smart ZDoom script folks out there. Maybe a small team could form to help turn linear searches into lookups, add 1 and 2 tic DELAYs to critical scripts, etc, unspaghettifying Sgt. Mark's creation?

 

Someone already mentioned "cobbled together", and that perfectly nails what BD is. The programming expertise required to write complex DECORATE is relatively low and what this boils down to is that a lot of the code looks like trial and error and not like some targeted programming effort. It is likely that a lot of this code was just borrowed from elsewhere. But remember: BD was written for a simpler DECORATE with no anonymous functions and no real scripting so all he could to was call functions in states and then set up sequences that happen to work.

 

 

1 hour ago, kb1 said:

 

Again, let's face it: Brutal Doom is loved by many, for better or for worse. Furthermore, it's a great test case for the engine and the script executor. Maybe, some volunteers?

 

Sadly it's also a source of many problems - to the point that so much of it depends on random chance that your luck may vary.

 

 

1 hour ago, kb1 said:

 

I can back that claim. Each little piece of debris is a full-blown object, conditionally susceptible to a great many conditional checks. GZDoom is up to five 32-bit

actor flag variables, right, anyone? Even if 2 of those are not used as boolean arrays, that's still 32*3 = 96 conditions, which translates to a LOT of checking going on per tic. And, like Graf suggests: If any of the debris is on a lift: LOOK OUT! Big performance drop.

Not really. Many of the flags only get checked in a single place to define a single trait. The main issue here is that any piece of debris is a full-blown *MOVING* object, meaning that each single piece has to run all collision checks each frame. That just costs time.

 

1 hour ago, kb1 said:

 

In a video clip on Rage development, Carmack mentions that a BIG frame drop was these little clumps of grass. He's showing this beautifully complex ride through Rage-ville, with floating structures, piles and piles of overturned, burnt cars, abandoned buildings, massively detailed cliffs with individual pebbles, unique tire tracks, etc..., and the big slowdown was these tiny clumps of grass?? CLUMPS OF GRASS??!!

 

Without proper profiling, there's no telling exactly what causes slow down. Calling it a "lack of optimization" usually totally misses the point.

 

Indeed. And the main problem here is not something 'unoptimized' but plain and simply that more code needs to run. Last year's portal changes also added some overhead to allow portal-relative calculations, which can even have an effect if a lot of stuff gets constantly spawned.

 

 

1 hour ago, kb1 said:

 

Hmmm. Gee, I just learned C... so, hey 25-year code vet: "hogwash!". You can have tons of features. But, you can't just throw new features on top of it. I know, let's make a totally new engine...and...

 

Heh. heh heh heh.

 

My response to such people would simply be: "Prove that you can do it better!"

Wanna bet that someone will suggest to rewrite the code in assembly or stuff like that...? :D

 

Just in case, has anyone checked if all those debris actors have +NOBLOCKMAP set? If not, that would explain to a great deal why it performs like shit.

 

Share this post


Link to post
1 hour ago, Graf Zahl said:

Just in case, has anyone checked if all those debris actors have +NOBLOCKMAP set? If not, that would explain to a great deal why it performs like shit.

Pretty sure they don't although I haven't looked. I just know that a lot of things in general are somewhat unoptimized in BD and the starter pack. That's one reason I created a vanilla improver WAD for the starter park to "fix" some things to make it less annoying to play.

Share this post


Link to post

Alright, more thoughts. (Warning: Rant)

 

One change I utterly detest is that the assault rifle and the minigun have a much higher fire rate. The assault rifle's change removes it's older role as a bullet conserving and easily controllable weapon, and makes it expend it's smallish magazine much faster, meaning you have to stop dishing out pain in order to reload much more. The minigun has it's already high fire rate seemingly doubled, making it expend ammunition stupidly quickly and changing it from a weapon that could be depended on for many situations, from mowing down large groups of zombies to eliminating multiple tougher targets, into a weapon that tears apart a Baron in two seconds flat and is completely overkill and a waste of ammunition for most situations it used to excel at. A whole extra bunch of effects, like gunfire smoke and spent belt segments being ejected, are also added to the weapon, making it bog down the framerate much more than it used to.

 

I'm also not a fan of the pump shotgun having a higher rate of fire when in iron sights mode, instead of having a tighter spread. It kind of goes against the point of using iron sights, which is to shoot with greater precision. One might say it isn't realistic for the spread to tighten when in iron sights mode, but I prefer practicality over realism.

 

And Mark brought the annoying zombie scream sounds back. Why? The v20b sounds worked perfectly and weren't grating on the ears.

 

Like Pyrolex said, the new punch sprites look stupid. They look like Doomguy is raising his arms next to his face and then punching. I also don't like the new punch system, which is like PB's melee system, but shitty. The old left-click-weak-executing-punch-right-click-strong-gibbing-punch system was much more predictable, practical, and simpler to use. Currently, to execute a Pinky, you have to mash the buttons and hope it doesn't gib it, while earlier it was left punch+right punch=done.

 

The Chainsaw goes back to being swung around like a madman. I liked the swinging better when it was an option, and you could just use the chainsaw like in vanilla.

 

(end rant)

 

Still, there are things I love: the vehicles, the new weapons (in particular the SMG and the Machine Gun), the new sprite work, the grab system, and the raise-after-firing thing being removed from the Plasma Rifle. 

Share this post


Link to post
1 hour ago, kb1 said:

Wow. This guy can take a bunch of different peoples' script code, and cobble it together in a pasta-like fashion, without a grasp of "programming theory", creating an award-winning game, obviously loved by many. He sounds pretty smart to me... [/Hilarious]

Well yeah.

I mean, "well the people like it!" doesn't really make the product any better.

 

Take Terraria and Minecraft for an example. Both have deplorable programming, with Terraria in particular being especially awful, but both also have massive fanbases. Just because they have massive fanbases and are both award winning and loved by many does not mean that the quality of the code is good. I really don't see what point you're trying to make.

 

1 hour ago, kb1 said:

Ok, so, joking aside, what is it that's so unoptimized? As you know, there's lots of smart ZDoom script folks out there. Maybe a small team could form to help turn linear searches into lookups, add 1 and 2 tic DELAYs to critical scripts, etc, unspaghettifying Sgt. Mark's creation?

Well, again I haven't taken a look yet at the codebase, but I'm assuming that if all these rumors of it being built up primarily of code and resources stolen from other projects and thrown together, it must be held together by tape, and I imagine there's all sorts of issues there. I'm just going off of what I know, and that is that Doom is 25 years old or so, and a mod for a source engine can not run properly for some reason on computers that run current generation games perfectly. Makes you kind of start thinking about some things. It's either the mod, the source engine, the computer running it, or a mixture of them. Now seeing as to how I run other mods and wads just fine, I am going to point towards the issue being something to do with the mod, but then again, the other mods I play aren't really as ambitious as Brutal Doom.

 

1 hour ago, kb1 said:

Hmmm. Gee, I just learned C... so, hey 25-year code vet: "hogwash!". You can have tons of features. But, you can't just throw new features on top of it. I know, let's make a totally new engine...and...

 

Heh. heh heh heh.

That's not what I said though.

I said if the case is GZDoom is just having features put on top of the old engine, maybe the better answer here to extend Doom into having more features is to do what Morrowind's community did when they began facing these types of issues and just begin a new engine altogether.

Share this post


Link to post
44 minutes ago, Praetor said:

...and just begin a new engine altogether.

 There's *just* one problem here: If you build a new engine that's supposed to be more efficient, it *just* won't be Doom anymore, which utterly depends on its idiosyncracies which ultimately make large parts of it prone to inefficiencies.

 

Share this post


Link to post
7 hours ago, kb1 said:

Ok, so, joking aside, what is it that's so unoptimized? As you know, there's lots of smart ZDoom script folks out there. Maybe a small team could form to help turn linear searches into lookups, add 1 and 2 tic DELAYs to critical scripts, etc, unspaghettifying Sgt. Mark's creation?

Doesn't Project Brutality do that, or at least have a good chance to?

Share this post


Link to post
7 hours ago, kb1 said:

Ok, so, joking aside, what is it that's so unoptimized? As you know, there's lots of smart ZDoom script folks out there. Maybe a small team could form to help turn linear searches into lookups, add 1 and 2 tic DELAYs to critical scripts, etc, unspaghettifying Sgt. Mark's creation?

 

Again, let's face it: Brutal Doom is loved by many, for better or for worse. Furthermore, it's a great test case for the engine and the script executor. Maybe, some volunteers?

Here's an interesting dilemma. Mark made BD his full-time job and he's getting paid for all of this by his patrons... and you're proposing that experienced coders should take time off their own projects to help this guy for free. Why?

Share this post


Link to post
1 hour ago, Praetor said:

That's not what I said though.

I said if the case is GZDoom is just having features put on top of the old engine, maybe the better answer here to extend Doom into having more features is to do what Morrowind's community did when they began facing these types of issues and just begin a new engine altogether.

Doom and Morrowind are massively different games. It's not just a question of which genre each one is in; it's also a question of the nitty-gritty of it, how they are modded, how they are played, and so on.

 

For a start, Morrowind is not a competitive game. It does not have anything equivalent to Doom's demos. So you can make slight changes to the physics engine without causing outcry from a large part of the player base. Secondly, Morrowind is built on the principle of having a single large open world that you can expand. Doom is built on the principle of having small self-contained levels that you can replace. The ESM/ESP format allows you to change references from another ESM/ESP file. With Doom there's none of that. You can't have a "PWAD" that just moves around an imp a little without touching the rest of the map, you have to replace the entire map. What does this mean? This means that "compatibility patches" are an ingrained thing in Morrowind modding, if you have mod conflicts then you can just solve that conflict in the construction set and make a patch. And this means that if you have an engine changes that breaks compatibility with an older mod that was tailored for the original engine's quirks, then you can make a compatibility patch to get it working again. And that's not something that you can do with Doom; at least not as easily.

 

Finally you have to look at how the world geometry is made. In Morrowind, you use prefabs that you can rotate and scale how you want. The world is built out of Lego blocks. Each block has its own properties (they can be statics that do nothing except collision, they can be activators that have a script attached to them, they can be containers that have an inventory, they can be NPCs or creatures which will act according to their AI packages, and so on) but each block is set in its way. In Doom it's more basic and arbitrary: you have vertices, lines, sectors, and things. The way these things act is largely arbitrary as you can apply any available action to any line, put any texture on it, and so on. And it turns out that there are a lot of quirks in line actions that can result in completely different behaviors for obscure reasons. In Morrowind, a door will always behave like a door; in Doom a door can squash the entire level. That means that compatibility with existing level requires a much greater level of slavish adherence to engine quirks, and cause the mere idea of rewriting it from scratch from the top down a much messier prospect. You might get an engine good enough at replicating the experience for the vanilla map, but who plays them? The people who will have heard of your engine will also be the people who will want to play mod maps with it.

Share this post


Link to post
36 minutes ago, dew said:

Why?

For a piece of that financial pie probably?

Share this post


Link to post
1 hour ago, 40oz said:

For a piece of that financial pie probably?

Yo if Mark starts contracting or rewarding coders for work on his mod, I'll be happy for everyone involved. It's how the system should work once you "go pro", imo. If that's what kb1 meant, we're on the same page.

Share this post


Link to post
Just now, Graf Zahl said:

 There's *just* one problem here: If you build a new engine that's supposed to be more efficient, it *just* won't be Doom anymore, which utterly depends on its idiosyncracies which ultimately make large parts of it prone to inefficiencies.

 

I'm not quite following you. It might be my adderall infused brain making a mess of things though. I refuse to make any further statements therefore since I don't understand. :L

At the risk of sounding more foolish, I will assume that what you mean is having an entire new engine == it's not Doom, but in that case, is OpenMW not Morrowind? It's still the same experience, just the engine is more optimized towards modern day computers and it's moved away from the older programming restraints.

 

Just now, Gez said:

Doom and Morrowind are massively different games. It's not just a question of which genre each one is in; it's also a question of the nitty-gritty of it, how they are modded, how they are played, and so on.

 

For a start, Morrowind is not a competitive game. It does not have anything equivalent to Doom's demos. So you can make slight changes to the physics engine without causing outcry from a large part of the player base. Secondly, Morrowind is built on the principle of having a single large open world that you can expand. Doom is built on the principle of having small self-contained levels that you can replace. The ESM/ESP format allows you to change references from another ESM/ESP file. With Doom there's none of that. You can't have a "PWAD" that just moves around an imp a little without touching the rest of the map, you have to replace the entire map. What does this mean? This means that "compatibility patches" are an ingrained thing in Morrowind modding, if you have mod conflicts then you can just solve that conflict in the construction set and make a patch. And this means that if you have an engine changes that breaks compatibility with an older mod that was tailored for the original engine's quirks, then you can make a compatibility patch to get it working again. And that's not something that you can do with Doom; at least not as easily.

 

Finally you have to look at how the world geometry is made. In Morrowind, you use prefabs that you can rotate and scale how you want. The world is built out of Lego blocks. Each block has its own properties (they can be statics that do nothing except collision, they can be activators that have a script attached to them, they can be containers that have an inventory, they can be NPCs or creatures which will act according to their AI packages, and so on) but each block is set in its way. In Doom it's more basic and arbitrary: you have vertices, lines, sectors, and things. The way these things act is largely arbitrary as you can apply any available action to any line, put any texture on it, and so on. And it turns out that there are a lot of quirks in line actions that can result in completely different behaviors for obscure reasons. In Morrowind, a door will always behave like a door; in Doom a door can squash the entire level. That means that compatibility with existing level requires a much greater level of slavish adherence to engine quirks, and cause the mere idea of rewriting it from scratch from the top down a much messier prospect. You might get an engine good enough at replicating the experience for the vanilla map, but who plays them? The people who will have heard of your engine will also be the people who will want to play mod maps with it.

Now THIS is what I am talking about.

Very interesting. I honestly didn't have any idea this is how things would have gone. I might have jumped the gun a bit in my earlier comments by trying to make it sound like it would be a simple ordeal. Yes, Morrowind and Doom are different games, and I can definitely see how having an engine quirk being repaired in this theoretical "New Doom" would cause older maps to break. Damn actually that is a big issue. That'd mean fucking a million maps are gone.

 

Well you've effectively destroyed the whole "make a new engine" argument I (tried) to make. :/

 

So then that leaves us here: what is there to do then? Are we basically just stuck with source ports that we add complexity on top of until it just crumbles under its own weight? Or am I being a cynical idiot and assuming that the code base to source ports like GZDoom are bad or something? Maybe it'll all be ok?

 

 

Also I'd still like to take a look at Brutal Doom's source and see what is going on in there. Or it might just be that Brutal Doom is too ambitious for its own good and it's pushing source ports to their limits. Idk. ;-;

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×