Various questions for a new game

[tonma]

I begin a new game so I'll post my futur questions here.

 

I wish to make a scrolling from a tilemap. No problem for the tilemap but I wish to avoid drawing gltich with double buffering.

It's nearly working. I changeview page 0, write on page 1. After the end of writing, I set view page to 1 and switch page.

 

But I have glitch on screen. How can I know the end of drawing, when switching page.

unsigned char page = 0;

tgi_setviewpage(page); 

page = 1;

while (1) {

	while (!tgi_busy()) {

		tgi_setdrawpage(page); 
		
		tgi_outtextxy(10, 30*page, "Hello World");

	
		tgi_setviewpage(page); 
		if (page == 1) { page = 0; } else {page = 1; }


	
	}

}



[+karri]

Getting rid of the glitch is exactly what tgi_updatedisplay() does. It will make the page swap during the VBL time.

 

I wonder why you want to use tgi_setviewpage() and tgi_setdrawpage(). Because now you are exactly duplicating what happens in the VBL interrupt routine

        lda     DRAWPAGE
        jsr     SETVIEWPAGE
        lda     DRAWPAGE
        eor     #1
        sta     DRAWPAGE
        jsr     SETDRAWPAGE

Or in C code

tgi_setviewpage(drawpage);
drawpage = drawpage ^ 1;
tgi_setdrawpage(drawpage);

 

[tonma]

Ok. Great, I wasn't sure.

 

I continue with tgi_updatedisplay()

[tonma]

It's me again.

 

I have the same problem than with flappy I think. All my image doesn't display. Everything works in mednafen \ linux but not in Windows or real hardware.

 

I load 2 tiles 8*8 from a tileset, without packed them and display on screen. The last column never display.

 

@karri I changed my makefile and code to be like you said to me for this bug. I change to mode=literal

 

Makefile :

 tile000002.o : tile_rpg.pcx
 $(SP) -r $< --slice 16,0,8,8 -c lynx-sprite,mode=literal,ax=0,ay=0 -w $*.c,ident=$*
 $(CC) --code-name $(CODE_SEGMENT) \
 --rodata-name $(RODATA_SEGMENT) \
 --bss-name $(BSS_SEGMENT) \
 --data-name $(DATA_SEGMENT) \
 $(CFLAGS) -o $*.s $*.c
 $(AS) -o $@ $(AFLAGS) $(*).s
# $(RM) $*.c
# $(RM) $*.s

In my code :

extern char tile000002[];

SCB_REHV_PAL sprbg1 = 
{
  BPP_4 | TYPE_NORMAL,	
  REHV | LITERAL, 0x00,
  0,
  tile000002,
  0, 0, 0x0100, 0x0100,
  { 0x01,0x23,0x45,0x67,0x89,0xAB,0xCD,0xEF }
};

sprbg1.hpos = 48;
sprbg1.vpos = 16;
tgi_sprite(&sprbg1);

On picture : Left = linux Right = hardware/handy Windows

 

I'll try without the slice. Same results.

 

Maybe my sp65 exe is corrupt !!!

/*
 * This file was generated by sp65 2.13.9 from
 * Slice of tile_rpg.pcx (8x8, 16 colors, indexed)
 */

#define tile000000_COLORS       16
#define tile000000_WIDTH        8
#define tile000000_HEIGHT       8
const unsigned char tile000000[] = {
    0x05,0xBB,0xBB,0xBB,0xBB,0x05,0xBB,0xBB,0xBB,0xBB,0x05,0xBB,0xBB,0xBB,0xBB,0x05,
    0xBB,0xBB,0xBB,0xBB,0x05,0xBB,0xBB,0xBB,0xBB,0x05,0xBB,0xBB,0xBB,0xBB,0x05,0xBB,
    0xBB,0xBB,0xBB,0x05,0xBB,0xBB,0xBB,0xBB,0x00,
};

I tried again with the tileset without slice. In Windows I lost my last column : 64*64, show only 63*64.

I add a purple column with photoshop to show the error.

Edited January 18, 2017 by tonma

[+karri]

The strange problems in Flappy were actually caused by using segments. You had used overlaid segments that were no longer in memory. I don't recall exactly where they were but the sudden speedup of the code and many of the glitches were due to using elements from the intro segment in the play segment.

 

