Duke4.net Forums: ATTENTION MODDERS: Interpolation Patch (Feedback, & notes for modders) - Duke4.net Forums

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

ATTENTION MODDERS: Interpolation Patch (Feedback, & notes for modders)  "A potential patch for EDuke32 that fixes interp for CON actors."

User is offline   Striker 

  • Auramancer

#1

I'm currently working on a patch for EDuke32 that I want to get peoples' (especially modders) feedback on.

This patch removes a rather retarded line of legacy Duke3D code that breaks interpolation for CON actors:

    if (AC_MOVE_ID(vm.pData) == 0 || movflags == 0)
    {
        if (deadflag || (vm.pActor->bpos.x != vm.pSprite->x) || (vm.pActor->bpos.y != vm.pSprite->y))
        {
            vm.pActor->bpos.vec2 = vm.pSprite->pos.vec2; // <-- This line is dumb
            setsprite(vm.spriteNum, &vm.pSprite->pos);
        }
        return;
    }

The problem here, is that the old position is overwritten by the new position every frame, before it even gets a chance to be processed by the interpolation code.

If you wondered why CON actors are jittery, but everything else is not, this is why. This patch makes CON actors behave like everything else.

I want modders to test out their own mods with this patch, and see how things behave.
If you have any instantly-teleporting actors in your mod that are being "tweened" from their old position to their new one, and you don't wish for this to happen, set htbpos(x/y/z) to the x/y/z coords of the actor after moving, like so:

    // Do this after changing x, y, or z, or calling a movesprite command.
    setactor[THISACTOR].htbposx sprite[].x
    setactor[THISACTOR].htbposy sprite[].y
    setactor[THISACTOR].htbposz sprite[].z

Shorter version in spoiler:
Spoiler

This is something hard-coded actors in Duke3D do when they need to teleport from one location to another, and is good practice to do anyway, with this patch or not.

Link to the patch itself: http://shadowmaveric...lation_Fix.diff
Here's a link to an eduke32.exe build with this patch: http://shadowmaveric...reX/eduke32.exe

I just want to get peoples' opinions on this patch, and whether or not this fix needs to be opt-in or not (I'm leaning towards no, because it's how all moving non-CON actors behave already).

Also, give it a try in Ion Fury, and marvel at how much smoother things are. :P

This post has been edited by Striker: 10 February 2020 - 06:59 PM

3

User is offline   Trooper Dan 

  • Duke Plus Developer

#2

For clarification: Does the current jitteryness affect actors that use SFLAG_SMOOTHMOVE , or only actors that don't use it?

I haven't noticed a problem, but I think I use that flag on pretty much all of my actors.
0

User is offline   Striker 

  • Auramancer

#3

View PostTrooper Dan, on 10 February 2020 - 06:34 PM, said:

For clarification: Does the current jitteryness affect actors that use SFLAG_SMOOTHMOVE , or only actors that don't use it?

I haven't noticed a problem, but I think I use that flag on pretty much all of my actors.

Yes. SFLAG_SMOOTHMOVE only affects the "move" CON command. Everything else is still jittery (like movesprite, or directly setting x/y/z).

This post has been edited by Striker: 10 February 2020 - 06:38 PM

0

User is offline   Trooper Dan 

  • Duke Plus Developer

#4

Oh, I see. Cool, I'll test it starting late tonight when I get home. I'm assuming your exe is based on the latest available build.
0

User is offline   Striker 

  • Auramancer

#5

View PostTrooper Dan, on 10 February 2020 - 06:41 PM, said:

Oh, I see. Cool, I'll test it starting late tonight when I get home. I'm assuming your exe is based on the latest available build.

Yeah, it's based on r8617.

(EDIT: It was 8617, not 8620)

This post has been edited by Striker: 10 February 2020 - 09:23 PM

0

User is online   Mark 

  • Honored Donor

#6

Is this applicable to mods using 3d models? I'm not 100 % sure what I'm looking for. In Decay, the zombies have the annoying stutter and jittery movements to the left and right as they move forward towards the player. Your mod didn't change that behavoir. Not sure if it was supposed to or not.

This post has been edited by Mark: 10 February 2020 - 07:00 PM

0

