I don’t know if it’s because of my ignorence, or is it that this is truely a problem. please fix me if I’m wrong. But I think the current sprite drawer (“sprite(texture, x, y)”) is just stupid when the sprite needs rotation. Simeon suggests we draw it at 0,0 (“sprite(texture, 0,0)”) then rotate it (the rotate method rotates at 0,0) then move it with translate. I think this is really stupid.
This is no biggie I understand, because we can just create a wrapper to hide this. But why not instead add another parameter to sprite(texture,x,y,angle)?
What if you want to rotate the sprite around a point that’s not at it’s center? What if you you want a sprite to be rotated around another sprite? What if you also want to scale the sprite; should another parameter be added for that? What if you want to scale the x and y axes separately? I think you see where I’m going with this. The way that Codea handles rotation etc is a pretty common way of doing it, is very flexible, and works quite well.
Also, sprite already has a load of parameters. Adding more would just make the interface more confusing, not less.
Why don’t you implement it yourself?? It could be a learning experience!
local _sprite = sprite
function sprite(s, x, y, w, h, a) -- sprite, x, y, width, height, angle
x = x or 0
y = y or 0
w = w or readImage(s).width
h = h or readImage(s).height
a = a or 0
pushMatrix()
translate(x, y)
rotate(a)
_sprite(s, 0, 0, w, h)
popMatrix()
end
Well, I already did 
Just add it as a dependency to any project and it should run as is
“What if you want to rotate the sprite around a point that’s not at it’s center? What if you you want a sprite to be rotated around another sprite? What if you also want to scale the sprite;…” – toadkick
If we need those functions you mentioned @toadkick then we would use the rotate() and scale(). But if I just needed a rotate an single image, maybe in my humble opinion it’s worth adding a “angle” parameter in sprite().
thank you @Jordan, I do understand your approach, and it is my method already. I’m just trying to suggest to Codea that it might be more convient as a optional parameter in the sprite() function. (just like the optional parameter “width” & “height”)
See, my problem isn’t that we have a difference of opinion, it’s that you are calling somebody’s hard and well thought out work stupid. In 2 different threads. Why would anyone want to do anything for you with an attitude like that? The reason the interface shouldn’t be changed is because there is nothing stopping you from doing what you want, as @Jordan has shown. Again, why complicate the interface for everyone to enable a tiny bit of convenience for one person?
I agree, calling it stupid is rude, and out of place in this forum
I’m sorry, I couldn’t think of any nicer words to explain my thoughts, I didn’t mean to be rude. I’m from China so please excuse my english (Poor vocab). What I’m really trying to say is something like, …hard? or… incomplete.
Please, as I also said in my thread. I know my opinon could be bad because of my ignorence, I’m not some pro game dev and I know that, so all I’m doing here is just stateting my own opinon and see if anyone can teach me something. Also I’m not here to get a moral lesson, my original opinon was not meant to be offensive to anyone. @toadkick
Back to the actual topic, the sprite() function does have scalers; the width and the height parameters.
so if it has scalers then why not have rotaters?
I like the idea of adding angle to sprite, but I can’t think of a good way to extend the API.
sprite() takes the following forms:
sprite( img ) sprite( img, x, y ) sprite( img, x, y, w ) -- height is computed aspect correct sprite( img, x, y, w, h ) -- arbitrary scale allowed ``` If we were to simply stick an `angle` parameter to get: `sprite( img, x, y, w, h, a )` then you would always need to specify an explicit width *and* height in order to also specify an angle. This means you would need to do the following:local w,h = spriteSize( "MySprite" ) sprite( img, x, y, w, h, angle ) ``` Each time you wanted to use the `angle` parameter. It would be nice to have a form that did not require an explicit scaling. Though I am unsure if it's possible. Any ideas? Edit: One idea that comes to mind is to allow an advanced sprite mode that takes a table. Could be messy, however.sprite( img, { x=0, y=0, a=45 } ) ``` This would allow specifying an angle without an explicit size. We could also then allow custom texture coordinates to be specified in the table, and so on.
@Simeon , I thinks it’s fine as is - its never been a problem (even when I was a Noob!) and could make things even more complicated i guess :-/
@simeon i agree with the general opinion expressed above (namely: it is fine the way it is), but just for the sake of discusssion, wouldnt this work? And if not, why?
sprite( img, x, y, nil, nil, angle )
@loolo78 i see from your replies that you have been an unfortunate victim of the ‘mail magnification effect’. Things that are completly ok in oral discusssion (like ‘but this is stupid!’) become rude and agressive when written directly in a mail or a post. Professionnally i’ve learned (the hard way…) a long time ago that in mail you have to divide by 10 the amplitude of your verbal criticisms if you want them to be received the way you meant them… Some years ago we had a great manager who set the following rule: ‘mail has to be limited to facts, never put emotionnal things in a mail, this is not appropriate. When you need to be emotionnal, go and tell the person directly’. Of course on this forum we are 1000 km apart so we cant tell directly… So we must remain factual!
While the way @loolo78’s puts across the point could be done in a much more constructive manner, I agree with his/her underlying point.
I think sprite rotation is something that would be a nice useful addition for Codea, particularly for beginners.
The sprite function is an easier way into displaying images on the screen (than for example using meshes, which incidentally has the option for specifying a rotation) but in earlier versions of codea used to be a lot slower when lots of sprites were on the screen.
I take @toadkick’s point of writing it yourself, but there is nothing wrong with suggesting an improvement to an existing function, particularly as it could be added as an optional extra parameter which wouldn’t alter any existing functionality
@Jmv38 interesting idea. So we could allow:
sprite( name, x, y, nil, nil, a )
and
sprite( name, x, y, w, nil, a ) -- for auto aspect
This looks a little unreadable to me. But it’s probably the best solution.
IMO the ‘w’ and ‘h’ parameters are already too much, and ultimately are unnecessary. I’ve never used them, I think the ‘scale’ function is a more sensible and flexible way to do it, just like I think the ‘rotate’ function is more sensible and flexible to rotate a sprite (vs. adding an optional ‘angle’ parameter).
Allowing “nil” ameliorates the problem of how to specify multiple optional parameters, but that makes for a pretty confusing an often unreadable interface too. Passing a table with named parameters is generally the best solution, but in this case I’m not a fan because ‘sprite’ is a frequently called function, and adding the overhead of creating (and garbage collecting) a new table every time you want to draw a sprite seems unnecessarily wasteful. As an alternate (optional) API I suppose either one of these are okay, but in general more artificial options just generally leads to more confusion, and I honestly just don’t think it’s worth it to make something that is already simple to do a tiny bit simpler.
Food for thought: would it make sense to add an angle param to ‘sprite’, but not to ‘text’, ‘rect’, ‘ellipse’, and ‘line’ as well?
I can see how it makes sense to add to sprite, and perhaps text — the API is not intended to be equivalent across primitives, but useful across primitives.
Personally I use the width parameter quite a lot (though not height, as I usually want a simple aspect correct scaling).
I also dislike the required nil arguments in order to implement angle at the end of the list.
“I can see how it makes sense to add to sprite, and perhaps text — the API is not intended to be equivalent across primitives, but useful across primitives.”
Fair enough, and a good answer.
I think probably the option to specify a table with named parameters is the best compromise, though I’m still dubious that it actually makes anything simpler than it already is. Being able to specify texture coordinates is intriguing though, and it’s something I’ve wanted for awhile. If a named params table is what it takes to get that, then I’m sold
@Simeon Maybe something along these lines could work.
existing sprite
sprite(img,x,y,w,h)
to use an angle with sprite
sprite.angle=degrees
sprite(img,x,y,w,h) -- existing call using the angle (0 default)
-- angle stays at degrees until another sprite.angle call