
...
The bad news is I don't know whether the method I did it with is "frowned" upon, so to speak.
Moderator: GZDoom Developers
Spoiler: "Entire code"
Graf Zahl wrote:In the end, what' preventing us from combining different approaches: Static mesh for the main parts of the map and some hybrid approach for portals where the static way won't work? The main view is the most important one anyway so if that can be sped up, it may even be fine to render the portals with a traditional BSP - and even there a lot depends on the portal's shape. A line portal can be handled with a simple hardware clip plane and for sector portals some analysis is necessary to decide how to do it - but that's normally a one-time operation when the map starts.
Eruanna wrote:"No" from any dev - be it dpJudas, Graf, myself, ZZYZX, or anyone else - simply means "do it (and maintain it) yourself if you want it that badly."
Beed28 wrote:Here's a demo file that has the Doom hitscan monsters now throwing imp fireballs if anyone wants to see, but I fear the method I used might end up being phased out...
Try it out with a few DeHackEd monsters that used the hitscan functions as well (the MAP29 boss in gd.wad is a good place to start, as she uses a hitscan attack).
Eruanna wrote:And to make it clear: I am 100% against any renderer code touching playsim code whatsoever. All by itself this will break Zandronum compatibility right out the gate because it does run as a headless server no matter what renderer it is configured for. And I've already mentioned breaking demos and multiplayer - even in the sorry state that they are in now I see no reason to break them further. Please don't.
kodi wrote:@jadwick
It's much easier to use an invisible Overlay state that calls A_WeaponOffset (or A_OverlayOffset) in a loop with whatever sway equation you wish to have. Start this overlay by calling A_Overlay once in/after the select state. Clear the overlay at the start of the Fire state and restart it after if you don't want swaying while firing.
Beed28 wrote:Here's a demo file that has the Doom hitscan monsters now throwing imp fireballs if anyone wants to see, but I fear the method I used might end up being phased out...
Try it out with a few DeHackEd monsters that used the hitscan functions as well (the MAP29 boss in gd.wad is a good place to start, as she uses a hitscan attack).
dpJudas wrote:I can't see any reason why a hybrid method wouldn't work. In fact, I think maybe one way of drawing the scene could be to still do the traditional BSP, but then it just skips render (only updates the clipper) for the parts it renders from the static mesh. So the current BSP walking code would draw the dynamic parts. The static parts are then drawn afterwards (or before - not sure which is best). In such an approach the portals could just be considered to not ever be in the static mesh.
Graf Zahl wrote:Goddamnit! Forget one sanity check and it gets abused. Here's the problem: Once I implement a Vulkan renderer that shader stuff will break for sure. It will also break if new shader based features get added. In clear English: DON'T DO THAT! - EVER!
replacementshader "name" { ... }
Users browsing this forum: difficultoldstuff and 0 guests