SpritesMind.Net

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.

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.

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.

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

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

I did a small update on KS, https://www.kickstarter.com/projects/83 ... ts/2261487

"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? All that other function do is a few VDP_setPaletteColor.
I get CRAM dots somewhere around line 192...what's up with that?

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.

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)

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.

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.

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.

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.

Try something like this:
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.

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!

Erm... Though wait, does volatile actually work in typedef or is it meant to be ignored?