Sprites in MSX-C

Page 1/8
| 2 | 3 | 4 | 5 | 6

By Wolverine_nl

Paladin (1015)

Wolverine_nl's picture

13-04-2014, 20:55

Hi,
I am busy with sprites in MSX-C and I have an issue that is puzzling me.
I wrote a little testprogram to display a sprite in screen 5, it doesnt give compiling errors and it does display a sprite, only the design is screwed up.
here is the code:

#pragma nonrec
#include <stdio.h>
#include <glib.h>

int i;
int x;
int y;

int *plspr[32] = 
0x07,0x04,0x04,0x04,0x04,0x04,0x04,0x04,
0x04,0x04,0x0C,0x18,0x30,0x60,0xC0,0xFF,
0xE0,0x20,0x20,0x20,0x20,0x20,0x20,0x20,
0x20,0x20,0x30,0x18,0x0C,0x06,0x03,0xFF;

int *plclr[16] = 
0x0F,0x0F,0x0F,0x0F,0x0F,0x0F,0x0F,0x0F,
0x0F,0x0F,0x0F,0x0F,0x0F,0x0F,0x0F,0x0F;

main()
{
screen((TINY)5);
ginit();
color((TINY)15, (TINY)0, (TINY)0);
cls();

/* display sprite */
inispr((TINY)2);
sprite((TINY)0, plspr);
colspr((TINY)0, plclr);
putspr((TINY)0, 50, 50,(TINY)0, (TINY)0);
}

It is probably the sprite pattern table i am not correctly adressing or something in that order, but i cannot get it to work.
I was thinking about a for statement, but am not sure how to proceed. There is not much on MSX-C, i have got a ANSI C book next to me, but not sure if i should use for instance i++ untill 31 is reached etc etc.
Does anyone have some experience with this matter?

Login or register to post comments

By kanima

Master (192)

kanima's picture

13-04-2014, 21:36

ints are 16 bit, so try changing your plspr and plclr arrays to char or unsigned char instead

By Wolverine_nl

Paladin (1015)

Wolverine_nl's picture

13-04-2014, 21:50

Ah, great, i will try this! Thanks for this info.

By Wolverine_nl

Paladin (1015)

Wolverine_nl's picture

14-04-2014, 08:26

I tried it, but the results are exactly the same.
Tomorrow i will try something else.
BTW is putting "unsigned" in front of char making it 16 bit again? I remember something in that order.

By Manuel

Ascended (15289)

Manuel's picture

14-04-2014, 13:52

No, 'unsigned char' is just an 8 bit value with meaning 0-255. At least it should be on MSX C.

By Wolverine_nl

Paladin (1015)

Wolverine_nl's picture

14-04-2014, 14:06

ok, because i got the same result as using int. So maybe the whole problem lies in something else. Will get back on this

By st1mpy

Champion (489)

st1mpy's picture

14-04-2014, 23:18

My guess is you want an array of unsigned chars, and not an array of pointers to unsigned chars.
So,

Unsigned char plspr[32] = {0x01, ... };

Or if you want a pointer,

Unsigned char *plspr = {0x01,...};

By Wolverine_nl

Paladin (1015)

Wolverine_nl's picture

15-04-2014, 09:58

If i use
unsigned char
with or without pointer, i get a duplicate error in the msxc compiler

This morning i started writing a separate function for it, maybe i can control it better, the compiler gave 0 errors and compiled the function, still with the same result, but now i can maybe pinpoint the problem better.
This afternoon i will try unsigned *plspr = blabla, this should actually work as well, if this doesn't work, then i know it is an address issue, the patterntable startaddress maybe conflicting, will check the glib.mac for more answers Wink

now i need some coffee...or hot chocolate Wink

By Wolverine_nl

Paladin (1015)

Wolverine_nl's picture

16-04-2014, 10:11

found it, was staring at it the whole time -=lol=- hahaha
it should be
static TINY blabla[] = {56, ....};

before i already used this some time ago in another program, only not for sprites Tongue
The manual file from Freddy Vulto (which is translated from the original MSX-C Library book which was Japanese)
gives you the impression you have to use pointer data, but i only have to do that when declaring something before i make my own function out of it. So it is a throw off, you get the wrong idea and i kept being stuck in that idea.

thanks all for your input.

Now the next step is moving this sprite and adding colours etc etc. will post this also if people are interested.

By Wolverine_nl

Paladin (1015)

Wolverine_nl's picture

17-04-2014, 11:37

Does anybody have experience in creating external .c files that use #include"bla.c" ?
Whats's better for the whole program(speed, performance wise), to use several files to compile to 1 or to put everything in 1 and only .h are included from the outside? Or does the assemblypart of the compile put everything in the same order as if I were to put everything in one c file?

By Manuel

Ascended (15289)

Manuel's picture

17-04-2014, 13:18

The preprocessor will include everything that's necessary to parse the program anyway. So parsing will be done on the complete program. Therefore, compilation time will not improve when putting stuff in separate files.

Page 1/8
| 2 | 3 | 4 | 5 | 6
My MSX profile