[Blade of Agony] New screenshots | p179

For Total Conversions and projects that don't otherwise fall under the other categories.
Forum rules
The Projects forums are ONLY for YOUR 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.

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

Postby Kinsie » Fri Jan 18, 2019 9:46 am

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
Kinsie
A Concept Utterly Obsolete
 
Joined: 22 Oct 2004
Location: MAP33
Discord: Find Me...
Twitch ID: thekinsie

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

Postby Enjay » Fri Jan 18, 2019 12:40 pm

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
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

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

Postby ravage » Fri Jan 18, 2019 1:38 pm

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
ravage
YAHOO!
 
Joined: 03 Sep 2003

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

Postby Nash » Sat Jan 19, 2019 2:38 am

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
Nash
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Github ID: nashmuhandes

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

Postby Tormentor667 » Sat Jan 19, 2019 4:23 am

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
Tormentor667
needs more detail
 
Joined: 16 Jul 2003
Location: Germany

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

Postby Rachael » Sat Jan 19, 2019 3:21 pm

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
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle

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

Postby Tormentor667 » Sun Jan 20, 2019 6:39 am

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" :)
User avatar
Tormentor667
needs more detail
 
Joined: 16 Jul 2003
Location: Germany

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

Postby drako » Sun Jan 20, 2019 4:55 pm

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 8:33 am, edited 2 times in total.
drako
 
Joined: 08 Jan 2016

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

Postby Enjay » Sun Jan 20, 2019 5:23 pm

Tormentor667 wrote:

That looks much better. :thumb:
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

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

Postby Wiw » Mon Jan 21, 2019 6:52 am

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
Wiw
Frequently puts foot in mouth
 
Joined: 11 Jun 2015
Location: Everywhere and nowhere.

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

Postby jazzmaster9 » Mon Jan 21, 2019 8:17 am

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
jazzmaster9
J̶̛͉̹͇̋U̶̥̩̞͋Ṣ̵̨̛͋T̶̩͉̈̈́͘ ̷͔̹̖̊̽M̷̥̞̓͘͘O̸̯̠̽́N̶̫̠̂͗Ḯ̶̜̃̇Ḳ̶͓̻̊̅̄A̵͖̘͒
 
Joined: 19 Apr 2012

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

Postby SamVision » Mon Jan 21, 2019 6:12 pm

For me all those filters and effects just lags the game and destroys visibility.
User avatar
SamVision
 
Joined: 13 Apr 2010
Location: Behind You

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

Postby Graf Zahl » Tue Jan 22, 2019 3:09 am

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
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

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

Postby Tormentor667 » Tue Jan 22, 2019 7:22 am

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
Tormentor667
needs more detail
 
Joined: 16 Jul 2003
Location: Germany

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

Postby Rachael » Tue Jan 22, 2019 8:09 am

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.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle

PreviousNext

Return to TCs, Full Games, and Other Projects

Who is online

Users browsing this forum: Dewzanity and 4 guests