Tänzer, a "ninja" game (Dev Diary thread)
Moderator: Mask of Destiny
Re: Unnamed "ninja" game (Dev Diary thread)
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
Good pull request idea maybe
Re: Unnamed "ninja" game (Dev Diary thread)
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.
Tänzer kickstarter: https://www.kickstarter.com/projects/83 ... lusive-gam
https://twitter.com/mix256
https://twitter.com/mix256
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
Re: Unnamed "ninja" game (Dev Diary thread)
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) :-/
Sprite maskingI 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.
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);
Code: Select all
SPR_setVisibility(sprite, AUTO_FAST);
Re: Unnamed "ninja" game (Dev Diary thread)
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.
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!
Tänzer kickstarter: https://www.kickstarter.com/projects/83 ... lusive-gam
https://twitter.com/mix256
https://twitter.com/mix256
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
Re: Unnamed "ninja" game (Dev Diary thread)
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...
Oh i see, well adding some kind of assert / debug method as enterMethod(methodName) / exitMethod() so exeption handler use them if available..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.
Still it would be annoying for the developer to do that for each method :-/
You're welcome :pStef wrote: ↑Wed Mar 21, 2018 8:52 amOMG.
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!
Re: Unnamed "ninja" game (Dev Diary thread)
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.
Tänzer kickstarter: https://www.kickstarter.com/projects/83 ... lusive-gam
https://twitter.com/mix256
https://twitter.com/mix256
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
Re: Unnamed "ninja" game (Dev Diary thread)
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
Re: Unnamed "ninja" game (Dev Diary thread)
You already have a logo? Where is it?
Tänzer kickstarter: https://www.kickstarter.com/projects/83 ... lusive-gam
https://twitter.com/mix256
https://twitter.com/mix256
Re: Unnamed "ninja" game (Dev Diary thread)
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.
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.
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
Re: Unnamed "ninja" game (Dev Diary thread)
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...
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
Re: Unnamed "ninja" game (Dev Diary thread)
normally VDP_init() reset everything (registers and VRAM)... that's weird.
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 courseTo 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.
Re: Unnamed "ninja" game (Dev Diary thread)
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.
Tänzer kickstarter: https://www.kickstarter.com/projects/83 ... lusive-gam
https://twitter.com/mix256
https://twitter.com/mix256
Re: Unnamed "ninja" game (Dev Diary thread)
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.
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.
HELP. Spanish TVs are brain washing people to be hostile to me.
Re: Unnamed "ninja" game (Dev Diary thread)
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
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.
Sik is pronounced as "seek", not as "sick".