It is currently Sat Oct 20, 2018 1:57 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 8 posts ] 
Author Message
PostPosted: Sat Jul 14, 2018 2:27 am 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 2006
Location: Fukuoka, Japan
I'm reviewing my old code while rebuilding my new engine with some part in C. Now I'm doing the collision detection in C and it's a lot easier than in assembler to debug but one thing that strikes me is 9 years ago, when I was experimenting with my engine, all my sprites have a top/left coordinate system and I use a constant offset per metasprite to know what to do when flipping it in the opposite direction.

I remember reading a long time ago all kind of way to manage the origin of a metasprite but I do not remember were it is on the forum (will search later tonight when the kids will be sleeping) but for the time being, is it common to start in the top left, like for the screen, even for metasprite? I don't know if it was intentional that I used that system or it was just a quick hack until I remake my sprite.

What are the advantage of each system? Right now I have some collision bug, which could be either caused by the system or the fact that the code is still raw so I'm just trying to search on the subject to make sure if I should continue that way or not. It's working but not perfect.


Top
 Profile  
 
PostPosted: Sat Jul 14, 2018 4:52 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1783
Location: Gothenburg, Sweden
The obvious advantage of the top-left corner are:
-easy to read sprite tables
-top-left sprite of the metasprite is always positioned 1:1 with the metasprite itself.

I think many games are using radiuses and center-positioned origins/anchors. If a metasprite has a square hitbox, one radius would be sufficient. But normally, you'd have xrad and yrad.

center positions ought to make directional flips easier.

it may be comfortable to keep the y anchor at the bottom of the metasprite in a platformer, but you don't have to.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Sat Jul 14, 2018 8:57 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6895
Location: Canada
Yeah, for my game, which scrolls horizontally and has gravity, I put the pivot (0,0) for a sprite in the middle horizontally, but on its feet. Actually, one pixel below the feet. This makes finding the ground relative to the sprite very easy, and also facilitates horizontal flips. Very often the hitbox did not need to be flipped for different directions, too.

For some things, especially if they were a 1 tile sprite (e.g. snow particles) I did use the top left, so that the sprite position could just directly be its pivot, or that the hitbox or other things I need to calculate from it could reuse the position directly as one of its corners, etc.

So... I actually did both, but the more "generic" case was the former. Like most things I would consider it on a case by case basis. You don't necessarily have to be locked into doing it only one way.

If I was doing a game that had vertical flips there might be a good reason to put it in the vertical middle too. In 3D games, having the pivot point centred is very convenient for rotating a character. We don't rotate here, but flips are sort of analogous.


Top
 Profile  
 
PostPosted: Sat Jul 14, 2018 10:05 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10901
Location: Rio de Janeiro - Brazil
I often use horizontally centered, bottom aligned anchors, but it depends on how characters move and behave. My metasprite engines always support freely placeable sprites with signed coordinates, so I can place the anchor anywhere I want.

Hardwiring the anchor to one side or the other means you have to compensate for the metasprite's width when turning around. Another problem is if you need to dynamically resize the sprite (e.g. James Pond can stretch vertically), because you'll have to awkwardly temper with the object's coordinate to compensate.

In James Pond's case, if you used a top left anchor, you'd have to decrease the object's Y coordinate whenever he stretched up, but the character isn't really moving up, it's still standing in the same place, it's just getting taller. It's awkward, and this sort of forced position manipulation could even impact the physics negatively.

It's true that not many games have stretching limbs or resizeable hit boxes, but I'd rather code something flexible than realize later on that I can't make an enemy behave a certain way or use hacks to do it.


Top
 Profile  
 
PostPosted: Sat Jul 14, 2018 6:34 pm 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 2006
Location: Fukuoka, Japan
@rainwarrior

You are tempting me to change my current test data to this format :) But... since it was done by hand, 9 years ago, this means changing all the metasprite and logic (which I do not remember much yet) just to test it. Hmmm.. I guess I will experiment about that once I have a tool to help manage my data. My goal it to make an engine that allows to make platformer similar to megaman, ninja gaiden and the like (fast paced games) so maybe it will be worth it later.

@rainwarrior and @tokumaru

You guys said that it will simplify for flipping the sprite but there is something I want to clarify. In my current implementation (top/left origin), when going in the right direction the sprite is shown "as-is". When it requires to be flipped to the left, I have an offset to know by how much this particular sprite requires to be adjusted to be adjusted to be exactly on the same center as when going right. It's quite primitive but was easy when doing the data by hand.

Now if my origin is at the center of the sprite and left say my meta sprite has a width of 4 sprites, this would mean the X coordinate would be something like (from left to right):

Code:
-0x0F, -0x08, 0x00, 0x08


and when we flip the sprite, because a sprite is 8 pixels wide, we need to adjust the position by 8 pixels to put them back at their proper place, right? So there is still an offset in some way but this time this offset is fixed, not specific per metasprite? Is what I'm saying makes sense?

I guess the first time I tried to make metasprite I didn't go with the origin at the center since it would have made it harder with signed value and the fact that at took the sprite location data from the ram of MM2 as a reference :lol:


Top
 Profile  
 
PostPosted: Sat Jul 14, 2018 7:15 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10901
Location: Rio de Janeiro - Brazil
Yes, there's still an offset, but it's constant, it doesn't vary per sprite. It's a subtle difference, but it's there.

My main argument is definitely the ability to dynamically resize sprites and hit boxes without awkward position adjustments that don't represent actual character movement.


Top
 Profile  
 
PostPosted: Sat Jul 14, 2018 10:10 pm 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 2006
Location: Fukuoka, Japan
@tokumaru

I see. So in my case that would be one less byte for that offset. I will migrate my data once I can have an automated process for adjusting my sprites (doing by hand is time consuming).

Thank you everyone for you comments, I will tests and see how it goes.


Top
 Profile  
 
PostPosted: Sun Jul 15, 2018 12:18 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6895
Location: Canada
Yes, there is an offset, but I have a "draw sprite" routine, and a "draw flipped sprite" routine. The flipped one adds 8 to the base X coordinate at the start, and when building tiles subtracts the metatile X coordinates instead of adding them. So really it's hardly any extra work for the CPU.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 8 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group