[dandouglas]

Hi everyone, I'm currently putting together a Duke 3D mod and have opted to use the map caching/hub map feature to let me increase the size of my main map. This works great, bar the split-second visual glitches when transitioning maps - I've slowed things down frame-by-frame and I think it's because a little of the animation of Duke spinning to face forward when starting a new level is playing each time, alongside a very brief loading screen (the background of which I've made plain black to minimise the impact). Does anyone have any tips on optimising these transitions? Ion Fury's are super-smooth, just a tiny pause between maps, and I'd like to match that if at all possible. Thanks!

[Danukem]

If the connected maps have the same orientation, then you could save the player's angle at the moment before map transport, then apply it after entering the new map. This might require hacking a display event to prevent showing the wrong angle for a frame, though, I'm not sure.


EDIT: Okay, so it's not that simple. After the map transition, the game seems to set the player angle to the angle of the green starting arrow of the new map, and apparently this happens *after* the logical place where you would want to insert your own angle override. So I'm trying to figure out where to put the angle override. (I have tried putting it in EVENT_ENTERLEVEL and it didn't work)

EDIT2: I have a hack now that sort of does the job. It's not pretty and I hope that a real solution is available. But here it is, in case you want to use it:

gamevar SAVEDANG 0 131073
gamevar SAVEDANGCOUNT 0 131073

This assumes that the maps are oriented the same way. (I.e. north in one map is the same as north in the other). If not you will need to compensate. In the same block of code where you use savemapstate, but before that command is issued, do this:

getp[].ang SAVEDANG
set SAVEDANGCOUNT 7

Now, also add this event code somewhere:

appendevent EVENT_DISPLAYROOMS

ifn SAVEDANGCOUNT 0 
{
	set cameraang SAVEDANG
	setp[].ang SAVEDANG
}
endevent

Finally, decrement the var so it goes down once per tic (this could be in the player actor for example):

ifn SAVEDANGCOUNT 0
	sub SAVEDANGCOUNT 1

The result of all this is the angle is forced to be the same as when the transition started, during the entire time when it would show the player turning to the start angle. Note that setting the player's actual angle in the display event is not good practice; this could happen when the count var is decremented instead but with current interpolation code I wasn't sure if that would lead to jittering.

[dandouglas]

Danukem, on 13 September 2021 - 08:55 AM, said:

If the connected maps have the same orientation, then you could save the player's angle at the moment before map transport, then apply it after entering the new map. This might require hacking a display event to prevent showing the wrong angle for a frame, though, I'm not sure.


EDIT: Okay, so it's not that simple. After the map transition, the game seems to set the player angle to the angle of the green starting arrow of the new map, and apparently this happens *after* the logical place where you would want to insert your own angle override. So I'm trying to figure out where to put the angle override. (I have tried putting it in EVENT_ENTERLEVEL and it didn't work)

EDIT2: I have a hack now that sort of does the job. It's not pretty and I hope that a real solution is available. But here it is, in case you want to use it:

gamevar SAVEDANG 0 131073
gamevar SAVEDANGCOUNT 0 131073

This assumes that the maps are oriented the same way. (I.e. north in one map is the same as north in the other). If not you will need to compensate. In the same block of code where you use savemapstate, but before that command is issued, do this:

getp[].ang SAVEDANG
set SAVEDANGCOUNT 7

Now, also add this event code somewhere:

appendevent EVENT_DISPLAYROOMS

ifn SAVEDANGCOUNT 0 
{
	set cameraang SAVEDANG
	setp[].ang SAVEDANG
}
endevent

Finally, decrement the var so it goes down once per tic (this could be in the player actor for example):

ifn SAVEDANGCOUNT 0
	sub SAVEDANGCOUNT 1

The result of all this is the angle is forced to be the same as when the transition started, during the entire time when it would show the player turning to the start angle. Note that setting the player's actual angle in the display event is not good practice; this could happen when the count var is decremented instead but with current interpolation code I wasn't sure if that would lead to jittering.

Thanks so much for putting all this together, I really appreciate it!

[dandouglas]

So I've had a chance to play around with this and the transition from Map 1 to Map 2 looks great, very little in the way of visual glitching - thank you!

However, and this is something I've only just noticed since moving my Map 1 start location back to its original position after testing, is that going back from Map 2 > Map 1 gives me a split-second view of the starting location of Map 1 - it's not too intrusive but it would be great if I could get rid of it.

I'm not 100% sure but I think the transition from Map 1 to Map 2 looks better is because I've placed the starting location of Map 2 in the same sector as the SE70 destination. When going from Map 2 to Map 1, it looks like the game is first inserting the player at the starting location (which is in a completely different area of the map) and then immediately teleporting them to the SE70 destination sector. This seems to explain the split-second visual glitch.

Any idea on a possible fix for this? I appreciate I'm being super-picky here and that this may be an unavoidable part of how map caching works in Duke 3D.

[Sangman]

I assume you'd have to spawn an invisible marker object at the location of the player just before he leaves the map. Then on re-entering much like with Dan's angle code above force the player's location to that marker?

[Danukem]

Sangman, on 17 September 2021 - 07:04 AM, said:

I assume you'd have to spawn an invisible marker object at the location of the player just before he leaves the map. Then on re-entering much like with Dan's angle code above force the player's location to that marker?

But he must already have code that moves the player to the correct place, or else the "split-second" view of the normal map start would not be split-second. I have the same issue and I move the player when EVENT_ENTERLEVEL triggers. So evidently the player is already in the normal start place before that event.