[Wolfenstein: Blade of Agony] v3.1 released (p204)

For Total Conversions and projects that don't otherwise fall under the other categories.
Forum rules
The Projects forums are only for projects. If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.

Got a cool project idea but nothing else? Put it in the project ideas thread instead!

Projects for any Doom-based engine (especially 3DGE) are perfectly acceptable here too.

Please read the full rules for more details.
User avatar
Kinsie
Posts: 7399
Joined: Fri Oct 22, 2004 9:22 am
Graphics Processor: nVidia with Vulkan support
Location: MAP33
Contact:

Re: [Blade of Agony] Road to Wolfenstein Devblog Part 02 | p

Post by Kinsie »

Graf Zahl wrote:What bothers me about that screenshot is not the guards - it's the food lying on the table. These items are so at odds with the rest of the graphics it almost hurts. And of course, using an upscale filter to smooth their edges...
Yeah, when I last played BoA a while back, there was a lot of issues with sprite resolution inconsistency between the guards and pretty all the environment prop sprites. I dunno if it's been manually applied or if it's just Torm's GZDoom settings, but trying to alleviate that with a quick-n-dirty sprite filter almost makes things worse.
User avatar
Enjay
 
 
Posts: 26517
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland
Contact:

Re: [Blade of Agony] Road to Wolfenstein Devblog Part 02 | p

Post by Enjay »

Tormentor667 wrote:First, we are all limited to the resources we can access and to the resources we can create. None of is a model designer, and even though we already tried to get someone supporting us in this department, we didn't find a person for the team.
You said that Nash is on the team. I don't know if you've discussed it with him (and he could have reasons for not wanting to do it) but he certainly can model.
Tormentor667 wrote:So, why did wie decide to mix up things and what is the general rule of our design philosophy? Quite simply: Enemies (except tanks) and smaller objects are all sprite based but "hires" (twice the resolution as in original Wolf, actually everyting as MacWolf resolution), larger objects (like tanks) and map geometry elements are models. We think that the static objects blend in very well with the map geometry and don't feel "wrong" when you look at them.
That's very close to the philosophy I adopted for my BGPA Burghead mod. I didn't have, and couldn't create, models for the enemies but I did want to include models and I feel that models work much better than sprites for bigger objects such as vehicles. So, my basic rule was "if it's an animal (soldiers, dogs, NPCs, etc) or comes from one/can be picked up by one (dropped items, med packs etc) it's a sprite but if it is 'solid' and/or 'part of the world' (vehicles, machines, trees, scenery items) then it's a model. It's not perfect. It's a compromise but it's the best that I could do and I tried to adopt those rules consistently within the mod.
User avatar
ravage
Posts: 289
Joined: Wed Sep 03, 2003 9:30 pm
Contact:

Re: [Blade of Agony] Road to Wolfenstein Devblog Part 02 | p

Post by ravage »

When working on hocusdoom I made it a point that any models I made/used had to fit the same style as the sprites and textures as well, which is why they tend to be fairly low poly and cleanish textures. Just something to think about.
User avatar
Nash
 
 
Posts: 17434
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia
Contact:

Re: [Blade of Agony] Road to Wolfenstein Devblog Part 02 | p

Post by Nash »

Enjay wrote:
Tormentor667 wrote:First, we are all limited to the resources we can access and to the resources we can create. None of is a model designer, and even though we already tried to get someone supporting us in this department, we didn't find a person for the team.
You said that Nash is on the team. I don't know if you've discussed it with him (and he could have reasons for not wanting to do it) but he certainly can model.
I was not asked to do any modeling work (at least as far as I can remember) but even if asked, I unfortunately cannot commit, as I already have my hands full on my own GZDoom-based standalone game... :( Sorry!

My contributions to Team BoA are mostly ZScript-related.
User avatar
Tormentor667
Posts: 13530
Joined: Wed Jul 16, 2003 3:52 am
Contact:

Re: [Blade of Agony] Road to Wolfenstein Devblog Part 02 | p

Post by Tormentor667 »

Rachael wrote:That's probably one of your better screenshots for the effect I was talking about - but I'll be honest - it *almost* works. [..] the colour of the food is so vibrant and pretty and the rest of the area is brown and drab.
You definitely made a good point here and it proofs that someteims you are simply blind when you work on your mod for a too long time with these assets. I tried to improve both of the meals now by reducing the brightness and vibrancy and making them look more realistic and fitting into their respective surroundings. Btw, I noticed that the screenshot shows the old 1x-size pixel objects. We improved them also in a real manual upscaling to reduce the "sprite filter" issue as well, @Graf Zahl. So, if there are other objects that stand out too much, let us know, its definitely something we can improve :)

