Movement of SkyViewpoint and internal datakeeping

[stan423321]

If you have never thought to try that before, you can derive an actor class from SkyViewpoint and move it, and the result is that the skybox view will move accordingly. This allows some interesting effects, the sanest of which is changing an in-map skybox to another in-map skybox. With the simplest of test skyboxes this appears to work.

The ZScript enabled versions of gzdoom.pk3 ship with SkyViewpoint which sends pointer to its home sector somewhere to sector portals data during initialization, however, which is somewhat unsettling. Am I supposed to somehow tell it to update this data when changing sectors?

[Graf Zahl]

You are misunderstanding this. level.sectorportals has no association with a single sector. It's the list of all portals and the skybox needs to associate itself with the corresponding portal data so that the portal gets rendered from the correct viewpoint. This is needed precisely for the case where the viewpoint moves.

[stan423321]

Okay, so the case of it moving is considered, that's great.

This is not strictly necessary for my purposes, but what is the purpose of CurSector assignment if not "association with a single sector"? This line:

Code: Select all

level.sectorPortals[0].mDestination = CurSector;

[Enjay]

If you have never thought to try that before, you can derive an actor class from SkyViewpoint and move it, and the result is that the skybox view will move accordingly. This allows some interesting effects, the sanest of which is changing an in-map skybox to another in-map skybox. With the simplest of test skyboxes this appears to work.

To be fair, you don't even need to derive a new actor from the original one (especially if all you want to do is move the skybox camera to another location to change the sky). Try the attached. It uses a standard skybox viewpoint and moves it with an ACS script (using Thing_Move) between 3 different locations.

SkyMove.zip

As an aside, I know that my (albeit simple) hurriedly (and horribly) done ACS script is not as efficient as it could be. I believe that using "case" or something might be better and using the WhichSky within the Thing_Move instruction too. I know how to do the second part, but using "case" has always confused me a little. Anyone able to post a more efficient version for me to learn from?

Code: Select all

#include "zcommon.acs"

int WhichSky;

Script 1 (void)
{
	if (WhichSky == 0)
	{
	WhichSky = 1;
	Thing_Move (1, 2, 1);
	Terminate;
	}

	if (WhichSky == 1)
	{
	WhichSky = 2;
	Thing_Move (1, 3, 1);
	Terminate;
	}

	if (WhichSky == 2)
	{
	WhichSky = 0;
	Thing_Move (1, 4, 1);
	Terminate;
	}
}

[Graf Zahl]

Okay, so the case of it moving is considered, that's great.

This is not strictly necessary for my purposes, but what is the purpose of CurSector assignment if not "association with a single sector"? This line:

Code: Select all

level.sectorPortals[0].mDestination = CurSector;

In the hardware renderer this is only used to get the current portal group, i.e. the continuous section of the map the portal is in.
I cannot say what the software renderer is doing with this - there's too much code shared with real sector portals to give you a comprehensive answer.

If you want to check, get Team TNT's Daedalus mod, there's one map (I think MAP21) which uses an extended spaceship-landing sequence which uses a moving skybox viewpoint. If that works correctly, you do not have to worry.

[Enjay]

This could also be useful: https://zdoom.org/files/other_examples/starbox.zip

[stan423321]

Moving a spaceship sounds like exactly one of the weirder things I had in mind. I'll take a look at the examples, thank you both.