Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: matthias1992 on October 09, 2010, 02:59:28 pm
-
Ok scrap my previous idea, way too hard D:
So new idea. Make individual sprites for the arms. legs, torso, head and all other movable body parts and just make it possible to rotate them. Now I recall that rotating a 8x8 sprite will need a 9x9 canvas in order to be able to rotate by 360 degrees. So I intend on making all the body parts 7x7. Point is, how do I rotate a 7x7 black box in axe? I am quite a newb at nearly all the physics stuff and do rotations/translations and so, (basically I suck at doing math but I wont admit it hehe) therefore if someone could come up with a small demo of a rotating 7x7 box in axe then that will help me out. I can quite easily learn from code but I would appreciate some explanation...
I hope I don't sound too demanding but I just need a memory and cpu efficient way to handle all the animations in AC and this method seems to be the golden midway...
May thanks!
-
For such small sprites, it would probably be easier and take up less space (and definitely be faster) to just have pre-rendered sprites for different rotation angles, instead of calculating and drawing rotated sprites on the fly.
-
You can write a program that takes an initial sprite and then rotates it 30 or 22.5 degrees each time and then exports the hex code for every rotation. It might be a little complicated to write, but speed isn't an issue since you're just pregenerating them. It would be a useful program for a lot of people actually. Maybe I should write one in Axe unless anyone else wants to give it a shot?
-
@Runer yea maybe I should have them pre-made...good idea.
@Quigibo, an excellent idea! Personally I have far too much projects in parallell to take on the challenge plus, I suck at mathematics in general...
-
You can write a program that takes an initial sprite and then rotates it 30 or 22.5 degrees each time and then exports the hex code for every rotation. It might be a little complicated to write, but speed isn't an issue since you're just pregenerating them. It would be a useful program for a lot of people actually. Maybe I should write one in Axe unless anyone else wants to give it a shot?
I'm giving it a shot. I'm using the best algorithm I can find without anti-aliasing.
-
It would be nice! Make sure to write a small tutorial on how to use it, though ;)
-
The first step to a really good sprite rotating algorithm: a really good sprite upscaling algorithm. ;D
-
O.o did you generate this with a program? It looks nice :O
-
that in itself would be very useful to have!
-
Didn't someone write a routine somewhere to magnify an entire screen?
And yeah, that does look useful. Can we have the code? ;D
-
O.o did you generate this with a program? It looks nice :O
Yes, in Axe. Now that I have upscaling working, I need to tackle rotation.
that in itself would be very useful to have!
I'm not really sure what it would be useful for, as the process is slow and takes about 3 seconds.
Didn't someone write a routine somewhere to magnify an entire screen?
And yeah, that does look useful. Can we have the code? ;D
Yes, I believe I wrote the routine (http://ourl.ca/6016/95659) you're referring to. ;)
And when I've completed it, I'll give it out. But rotating still has to be implemented.
-
Didn't someone write a routine somewhere to magnify an entire screen?
And yeah, that does look useful. Can we have the code? ;D
Ya, Raylin asked a bit ago for one so DJ wrote one that does it actively and mine takes a a sprite and just displays the result. I don't remember where that thread is though.
-
Darn if that was faster it would rule for games with rotating ships or even rotating maps, like in Kartingz for 68k calcs.
-
hmm, 3 seconds is a little long. however, it would still be useful for learning from(and for being able to look at pretty things) and may make resizes of peeps easier(although i can just use paint for that, i guess). good luck with rotation.
-
Darn if that was faster it would rule for games with rotating ships or even rotating maps, like in Kartingz for 68k calcs.
Yeah, that's too bad. Otherwise, squidgetx could use that in Cuberunner...
-
One solution, if you got the memory and if your sprites cannot zoom extremly large, would be to pre-render every possible sprite zooms/rotations and store them in an arbitrary buffer, or even pre-store them in an appvar (less loading time, but larger file size when not playing the game), so when you need to use the sprites, you just recall a different one when rotation/zooming is needed.
-
Well the point of this isn't really for zooming, it's for rotation. I'm supersampling the image so when I rotate it, which can result in rounding errors due to pixel bondaries, and then scale it down to one quarter or one eighth of its size, the errors will also be scaled down. But yeah, the whole purpose of this is to pre-render rotations of a sprite.
-
Yeah I know, I just gave zooming as example as well because I knew it wasn't super ultimate mega fast enough to be used in mass scale in games.
One day I really need to give pseudo 3D a try in Axe, although I am a bit concerned about lack of floating points