[ALPHA] Total Chaos - Open Alpha out now!

[Nash]

Hello. I'm leaving feedback here instead of the ZDoom forum because I figured Wad'a'holic is more active here than there.

- Please add a user option to disable or adjust the factor/multiplier of the view tilting/rolling for the player's movements as I get motion sick very easily and there doesn't seem to be a way adjust it. I don't mind immersive first person stuff but it's a little too much right now. A slider in the Options menu would be much appreciated.

- Please seriously consider losing the entire HudMessage render canvas and let the game render natively. It does not cover the entire screen (I still see slivers of the "real" view behind the HudMessage canvas), it is not widescreen friendly and you will never be able to account for every user configuration possibility; past, present or future. The view is very blurry (or pixelated if the user has turned off texture filtering) and - most importantly - GZDoom's built-in framebuffer post processing does not work. I was disappointed that I couldn't play TC with GZDoom's native SSAO and Bloom shaders. I don't know why you still need to render the game to a HudMessage canvas but just in case - you can already natively roll the player's camera (that's why I added the camera rolling features into GZDoom! :P ChangeActorRoll / A_SetRoll) and if you want TRUE post processing, GZDoom's framebuffer architecture already allows such a thing. I will pass the message along to dpJudas to see if he's willing to implement native motion blur into the post processing pipeline, which appears to be something TC had to hack in in the past. And finally, another reason to drop fake-postprocessing-via-HudMessage hacks: they will never be virtual reality hardware friendly, ever.

(It might interest you to know that dpJudas has indeed expressed interest to implement a host of other postprocessing shader goodies in future so that's good news)

- Minor nitpick - the game's SmallFont (options menu) is too low res and blurry, which is inconsistent with the high res UI elements seen in everything else in the game.

Congratulations on the open alpha release, I was really looking forward to play this but I unfortunately cannot due to the first 2 issues above - which saddens me because I can see that obviously a lot of hard work went into the art assets and I was eager to enjoy them.

Thanks for your consideration and keep up the massively awesome work. Looking forward to see these issues addressed so I can enjoy the game!

[kodi]

Chiming in with everything nash said, while adding that I love the art direction and providing an example of a scaled smallfont in the options menu:

[Wad'a'Holic]

Hey Nash, cheers for the indepth feedback!

- Please add a user option to disable or adjust the factor/multiplier of the view tilting/rolling for the player's movements as I get motion sick very easily and there doesn't seem to be a way adjust it. I don't mind immersive first person stuff but it's a little too much right now. A slider in the Options menu would be much appreciated.

This shouldn't be too hard to implement, it will be coming in the near future :D

- Please seriously consider losing the entire HudMessage render canvas and let the game render natively. It does not cover the entire screen (I still see slivers of the "real" view behind the HudMessage canvas), it is not widescreen friendly and you will never be able to account for every user configuration possibility; past, present or future. The view is very blurry (or pixelated if the user has turned off texture filtering) and - most importantly - GZDoom's built-in framebuffer post processing does not work. I was disappointed that I couldn't play TC with GZDoom's native SSAO and Bloom shaders. I don't know why you still need to render the game to a HudMessage canvas but just in case - you can already natively roll the player's camera (that's why I added the camera rolling features into GZDoom! :P ChangeActorRoll / A_SetRoll) and if you want TRUE post processing, GZDoom's framebuffer architecture already allows such a thing. I will pass the message along to dpJudas to see if he's willing to implement native motion blur into the post processing pipeline, which appears to be something TC had to hack in in the past. And finally, another reason to drop fake-postprocessing-via-HudMessage hacks: they will never be virtual reality hardware friendly, ever.

This is currently at the top of the tech problems list.
I have started working on a replacement of the camera and weapon placement systems that do away with the CamTexture compositing system completely, however I've reached a roadblock in the way of translating the weapon to the players viewport.

Rather than using the native ZDoom weapon system, I've written my own in gdcc. When compositing the view with CamTextures I was able to simply render the weapon model inside this, but after doing away with the CamTextures and placing the viewmodel in front of the player, I am needing to attach it to the players view, but with the 35tic limitation I'm having trouble having it track properly without stuttering when the player moves around.

I managed to get A_Warp to run an interpolation with the position, however the problem now is I can't get the angle and pitch to do the same, resulting in smooth XYZ movement, but stuttering camera rotations.

I'm not too concerned about loosing the motion blur. While I personally feel it adds a lot, there are many who would rather play without it, it also caked performance in some instances which I didn't feel was acceptable.
There are post-processing shaders inside ReShade that can do motion blur, so I feel if I leave it out, it won't be massively missed

Cheers for the feedback!

[Nash]

modular weapon system

I also had a problem with this and I've tried all kinds of solutions (even the one you mentioned) but as you've discovered, there's always technical showstoppers.

I see two available options right now currently (although I have ditched the modular weapon system for my project)


1) A_Overlay and friends
2) Wait for ZScript. Graf Zahl said access to low level DThinkers is definitely on the list, which means we can completely override the base Weapon class. You can do your weapon composting on a low level there and not be at the mercy of the 35hz ACS VM. And ZScript is actually progressing VERY fast lately (unlike DoomScript LOL) so I actually expect this to be available really soon. If you do a ZDoom forum search for ZScript, you'll find plenty of reading material and interesting bits of info that will definitely be of interest to large scale projects like TC. Even the currently available features of ZScript in the alpha builds are vastly more powerful than DECORATE already (structs, enums, custom pointers, custom functions)!

[Wad'a'Holic]

I may hold the course with the current system and look at refactoring it closer to the next release. ZScript does indeed sound promising.

[Lollipop]

I tried this out for a moment, and I liked what I could see in terms of feel and the nice tech developed for this. Unfortunately the experience was unbearable for me because GZDoom is appearently unable to run without visual artifacts in a vast quantity that made it impossible for me to see shit.
I will definitely play this when zan catches up in terms of the things this mod needs to run, but I'm just not using GZDoom as it would be an outright dishonor to your efforts.

Good luck with the further development. :)

[Combinebobnt]

Good job on adding combat, run away simulators are boring. I wonder if my pc that barely got by doom 4 can run this...