#28028 - amatolihi - Tue Oct 26, 2004 10:11 am
Hi guys,
I am new to this forum and I have a few questions that I think you more experienced people may be able to answer.
I am not a GBA programmer, but I do have programming experience in stuff like Java. My buddy (he's the programmer) has constructed a game framework and he has asked me to do the in game sprites for the characters.
I found the maximum sprite size of 64x64 to be way too small to incorporate the full extent of the character. The obvious solution was to join another sprite to it and draw the character to span both sprites when necessary. However, we felt that it was complicated and so we tried to stick to a single sprite.
Have any of you guys done games that needed sprite joining before? If you have, would you please help us by shedding some light on your experience?
I'm sorry I can't be more specific on the particular areas which I think we have problems with because I am not the programmer. I'm just asking questions at a very high level to engage some discussion.
Thanks :)
#28033 - yaustar - Tue Oct 26, 2004 11:59 am
Haven't tried it myself but have though about it.. The ways I came up with was to either use a Background layer and change the tiles in the memory for each frame during vblank or develop an engine used to join sprites together (there was a topic about a month back on this, take a look around).
_________________
[Blog] [Portfolio]
#28036 - poslundc - Tue Oct 26, 2004 2:13 pm
Stitching sprites together is easy if they aren't being rotated or scaled. It's a lot tougher if they are, but it's still doable.
If you need the bigger sprites, then go for it.
Dan.
#28043 - amatolihi - Tue Oct 26, 2004 3:00 pm
Thanks for responding guys :)
Well, we tried optimizing usage of a single sprite during animation by shifting the character around on the sprite space and shifting the character's "Hotspot" by a corresponding offset value to maintain the illusion that the character was actually still in the same spot :D. It'd look really odd in the OAM viewer where the sprite would look like it was it was jumping left and right :)
It totally screwed up when we got to collision detection where we needed to determine where the hell the character was in the world space and had a hotspot that was jumping.
Well, The big problem now is what kind of information is required to represent multiple sprites cohesively as a single sprite. We got a hotspot so I was thinking that using that as a point of reference to determine the locations of the sprite parts would be a good idea.
Does anyone have other ideas on how to implement this? :D
#28046 - tepples - Tue Oct 26, 2004 4:04 pm
| amatolihi wrote: |
| Well, we tried optimizing usage of a single sprite during animation by shifting the character around on the sprite space and shifting the character's "Hotspot" by a corresponding offset value to maintain the illusion that the character was actually still in the same spot :D. |
An elementary technique to anybody familiar with Klik n Play or The Games Factory.
| Quote: |
| It totally screwed up when we got to collision detection where we needed to determine where the hell the character was in the world space and had a hotspot that was jumping. |
Then store a collision shape relative to the hotspot along with each cel, just as you store the position of each cel relative to the hotspot. You'll need this for crouch or crawl animations anyway.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#28053 - ScottLininger - Tue Oct 26, 2004 4:24 pm
How many sprites are you using for the character? Could you paint a mental picture? (Or better yet, post a real one?)
Counter-intuitively, perhaps, I find it's often EASIER to build a large character out of *lots* of small sprites, because then you can have a sprite that is dedicated to, say, an arm, then move it around as it animates.
Another solution (especially for relatively small homebrew games) is to create an "ubersprite" that is actually four 64px sprites grid, or however many 64px sprites you need to cover the entire possible sweep of the character's animations. Sure, you'll have a lot of dead pixels in there, but that can be okay if you have the spare processing cycles.
(Which of course depends on the other stuff you're doing at the same time... again, a picture would be helpful, or at least a decription of the game.)
-Scott
#28070 - amatolihi - Tue Oct 26, 2004 5:50 pm
The character that we are creating has a red trenchcoat and a big ass sword, very reminiscent of a character from a CAPCOM game but not really the same guy. :D
Generally, the character takes up 2/3 of the height of the 64x64 and 1/3 of the width. However when he attacks, there are times when the sword would have to go beyond the 64x64 either at the front or at the back or at the top.
I think it'd generally be quite a waste of sprite space if we were to allocate 4 sprites for this 1 character permanently though... But maybe it doesn't really matter as there can be up to 128 yah.
I've asked my friend to post on this topic on my behalf since he's the one coding and stuff. I'm just a trying to help out on stuff I dun understand :D.
#28074 - sajiimori - Tue Oct 26, 2004 6:38 pm
Lay down the law, man. Tell your friend it's his job to make the artist's life easier. ;)
#28082 - Marill - Tue Oct 26, 2004 7:34 pm
Hey yo, thanks for reading! :) I'm the programmer!
righto! :) I am all for making it easier to create the art for the game, coz the easier it is for the artist to create the art, the better the art for hte game will be!
right now what we're trying to do is to make it such that the character sprite can be more than 64x64.
Sometimes, it is difficut to constrain a character animation within 64x64 space since perhaps he will have a long range spear that will reach far that will go out of 64x64 space.
So what we're thinking is compose the character using multiple sprites. For example, the character can be composed of 2 64x64 sprites arranged horizontally.
If that is too much space, the sprite can be composed of a 64x64 sprite with another 8x32 horizontally centered to accomodate extra space for the "spear".
Right now, my idea is to keep a hotspot position, and all the sprites that are used to compose this character will be defined as an offfset position from this hotspot.
I do not want to dabble into rotation and scaling of these individual sprites yet, although i wil consider it if it is realy needed - for example on the huge boss characters.
So are there any suggestions to alternative data structures? or any improvements and alternative methods to achieve sprite joining?
thanks in advance! and if i'm not being clear about some points please let me know, i'll try to explain it clearer.
#28126 - tepples - Wed Oct 27, 2004 1:59 am
I'd say make the character and the weapon as two separate sprites. Incidentally, this will allow you to reuse your engine for a game with weapon selection or pickup weapons.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#28129 - sajiimori - Wed Oct 27, 2004 2:27 am
My best suggestion is to write (or find) a program that will automatically find an optimial (or at least reasonable) subdivision of a large graphic into multiple sprites, then generate data that describes the pieces and have your engine interpret the data and build large objects automatically.
The key is to hide the fact that they are made from multiple sprites, so the rest of your code can treat them as single objects.
After you have a system like that, you'll get a good subdivison for your character even if the weapon is extended all the way, and the only reason to explicitly seperate the weapon from the body is if you want to be able to switch weapons.
If you did want multiple weapons, it is merely a question of animating a set of weapons to fit the exact motions of the character, at which point it is trivial to move the two "meta-objects" (body and weapon) in synchronization.
#28143 - Marill - Wed Oct 27, 2004 8:23 am
I think i will go ahead with using a structure that stores
(1) a center position
(2) array of sprite parts (these are not low level GBA sprites, but rahter a middle level GameSprite structure that I have defined, each already taking care of its own animation control)
(3) array of corresponding sprite part offsets from the center point.
(4) the number of sprite parts composing this character
and I'll call this a GameSpriteGruop.
With such a structure, it will be able to support BOTH tepples's suggestion of seperating character and weapon, AND sajimori's suggestion of finding an optimal split configuration.
Both these suggestion requires such a structure to do the sprite joining anyways.
Sepration of weapon will probably have to involve sprite part rotation (like Castlevania Aria of Sorrow, where he swings the huge sword) it'll be more complex to handle, but it can offer flexibility in changing of different weapons. I can see why AoS went for that, coz in that game you can equip many differnt weapons and they animate differently.
So then, a higher level sturcuter like GameCharacter can be the owner of GameSpriteGroup, and so in the game code, it treats the character like in single object - the GameCharacter and not have to bother about details in the translation and animation of the sprites.
The devil is in the details tough.... within the GameSpriteGroup code that has to handle the proper translation of the offsets of the sprite parts.
I forsee that they will be some complication when the center position of the group is no on the center axis of the group and when the character changes direction from left to right, I'll need to take that into account how to properly flip the offset values.
woo! :) more coding! :P
#28146 - amatolihi - Wed Oct 27, 2004 12:03 pm
I think it would make sense in this case to design the weapons as seperate groups of sprites that have animations that tie in with the character's animation in such a way it looks like they are drawn together.
The GameCharacter doesn't have to know what is going on in the WeaponSpriteGroup as well, all it has to do is tell it to use the idle animation, running animation, slashing animation etc...
There are probably going to be some frames where the weapon overlaps the character sprite or vice versa, but those involve priority value switching which I think will be the same across the board for every weapon of that type.
Doing it this way has 2 advantages.
1. Allows for more fluid animation and attack graphics rather than a rotating blade.
2. Allow for different Palette to be used for the weapon and whatever attack effect the weapon has to employ. eg. Fire Slash for fire blade, Ice Slash for Ice Blade...
It'd probably be an ass to code, but i think that if the character sprites joining can be implemented, the weapon sprites would use a similar concept.