search

pythonarcade / arcade

Easy to use Python library for creating 2D arcade games.
http://arcade.academy
Other
1.66k stars 316 forks source link

Resolve lingering issues with Vec2 #2184

Open einarf opened 2 weeks ago

einarf commented 2 weeks ago

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 commented 2 weeks ago

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 commented 1 week ago

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 commented 1 week ago

Put 10+ hours into fixing up pyglet vectors with complete unit tests https://github.com/pyglet/pyglet/pull/1151 https://github.com/pyglet/pyglet/pull/1154

einarf commented 1 week ago

@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 commented 1 week ago

https://github.com/pythonarcade/arcade/pull/2219

pushfoo commented 1 week ago

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