Vector based sprites

[einarf]

• Resolve lingering issues related to pyglet vectors (whatever that is)
• Possibly issues with implementation details in pyglet
• Possibly we should revert parts of Name scale properties on Sprites to things that make sense #2021
• If we end up using Vec2 in sprites we must do performance testing. Moving rotating and scaling 3400 sprites per frame (the current 60fps limit) will cause over 1 million calls to the sprite properties. It's the hottest path we have in arcade.

Likely it's simpler to keep the old float scale for now because most users rely only on uniform scale. We can get more fancy about these properties in the future, but only when we have vectors sorted out. Only scale being a vec2 doesn't really make sense right now.

New issue should be created for sorting out vectors.

[DigiDuncan]

Can I ask why the request for reverting aspect of #2021? I agree Vecs behavior isn't ideal, but I don't think returning anything but a Vec2 makes sense for scale; the issue lies with Vec.

[einarf]

Can I ask why the request for reverting aspect of #2021? I agree Vecs behavior isn't ideal, but I don't think returning anything but a Vec2 makes sense for scale; the issue lies with Vec.

Technically you are 100% right that scale is a vec2. However, after looking at a lot of code I'm not entirely convinced this is the right path. Likely in 99% of cases users want uniform scale. The sprite initializer also take a float scale so we already have an inconsistency. Looking at existing libraries out there we can see that scale appears as both float and vec2. There isn't really a right or wrong solution here. Even pyglet sprites are using float scale.

However.. if we fix all the issues with vec2, use it consistently and the performance testing is promising it might be the way to go. There is a lot of work that needs to go in there to ensure that we have a future proof api. Also remember that sprite properties are the hottest path in the arcade code base. They can be called hundreds of thousands of times per second. Almost every system interacts with them.

Right now I don't see that we have the time to attack this problem. We already have way too much on our plate and need to get this release out as soon as possible. If we can take our time and design some new sprites in future or experimental in 3.x.x that would likely be a more realistic path.

I would suggest making a new issue for starting this experimentation. Introducing new sprite types and see how they play out is a much safer option.

[einarf]

Put 10+ hours into fixing up pyglet vectors with complete unit tests
pyglet/pyglet#1151
pyglet/pyglet#1154

[einarf]

@pushfoo Created this branch Vecifying sprites fully. Is someone is able to performance test that vs the current sprites with good results it's possible we can get that in for 3.0. The work just needs to be done. https://github.com/pythonarcade/arcade/tree/scary-vecs-and-nice-sprites

@DigiDuncan Is likely interested in this.
@Cleptomania Might have something to say related to arcade-accelerate

[einarf]

#2219

[pushfoo]

Feel free to make optimizing PRs into #2219. It passes tests, but it does not try to be as fast as possible.