User is offline   Striker 

  • Auramancer

#7

View PostMark, on 10 February 2020 - 06:56 PM, said:

Is this applicable to mods using 3d models?

Applies to any mod. Though, this is different than 3D model animation interpolation, this is for the general movement of actors.
0

User is online   Mark 

  • Honored Donor

#8

This stutter and jittering is from their movement and not the anim frames. Its been going on for years and I just shrugged it off as typical builtin AI behavior

This post has been edited by Mark: 10 February 2020 - 07:05 PM

0

User is offline   Striker 

  • Auramancer

#9

View PostMark, on 10 February 2020 - 07:02 PM, said:

This stutter and jittering is from their movement and not the anim frames. Its been going on for years and I just shrugged it off as typical builtin AI behavior

It's a mix of things. It's a combination of AI having weird movement (which is unchanged in this patch, SFLAG_SMOOTHMOVE remedies this), and CON actors having no interpolation at all (visually locked at 30hz) exacerbating matters.

This post has been edited by Striker: 10 February 2020 - 08:04 PM

0

User is offline   Trooper Dan 

  • Duke Plus Developer

#10

@Striker: So for us luddites or don't compile our own exe but who want to use the latest Eduke32 (pretty important ATM with all the fixes just added), we would need a new exe with your patch applied.

Also, thanks for the info about the htb stuff. I remember reading that before but I completely forgot about it until you mentioned it.


EDIT: You know what, I'm just not seeing the difference in my actors. AA has a pretty good test case in the very first level. You've got the player's companion and both enemies all using movesprite to move pretty much all the time. They don't even use normal move to move. And it looks smooth regardless of your patch. I've tested with both regular 8620 and also 8641 versus your patched 8620. All of these actors do have the smoothmove flag applied, but you said that wouldn't help. It seems to me I would notice the difference if there was one, because I used to notice it all the time in the old days before the smooth move flag existed.

This post has been edited by Trooper Dan: 11 February 2020 - 02:54 AM

0

User is offline   Striker 

  • Auramancer

#11

View PostTrooper Dan, on 11 February 2020 - 02:45 AM, said:

@Striker: So for us luddites or don't compile our own exe but who want to use the latest Eduke32 (pretty important ATM with all the fixes just added), we would need a new exe with your patch applied.

Also, thanks for the info about the htb stuff. I remember reading that before but I completely forgot about it until you mentioned it.


EDIT: You know what, I'm just not seeing the difference in my actors. AA has a pretty good test case in the very first level. You've got the player's companion and both enemies all using movesprite to move pretty much all the time. They don't even use normal move to move. And it looks smooth regardless of your patch. I've tested with both regular 8620 and also 8641 versus your patched 8620. All of these actors do have the smoothmove flag applied, but you said that wouldn't help. It seems to me I would notice the difference if there was one, because I used to notice it all the time in the old days before the smooth move flag existed.

Does this actor ever call "move" at any point? That can have an effect on the behavior. This is mainly for actors that move strictly through movesprite/setsprite or direct setting of x/y/z. (move 0)

Keeps you from having to do hacks like this:
move SMOOTH_HACK 0 0 // Hack to bypass condition in VM_Move.
spriteflags TRACER 8196
actor TRACER 0
	ifaction 0
	{
		setactor[THISACTOR].shade -127
		sizeat 10 10
		cstat 32768
		action ANULLACTION
		move SMOOTH_HACK geth getv
	}
	else
	{
		ifcount 2 { }
		else ifcount 1
		{
			cstat 2176
		}
	}
	
	ifcount TRACERTIME killit
	
	getactor[THISACTOR].x SPAWN_ORIGX
	getactor[THISACTOR].y SPAWN_ORIGY
	getactor[THISACTOR].z SPAWN_ORIGZ
	addvarvar SPAWN_ORIGX DEST_X
	addvarvar SPAWN_ORIGY DEST_Y
	addvarvar SPAWN_ORIGZ DEST_Z
	setsprite THISACTOR SPAWN_ORIGX SPAWN_ORIGY SPAWN_ORIGZ
enda

Which will drain on performance if you have a lot of actors doing this, since it has to go through the rest of VM_Move without it really doing anything of use. Plus, this kind of hack with move clobbers a bunch of other stuff and can completely break certain behaviors.