Another problem is uninitialized variables. In emulators the variables are filled with zero at startup. On the real Lynx you have random values.

[tonma]

Ok. I'll restarting with a new empty project.

 

I needed it to share the high score. I would look at it later to be sure not to make a mistake. But I understand, I load intro and play at the same memory position.

[tonma]

I still have my image problem. The last line of my graphics don't appear with the windows emulator and on hardware.

You can see left mednafen / linux and right handy / windows. The same 80 * 80 pixel file.

 

I create a sample code very simple without variable and with two segments to test but I have the same problem. Main and Intro segment. I use literal non-packed pictures for test.

 

Can this come from my spr65 converter file ?

 

 

extern char robot[];

SCB_REHV_PAL sprrobot =
{
  BPP_4 | TYPE_BACKGROUND, 
  REHV | LITERAL, 0x00,
  0,
  robot,
  20, 20, 0x0100, 0x0100,
  { 0x01,0x23,0x45,0x67,0x89,0xAB,0xCD,0xEF }
};

I've add my source file.

 

 

100 posts

rpg.zip

Edited January 26, 2017 by tonma

[+karri]

An interesting problem. When I look at the literal sprite encoding it looks ok.

 

Below is one line of robots. The first byte is the offset to the next line 0x29 = 41 bytes. Makes sense as a line has 80 pixels.

Then we have the colours E E = two sky pixels A A A A = 4 green pixels and so on. The line ends with E E = two sky pixels.

0x29,0xEE,0xAA,0xAA,0xEE,0xEE,0xAA,0xAA,0xEE,0xEE,0xAA,0xAA,0xEE,0xEE,0xAA,0xAA,0xEE,0xEE,0xAA,0xAA,0xEE,
     0xEE,0xAA,0xAA,0xEE,0xEE,0xAA,0xAA,0xEE,0xEE,0xAA,0xAA,0xEE,0xEE,0xAA,0xAA,0xEE,0xEE,0xAA,0xAA,0xEE,

0x29,0xEA,0xA8,0x8A,0xAE,0xEA,0xA8,0x8A,0xAE,0xEA,0xA8,0x8A,0xAE,0xEA,0xA8,0x8A,0xAE,0xEA,0xA8,0x8A,0xAE,
     0xEA,0xA8,0x8A,0xAE,0xEA,0xA8,0x8A,0xAE,0xEA,0xA8,0x8A,0xAE,0xEA,0xA8,0x8A,0xAE,0xEA,0xA8,0x8A,0xAE,

0x29,0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,
     0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,

0x29,0xAE,0xAA,0xAA,0xEA,0xAE,0xAA,0xAA,0xEA,0xAE,0xAA,0xAA,0xEA,0xAE,0xAA,0xAA,0xEA,0xAE,0xAA,0xAA,0xEA,
     0xAE,0xAA,0xAA,0xEA,0xAE,0xAA,0xAA,0xEA,0xAE,0xAA,0xAA,0xEA,0xAE,0xAA,0xAA,0xEA,0xAE,0xAA,0xAA,0xEA,

0x29,0xAE,0xAA,0xAA,0xEA,0xAE,0xAA,0xAA,0xEA,0xAE,0xAA,0xAA,0xEA,0xAE,0xAA,0xAA,0xEA,0xAE,0xAA,0xAA,0xEA,
     0xAE,0xAA,0xAA,0xEA,0xAE,0xAA,0xAA,0xEA,0xAE,0xAA,0xAA,0xEA,0xAE,0xAA,0xAA,0xEA,0xAE,0xAA,0xAA,0xEA,

0x29,0xEE,0xAE,0xEA,0xEE,0xEE,0xAE,0xEA,0xEE,0xEE,0xAE,0xEA,0xEE,0xEE,0xAE,0xEA,0xEE,0xEE,0xAE,0xEA,0xEE,
     0xEE,0xAE,0xEA,0xEE,0xEE,0xAE,0xEA,0xEE,0xEE,0xAE,0xEA,0xEE,0xEE,0xAE,0xEA,0xEE,0xEE,0xAE,0xEA,0xEE,

