Thank you Blastar and NeoHomeBrew for the insights.
I have always been fascinated by the scaling effect.
I'm sorry in advance if I sound thick here.
If you did have a 512*512 background image.
We know based on Blastar's statement the horizontal width would be accommodated if a scale were to be performed.
NeoHomeBrew you mention that 16th 'pixel line' of the 16th tile is where the seam occurs.
In the case above we would get a nasty seam as the height is taller than 256 pixels if we perform a scale.
Is there a way to fix the seam programmatically so the image appears in the correct proportion, it is scaled to or are you stuck at that point?
Blastar mentions lookup tables but where I am not clear is that the hardware seems to force the seam on vertical scales that exceed 256 pixels. Can the seam be closed somehow?
I have to imagine that "Samurai Showdown" has backgrounds taller than 256 pixels. The scaling will reduce the image size and there needs to be additional image data above the viewable area to ensure there is always enough 'background' on the 320x224 screen.
Sorry to be a nag this has been swirling around in this head of mine for some time.
Ok so I feel like a dork. NeoHomeBrew you mentioned in your previous post
That means, if you want to shrink a sprite with a tile-size of 16 or more, you have to split the image and re-assemble it again at the "repeating point" between tile 1 and tile 32 to avoid pixel distortion at the 16th line of tile 16.
Does that mean a 512 image that takes 32 sprites needs to be cut in half? Meaning you need to load two 256*256 images equaling 64 sprites just to see the assembled 512*512 image scaled?
Really sorry to highjack the thread I watched your video a bunch of times and I'm pretty sure your video and code answers my questions. I need to get your demo with my own basic image and play around to see if I can make the seams match up!