This post has been edited by Striker: 11 February 2020 - 07:15 AM

0

User is offline   Trooper Dan 

  • Duke Plus Developer

#12

View PostStriker, on 11 February 2020 - 05:51 AM, said:

Does this actor ever call "move" at any point? That can have an effect on the behavior.


Yes, but the moves they use have no velocities on them, they are used more like vars.
I define a move like this:

move BADGUYRUN

The actor will always be using some move or other with no velocity on it, then I can refer to "ifmove BADGUYRUN" but the actual movement is caused by the movesprite command.

edit:
I don't typically use setsprite unless the actor is supposed to be teleporting; just movesprite. Also, calling it a "hack" is a bit of a stretch since using moves as vars was done in the original 1996 CONS (OK, now that I type that it almost looks like an argument for the opposite conclusion). In any case, does that break something I should be concerned about?

This post has been edited by Trooper Dan: 11 February 2020 - 10:13 AM

0

User is offline   Striker 

  • Auramancer

#13

View PostTrooper Dan, on 11 February 2020 - 10:07 AM, said:

Yes, but the moves they use have no velocities on them, they are used more like vars.
I define a move like this:

move BADGUYRUN

The actor will always be using some move or other with no velocity on it, then I can refer to "ifmove BADGUYRUN" but the actual movement is caused by the movesprite command.

edit:
I don't typically use setsprite unless the actor is supposed to be teleporting; just movesprite. Also, calling it a "hack" is a bit of a stretch since using moves as vars was done in the original 1996 CONS (OK, now that I type that it almost looks like an argument for the opposite conclusion). In any case, does that break something I should be concerned about?

That move command is why you see no difference on your enemies with this patch. A move call changes some internal flags in how things are handled in CON's VM_Move function, and they stay until the next move call. (Interpolation works if move != 0 in stock eduke32, this patch allows it to work in situations where you never use "move" even once) They don't need to have velocities to have some (possibly undesired, depending on your use case) effect.

Keep in mind, even if the velocity is 0, "move" can still have ill effects (like rapidly scaling down and clobbering x/y/z velocities, which can cause issues if you need to use those values directly for whatever reason). Take for example, my blood splatter actor in StrikerDM. If I put a single "move" command anywhere, even if it's 0 velocity, it breaks it's movement significantly (no longer moves in a nice wide arc, immediately drops to the ground, with moon gravity.) because of how it messes with a bunch of values behind the scenes constantly, every frame, even if only called once in it's lifetime.

Using moves as vars was a thing, yes, but it did, and still has drawbacks (due the aforementioned velocity clobbering). In EDuke32 era, you're better off using gamevars if you're just storing and reading back information.

Best test this thing with actors that never once call "move". Think special effects like particles, debris, or whatever. BTW, I am wanting feedback because this may end up in mainline.

This post has been edited by Striker: 11 February 2020 - 03:28 PM

0

User is offline   Trooper Dan 

  • Duke Plus Developer

#14

View PostStriker, on 11 February 2020 - 03:17 PM, said:

Best test this thing with actors that never once call "move". Think special effects like particles, debris, or whatever. BTW, I am wanting feedback because this may end up in mainline.


I don't mean to be obstinate, but all my actors that move already call "move". It's a habitual way of coding them that evolved partially through observation. Now that you have explained it, yes I have noticed the clobbering, but I just compensate for it by increasing certain numbers. I could be suffering a small performance penalty, but at this point it's all working and I'm getting ready for a major release, so I don't want to go back and change the way it works just to test a patch.
0

User is offline   Striker 

  • Auramancer

#15

Then I will just wait for someone else that has something that's affected by this patch. You're not the only modder here. :P (Just the only one paying attention right now, it seems. Hopefully I'll get more input.)

In the meantime, if you just want to see what difference it CAN make, try Ion Fury with this, and compare with the stock build.

This post has been edited by Striker: 11 February 2020 - 04:09 PM

0

Share this topic:


Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic


All copyrights and trademarks not owned by Voidpoint, LLC are the sole property of their respective owners. Play Ion Fury! ;) © Voidpoint, LLC

Enter your sign in name and password


Sign in options