0x29,0xEE,0xAE,0xEA,0xAE,0xEE,0xAE,0xEA,0xAE,0xEE,0xAE,0xEA,0xAE,0xEE,0xAE,0xEA,0xAE,0xEE,0xAE,0xEA,0xAE,
     0xEE,0xAE,0xEA,0xAE,0xEE,0xAE,0xEA,0xAE,0xEE,0xAE,0xEA,0xAE,0xEE,0xAE,0xEA,0xAE,0xEE,0xAE,0xEA,0xAE,

0x29,0xEA,0xAE,0xEE,0xEE,0xEA,0xAE,0xEE,0xEE,0xEA,0xAE,0xEE,0xEE,0xEA,0xAE,0xEE,0xEE,0xEA,0xAE,0xEE,0xEE,
     0xEA,0xAE,0xEE,0xEE,0xEA,0xAE,0xEE,0xEE,0xEA,0xAE,0xEE,0xEE,0xEA,0xAE,0xEE,0xEE,0xEA,0xAE,0xEE,0xEE,

So what is wrong here?

 

From the manual:

 

"Well, I finally found the bug that required a pad byte of 0 at the end of each scan line of data. But, It is actually 2 bugs. I have fixed one of them, but the other requires an extensive change. Too bad, I am out of time. Therefore:

There is a bug in the hardware that requires that the last meaningful bit of the data packet at the end of a scan line does not occur in the last bit of a byte (bit 0). This means that the data packet creation process must check for this case, and if found, must pad this data packet with a byte of all 0s. Don't forget to adjust the offset to include this pad byte. Since this will only happen in 1/8 of the scan lines, it is not enough overhead to force me to try to fix the bug. Sorry."

 

The problem here is that the last bit is 0. So it should not need to be padded with a 0. You could test this by changing all the 0x29 bytes to be 0x2a and adding a byte 0x00 at the end of every line.

 

Edit: of course this is a bug in sp65. The last bit and the last meaningful bit is two different things. So in the case the last bit of the byte at the end of the scanline is in use we need an extra pad byte.

Edited January 26, 2017 by karri

[+karri]

I just pushed the fix to sp65.

 

Here is also a compiled version of your code with the fix in place.

 

 

rpg.zip

[tonma]

I just pushed the fix to sp65.

 

Here is also a compiled version of your code with the fix in place.

 

 

 

Awesome. I'll fix my tools.

[tonma]

New question.

 

I'm making a new game and i wish to use different background in every level.

 

I wish to keep my gameplay for all the game, in game.c for exemple in one segment. And only change graphics segment and SCB_REHV_PAL object when loading new background.

So I'll have something like code between 0x0200 and 0x3800 (segement code) and the graphics bewteen 0x3800 and 0x3D00 (segment graf_lev1) and the graphics bewteen 0x3800 and 0x3D00 (segment graf_lev2)

 

In the start of the game :

lynx_load(GRAF_LEV1);
lynx_load(CODE_GAME);

main_game();

In my main_game function :

extern char background[];  //Segment graf1
extern char background2[]; //Segment graf2

SCB_REHV_PAL sprBG= 
{
  BPP_4 | TYPE_BACKGROUND,	
  REHV | PACKED, 0x00,
  0,
  background,
  0, 0, 0x0100, 0x0100,
  { 0x01,0x23,0x45,0x67,0x89,0xAB,0xCD,0xEF }
};

When I change level, I want to load my level2 above the level1 in memory:

lynx_load(GRAF2_FILENR);
sprBG.data = background2;

Does it make sense?

My game works, but when I add the graf2 semgent, the lynx never throws my main_game function.

Edited February 4, 2017 by tonma

[tonma]

I upload my file. I certainly made a mistake in my segment creation.

Scroll3 works without graf2 segment and scroll2 doesn't work with the graf2 segment. Same code.

scroll.zip

[LX.NET]

I might be wrong here, but I believe that the layout of the "files" on the directory.s have to be in the same order as the ones in the segments of the lynx-coll.cfg. Otherwise the loading of files will not work correctly. One has the order Graf1, Intro, Graf2, whereas the other defines graf1, graf2, Intro.

Give it a try to reorder them.

That's for scroll2 btw

Edited February 4, 2017 by LX.NET

[tonma]

Oh thanks.

 

Fine, I'll test that. I've only take care of the ram not the order.

[tonma]

Wonderful, it's alive.

 

Thanks a lot. It was exactly the problem.