Writing a game sprite driver

[Tigerskunk]

Nice work, McGeezer!



Looks great so far...

[mcgeezer]

Originally Posted by Steril707

Nice work, McGeezer!



Looks great so far...

Thanks buddy!

[mcgeezer]

Sorry for lack of updates on the technical side of the game at the moment, rest assured I'm still working on it.

At the moment I'm knee deep in debugging some very difficult bugs.

Like intermittent, weird crashes... sometimes none crashes.

Very frustrating and time consuming.

Geezer

[saimon69]

On the audio side am working to bring musics to three channels due to feedback, is time consuming too :/

[Nightshft]

Hey McGeezer. This version of bomb jack is just great! What would you have to change to memory layout/hunks to make it compatible with machines with 1MB of chipmem and no fastmem? (like some A600 or A1200). (I'd absolutely love to play it on a physical machine!)

[TroyWilkins]

Wow, fantastic work so far, this has been wonderful to see go from the start to where it is now, I really appreciate you taking the time to post the updates and share with us all how it's progressed. And I've learned from the technical discussion too. Great work!

[mcgeezer]

Originally Posted by Nightshft

Hey McGeezer. This version of bomb jack is just great! What would you have to change to memory layout/hunks to make it compatible with machines with 1MB of chipmem and no fastmem? (like some A600 or A1200). (I'd absolutely love to play it on a physical machine!)

This is now quite high on my list to sort out given I'm nearing the end of development. I'll try and put it in the next Beta as I want it to be OS friendly.

PS - Thanks for the feedback - really appreciate it!

[mcgeezer]

Originally Posted by TroyWilkins

Wow, fantastic work so far, this has been wonderful to see go from the start to where it is now, I really appreciate you taking the time to post the updates and share with us all how it's progressed. And I've learned from the technical discussion too. Great work!

Thanks for your kind words and glad someone has learned from my work. It has been a really enjoyable learning curve for me as well.

[LeCaravage]

Played beta3E version on PAL Amiga 500 KS1.3 + 1,8Mb Fake Fast Ram.
Great experience, addictive game. Played it during 30 mins.

No major bug or crash popped out during this session.
The only disturbing thing is the random/periodic short slow down (during 1 or may be 2 frames?).
May be I'm wrong as I'm not a specialist but, the music sounds way better on real machine (old CRT TV) than on YT.

Great work. Bravo.

Nitpicking : Do you plan to horiz. center game area with monitor border ?

[mcgeezer]

Originally Posted by LeCaravage

Played beta3E version on PAL Amiga 500 KS1.3 + 1,8Mb Fake Fast Ram.
Great experience, addictive game. Played it during 30 mins.

No major bug or crash popped out during this session.
The only disturbing thing is the random/periodic short slow down (during 1 or may be 2 frames?).
May be I'm wrong as I'm not a specialist but, the music sounds way better on real machine (old CRT TV) than on YT.

Great work. Bravo.

Nitpicking : Do you plan to horiz. center game area with monitor border ?

Wow - thanks very much for the great feedback!

The slow downs are caused by too many sprites on screen at the same time, the code still needs to be optimised so with a bit of luck I'll be able to get it running smooth with 10 enemies (like the arcade).

I wasn't aware the display was not centered, are you able to take a photo for me so I can align it?

Thanks,
mcgeezer

[Samurai_Crow]

Originally Posted by mcgeezer

Wow - thanks very much for the great feedback!

The slow downs are caused by too many sprites on screen at the same time, the code still needs to be optimised so with a bit of luck I'll be able to get it running smooth with 10 enemies (like the arcade).

I wasn't aware the display was not centered, are you able to take a photo for me so I can align it?

Thanks,
mcgeezer

Sprites 7 and 8 stop working when you center the screen.

[LeCaravage]

I noticed this periodic short slow down occurs even in the title screen or when there's only one ennemy. Must check if it's also there in WinUAE though.

Edit : Just tested it on WinUAE (Amiga 500 KS1.3 512Kb CHIP + 512KbF. Fast) and the same slow down is present.

Here is the photo of the decentered screen :

[Samurai_Crow]

Originally Posted by LeCaravage

I noticed this periodic short slow down occurs even in the title screen or when there's only one ennemy. Must check if it's also there in WinUAE though.

Here is the photo of the decentered screen :

Ah! So it's the right border that needs trimming! That's better! Those sprites only go away when you trim the left border.

[mcgeezer]

Originally Posted by LeCaravage

I noticed this periodic short slow down occurs even in the title screen or when there's only one ennemy. Must check if it's also there in WinUAE though.

Edit : Just tested it on WinUAE (Amiga 500 KS1.3 512Kb CHIP + 512KbF. Fast) and the same slow down is present.

Here is the photo of the decentered screen :

Moving the display 1 word to the right should not be a problem, I'll check it out on my real Amiga first as well beforehand.

The slowdown is actually caused by the mod playback routine or the music module itself, as of yet I haven't been able to shed much light on it but I might contact PHX and see if he knows what might be going on. The sound is placed on interrupt 3 so it gets priority over everything else - so something in there is stealing frames from the game.

You'll only lose sprites 7/8 if you move the display window down to word $30... at the moment it is at $3c so I probably just need to move it to $3e.

Cheers,
Geezer

[LeCaravage]

Regarding this pb of slow down. May be, if you use in your main program a vertical synch with a BNE you should replace it with a BCS ?

For instance :

.vsync:
move.l $dff004,d0
and.l #$1ff00,d0
cmp.l #250<<8,d0
BNE.b .vsync

replace it with :

.vsync:
move.l $dff004,d0
and.l #$1ff00,d0
cmp.l #250<<8,d0
BCS.b .vsync

The music interrupt the sync just at the edge of 250 and at the return from music to main code the vertical pos is > 250 so the frame is skipped because of the BNE.

[mcgeezer]

Originally Posted by LeCaravage

Regarding this pb of slow down. May be, if you use in your main program a vertical synch with a BNE you should replace it with a BCS ?

For instance :

.vsync:
move.l $dff004,d0
and.l #$1ff00,d0
cmp.l #250<<8,d0
BNE.b .vsync

replace it with :

.vsync:
move.l $dff004,d0
and.l #$1ff00,d0
cmp.l #250<<8,d0
BCS.b .vsync

The music interrupt the sync just at the edge of 255 and at the return from music to main code the vertical pos is > 255 so the frame is skipped because of the BNE.

Holy shit dude! That's exactly what it was! The frame rate is now rock solid!

Thanks you ever so much Le Caravage!

Geezer

[mcgeezer]

Being out of the Amiga game for over two decades means my knowledge of Amiga hardware is very very limited so I know absolutely next to nothing about accelerator cards and the like.

The only real hardware I have at the moment is my A500 which I'm amazed still works.

Anyway, on topic - Bomb Jack crashes when there's an accelerator card in use. It runs fine on stock Amiga 500/600/1200. What I can say is that interrupts are still firing so I can only put it down to invalid ways I access the hardware.

Are there any do's and don'ts that would cause this behavior of crashing when using a fast CPU/accelerator? I'm more than happy to share the code if it helps track down what is going on. I haven't done a whole lot of testing because I just don't have the hardware to try it and I can't reproduce it in WinUAE with a faster CPU configured at 28Mhz.

Any help is really appreciated.

Thanks,
mcgeezer

[Apollo]

Since you say that the interrupts are still firing I assume its not the problem that the interrupt vectors are moved into fastram.

• do you use self modifying code? higher 680x0s have an instruction cache
• do you rely on cpu timing loops?
• maybe a forgotten blitter wait which maybe wasn't a problem on 68000 since the blitter was ready anyway before you fired the next blitter move

[mcgeezer]

Originally Posted by Apollo

Since you say that the interrupts are still firing I assume its not the problem that the interrupt vectors are moved into fastram.

• do you use self modifying code? higher 680x0s have an instruction cache
• do you rely on cpu timing loops?
• maybe a forgotten blitter wait which maybe wasn't a problem on 68000 since the blitter was ready anyway before you fired the next blitter move

Thanks Apollo

There's no self modifying code or CPU timing loops.
I'll double check the blitter waits though - so a good shout.

[Asman]

@mcgeezer
change (mean adapt ) your blitter waits macro to

;-----------------------------------------------------------------------------
;
;in
;	a5 - _custom
;
BLITTERWAIT:	MACRO
		tst.b	dmaconr(a5)
.1\@		btst	#6,dmaconr(a5)
		bne.b	.1\@
	ENDM

;-----------------------------------------------------------------------------

This should help you.