Infinite vertical scrolling

[LuigiThirty]

Oh! I'd have never thought of that. The Copper should be made to update the bitplane pointers just before we hit the visible area, shouldn't it?

Programming the Atari 800's ANTIC is starting to come back to me, hah.

[LuigiThirty]

I found the problem and we both missed it. The frame loop does this every coarse scroll:

for(int i=0;i<NUM_BITPLANES; i++){
	B_BlitTileRow(BPScreen1, levelTileMap, bgTileGraphics, screenPointerRowOffset);
}

...but B_BlitTileRow already takes bitplanes into account:

for(int i=0;i<4;i++){
	for(int column=0;column<20;column++){		
		int tileIndex = tileIndices[rowTilemapOffset + column];
		B_BlitTile_ASM(bitplanes[i], column*16, rowBitplaneOffset, bgTileGraphics[i], tileIndex);
	}
}

So we were doing 320 blits instead of 80. Removed the extra loop and added a WAIT to the Copperlist and it's perfectly smooth now before I do any more optimization.

[phx]

Great you finally found it!

You might want to consider switching to interleaved bitplanes nevertheless. And do some optimizations to the inner core assembler routines, like blit.s. For example replace the mulu #20 with lsl #2 and lsl #4, or better, use a table for all y line offsets on the screeen.

[roondar]

Originally Posted by LuigiThirty

I found the problem and we both missed it. The frame loop does this every coarse scroll:

for(int i=0;i<NUM_BITPLANES; i++){
    B_BlitTileRow(BPScreen1, levelTileMap, bgTileGraphics, screenPointerRowOffset);
}

...but B_BlitTileRow already takes bitplanes into account:

for(int i=0;i<4;i++){
    for(int column=0;column<20;column++){        
        int tileIndex = tileIndices[rowTilemapOffset + column];
        B_BlitTile_ASM(bitplanes[i], column*16, rowBitplaneOffset, bgTileGraphics[i], tileIndex);
    }
}

So we were doing 320 blits instead of 80. Removed the extra loop and added a WAIT to the Copperlist and it's perfectly smooth now before I do any more optimization.

Ah, yes.. That would seem to be a small optimisation on your part
Great that it works now!

That said, I would like to echo PHX's comments about interleaved bitmaps. They do speed up blitting by a sizable margin (especially on slower machines) and are usually worth the small extra memory use.

[DanScott]

Also, with interleaved, you can always blit plane by plane for masked bobs, if you don't want to store the interleaved mask (especially for large objects)

[Samurai_Crow]

Personally, I wouldn't use bitplane interleave for transparent blits. For opaque blits like tiles it is great!

[LuigiThirty]

It took me a while but I've got it all set up for interleaved bitplanes now and can draw my tilemaps much faster It's not much to look at yet but it's really cool to me!

[DanScott]

Originally Posted by Samurai_Crow

Personally, I wouldn't use bitplane interleave for transparent blits. For opaque blits like tiles it is great!

I can't think of anytime i would not use interleaved planes these days

And if you're plotting tiles... then by reason, you are probably going to want to plot masked bobs over the top.. and then also to save and restore the background... for 4 a bitplane screen that's 3 blits (interleaved) compared to 12 (non-interleaved) for each object plotted

[LuigiThirty]

I haven't tried interleaved masked bobs yet but I did figure out how to import maps from Tiled using my tile set and can draw backgrounds of any length! Now I just need to fix my blit routine to use a source tilemap (256x256 4 bitplanes interleaved) of more than 16 tiles...

[DanScott]

Don't forget, you can pre-calculate your tile offsets and store those in the map (rather than a tile index)... there's some other easy and quick optimisations I can see in that ASM tile plotter too

[LuigiThirty]

That's just because I haven't updated the remote repository in a while.

I'm proud of myself for even getting this far considering I've never programmed an Amiga (or owned a real one!) since I bought my A2000 last month or so. I've done some ST stuff, wrote a dinky disk operating system for Easy68K (okay, a console with three or four commands that can run binaries off a floppy disk) a while back - that's all buried somewhere in my Github.

