#25908 - pio_troland@wp.pl - Tue Aug 31, 2004 2:05 pm
How to make a sprite bigger or smaller?
#25911 - keldon - Tue Aug 31, 2004 3:03 pm
what you are after is scaling, the link provided should help http://user.chem.tue.nl/jakvijn/tonc/affine.htm
For other information, the FAQ lists a lot of this (including that link).
---
in short, you'll be manipulating the sprites scale attributes.
#25919 - zazery - Tue Aug 31, 2004 5:26 pm
One thing I don't think is mentioned is that you can sew sprites together. I've seen it after disecting my dumped commercial games. It turns out to save space one sprite consists of a few 8x8 sprites and a few 16x8 sprites. You can get around the 64x64 limit by making sprites move together in special ways. I haven't bothered with it yet.
#25923 - sajiimori - Tue Aug 31, 2004 6:34 pm
Mixing that with scaling is a real pain.
#25941 - keldon - Wed Sep 01, 2004 5:57 pm
well why not simply code one, and report back the problems to the community
#25943 - Miked0801 - Wed Sep 01, 2004 6:02 pm
Because we NDA'd him too. Muhuhahahaha!
No really, the hard part of doing this is figuring out just how the hardware handles sprite scaling. We've got a version locally that does this correctly about 99% of the time, though occasionally, we get a 1 line overlap...
#25954 - dagamer34 - Wed Sep 01, 2004 8:43 pm
| Miked0801 wrote: |
Because we NDA'd him too. Muhuhahahaha!
No really, the hard part of doing this is figuring out just how the hardware handles sprite scaling. We've got a version locally that does this correctly about 99% of the time, though occasionally, we get a 1 line overlap... |
Pain in the @$$, huh?
_________________
Little kids and Playstation 2's don't mix. :(
#25955 - DiscoStew - Wed Sep 01, 2004 8:55 pm
| sajiimori wrote: |
| Mixing that with scaling is a real pain |
Yes, it is a real pain, but once you've got it working, you fell great knowing that you accomplished it. That is how I felt.
I had worked on my Object Handler/Animator for so many months (since last year, but these past few months I've been doing other things), and that one key element alone took a good amount of time to implement. As much as I'd like to show the little demo that I made with it, I can't because it would give away what my major demo is based on. It's hard to not show off the long hours you put into something because in the end, you want people to look at it and think "WOW!"
And I'm sorry, I am not giving any source code out of it because something of this magnitude is too precious to give away. I'll probably make a library out of it or something sometime in the future. Please don't ask when.
_________________
DS - It's all about DiscoStew
#25956 - poslundc - Wed Sep 01, 2004 9:08 pm
| DiscoStew wrote: |
It's hard to not show off the long hours you put into something because in the end, you want people to look at it and think "WOW!"
And I'm sorry, I am not giving any source code out of it because something of this magnitude is too precious to give away. |
HAhahaha...
... "Precious"? Figuring out the scaling adjustments is a pain, sure. But it's a pain that takes like maybe fifteen minutes or so with paper and pencil once you're committed to doing it.
Not trying to get down on you for your independent work (which is commendable), and not suggesting you distribute your source code or anything (which is perfectly allright as far as I'm concerned... it's not like I'm dishing out all of my source), but... get off your high horse. You ain't that special, kid.
Dan.
#25959 - ecurtz - Wed Sep 01, 2004 10:07 pm
Heh heh...
I think if you're gonna talk that kind of smack you better make with the code poslundc...
eli
#25960 - DiscoStew - Wed Sep 01, 2004 10:13 pm
Ok, so maybe I stretched it out a little bit there on the scaling adjustments, but the amount of work I put into my actual Object Handler/Animator, including the tedious pieces associated like sprite memory management, palette/sprite cel sharing, prioritizing, and all that other junk I'm implemented, leaving someone using the library to not have to deal with a single memory-mapped register or VRAM memory completely associated with sprites IS precious to me! THAT is what I meant!
I may not be as talented as many people here (including yourself), but when does that give you the right to mock people who aren't as talented?
_________________
DS - It's all about DiscoStew
#25961 - poslundc - Wed Sep 01, 2004 10:27 pm
Sorry if I came across as mocking. There's nothing wrong with being proud of what you've done, but seriously, try to keep your passions in check. To my knowledge the forum hasn't been crawling with people begging you to release your precious source code to the public, so what's the point of bringing it up? Your post came across as trying to impress everyone with your uber-coding-skillz. Just so you know, we're not. Maybe try again after you've been published or something.
ecurtz: You can find some of my older stuff at http://www.danposluns.com/gbadev, FWIW.
Dan.
#25963 - sajiimori - Wed Sep 01, 2004 10:52 pm
Sheesh, it was just one little comment. :/ Is it a full moon or something?
#25965 - DiscoStew - Wed Sep 01, 2004 11:23 pm
Like I said, I'm not as talented as many people here. Heck, everyone who has released a demo is showing off their skills with the GBA; I just haven't released a demo yet. And ofcourse no one has asked about the source code, because practically nobody knew I was doing this before-hand. Is it so bad to state what I plan to do with it before people ask me questions? I may be stating the obvious, but doesn't everyone now and then?
Perhaps we should stop this before it gets out of hand. This isn't helping anyone, including ourselves. I'll just keep my mouth shut on the subject.
_________________
DS - It's all about DiscoStew
#25971 - dagamer34 - Thu Sep 02, 2004 4:10 am
| DiscoStew wrote: |
Like I said, I'm not as talented as many people here. Heck, everyone who has released a demo is showing off their skills with the GBA; I just haven't released a demo yet. And ofcourse no one has asked about the source code, because practically nobody knew I was doing this before-hand. Is it so bad to state what I plan to do with it before people ask me questions? I may be stating the obvious, but doesn't everyone now and then?
Perhaps we should stop this before it gets out of hand. This isn't helping anyone, including ourselves. I'll just keep my mouth shut on the subject. |
I've released a demo but it's still pending. I sent it about a week ago but it still hasn't gotten up to the main page. What's the hold-up?
_________________
Little kids and Playstation 2's don't mix. :(
#26066 - Cearn - Mon Sep 06, 2004 2:56 pm
| zazery wrote: |
| One thing I don't think is mentioned is that you can sew sprites together. |
It's on the todo list, but here's the general gist of it. (Sorry if this seems a little bit rushed, I'll see if I can write a more proper document later)
Combining/sewing affine sprites is basically the same as the anchoring I used in the mode 7 tutorial. The basic equation for any type of affine mapping is
(1) P*(q-q0) = p-p0,
where
P : the familiar P matrix
p, q : arbitrary points in texture and screen space, respectively
p0, q0 : the mapping's origins (again, in texture and screen space, respectively)
For sprites, the origins are always at the center of the sprites, so
(2) P*(q-cq) = p-cp,
where cp and cq the sprite's center in texture and screen space. To change this to an arbitrary origin (the aforementioned p0 and q0), simply subtract the equations and shuffle:
P*(q-q0) = p-p0
P*(q-cq) = p-cp -
----------------------------------------
P*(cq-q0) = cp-p0
(3) cq = q0 + P^(-1) * (cp-p0)
Or, a little bit shorter,
(3b) cq = q0 - P^(-1) * a
where a the anchor: the point of the sprite you want as your origin, relative to its center.
The final step is to calculate the top-left coordinates dx of the sprite to enter into the OAM:
(4) dx = cq - b*s
where s is the size of the sprite ( s=(width,height) ) and b is a parameter to account for the influence of the double-size flag. b=1 if DS is on and 1/2 if it's off.
Recapping, you have
(3b) cq = q0 - P^(-1) * a
(4) dx = cq - b*s
To use this for combined sprites, draw the combined sprite in an image editor, pick an origin, create a list of anchors (and sizes) for each sub-sprite, then apply eq 3b and 4.
That's the easy part. Putting it into practice brings a number of potential problems.
Firstly, because you need the inverse of P, there may be roundoff errors in the calculations. while theoretically P*P^(-1) =I, it'll probably be off just a little bit unless you pick your parameters with care.
Secondly, and this is probably more important, even though you've moved the origin to p0 as far as placement is concerned, the affine mapping itself still starts at the center of the sprite! To see why this is important, consider this example: start with a simple width-16 texture line of alternating pixels; something like:
Upon scaling it could look like this
| Code: |
| #__#__#__#__x__#__#__#__ |
regardless of where you place it. Now, if you were to use 2 of these to make a larger sprite, placed 4 pixels apart, you'd get something like this:
| Code: |
#__#__#__#__x__#__#__#__
#__#__#__#__x__#__#__#__
|
Note that the hashes aren't aligned anymore. Even worse, if you try to sew together multiple sprites of different dimensions, the pixel-to-pixel transformations will be different even if you use the exact same matrix!
And then, of course, there's that annoying clipping artifact; even with the DS flag on, you will lose pixels for non-square sprites on rotation. If that happens to a middle sprite of your combination, well ... eeww.
So yeah, sewing together affine sprites is a real pain. If anyone is interested in a simple demo that shows the theory given above and its inherent problems, take a look at this rather sad excuse of a demo that I threw together a few weeks ago.