nesdev.org

It was indeed just scaling, though this scaling can be combined with shearing.

My current code is 100% tile based which is trivial, but I plan to change it in a future project to use traditional bounding box based collision with the background.

It would work pretty much as discussed in this thread: you start at the destination X and Y position of the sprite. You then loop over the width and height of the sprite (from the starting position) checking tiles to see if they're solid as you go. If no solid tiles are found, then the sprite is moved, otherwise it isn't. Additional code is executed if the sprite collided to make sure that the sprite is moved to the edge of the tile that it collided with.

This is not very efficient, but it works for sprites of arbitrary sizes moving at arbitrary speeds in arbitrary directions, and it's very simple to implement.

The alternative is to only sample a couple of individual points based on known factors like the speed of the object, the size of the tiles, and the size of the sprite. For example, if Mario is moving left, you can do a single check a constant finite distance ahead of him to determine if he needs to stop. This is wildly more efficient than the above method, but it has limitations. You have to know about the exact sprite size involved, the velocity involved, and the tile sizes involved. So it'll be different for most different combinations, and it fails in certain circumstances.

If I were making a game, I'd make most of the enemy bullets one point and have a special routine for it, because you don't need to check height and width then. I already have a special metasprite code for dealing with one sprite objects, because it's not like you need to rearrange it whenever the object is being flipped vertically or horizontally. I someday want to share my game engine (I believe there aren't a lot of people making games for the SNES because of this stuff) and people with little programming knowledge could use it and work around it, and (hopefully) they'd start to learn more about programming as they go along (I mean, they'd still need some knowledge for coding objects and stuff) and would adjust it how they want it. Maybe this is an unrealistic idea, but I find making an entire game by myself to be much more unrealistic. A lot of decisions I've been making are to make this as flexible as possible, like the vram slot idea so people wouldn't have to worry about it.