[LuigiThirty]

And here's where we're at now!



I think I'm going to make a cheap River Raid knockoff. No interleaved bobs yet but I've got a 1-color text area now as a status bar. It's magic compared to VGA - just wait for the right scanline and change the bitplane pointers, no mucking with scroll registers or anything. I'm sure 99% of NTSC systems these days can do 320x224...

[LuigiThirty]

So now I'm trying to do cookie-cutter shifted blits onto my interleaved screen and having some trouble getting it working.

Here's the routine I've got that's not working. It draws a squished bob with garbage below it so we're reading past the end of the bitmap data. The modulos are wrong maybe?

destination is a pointer to the start of the visible screen.
source for this example is a 32x32 4-bitplane bitmap (so 32x128 here).

void B_Blit(PLANEPTR destination, int destX, int destY, APTR source, int srcX, int srcY, int sizeW, int sizeH, PLANEPTR oldBackground) {
	
	destY = destY*2; //?
	
	UWORD shift = (destX % 16) << 12;
	UWORD firstwordmask = 0xFFFF >> shift;
	UWORD lastwordmask = 0xFFFF << (16-shift);
	
	int bltW_words = sizeW/16;
	int bltW_bytes = sizeW/8;
	APTR srcPointer = (APTR)((UBYTE *)source + (srcY * (sizeH/16)) + srcX/8);
	APTR destPointer= (APTR)((destination + (destY * SCREEN_WIDTH_WORDS) + destX/8));
	
	//Increase blit size by 1 word to account for shifts. I think these numbers are wrong
	//UWORD sourceSkip = bltW_bytes - 2;
	UWORD destinationSkip = SCREEN_WIDTH_BYTES - bltW_bytes;
	UWORD blitsize = (sizeH << 6) + bltW_words + 1;
	
	BlitWait(); //wait for the blitter to become available
	
	Hardware->dmacon 	= 0x8040; //make sure blit DMA is enabled	
	Hardware->bltcon0	= 0x0FCA | shift; //AB + /AC
	Hardware->bltcon1	= 0x0000 | shift; //shifting the B source
	
	Hardware->bltadat 	= 0x0000; //preload with 0xFFFF for cookie cutting;
	Hardware->bltafwm	= firstwordmask;
	Hardware->bltalwm	= lastwordmask;
	
	Hardware->bltapt	= srcPointer;
	Hardware->bltbpt	= srcPointer;
	if(oldBackground == NULL)
		Hardware->bltcpt= destPointer; //if we don't have a background, use the destination
	else
		Hardware->bltcpt= oldBackground; //if we do have a background, use it
	Hardware->bltdpt	= destPointer;
	
	Hardware->bltamod	= sourceSkip;
	Hardware->bltbmod	= sourceSkip;
	if(oldBackground == NULL)
		Hardware->bltcmod = destinationSkip; //screen size
	else
		Hardware->bltcmod = 0; //we have a background, so don't skip any bytes
	Hardware->bltdmod	= destinationSkip;
	Hardware->bltsize	= blitsize; //execute
}

If I leave out the shifting and cookie cutting, I have a working blit routine for the 32x32 4bpp graphic. This routine draws my bob correctly.

void B_BlitOverwrite(PLANEPTR destination, int destX, int destY, APTR source, int srcX, int srcY, int sizeW, int sizeH) {
	
	destY = destY*2; //?
	
	int bltW = sizeW/16;
	APTR srcPointer = (APTR)((UBYTE *)source + (srcY * (sizeH/16)) + srcX/8);
	APTR destPointer= (APTR)((destination + (destY * SCREEN_WIDTH_WORDS) + destX/8));
	
	//Increase blit size by 1 word to account for shifts
	UWORD sourceSkip = 0;
	UWORD destinationSkip = SCREEN_WIDTH_BYTES - bltW*2;	
	UWORD blitsize = (sizeH << 6) + bltW;
	
	BlitWait(); //wait for the blitter to become available
	
	Hardware->dmacon 	= (UWORD)0x8040; //make sure blit DMA is enabled	
	Hardware->bltcon0	= (UWORD)0x09F0; //D = A
	Hardware->bltcon1	= (UWORD)0x0000;
	
	Hardware->bltadat 	= (UWORD)0x0000;
	Hardware->bltafwm	= (UWORD)0xFFFF;
	Hardware->bltalwm	= (UWORD)0xFFFF;
	
	Hardware->bltapt	= srcPointer;
	Hardware->bltdpt	= destPointer;
	
	Hardware->bltamod	= sourceSkip;
	Hardware->bltdmod	= destinationSkip;
	Hardware->bltsize	= blitsize; //execute
}

