Stephane-D
commented
3 years ago Oh indeed thanks for the report ! I never realized that we can't do tilemap column update when using the 128x32 tilemap size as the auto-increment register allow a value from 0 to 255 only (and 0 is actually 0, not 256...) That is a real failure in the design. I guess i will have to add checks to avoid that case to happen or at least put KLog messages to warn about it. I can explain why it's working using larger images: SGDK detects that tilemap row update would be more efficient here so it will use setTileMapDataRowEx(..) function instead which is not impacted by the issue.
matteusbeus
a-dietrich
I tried to use VDP_drawImageEx() to copy an image of 72x224 pixels into a large plane, which has been set to 128x32 tiles. Unfortunately, this seems to give a wrong result. It can be seen on the left of the attached image.
I did some digging, and in the SGDK CPU code path there might be a problem in setTileMapDataColumnEx(). The auto increment gets set to 2*128, which is then passed on as an u8. In the attached reproducer yoou can find a modified version of setTileMapDataColumnEx() that does not use the auto increment (block in the middle of the image).
Interestingly, when using a larger source image (e.g., 128x224 pixels) there is no problem. I've included a number of source images in the reproducer.
Thanks for having a look!
reproducer.zip