Page 162 of 178

Re: [Blade of Agony] Tank Battlefield Screens! | p161

PostPosted: Sun Apr 08, 2018 5:22 am
by Tormentor667

Re: [Blade of Agony] Tank Battlefield Screens! | p161

PostPosted: Sun Apr 08, 2018 10:39 am
by Rex705
Oooooooo pretty. I can't wait to play this.

Re: [Blade of Agony] Tank Battlefield Screens! | p161

PostPosted: Sun Apr 08, 2018 6:01 pm
by RockstarRaccoon
Chapter 3 is looking appropriately harrowing there.

Re: [Blade of Agony] Tank Battlefield Screens! | p161

PostPosted: Wed Apr 18, 2018 9:28 am
by wolfmanfp
The text at the end of Chapter 2 has an error:
Spoiler:

Re: [Blade of Agony] Tank Battlefield Screens! | p161

PostPosted: Thu Apr 19, 2018 7:19 am
by peachesjelly
i have a bug when playing blades of agony
i posted an imgur link to show what is the bug
https://imgur.com/g9ycEh7

Re: [Blade of Agony] Tank Battlefield Screens! | p161

PostPosted: Thu Apr 19, 2018 10:20 am
by wildweasel
Those icons are placeholder sprites for 3D models. You need to be using the OpenGL renderer.

Re: [Blade of Agony] Tank Battlefield Screens! | p161

PostPosted: Thu Apr 19, 2018 10:21 am
by peachesjelly
How do i enable it

Re: [Blade of Agony] Tank Battlefield Screens! | p161

PostPosted: Fri Apr 20, 2018 4:49 pm
by RockstarRaccoon
peachesjelly wrote:How do i enable it

When you start GZDoom, select the Hardware renderer, not the Software one.

Also, to take a screenshot in GZDoom, use the "prt sc" key.

Re: [Blade of Agony] Tank Battlefield Screens! | p161

PostPosted: Sun May 13, 2018 3:03 am
by Graf Zahl
So I just updated the mod from the git repo to run some performance tests on C3M3 - and I had to notice that performance got even worse than it was in the last version I had!

In some places of the map the FPS display dipped down to values of 15 and less - and I actually do have a rather powerful system that certainly outclasses 70-80% of what's common in the market.
In short: The map looks like it's unplayable right now. Are there any plans to address this? The village surely looks beautiful, but what does it help if the map cannot be played? When inside the village my average FPS hovers around 30, when getting father away it goes, like I said, down to 14/15. About half of that time is spent on portals alone (that's the church steeple and the surrounding horizons. So one thing you absolutely should consider is to replace the horizons with traditional sky hacks, because they incur a lot less processing overhead - of course they won't solve the performance issues entirely but they'll probably help a bit already as there's up to 20 portals visible in some scenes.

I'd also recommend to redesign the church to not require a portal. In a map that already sufferes from too many portals, such a purely visual one should be omitted. Just make a smaller church! ;)

Re: [Blade of Agony] Tank Battlefield Screens! | p161

PostPosted: Sun May 13, 2018 6:13 am
by Tormentor667
Thanks kindly for your feedback, I just took another opportunity to change the things you have mentioned regarding the church tower (portal was removed, construction via 3d floors) and the horizon lines (classic sky tricks). I unfortunately can't tell if it is any better now, maybe you can give the latest commit another try.

Do you have any other suggestions that will improve the performance without any conceptual losses?

Re: [Blade of Agony] Tank Battlefield Screens! | p161

PostPosted: Sun May 13, 2018 7:49 am
by Graf Zahl
The spot that previously was 15 fps is now 20 fps, so it definitely helped.

For the rest, I don't think it can be solved without engine-side help. I am experimenting with something but obviously cannot guarantee any results.

Re: [Blade of Agony] Tank Battlefield Screens! | p161

PostPosted: Sun May 13, 2018 10:09 am
by RockstarRaccoon
I'm interested to hear how this works out, because I'm also a big fan of large open areas. Personally, I've been wondering if performance could be improved on them if the system which draws lower details at further distances was better implemented, maybe if we could incorporate fog to make the renderer use less power for distant objects.

I'll also note, Tormentor, that I noticed the other day while poking around in the new C1 maps, that some of the textures on your MD3 models are incredibly high resolution. If you have a lot of rocks in a map, and all the rocks have a 2046x2046 texture, that's going to be a bit overwhelming on the graphics card. We had a pretty intensive system we were going to use for Membrane, but we had to scale it back when we realized just how much VRAM it would use.

Even on my new development machine, which MicroStar made for professional gaming, there are dips in the frame rate whenever you abuse portals or have too many insane-res textures or too many intensive effects in a big open area.

Re: [Blade of Agony] Tank Battlefield Screens! | p161

PostPosted: Sun May 13, 2018 11:05 am
by Graf Zahl
RockstarRaccoon wrote:I'm interested to hear how this works out,


It will take some time to have results. This is not a simple task and this most definitely cannot be automated for existing maps. It is something that will have to be explicitly set up for a map and will also have some restrictions of what can be combined. Remember: The goal is to save time and one important aspect here is to cut down on checks for rare special cases or stuff that cannot be simplified.

Re: [Blade of Agony] Tank Battlefield Screens! | p161

PostPosted: Sun May 13, 2018 11:49 am
by RockstarRaccoon
I would actually be very happy if there was a system where I could tag sectors or lines to help the renderer and BSP along. If you look back in the feature forums, you'll see that I actually asked for such a feature a while back.

Re: [Blade of Agony] Tank Battlefield Screens! | p161

PostPosted: Sun May 13, 2018 1:02 pm
by Graf Zahl
Sure. The main problem, of course, is that Doom lives and dies by the BSP so fudging with that is bound to cause some problems down the line that need to be worked out first.
The entire idea of creating static parts of the map basically requires that those parts are excluded from normal processing, but then such important things as polyobjects, dynamic lights and particles will no longer work because what they assume about the BSP will no longer be true.

There's of course solutions for this but they all have a problem with how Doom organizes its level data, i.e. some global arrays of stuff that get referenced directly from everywhere and which all assume they are the only one of their kind in town.

So I won't make any promises. Right now I cannot say what will be doable because first some heavy data restructuring is needed.