Wall portals
Moderator: GZDoom Developers
-
- Posts: 486
- Joined: Tue Nov 29, 2005 2:15 pm
- Graphics Processor: nVidia with Vulkan support
Re: Wall portals
I'm wondering the same. Been a few months with no word, I hope this doesn't go the way of the dodo, as this has amazing potential.
-
- Posts: 1112
- Joined: Sat May 22, 2010 12:49 pm
Re: Wall portals
Aw man why you bump I hoped for an update :/
-
-
- Posts: 17465
- Joined: Mon Oct 27, 2003 12:07 am
- Location: Kuala Lumpur, Malaysia
Re: Wall portals
Hope this doesn't suffer the same fate as AFADoomer's automap branch... :/
-
-
- Posts: 1384
- Joined: Sun Oct 14, 2012 1:43 am
- Location: Ukraine
Re: Wall portals
HI
Got myself pointed to this thread on Zandronum IRC.
Basically I'm coding the new version on occasion and only once I get (random) insights on how to do stuff the good way so it won't randomly bug out, unlike the /portals branch which had pretty much proof-of-concept code just so I could experiment (and also see it on my screen that "it actually works!")
Sorry for people that expected this to be in the next ZDoom release and/or expected that /portals branch is "the almost complete" version :\
Sadly nothing new happened in few months.. but anyway I'll probably finish the Z-difference physics enabled portals in the /portals2 branch soon, most likely featuring large changes to mapthing collision C struct... which is what I was trying to avoid in /portals btw, instead trying to calculate the necessary info with recursive physics calls. Which at the end resulted in odd behavior shit while touching simultaneously "real" and "portal" objects, as well as things in two different portals. Just an example of why /portals branch is bad even though its "almost complete".
Also one thing I definitely need to have an insight about is stuff sticking out of a portal, and collisions with such things, I don't think the blockmap would allow me to specify that "thing X comes from portal Y and thus has coordinates Z instead of thing->x/y/z" while linking it there multiple times. The way it works right now, is doing the reverse check — checking if the collided thing is coming from a portal, if it's too far away, but was encountered in the blockmap.
But that's unreliable for setups like: two close portals looking at each other, different heights, and a cacodemon sticking out of the upper portal into the lower one. The cacodemon would have x-y collision both in the portal and the real plane... oh and the hitscan tracers aren't working properly there too. For the same reason.
The current idea is ditching the physics voodoo and spawn a ghost invisible thing of the same dimensions through the portal that would transfer damage to the original... and possibly do some AI... and prevent the master from going anywhere if it gets stuck, too.
Also wat does this automap branch do?
Got myself pointed to this thread on Zandronum IRC.
Basically I'm coding the new version on occasion and only once I get (random) insights on how to do stuff the good way so it won't randomly bug out, unlike the /portals branch which had pretty much proof-of-concept code just so I could experiment (and also see it on my screen that "it actually works!")
Sorry for people that expected this to be in the next ZDoom release and/or expected that /portals branch is "the almost complete" version :\
Sadly nothing new happened in few months.. but anyway I'll probably finish the Z-difference physics enabled portals in the /portals2 branch soon, most likely featuring large changes to mapthing collision C struct... which is what I was trying to avoid in /portals btw, instead trying to calculate the necessary info with recursive physics calls. Which at the end resulted in odd behavior shit while touching simultaneously "real" and "portal" objects, as well as things in two different portals. Just an example of why /portals branch is bad even though its "almost complete".
Also one thing I definitely need to have an insight about is stuff sticking out of a portal, and collisions with such things, I don't think the blockmap would allow me to specify that "thing X comes from portal Y and thus has coordinates Z instead of thing->x/y/z" while linking it there multiple times. The way it works right now, is doing the reverse check — checking if the collided thing is coming from a portal, if it's too far away, but was encountered in the blockmap.
But that's unreliable for setups like: two close portals looking at each other, different heights, and a cacodemon sticking out of the upper portal into the lower one. The cacodemon would have x-y collision both in the portal and the real plane... oh and the hitscan tracers aren't working properly there too. For the same reason.
The current idea is ditching the physics voodoo and spawn a ghost invisible thing of the same dimensions through the portal that would transfer damage to the original... and possibly do some AI... and prevent the master from going anywhere if it gets stuck, too.
Also wat does this automap branch do?
-
-
- Posts: 17934
- Joined: Fri Jul 06, 2007 3:22 pm
Re: Wall portals
AFADoomer worked on something that'd make the automap a widget that can be placed in the status bar.
-
-
- Posts: 17465
- Joined: Mon Oct 27, 2003 12:07 am
- Location: Kuala Lumpur, Malaysia
Re: Wall portals
http://forum.zdoom.org/viewtopic.php?f= ... map+branchZZYZX wrote: Also wat does this automap branch do?
Good to hear from you BTW! Best of luck with your endeavors.
-
- Posts: 1337
- Joined: Tue Jul 15, 2003 4:18 pm
Re: Wall portals
I badly hacked it into the code at the time. I just don't have time to re-do it properly now... Don't even have a dev machine set up. I really don't think it would be difficult - the existing automap code is already set up to take 'window' coordinates, that just needs to be externalized to a proper function that can pass dynamic sizes, and then be set up to work cleanly via ACS.Gez wrote:AFADoomer worked on something that'd make the automap a widget that can be placed in the status bar.
-
-
- Posts: 12328
- Joined: Tue Jul 21, 2009 12:04 pm
- Preferred Pronouns: He/Him
- Operating System Version (Optional): Windows 11
- Graphics Processor: nVidia with Vulkan support
- Location: capital N, capital S, no space
Re: Wall portals
Wouldn't it be better as an SBarInfo feature?AFADoomer wrote:[...] and then be set up to work cleanly via ACS.
-
- Posts: 1337
- Joined: Tue Jul 15, 2003 4:18 pm
Re: Wall portals
Probably better in SBarInfo, yes. I originally intended to set it up to be able to be used like an on-screen scanner that could be turned on and off, hence ACS...
Either way, we're threadjacking .
Either way, we're threadjacking .
-
- Posts: 753
- Joined: Tue Jul 15, 2003 3:37 pm
Re: Wall portals
Saw this being mentioned on DW. Just wanted to say that it looks amazing, keep up the great work!
-
- Posts: 772
- Joined: Sun May 04, 2014 7:22 pm
Re: Wall portals
Indeed. It would be a beyond glorious feature if it were to make it into the main codebase.
-
- Posts: 291
- Joined: Mon Nov 14, 2011 9:59 am
- Preferred Pronouns: He/Him
- Operating System Version (Optional): Windows 11
- Graphics Processor: nVidia with Vulkan support
- Location: Around weirdos, I'm the biggest weirdo among them
Re: Wall portals
Wow, keep up the good work!
.. I can already see that Terry-trolls will use this, a lot.
.. I can already see that Terry-trolls will use this, a lot.
-
-
- Posts: 17934
- Joined: Fri Jul 06, 2007 3:22 pm
Re: Wall portals
Thanks, now I'm less sad about this not having had any progress at all since December last year.KiLerZolika wrote:.. I can already see that Terry-trolls will use this, a lot.
-
-
- Posts: 1384
- Joined: Sun Oct 14, 2012 1:43 am
- Location: Ukraine
Re: Wall portals
Hey, commits!
-
- Posts: 8196
- Joined: Sun Jan 28, 2007 3:55 pm
- Preferred Pronouns: He/Him
- Location: QZDoom Maintenance Team
Re: Wall portals
And a video!