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.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...
[Wolfenstein: Blade of Agony] v3.1 released (p204)
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.
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.
- 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
Re: [Blade of Agony] Road to Wolfenstein Devblog Part 02 | p
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: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.
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.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.
Re: [Blade of Agony] Road to Wolfenstein Devblog Part 02 | p
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
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!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.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.
My contributions to Team BoA are mostly ZScript-related.
- Tormentor667
- Posts: 13530
- Joined: Wed Jul 16, 2003 3:52 am
- Contact:
Re: [Blade of Agony] Road to Wolfenstein Devblog Part 02 | p
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 improveRachael 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 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.Kinsie wrote: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.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...
Disregarding what Nash stated already, I wasn't even aware that he is capable of modelingEnjay 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.
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 insideEnjay 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.
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 scratchravage 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.
Re: [Blade of Agony] Road to Wolfenstein Devblog Part 02 | p
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.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.
- Tormentor667
- Posts: 13530
- Joined: Wed Jul 16, 2003 3:52 am
- Contact:
Re: [Blade of Agony] Road to Wolfenstein Devblog Part 02 | p
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
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
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.
- 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
I know we're trying to appeal to everyone, but do we really need all those filters? The motion blur, especially.Tormentor667 wrote:Motion Blur, Vignette, Lens Flares, Film Grain...
- jazzmaster9
- Posts: 862
- Joined: Wed Apr 18, 2012 11:37 pm
- Contact:
Re: [Road to Wolfenstein] Devblog 02 | Modern Shaders
This guy right here won't mind playing around with some of thoseWiw wrote:I know we're trying to appeal to everyone, but do we really need all those filters? The motion blur, especially.Tormentor667 wrote:Motion Blur, Vignette, Lens Flares, Film Grain...
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
For me all those filters and effects just lags the game and destroys visibility.
- Graf Zahl
- 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
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.
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.
- Tormentor667
- Posts: 13530
- Joined: Wed Jul 16, 2003 3:52 am
- Contact:
Re: [Blade of Agony] Road to Wolfenstein Devblog Part 02 | p
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".Graf Zahl wrote:On my work Mac the filters do not even work.
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-jazzmaster9 wrote: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
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.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".
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.