[alpine9000]

You need to blit an extra word per line for shifting, and your modulo doesn't reflex this.

If you put the extra word in your bltW_* and fix everything from there it should work.

Also, the last word mask should be 0x0000.

[Pat the Cat]

Eh, LuigiThirty, if you do want to start "hitting the metal" with machine code, there was a series run in Ace magazine, or maybe Amiga Format called "Davy Jones Locker". From the guy that did Menace, I think.

Originally Posted by kamelito

Source code is here : http://amr.abime.net/issue_165_coverdisks Kamelito

and here http://amr.abime.net/issue_164_coverdisks http://amr.abime.net/issue_163_coverdisks

for info coverdisk 40b and 41b covers Bullfrog programming tutorials.

I daresay there are much more recent tutorials than that on the subject, but certainly, a lot of people did such games on the Amiga. Better than a lot of other platforms.

None of 'em used C, as I recall. Not my kind of game though. Some did use AMOS Basic, that's for sure.

But, if you are having success and fun using C, good luck with your endeavour.

What flavour of C are you using?

[LuigiThirty]

Originally Posted by Pat the Cat

Eh, LuigiThirty, if you do want to start "hitting the metal" with machine code, there was a series run in Amiga Format called "Davy Jones Locker". From the guy that did Menace, I think.

I daresay there are much more recent tutorials than that on the subject, but certainly, a lot of people did such games on the Amiga. Better than a lot of other platforms.

None of 'em used C, as I recall. Not my kind of game though. Some did use AMOS Basic, that's for sure.

But, if you are having success and fun using C, good luck with your endeavour.

What flavour of C are you using?

C99 via VBCC. The actual tile blit routine is in 68K along with some other stuff. Basically I'm writing my new graphics routines in C and translating them to ASM for efficiency once they actually work. The game logic is in C.

[LuigiThirty]

Cool, I got it working! Now if I could figure out how to get Grafx2 to spit out a mask layer in the ILBM file I'll be set. I could generate the mask layers on the fly when the image is loaded but I'm sure someone's ran into this before.

[phx]

Originally Posted by LuigiThirty

Cool, I got it working!

What was the problem? These lines definitely look wrong:

    UWORD shift = (destX % 16) << 12;
    UWORD firstwordmask = 0xFFFF >> shift;
    UWORD lastwordmask = 0xFFFF << (16-shift);

"shift" is multiplied by 4096.

Now if I could figure out how to get Grafx2 to spit out a mask layer in the ILBM file I'll be set. I could generate the mask layers on the fly when the image is loaded but I'm sure someone's ran into this before.

Yes, there are certainly various tools for that task. Everybody has their own.

In my last games we were using Gimp to draw the animation phases into a BMP picture and I wrote a portable C program to convert the picture into raw graphics data and masks. bmptoraw.c in Solid Gold (source on Aminet).

[LuigiThirty]

Originally Posted by phx

What was the problem? These lines definitely look wrong:

    UWORD shift = (destX % 16) << 12;
    UWORD firstwordmask = 0xFFFF >> shift;
    UWORD lastwordmask = 0xFFFF << (16-shift);

"shift" is multiplied by 4096.

I meant it works where it doesn't have to do any shifting. The problem with blitting to (0,0) seemed to be the incorrect modulo.