That is a rather involved hack for sprite/obj related things, and not all that much more fun in backgrounds. In both cases you risk stretching limits of the hardware itself and maybe having to redo a whole of the game's own internal logic to pull such a thing off to the point where it is better to refine your artistry than try to do such a thing.
Still the basic building block of the 2d world back then was the tile. Usually 8x8 blocks of pixels (though 16x16 happened for some, and some text might use different things), said tiles (usually found on something called the video RAM aka VRAM) possibly being combined into greater images. VRAM is sharply limited in most old consoles so adding more might run into limitations here needing workarounds (either delete other things, learn to cycle things into memory by addition code), not to mention it does not have to work "a" time it is on screen but every time it is on screen -- working in normal battles is one thing, working in boss battles another.
If they are sprites/objects/objs then the position gets dictated by the Object Area Memory aka OAM, backgrounds (BG) being controlled by some form of map. OAM then having various functions like position (translation if you want to take it back to schoolboy maths), rotation (usually by 90 degrees and multiples thereof rather than arbitrary amounts), mirroring/flipping, scaling and other warp effects (though for the SNES the mode7 warp effects. Older consoles maybe lacking such things in hardware meaning either you do it at the software level (slow and hard) or waste space in the ROM (and complicate things in VRAM) and do it all on the PC you drew it on originally.
The colours are usually dictated by palettes which are a further area of memory, though if you have an image like that above you probably know about that already. You can do some animations by changing the palette though.
Some systems will combine tiles at hardware level and allow you to manipulate a greater collection as one, other things (including games themselves wanting to do their own thing even on systems with support) will do the collective movements at software level such that the hardware has no idea.
Hitboxes need to be mentioned here as well. Some usually older hardware will detect when something collides with another thing in hardware itself but this was deemed limiting so instead later things tend to be about software collisions where the software itself determines what counts.
https://www.pcgamer.com/how-hitboxes-work/ is a bit basic but serves as a nice intro. If you are changing the length of a sprite construction then you might well have to deal with this as well, indeed even just changing the transparent pixels such that something appears to be a different size can change how players perceive the fairness of your game.
