Tänzer, a "ninja" game (Dev Diary thread)

[Grind]

I've gotten burned by this one so many times. I think adding bounds checking for debug only would be very helpful to catch this stuff.

Good pull request idea maybe

[mix256]

I've gotten burned by this one so many times. I think adding bounds checking for debug only would be very helpful to catch this stuff.

Good pull request idea maybe

For sure it could lead to incorrect frame pointer if you use setAnim (or setFrameAndAnim / setFrame) with incorrect index :p i'm not doing any bounds verification (for performance reason obviously).

SGDK could have its own crash screen when asserts fail in debug mode, maybe? With some kind of (human readable) stack trace.

I have, though, found a strange sprite issue that you Stef probably knows something about.
The "main lander" sprite is 168px wide. It is not visible when having some specific coordinates.
Namely -128 and -160. The -128 one only happens when there are more sprites on the same row, it seems. But the -160 one happens even when the sprites is a bit down on the screen. (the screenshots show 5F instead of 60 and 7F because of 80...Fusions screenshot-taker advanced a frame...but not fully...was really strange.)

Showing:

x-coord -128:

Showing:

x-coord -160:


Any ideas about this? I would understand it if there was a glitch when the whole sprite is on screen, but it's just at these X-coordinates it glitches.

[Stef]

SGDK could have its own crash screen when asserts fail in debug mode, maybe? With some kind of (human readable) stack trace.

