Sega Genesis Dev Kit (SGDK)

[cero]

I believe the compiler can't do that because of the () parenthesis - the divide was outside of them.

[djcouchycouch]

For the makefile, moving the mkdir calls from the .c and .s compilation to a pre-build step would be a good idea. On my projects, I kept adding more and more directories to those sections and never noticed the compilation speed gradually slowing down. It would attempt to recreate the same set of folders every time it tried to compile a file. Moving the mkdir calls to a pre-build step cut my compilation time by more than half.

djcc

[cero]

I wondered what mkdir calls, there aren't any in the gendev skeleton makefile, but seems there are in "makefile.gen" shipped in sgdk.

[Stef]

Never realized it was so costly. I just pushed the new makefile to do that in pre-build process

[dub]

Hi,
I switched my project on the new version of sgdk and I have a problem with the fading (in and out). It works well on emulated but not on the real hardware. I have glitch on screen (bad palette transition). And I have not this problem with the old sgdk with the same code.

I add this code to the sample "sprite".

Code: Select all

// START button state changed
    if (changed & BUTTON_START)
    {
	
		u16 palette[64];
		u8 i;
		
		for (i=0; i<64; i++)
			memcpy(&palette[i], palette_black, 1 * 2);

	
		VDP_fadeOut(0, (4 * 16) - 1, 400, FALSE);
		VDP_waitFadeCompletion(); // wait til fade has completed
		
		// prepare palettes
    memcpy(&palette[0], bgb_image.palette->data, 16 * 2);
    memcpy(&palette[16], bga_image.palette->data, 16 * 2);
    memcpy(&palette[32], sonic_sprite.palette->data, 16 * 2);
    memcpy(&palette[48], enemies_sprite.palette->data, 16 * 2);
	

    // fade in
    VDP_fadeIn(0, (4 * 16) - 1, palette, 400, FALSE);
	
		VDP_waitFadeCompletion(); // wait til fade has completed
    }

I put the source code and ROM for testing.
https://dl.dropboxusercontent.com/u/27435968/fading.zip

[Moon-Watcher]

The fade is sync-ed, do you need to call VDP_waitFadeCompletion()?

[dub]

yes
you're right. I don't need it but it's because I use it later with a not sync fading.

But I try the two options and I've the same problem.

[cero]

Are you sure you're using the latest? It has the "xgm hang during fade" issue, which is fixed in the current sgdk.

[dub]

Yes the very last. I download it this morning and compil the Library.

It's weird.

I test with this line of code only present in the sgdk 1.2 : VDP_setTextPlan(PLAN_WINDOW);
So I think, I have the last version.

[Moon-Watcher]

if (changed & BUTTON_START)

So it's that code

[dub]

Yes, thanks so much.

I put my code outside this function and it works. :mr green:

Code: Select all

void doingFade()
{
	if (fadechange == 1)
	{
		fadechange = 0;
		..
		do fade
		..
	}
}

// START button state changed
    if (state & BUTTON_START)
    {
   
      fadechange = 1;
    }

[Stef]

You were doing a synched fading process in the JOY event callback ? that can be a problem indeed as it locks all interruptions (at least you have to know it), still i need to check why it does not work correctly on real hardware.

[dub]

I have to test all my functions. Maybe just a little thing.
But I need to check every time on real hardware. It's so long

[dub]

I test again and this time directly from the sample sprite whitout changing anything and I always have the same glitch when fading in the top of the screen.

If I increase the value of frame of duration fading, it's more visible. I'll try too with async value (false/true)
VDP_fadeIn(0, (4 * 16) - 1, palette, 200, FALSE);
VDP_fadeIn(0, (4 * 16) - 1, palette, 200, TRUE);

May it be my megadrive with my everdrive ?

[Stef]

I need to check that but it looks the palette is transferred during active period and so you have those infamous CRAM dot bug (printed in image when CRAM is wrote). Probably a timing issue in SGDK (CRAM should be wrote during blanking only for that reason).