Page 170 of 173

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

PostPosted: Fri Jan 18, 2019 9:46 am
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.

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

PostPosted: Fri Jan 18, 2019 12:40 pm
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.

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

PostPosted: Fri Jan 18, 2019 1:38 pm
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.

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

PostPosted: Sat Jan 19, 2019 2:38 am
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.

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

PostPosted: Sat Jan 19, 2019 4:23 am
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 :|

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

PostPosted: Sat Jan 19, 2019 3:21 pm
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. :)

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

PostPosted: Sun Jan 20, 2019 6:39 am
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" :)

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

PostPosted: Sun Jan 20, 2019 4:55 pm
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

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

PostPosted: Sun Jan 20, 2019 5:23 pm
by Enjay
Tormentor667 wrote:

That looks much better. :thumb:

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

PostPosted: Mon Jan 21, 2019 6:52 am
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.

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

PostPosted: Mon Jan 21, 2019 8:17 am
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?

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

PostPosted: Mon Jan 21, 2019 6:12 pm
by SamVision
For me all those filters and effects just lags the game and destroys visibility.

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

PostPosted: Tue Jan 22, 2019 3:09 am
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.

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

PostPosted: Tue Jan 22, 2019 7:22 am
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-

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

PostPosted: Tue Jan 22, 2019 8:09 am
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.