MSX FUSION-C, Talking about bugs, errors, mistakes

I tested Fusion-C briefly. If I remember correctly, an int for an array index didn't work, it must be a char. Also there was no compile-time error or warning about that, the program just didn't work when it was an int.

But I haven't checked out the newest version.

I took another look into this.

I played with Pt3Player-MSX2-Demo.c. I changed the example so the playing tune could be switched on runtime.

There is that local variable char music that is used as an index. When changed to an int the program doesn't work. However, if I make that variable global, it works either way.

I don't know what is going on. There seems to be something funny about locals, at least in that example. Maybe it's stack overflow or something.

Has anyone tried SetDate and SetTime?

SetDate with a Date structure set as:
year = 2019;
month = 2;
day = 25;

Will return true and not set the date...

Also trying SetTime wit Time structure set as:
hour = 23
min = 50
sec = 40

Will return true and not set the time... Using Konamiman asm.h/asm.lib and DosCall like in his SNTP example:

https://www.konamiman.com/msx/networking/source/sntp.c

Works like a charm... Not sure if I'm overlooking something, as it is really late and I might be tired... :P

Hi everybody:
I'm still working with Fusion.
Something is driving me crazy ... I put the following example:

#include "fusion-c/header/msx_fusion.h"
#include "fusion-c/header/vdp_graph1.h"
#include "fusion-c/header/vdp_sprites.h"
#include "fusion-c/header/vdp_circle.h"

void main(void) 
{
	unsigned char nave[] = {
		0x00,0x00,0x01,0x01,0x02,0x02,0x02,0x07,0x07,0x09,0x1F,0xA9,0xCF,0x89,0xF9,0x86,0x00,0x00,0x80,0x80,0x40,0x40,0x40,0xE0,0xE0,0x90,0xF8,0x95,0xF3,0x91,0x9F,0x61
	};
	unsigned char disparo[] = {
		0x18,0x3C,0x18,0x18,0x18,0x18,0x18,0x18,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
	};
	unsigned char enemigo[] = {
		0x20,0x10,0x08,0x05,0x3E,0x21,0x21,0x11,0x0E,0x07,0x0D,0x1C,0x1C,0x0C,0x0C,0x04,0x04,0x08,0x10,0xA0,0x7C,0x84,0x84,0x88,0x70,0xE0,0xB0,0x38,0x38,0x30,0x30,0x20
	};
	unsigned char enemigo2[] = {
		0x08,0x08,0x04,0x04,0x1E,0x21,0x21,0x21,0x1E,0x1E,0x0D,0x1D,0x27,0x40,0x80,0x80,0x10,0x10,0x20,0x20,0x78,0x84,0x84,0x84,0x78,0x78,0x50,0x58,0xE4,0x02,0x01,0x01
	};

	SpriteReset();
	Sprite16();
	SpriteSmall();	
	SetSpritePattern( 0,     nave, 32);
	SetSpritePattern( 4,  enemigo, 32);
	SetSpritePattern( 8, enemigo2, 32);
	SetSpritePattern(12,  disparo, 32);
	
	Screen(2);
	Cls();

	SC2Rect(0,171,254,192,13,FILL_ALL); // this line mess the sprites up ... Why?

	PutSprite( 2,  4,   35, 40, 3);
	PutSprite( 3,  4, 2*35, 40, 3);
	PutSprite( 4,  4, 3*35, 40, 3);
	PutSprite( 5,  8,   35, 64, 5);
	PutSprite( 6,  8, 2*35, 64, 5);
	PutSprite( 7,  8, 3*35, 64, 5);
	PutSprite( 8,  4,   35, 88, 7);
	PutSprite( 9,  4, 2*35, 88, 7);
	PutSprite(10,  4, 3*35, 88, 7);

	PutSprite( 1, 0, 80, 152, 15);

	WaitForKey();
}

Sptrites look wrong but if I comment lines SC2Rect(... Then Sprites look fine. It don't make sense... a filled rectangle messing with sptrites?....

Could you tell if I'm doing something wrong or It is a bug?

As usual ... Thanks in advantage. I really apreciate your help.

PS: the question I did before was solved with your instructions ... thanks

I tested your code. The rectangle simply is too tall, causing the VRAM write to extend to sprite pattern area.

Try
SC2Rect(0,171,254,191,13,FILL_ALL);

Seems there is no boundary check, unlike in BASIC.