VDP_drawText > x pos overflows VRAM

[bferguson3]

Steps

1. Make any example project
2. Add code: VDP_drawText("String", 60, 0);
3. Observe rom crashes

This appears to be arbitrary, as the Y offset doesn't crash. This should either be marked "unsafe" (eg VDP_drawTextUnsafe) or fixed so that it won't cause this headache.

[Stephane-D]

I can make these methods specifically more safe but in general adding that kind of safety does make SGDK a bit slower as we are running C code on a 7.7 Mhz 68000. SGDK does still contains some barriers here and there but there is always trade-off between performance and safety so unfortunately you can't expect every methods to be inherently safe.

[Stephane-D]

I specifically protected VDP_drawText() / VDP_clearText() methods but to be honest i'm not really sure that is a good idea as a lot of other methods (as VDP_fillTileMapRect(..) for instance) aren't safe and i don't think it would be a good idea to try to make all these methods safe for global performance.

[bferguson3]

Why, then, can you print at Y = 200 or whatever and its fine?

All you need to do is prevent the routine from writing outside of VRAM bounds, that's a very easy fix to implement and should be in ANY vram writing routine.

[bferguson3]

Please note that the way this routine appears is coded, it requires the tile offset within the MAP, not VRAM.

If this is not intended, then the X and Y parameters should be forced between 0-39 and 0-24.

[Stephane-D]

Writing at Y = 200 isn't fine at all ^^ It's just it's kind of unpredictable behavior happening there and it may eventually crash. If you speak about the drawText routine themself, they are writing to the tilemap (which is located in VRAM) and not only to visible screen area. Also now the method is checking you're outside the tilemap bounds and take care of that.

[bferguson3]

I understand, I was getting unpredictable results because of my tilemap size. I think narrowing the map to size of BG planes helps a lot.

On Fri, Dec 11, 2020, 09:02 Stephane Dallongeville notifications@github.com wrote:

I can make these methods specifically more safe but in general adding that kind of safety does make SGDK a bit slower as we are running C code on a 7.7 Mhz 68000. SGDK does still contains some barriers here and there but there is always trade-off between performance and safety so unfortunately you can't expect every methods to be inherently safe.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Stephane-D/SGDK/issues/180#issuecomment-743208599, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH3QAM6FDK6JXDINVLTGHZDSUIQ53ANCNFSM4UWTQ2GA .