Kinsie wrote:
Graf Zahl wrote:What bothers me about that screenshot is not the guards - it's the food lying on the table. These items are so at odds with the rest of the graphics it almost hurts. And of course, using an upscale filter to smooth their edges...
Yeah, when I last played BoA a while back, there was a lot of issues with sprite resolution inconsistency between the guards and pretty all the environment prop sprites. I dunno if it's been manually applied or if it's just Torm's GZDoom settings, but trying to alleviate that with a quick-n-dirty sprite filter almost makes things worse.
You are definitely right. For the release of Chapter 2 we weren't finished yet with converting all props and items to the double-scale look that we had for the enemies (guards, bosses, etc). Our spriter DoomJedi did catch up with most of it now, having almost every sprite in a higher resolution if it makes sense and the looks benefit.
Enjay wrote:You said that Nash is on the team. I don't know if you've discussed it with him (and he could have reasons for not wanting to do it) but he certainly can model.
Disregarding what Nash stated already, I wasn't even aware that he is capable of modeling :)
Enjay wrote:That's very close to the philosophy I adopted for my BGPA Burghead mod. I didn't have, and couldn't create, models for the enemies but I did want to include models and I feel that models work much better than sprites for bigger objects such as vehicles. So, my basic rule was "if it's an animal (soldiers, dogs, NPCs, etc) or comes from one/can be picked up by one (dropped items, med packs etc) it's a sprite but if it is 'solid' and/or 'part of the world' (vehicles, machines, trees, scenery items) then it's a model. It's not perfect. It's a compromise but it's the best that I could do and I tried to adopt those rules consistently within the mod.
Exactly, and I think that this compromise works pretty well. Sure, it's a "mish-mash"-style of resources but we try to make it feel as good as possible and it's simply the only way we can realize our visions. Fortunately the feedback has been very good so far, even on more official gaming review sites and despite the fact that I can understand Rachael's gripes it has been received quite well outside the Doom community - and also inside :)
ravage wrote:When working on hocusdoom I made it a point that any models I made/used had to fit the same style as the sprites and textures as well, which is why they tend to be fairly low poly and cleanish textures. Just something to think about.
Absolutely true and I have to say that the art-design in Hocus Doom is simply perfect, really. The aesthetics feel like this is an official game from Apogee, coming directly from the 90's, delivered by a DeLorean :) Still the problem stays - we simply don't have a person on our team who is able to create such models from scratch :|
User avatar
Rachael
Posts: 13530
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: [Blade of Agony] Road to Wolfenstein Devblog Part 02 | p

Post by Rachael »

Tormentor667 wrote: I tried to improve both of the meals now by reducing the brightness and vibrancy and making them look more realistic and fitting into their respective surroundings.
I've yet to see the results of such work - but just based on what you have stated here, I believe it will improve things greatly in at least that particular screenshot - as well as any other scene where that prop is used. :)
User avatar
Tormentor667
Posts: 13530
Joined: Wed Jul 16, 2003 3:52 am
Contact:

Re: [Blade of Agony] Road to Wolfenstein Devblog Part 02 | p

Post by Tormentor667 »

It's definitely better than before, that's what I can tell :) If there is anything else, just let me know, we are always happy to get some input regarding this "mod-blindness" :)
drako
Posts: 30
Joined: Fri Jan 08, 2016 8:16 pm

Re: [Blade of Agony] Road to Wolfenstein Devblog Part 02 | p

Post by drako »

I have just downloaded the newest GitHub wolfendoom-master.zip and tried to run it with the newest gzdoom x64 (Jan 19 version). It crashes with access violation error when I try to play a map (either by using console MAP CxMy or by using "new game"). Is it just problem on my side or some of you have similar problems?

EDIT: It seems that x32 build (Jan 21, 251) works better, It crashes when I go to c1m1 (command map c1m1) but it does not crash on map c1m2-c1m5 (I did not test others). x64 crashes on all the above.

EDIT2: Discussion forwarded to viewtopic.php?f=2&t=63365&p=1088482#p1088482
Last edited by drako on Tue Jan 22, 2019 7:33 am, edited 2 times in total.
User avatar
Enjay
 
 
Posts: 26517
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland
Contact:

