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

Announce (tech) demos or games releases

Moderator: Mask of Destiny

User avatar
Miquel
Very interested
Posts: 360
Joined: Sat Jul 30, 2016 12:33 am

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

Post by Miquel » Thu Aug 02, 2018 9:55 pm

Yeah! everyday when I get out to the street thousands of people approach me saying they have done a MD game is asm, even children.
Sik wrote:
Thu Aug 02, 2018 8:09 pm
Pressing Start and another button at the same time is hell (at least in the case of an action game), you need to change the position of your fingers since the Start button is not ready to press while in the usual stance. That's something you want to avoid at all costs.
Well on a 6 button pad was not that difficult to press X and, B or C, I thought it was similar with the 3 button pad.
Anyway, my input reading routine is changed to (3button only):
Start+Left => X
Start+Up or Start+Down => Y
Start+Right => Z

I use X, Y and Z to show "items menu", "map" and "save menu" so not really action buttons, I think it can work.

Chilly Willy
Very interested
Posts: 2619
Joined: Fri Aug 17, 2007 9:33 pm

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

Post by Chilly Willy » Sat Aug 04, 2018 1:20 am

START + button is easy... if you push start with the other thumb and the buttons like normal. You just have to let off the dpad for an instant.

On a stock 6 button, MODE is the perfect selector button as it's on the right shoulder. Of course, on the 6 button, you probably don't need the selector.

There's also the START + dpad mentioned earlier. Then you push START instead of a button while keeping on the dpad with the other thumb.

User avatar
Miquel
Very interested
Posts: 360
Joined: Sat Jul 30, 2016 12:33 am

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

Post by Miquel » Sat Aug 04, 2018 8:14 pm

Chilly Willy wrote:
Sat Aug 04, 2018 1:20 am
START + button is easy... if you push start with the other thumb and the buttons like normal. You just have to let off the dpad for an instant.
It's easy doing it once, but while playing it's not very comfortable.
Chilly Willy wrote:
Sat Aug 04, 2018 1:20 am
There's also the START + dpad mentioned earlier. Then you push START instead of a button while keeping on the dpad with the other thumb.
As long as you disable dpad input while start is down for the ergonomic side works, the be used side feels estrange at the beginning. To fight that, in my case, the start button will also be used to access the same functionality.

mix256
Very interested
Posts: 124
Joined: Thu Jan 25, 2018 2:08 pm
Location: Sweden
Contact:

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

Post by mix256 » Wed Aug 08, 2018 11:06 am

I got the test-carts and boxes yesterday! They are awesome! Way better than I could have hoped for.
So super happy! :D

Will do a proper update on the KS site and here on Sunday, showing pics and stuff of it.

mix256
Very interested
Posts: 124
Joined: Thu Jan 25, 2018 2:08 pm
Location: Sweden
Contact:

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

Post by mix256 » Mon Aug 13, 2018 8:43 am


mix256
Very interested
Posts: 124
Joined: Thu Jan 25, 2018 2:08 pm
Location: Sweden
Contact:

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

Post by mix256 » Sat Aug 25, 2018 11:56 am

"I'll handle the CRAM dots later", I said to myself. Now "later" is here, and I don't know what to do about it.
This should be ok, right?

Code: Select all

VDP_waitVSync();
colorCyclePressStart(colorCycleTimer++);
All that other function do is a few VDP_setPaletteColor.
I get CRAM dots somewhere around line 192...what's up with that?

User avatar
Miquel
Very interested
Posts: 360
Joined: Sat Jul 30, 2016 12:33 am

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

Post by Miquel » Sun Aug 26, 2018 10:52 am

mix256 wrote:
Sat Aug 25, 2018 11:56 am
I get CRAM dots somewhere around line 192...what's up with that?
The color dots appear when the color bus is accessed twice at the same moment. VPD is accessing it most of the time during display period to acquiere color info to render the image; even when only displaying the background color.

So, you change colors only during vblank (pay attention when 60hz mode on a 50hz display), or you time it PERFECTLY to avoid concurrency.

I don't know how SGDK works but sure you are accessing colors at display time.

User avatar
Sik
Very interested
Posts: 736
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

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

Post by Sik » Sun Aug 26, 2018 3:38 pm

Just to make it clear: VDP never lets go of the CRAM bus, so any writes to the palettes will always result in CRAM dots, no exception. The best you can do is try to hide them in border area, which is what games do in general.

Anyway, back to the problem... that isn't helpful at all. May need to post some more code to see what's actually going on :​/ (for all we know there's some silly mistake lurking that you aren't aware of that makes it not write them in vblank time)
Sik is pronounced as "seek", not as "sick".

User avatar
Miquel
Very interested
Posts: 360
Joined: Sat Jul 30, 2016 12:33 am

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

Post by Miquel » Sun Aug 26, 2018 6:31 pm

You know perfectly well that on display's blank periods there is no pixel activation, so doesn't matter if the vdp is using color bus, you can safelly change color info then. The vblank period could be smaller for the display, but still there is plenty of time on at least 99.99% of displays to do it.

My propouse was to reduce the problematic area, since all we have is:

