Page 1 of 2

Actor Sprite Offsets

PostPosted: Fri Jul 19, 2019 2:53 pm
by Major Cooke
Pull Request

Simple, effective, and easy to work with: +X shifts to the right, +Y shifts down just like A_OverlayOffset, so there's at least some form of consistency.

Code: Select allExpand view
Class z : Actor
{
   Default
   {
      +NOINTERACTION
   }
   
   States
   {
   Spawn:
      MISL A 1
      {
         A_SpriteOffset((SpriteOffset.X + 1.0) % 35.0,(SpriteOffset.Y + 1.0) % 35.0);
      }
      Wait;
   }
}


This shifts the sprite to the right and down by one unit and resets every second.

Re: Actor Sprite Offsets

PostPosted: Fri Jul 19, 2019 3:05 pm
by Graf Zahl
This doesn't look right:

Code: Select allExpand view
if (spritetype & (RF_FLATSPRITE | RF_WALLSPRITE))
      {
         SOX = 0.f;
         SOX = 0.f;
      }


You also forgot to serialize the new values.

Re: Actor Sprite Offsets

PostPosted: Fri Jul 19, 2019 3:32 pm
by Major Cooke
Fixed both.

Re: Actor Sprite Offsets

PostPosted: Fri Jul 19, 2019 3:46 pm
by Nash
Only for the hardware renderer? What about Carmack and Softpoly?

Re: Actor Sprite Offsets

PostPosted: Fri Jul 19, 2019 6:37 pm
by Major Cooke
Hardware renderer only.

After speaking with dpJudas, he said not all the sprite stuff is working so support might not be worth the effort in softpoly.

Last time I tried to touch the Carmack renderer, it exploded. I am never touching that renderer ever again.

Re: Actor Sprite Offsets

PostPosted: Fri Jul 19, 2019 7:37 pm
by Rachael
Major Cooke wrote:Last time I tried to touch the Carmack renderer, it exploded. I am never touching that renderer ever again.

Such things do tend to occur with that thing. ;)

For a feature like this, from an objective standpoint I would say it should be done, if you can. But I know that thing is scary and tends to explode a lot. The important thing to remember is, though: There are still a significant number of people who use it, even if not full-time, and if there are things that can be accomplished with simple tweaks for hwrenderer compatibility they should be done.

I would ask you consider at least giving it an effort. If you can't do it then fine, you can't, but at least then I'll be happy you tried. But I realize and understand that may be too much to ask - because I don't even know where sprite offsets are managed in that thing. First place I would look, though, is "src\rendering\swrenderer\things\r_sprite.cpp"

Re: [OpenGL Only]Actor Sprite Offsets

PostPosted: Sat Jul 20, 2019 9:24 am
by Major Cooke
Alright, it's done. All three renderers.

This submission is now ready.

Re: Actor Sprite Offsets

PostPosted: Sat Jul 20, 2019 11:59 am
by Rachael
Thank you Cooke!

Re: Actor Sprite Offsets

PostPosted: Sat Jul 20, 2019 2:09 pm
by Major Cooke
No problem. After this PR is merged, hopefully I won't have to touch the SW renderer anymore. I have inserted blockers on all three from wall/flat sprites, so if someone makes that happen on SW renderer it's already taken care of.

The reason I disabled offsets is because it's not worth breaking their behaviors over, not to mention you're dealing with sprites that appear much more third dimensional. It's just far too painful to let them mingle together.

Re: Actor Sprite Offsets

PostPosted: Wed Jul 24, 2019 12:22 pm
by Graf Zahl
While I have nothing against the feature itself, there's two things that genuinely bug me:

1. This is adding yet another 16 bytes to AActor.
2. This is adding yet more code to HWSprite::Process.

Essentially this means that one of the most critical functions in the engine adds more execution time and added risk of cache misses - and it's already suffering from both too much.
I think one thing that needs to be done eventually is to make a few fields in AActor which are not precision critical single precision floats, and we seriously need to think about how to address the code explosion in HWSprite::Process, because a lot of code in there is for rarely used specialty features - like this one.

Re: Actor Sprite Offsets

PostPosted: Wed Jul 24, 2019 12:39 pm
by Major Cooke
I understand. Did you want to address that first before merging then?

Re: Actor Sprite Offsets

PostPosted: Wed Jul 24, 2019 12:46 pm
by Graf Zahl
It was mainly a general concern and nothing specific to the PR - which by itself is fine. I'm just concerned because this is yet another of these things that adds more overhead in a piece of code that already becomes a problem in maps with lots of actors (10000 or more)

Re: Actor Sprite Offsets

PostPosted: Wed Jul 24, 2019 1:04 pm
by Major Cooke
I just meant, did you want to perhaps hold off merging my stuff until the render stuff is sorted out, getting the general concern stuff out of the way first.

Re: Actor Sprite Offsets

PostPosted: Wed Jul 24, 2019 1:10 pm
by Graf Zahl
The render stuff is not something easily sorted out. I think by now the only option would be a duplicate of HWSprite that only handles base features.

Re: Actor Sprite Offsets

PostPosted: Thu Oct 24, 2019 10:05 pm
by Major Cooke
Turns out you were right. This definitely had an affect on AEons of Death pretty hard. A terrible shame really. :(

I've removed it from QZDoom for the time being. This will be merged in later when enough testing is done on the current round of PRs is handled.