Re: [Blade of Agony] Road to Wolfenstein Devblog Part 02 | p

Post by Enjay »

Tormentor667 wrote:
That looks much better. :thumb:
User avatar
Wiw
Posts: 766
Joined: Thu Jun 11, 2015 1:58 am
Graphics Processor: nVidia with Vulkan support
Location: Everywhere and nowhere.

Re: [Road to Wolfenstein] Devblog 02 | Modern Shaders

Post by Wiw »

Tormentor667 wrote:Motion Blur, Vignette, Lens Flares, Film Grain...
I know we're trying to appeal to everyone, but do we really need all those filters? The motion blur, especially.
User avatar
jazzmaster9
Posts: 862
Joined: Wed Apr 18, 2012 11:37 pm
Contact:

Re: [Road to Wolfenstein] Devblog 02 | Modern Shaders

Post by jazzmaster9 »

Wiw wrote:
Tormentor667 wrote:Motion Blur, Vignette, Lens Flares, Film Grain...
I know we're trying to appeal to everyone, but do we really need all those filters? The motion blur, especially.
This guy right here won't mind playing around with some of those :)


Also im really liking the new shading on those Food sprites. will the same be done on the Enemy soldiers?
User avatar
SamVision
Posts: 2425
Joined: Tue Apr 13, 2010 4:47 pm
Location: Behind You

Re: [Blade of Agony] Road to Wolfenstein Devblog Part 02 | p

Post by SamVision »

For me all those filters and effects just lags the game and destroys visibility.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: [Blade of Agony] Road to Wolfenstein Devblog Part 02 | p

Post by Graf Zahl »

On my work Mac the filters do not even work. The Motion Blur filter only creates total visual garbage, so this needs to be off by default. The game starts up only showing visual garbage.
Remember, GZDoom does not enable its postprocessing effects by default, they all need to be enabled by the user. The same goes for the shadowmap feature.

All of this requires very beefy hardware to work well, and somewhat decent drivers to even just work. On Mac we got neither: Only Intel crapware and a totally obsolete OpenGL backend.
Switching on the filters reduces performance by half, even when being compiled in debug mode! And there's still a significant portion of users on such systems with weak graphics hardware.

Sorry, but in this case I have to say that this compulsive need for being "cool" is seriously backfiring. Do it like any other person would do and make these OPTIONS, i.e. only let the user decide if they want it and not force it on upon first start. This will give a devastating impression to this mod because it runs like crap on lower end hardware and sacrifices a major piece of performance on better systems for mostly degrading effects. The average user will have no fucking clue how to tune the game to their system and then spread bad word of mouth.
User avatar
Tormentor667
Posts: 13530
Joined: Wed Jul 16, 2003 3:52 am
Contact:

Re: [Blade of Agony] Road to Wolfenstein Devblog Part 02 | p

Post by Tormentor667 »

Graf Zahl wrote:On my work Mac the filters do not even work.
Thanks for the feedback Graf Zahl, you really made some good points with your post. I think it's the right decision in this case to set the "post-processing" by default to "off". :)
jazzmaster9 wrote:Also im really liking the new shading on those Food sprites. will the same be done on the Enemy soldiers?
The only difference in the food sprites is the vibrancy and color, not the shading actually. Considering how many sprites we would have to rework for the enemies, it's very unlikely that we will adjust the shading for them-
User avatar
Rachael
Posts: 13530
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: [Blade of Agony] Road to Wolfenstein Devblog Part 02 | p

Post by Rachael »

Tormentor667 wrote:Thanks for the feedback Graf Zahl, you really made some good points with your post. I think it's the right decision in this case to set the "post-processing" by default to "off". :)
If it's any consolation, you can put in a message in your menu that says "enable all shader effects" and then lock it behind a message that says "This will configure the game the way it was meant to be experienced - however it requires an incredibly advanced system and may not work with all configurations. This can cause the game to become unstable or even crash on weaker hardware. Are you sure you wish to do this?" followed by a Yes/No prompt. The menu entry can then execute an alias defined in keyconf to switch the relevant shaders on.

But be careful - I do agree with Graf when he says this compulsive need to be "cool" can seriously backfire. At least it gives you the option to present to the user a way to configure the game the way it was "meant" to be played.
Post Reply

Return to “TCs, Full Games, and Other Projects”