VDP_waitVSync(); /* waits for the vblank flag to flip to 1 */
VDP_setPaletteColor(...); /* directly changes color */

we now can focus on the first function since is the one that seems to fail.

Speaking of that, mix256, is there a "volatile" attribute when accesing the vpd flag? Dispite depending on the C optimizations can work (or not), it MUST be there to be sure that always works.

mix256
Very interested
Posts: 124
Joined: Thu Jan 25, 2018 2:08 pm
Location: Sweden
Contact:

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

Post by mix256 » Mon Aug 27, 2018 5:22 am

Miquel wrote:
Sun Aug 26, 2018 10:52 am
I don't know how SGDK works but sure you are accessing colors at display time.
Sik wrote:
Sun Aug 26, 2018 3:38 pm
Anyway, back to the problem... that isn't helpful at all. May need to post some more code to see what's actually going on :​/ (for all we know there's some silly mistake lurking that you aren't aware of that makes it not write them in vblank time)
Miquel wrote:
Sun Aug 26, 2018 6:31 pm
VDP_waitVSync(); /* waits for the vblank flag to flip to 1 */
VDP_setPaletteColor(...); /* directly changes color */

we now can focus on the first function since is the one that seems to fail.
Thanks!

Just wanted to be sure that my reasoning was right - a CRAM change in the vblank will generate dots but in the vblank part.
So the above code should do that, but it isn't for some reason.
Will do some proper investigation later tonight.

Edit: Just tested it on my pal machine and there it works as expected. So there is something with the NTSC vsync as you pointed out Miquel.

notaz
Very interested
Posts: 178
Joined: Mon Feb 04, 2008 11:58 pm
Location: Lithuania

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

Post by notaz » Mon Aug 27, 2018 9:11 am

mix256 wrote:
Sat Aug 25, 2018 11:56 am

Code: Select all

VDP_waitVSync();
colorCyclePressStart(colorCycleTimer++);
All that other function do is a few VDP_setPaletteColor.
I get CRAM dots somewhere around line 192...what's up with that?
Uninformed guess (since I don't know if you are using interrupts):
You wait for vsync, vblank flag gets set, VDP_waitVSync() returns, interrupt arrives (it's always slightly delayed after the flag), you do tons of work there which ends at line ~192, interrupt returns, you write CRAM.

mix256
Very interested
Posts: 124
Joined: Thu Jan 25, 2018 2:08 pm
Location: Sweden
Contact:

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

Post by mix256 » Mon Aug 27, 2018 12:20 pm

notaz wrote:
Mon Aug 27, 2018 9:11 am
Uninformed guess (since I don't know if you are using interrupts):
You wait for vsync, vblank flag gets set, VDP_waitVSync() returns, interrupt arrives (it's always slightly delayed after the flag), you do tons of work there which ends at line ~192, interrupt returns, you write CRAM.
Thanks! But no interrupts, and it works "fine" on my PAL machine.

User avatar
Miquel
Very interested
Posts: 360
Joined: Sat Jul 30, 2016 12:33 am

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

Post by Miquel » Mon Aug 27, 2018 12:21 pm

Try something like this:

Code: Select all

void VDP_waitVSync()
{
    volatile vu16 *pw;

    pw = (volatile u16 *) GFX_CTRL_PORT;

    while (*pw & VDP_VBLANK_FLAG);
    while (!(*pw & VDP_VBLANK_FLAG));
}
on "vpd.c".

This volatile NEEDS to be there, it's the way to inform the compiler that the value is pointing to can be changed externally. If it's not there, the compiler can optimize it to a never ending loop, just ignore it, or doing what you expect; all depends on the optimizations that it's applying, which can be even different in each case if inlining.

mix256
Very interested
Posts: 124
Joined: Thu Jan 25, 2018 2:08 pm
Location: Sweden
Contact:

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

Post by mix256 » Mon Aug 27, 2018 12:55 pm

Miquel wrote:
Mon Aug 27, 2018 12:21 pm
Try something like this:

Code: Select all

void VDP_waitVSync()
{
    volatile vu16 *pw;

    pw = (volatile u16 *) GFX_CTRL_PORT;

    while (*pw & VDP_VBLANK_FLAG);
    while (!(*pw & VDP_VBLANK_FLAG));
}
on "vpd.c".

This volatile NEEDS to be there, it's the way to inform the compiler that the value is pointing to can be changed externally. If it's not there, the compiler can optimize it to a never ending loop, just ignore it, or doing what you expect; all depends on the optimizations that it's applying, which can be even different in each case if inlining.
Thanks! Didn't think about checking that, was thinking Stef had done it for me. :)
Will try it as soon as I get back home!

User avatar
Sik
Very interested
Posts: 736
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

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

Post by Sik » Mon Aug 27, 2018 12:58 pm

Erm...

Code: Select all

/**
 *  \typedef vu16
 *      volatile 16 bits unsigned integer.
 */
typedef volatile u16 vu16;
Though wait, does volatile actually work in typedef or is it meant to be ignored?
Sik is pronounced as "seek", not as "sick".

Post Reply

Who is online

Users browsing this forum: No registered users and 0 guests