¿eso no daría 64x48?, si los pixels que no se dibujan no gastan recursos, entonces vale... pero, ¿que tal el sistema de colisiones?, lo imprescindible es evitar el efecto de que se choca con el aire.
No 32 de ancho, y 32+16 de alto, 32x48 px, todo gasta recursos aunque no se dibuje, solo que gasta menos
El hardware admite valores multiplos de 8, lo mas cercano a lo que dices es 16x24
Sobre la colicion, depende mucho del engine. En mi caso, el que yo programe va por bloques de 32x32, asi que, en caso que un sprite sea mas grande, se rige igualmente por el mismo principio
Aqui entra en juego el tema de las prioridades de los sprites. En megadrive, cuando cargas los sprites en memoria, el ultimo, tapa al primero.
Cuando se quiere que suceda lo contrario, hay que cargar los sprites en el orden inverso..
Cuelgo una imagen como ejemplo, en el caso de 32x42px el detector de colicion, esta en la parte inferior de cada sprite, los primeros 16 pixeles de cada sprite, no hacen colicion de ningun tipo. En el caso de 32x32, todo el sprite hace colicion
En el primer ejemplo, la anciana tiene prioridad alta y esta en movimiento, y tapa al segundo sprite hasta estar 16 pixeles por arriba, donde se detecta la colicion
El segundo caso, no hay colicion, porque aunque se toquen, no se detecta hasta q esten juntos al menos 16 pixeles
En el tercer caso, viene el problema, donde la anciada tiene prioridad baja, y el segundo sprite, es el que esta en movimiento tiene pripiridad alta, quedando por arriba... aqui habria que invertir las prioridades, lo que implicaria programar, una funcion que detecte continuamente en que posicion esta cada sprite, y valla redibujandolos.... (algo similar a lo que pasa en el Street of Rage por ejemplo, donde puedes estar por arriba o por debajo de otro sprite...)
El tercer caso, son sprites de 32x32, siempre chocan por los bordes