In fact the crash screen you got is already generated by SGDK, and even if i can arrange it a bit to make it more pleasant to read, it will still generate hexa code. In debug mode i could eventually try to get method name or something like that but honestly i think it would be quite difficult (i've no idea about how get them from embedded debug data) :-/

I have, though, found a strange sprite issue that you Stef probably knows something about.
The "main lander" sprite is 168px wide. It is not visible when having some specific coordinates.
Namely -128 and -160. The -128 one only happens when there are more sprites on the same row, it seems. But the -160 one happens even when the sprites is a bit down on the screen. (the screenshots show 5F instead of 60 and 7F because of 80...Fusions screenshot-taker advanced a frame...but not fully...was really strange.)

...

Any ideas about this? I would understand it if there was a glitch when the whole sprite is on screen, but it's just at these X-coordinates it glitches.

Sprite masking
Having a sprite with a X position of -128 (0 hardware wise) will act as a mask for all sprites displayed after it (and the mask apply on the whole height of the mask sprite). Also -160 would probably give you a positive position as -128 is the minimum on hardware. You really need to avoid that situation (negative sprite coordinates below -100), also it's bad because having sprite outside screen X wise still eat the sprite budget per line so it's better to clip them ! If you want you can use the sprite engine so it can do it for you automatically (computing the visibility for sprite). I think you only need to have the "per hardware sprite" visibility computation for large sprite (it takes more time obviously) :

Code: Select all

SPR_setVisibility(sprite, AUTO_SLOW);

and for smaller sprite you can use visibility computed for the whole meta sprite :

Code: Select all

SPR_setVisibility(sprite, AUTO_FAST);

that should be the default mode.

[mix256]

In fact the crash screen you got is already generated by SGDK

Ah, I didn't know that but the crash screen is great as it is, I think. Did you see my comment about it not being fully on screen a lot of times? Like the x-scroll value wasn't reset, or something. Is that something you are in control of, even after a crash?
I was thinking there could be a different kind of crash screen for debug-assertions, that would require the programmer to jack itself into if proper stack traces would be needed. Could be as easy as adding the function name and some parameters to a list at the start of a function and removing it at the end and all failed asserts in the function could just show the crash. Just thinking out loud here.

Sprite masking

OMG.
I could have swore I'd read about x-coord 0 somewhere, when I first saw the glitching behavior, but couldn't find it. But I see now that's in the vdp documentation. Thanks!

I'll just add AUTO_SLOW to the lander ship sprite and take the rest as they show problems, or not. Again, huge thanks!

[Stef]

Ah, I didn't know that but the crash screen is great as it is, I think. Did you see my comment about it not being fully on screen a lot of times? Like the x-scroll value wasn't reset, or something. Is that something you are in control of, even after a crash?

Yeah i saw it but i'm surprised as i'm doing a VDP_init() call to be sure to reset everything with display, so i don't understand how the scroll value can be incorrect (normally VRAM should be reset as well). I need to investigate that...

I was thinking there could be a different kind of crash screen for debug-assertions, that would require the programmer to jack itself into if proper stack traces would be needed. Could be as easy as adding the function name and some parameters to a list at the start of a function and removing it at the end and all failed asserts in the function could just show the crash. Just thinking out loud here.

Oh i see, well adding some kind of assert / debug method as enterMethod(methodName) / exitMethod() so exeption handler use them if available..
Still it would be annoying for the developer to do that for each method :-/

OMG.
I could have swore I'd read about x-coord 0 somewhere, when I first saw the glitching behavior, but couldn't find it. But I see now that's in the vdp documentation. Thanks!

I'll just add AUTO_SLOW to the lander ship sprite and take the rest as they show problems, or not. Again, huge thanks!

You're welcome :p

[mix256]

Still it would be annoying for the developer to do that for each method :-/

Yeah, but one could start doing that just when doing the trouble shooting. Using two simple-to-use macros.
Do you have a logo for SGDK that can be used as a vanity screen-thing? Just hit me that I need to hit that donate-button of yours as well.

[Stef]

Haha, someone just sent me a SGDK logo some days ago but well, i think i prefer my original SGDK logo, need to change the text though :p

[mix256]

...i think i prefer my original SGDK logo, need to change the text though :p

You already have a logo? Where is it?

[Grind]

Are you using tile/line hoz scroll instead of plane scroll? Perhaps VDP_init() doesn't set the mode back to plane but didn't check myself.

To expand on the debug assertion idea, GCC provides the macros __FILE__, __LINE__, and __FUNCTION__, which could be fed to an error handler if an assertion fails. Though that would need macro versions of most library calls to get the right info, and all those strings could take up quite a bit of space.

For something specific like sprite frame bounds it would probably be enough to verify the argument of setFrame and setAnim are less than the actual frame/animation count of the sprite. If it is too large or negative, crash with the index that tried to be accessed with a message like "sprite frame x out of bounds". Though, I wonder how many people would actually think to switch to 'make debug' after getting an address error.

[Stef]

...i think i prefer my original SGDK logo, need to change the text though :p

You already have a logo? Where is it?

Not yet put on the repository, in fact this is the one you can find from the profil picture here :
https://github.com/turiaso

This guy is actually writing the resourcemanager tool, and he also made that logo but the color conversion make it not really nice on MD, i guess that needs some work...

[Stef]

Are you using tile/line hoz scroll instead of plane scroll? Perhaps VDP_init() doesn't set the mode back to plane but didn't check myself.

normally VDP_init() reset everything (registers and VRAM)... that's weird.

To expand on the debug assertion idea, GCC provides the macros __FILE__, __LINE__, and __FUNCTION__, which could be fed to an error handler if an assertion fails. Though that would need macro versions of most library calls to get the right info, and all those strings could take up quite a bit of space.

For something specific like sprite frame bounds it would probably be enough to verify the argument of setFrame and setAnim are less than the actual frame/animation count of the sprite. If it is too large or negative, crash with the index that tried to be accessed with a message like "sprite frame x out of bounds". Though, I wonder how many people would actually think to switch to 'make debug' after getting an address error.

I will probably add boundaries check here and add warning messages in the KMod output log (as i'm already doing for some severe errors). It's a good practice to stay with "make debug" when developing / debugging game and just pass to release for testing performance and on final release of course

[mix256]

but the color conversion make it not really nice on MD, i guess that needs some work...

Apart from the lens flare, it should look ok.
Seems to be a sega-font for download, don't know what the license is but I'll look into that.

Would it be ok for you if I use something like this then?


Would look awesome on the back of the box as well.

[Miquel]

I'm completely against checking everything philosophy, on the contrary I think you should embrace the crash as soon as possible idea.

Once that said, here the problem is the lack of abstraction. A compiler is not only a tool for making programs, but an abstraction for making other abstractions. In other words you need a tool with resources as input an code as output, and let it deal with indexes. Not everything has to be done with standard c code. But everything should be able to be transform to it.

[Sik]

Though, I wonder how many people would actually think to switch to 'make debug' after getting an address error.

It'd still be helpful for people who know to do it. And we could always just say "use make debug" here as a reply :v

I'm completely against checking everything philosophy, on the contrary I think you should embrace the crash as soon as possible idea.

A failed assert is an intentional (and controlled) crash.

Also don't forget Mega Drive doesn't have a MMU so often it doesn't result in a crash but in weird glitches which are extremely harder to debug as the program won't stop at the error point and so you'll have a harder time with the debugger to trace it back.

[Iridon]

Would it be ok for you if I use something like this then?

Wow looks nice!
Then it also make me see it as Sega Donkey Kong (SG-DK) which makes it ever better!