[request] Not exactly an ST port.... Black Tiger Redux?

[Retro-Nerd]

Originally Posted by s2325

Maybe it's possible to use Backbone to redone this game?

Another slow game with unstable fps? No way.

[dlfrsilver]

Originally Posted by StingRay

I like how you conclude that just because something uses 16 color Atari ST degas pictures it is "typical ST port shit"... It's not like the graphics data can easily be converted at runtime to Amiga format...

Anyway, the game is way too slow to be enjoyable, I doubt the ST version is much faster. The binaries are still in Atari ST format and I am checking the code, not sure I can be bothered to do anything with that game though.

What i mean by that is that since the game is ST native, it means no more than 16 colors, when the amiga could have handled IFF 32 colors (maybe 64 colors could be possible ?), that's why it's shitty ! This game uses 256 colors in original, 16 colors that's way too low ! Even 32 colors would be a bit "just" to be honest.....

then, the amiga version has a hidden file table, all those are hidden on the disk,and they have real filenames. I would have been pleased to even disassemble it with resource if i had the possibility to ressource it.

The game is unfortunately a bit faster on ST, sorry to say it. That's because and you will confirm it, that the 68000 code for this game relies mainly on the processor !

Also about the Z80 to 68000 code conversion, this is not possible.
the main reason is that coin-op code programs, either in Z80 code or 68000 code, interleaves code parts with data parts like this :

1) VECTOR TABLE
2) CODE PART
3) DATA PART
4) CODE PART
5) DATA PART

And so on. The tiledata are the data parts, this are like configuration data in order the get the exact sprite sequences. As such, most arcade sprite rips are uncomplete on the sites where you can find them.

I can speak about this matter because i have already fully sipped Final fight arcade sprite data, in order to build full sprites frames for Final Fight AGA (i did DAMND, EDI.E already). From let's say 50 tiles for 1 sprite (ex : BILL BULL, i have been able by looking at the sprite data to build 69 sprites frames !!). A game like final fight arcade can have sprites built from spritedata file as big as 11kb, which is really huge.

I think the z80 code has been converted almost by hand, and Richard Lilley has ripped from the coin-op program code the level datas, because the levels are very faithfull to those of the coin-op minoring the secret places in the walls with bonus items.

To note also that tiledata are based on bytes, where on final fight they are word based.

[Asman]

Originally Posted by saimon69

What i wonder however is why that game run at so crappy 6FPS? OK, st port is not that better, but i wonder if is due to "processor fatigue" or bad programming... maybe the original team DID use the z80->68k tool to convert the code and is not optimized

In my opinion that was bad programming. Lets focus on example from game. Very simple one. Just set colors.

Offset $f4 from BT.PRG

	move.l	#ColorsTable,a0		;20c (ColorsTable offset $ad20)
	move.w	#2,d0			;8c
	trap	#3			;38c
					;sum 66c

handling of trap is stored in AEXEC.PRG (offset $392).

	move.l	a6,-(sp)		;12c
	move.w	#$2000,sr		;12c
	lsl.w	#2,d0			;10c
	move.l	#FncTable,a6		;20c
	add.w	d0,a6			;8c
	move.l	(a6),a6			;12c
	jsr	(a6)			;16c
	move.l (sp)+,a6			;12c
	rts				;16c
					;sum 118c

FncTable:

	dc.l ScreensClearLines
	dc.l SwapScreenPointers
	dc.l SetColors
	...

And the last we have SetColors (offset $90c in AEXEC.PRG)

	move.l a0,someLabel	;20c
	move.l #$dff180,a1	;12c
	move.w #15,d1		;8c
.loop:	move.w (a0)+,d0		;8c
	add.w d0,d0		;4c
	add.w #$111,d0		;8c
	move.w d0,(a1)+		;8c
	dbf d1,.loop		;10c taken (12c not taken - one time )
	rts			;16c
				;sum 666c = 40 + 38*15 + 40 + 16

So total is 850c for such simple routine, which should be take 180c or about 400c when we use typical approach with dbf.

	move.l	#$dff180,a1		;12c
	move.l	#ColorsTable,a0		;20c
	movem.l	(a0),d0-d7		;76c
	movem.l	d0-d7,(a1)		;72c
					;sum 180c

----------------
EDIT

I just checked Atari ST file EXEC.PRG and setColors looks like

SetColors:	move.w	#1,(someLabel).l
.wait:	tst.w	(someLabel).l
	bne.b	.wait
	move.l	#$FFFF8240,a1
	move.w	#15,d1
.loop:	move.w	(a0)+,d0
	move.w	d0,(a1)+
	dbra	d1,.loop
	rts

Faster then Amiga version - but still slow as hell.

Edit2: Just to be sure, trap and handling of trap is same as in on Amiga, mean total cycles counts will be 66 + 118 + about 500 = about 700 cycles.

[dlfrsilver]

Pffff..... everything is said here. I wonder if the coder was an ST fanboy....

[Asman]

In the zone I put package BlackTiger.zip. Package contains. Atari ST files, Amiga Files, some Image to compare Arcade and Amiga version and little proggy with C sources for visual c++ 2008 express (cross compiled with vbcc) to extract files from disk to real files ( tested on WinUAE with black tiger ipf in df0: ). Package contains partially resourced amiga executable files: bootblock, aexec (start address is $A500), bt (start address is $D2D8). Above resourced files may contains something wrong and need more work.
Any comments welcome.

[dlfrsilver]

I have found the copy protection routine in lbC003172 hehe

sync $4124 (looks like the usual gremlin protection track....)

So far, no sign of any Blitter or copper routine, only pure 68000 code (Pfff !)

EDIT : found LINK and UNLK, so it also use C code

EDIT : Absolutely no use of any hardware register for the GFX, sound, music ! Only DFFXXX Interrupt request, VHPOSR, and 2 others.

The amiga is almost used like if it was an Atari ST, minor the few amiga specific regs, feck !

I understand why the whole bloated thing runs at 6 frames per sec ! The problem is the amount of time needed to work out the ST screen routines and convert those to blitter assisted routines.....

[Retro1234]

If the game was totaly cpu dependant couldnt it run faster on higher CPUs -as a nice side affect?

[leathered]

Originally Posted by Boo Boo

If the game was totaly cpu dependant couldnt it run faster on higher CPUs -as a nice side affect?

I tried this on 030 and via emulation using 'fastest possible'. Under emulation it was drastically faster, although it scrolls much quicker than the arcade. On 030 it was playable but still jerky.
It looks like the scroll updates 8 pixels, but not at every frame (or even 2).
The scrolling is very staccato, around 4-8 fps I reckon.

[Retro1234]

When I looked at the Arcade version I just thought how much quicker the sprite animations looked.

[dlfrsilver]

@Boo Boo : "If the game was totaly cpu dependant couldnt it run faster on higher CPUs -as a nice side affect? ".

Well it could but it's not on my A1200 @030, it's not that faster, plus under whdload it trigger an access fault when you jump

The arcade version runs at 60 fps, this is so uncomparable....

[StingRay]

Originally Posted by dlfrsilver

then, the amiga version has a hidden file table, all those are hidden on the disk,and they have real filenames. I would have been pleased to even disassemble it with resource if i had the possibility to ressource it.

And what exactly is the reason you couldn't disassemble it? Ripping the files is trivial as the directory format is extremely simple. Also, how did you compare the code then?

Originally Posted by Asman

In my opinion that was bad programming. Lets focus on example from game. Very simple one. Just set colors.

I beg to disagree. As long as the low-level code is not called every frame the trap approach isn't that bad. It makes it quite simple to port the game to different machines since only the low-level code has to be adapted.

Originally Posted by dlfrsilver

Pffff..... everything is said here. I wonder if the coder was an ST fanboy....

Of course he was... Because that's what you want to believe anyway.

Originally Posted by dlfrsilver

I have found the copy protection routine in lbC003172 hehe

Big deal, the protection routine is neither interesting nor hard to find. It's the least interesting part of the whole game.

[dlfrsilver]

@Sting : I could not rip the files because i'm not used at all to do that.

Well after going on the ressourced BT.PRG, i have not seen any hardware register for Blitter, nor scrolling. This game relies only on the main processor to deal with display.
To me it's the equivalent to R-type CPC (the CPC version is an emulation of the spectrum version), Black tiger Amiga is almost an emulation of the atari ST version.

About what i said about "ST fanboy". Just tell me how a coder could be good at coding in 68000 on an ST, and being bad at coding in 68000 for the amiga ?

Note also that the coder was whining about "We could do a 32 colors version, but it would means redrawing the graphics from scratch which would take ages. If we'd done the amiga version first then we'd probably have used 32 colors and cut them down to 16 for the ST - It's something we're bearing in mind for the future.".
The game was sold on ST for 19.99 pounds on 2 disks, and for 24.99 pounds for amiga on 1 disk.

This reminds me that we had to pay more for a game on amiga that was most of the time an ST port.

Oh well.

About the copy protection, yep, i saw it, so i just posted

In the same vein, you have the rainbow islands case. Have seen some coin-op screens, the game display is in 32 colors.
But Steve Turner & A. Braybrook said in an interview, that he couldn't use 32 colors, because he didn't have the computing time to trace the 5th bitplan (minoring the fact that he rewrote the display routine to use the blitter).

[Havie]

Have never played this on the Amiga - had a go today and it is shockingly bad; slow, jerky and poor colours. Looks like there's a good game hiding in there somewhere but needs more speed and better scroll (graphics I could live with). Would be impressed to see an Amiga specific version.

[Asman]

Originally Posted by StingRay

I beg to disagree. As long as the low-level code is not called every frame the trap approach isn't that bad. It makes it quite simple to port the game to different machines since only the low-level code has to be adapted.

Your post make me to rethink what I'm posted and I still think why they used

move.w #RoutineNumber,d0
trap #3

Instead of just

jsr Routine

Which is much simpler for me and more obvious then trap.

And what you mean when you write low-level code ? What kind of routines you mean ? Thank you.

[Galahad/FLT]

Originally Posted by Asman

Your post make me to rethink what I'm posted and I still think why they used

move.w #RoutineNumber,d0
trap #3

Instead of just

jsr Routine

Which is much simpler for me and more obvious then trap.

And what you mean when you write low-level code ? What kind of routines you mean ? Thank you.

I think what Stingray means is code that isn't game speed critical.

Setting up a screen one time outside of a main game loop, or inserting colours into registers, disabling the audio filter, these are all low level routines, they are not time critical, they do the job required, and thats enough.

If any of these routines were to be in a main game loop (i.e. constantly refreshing colour registers etc), then that would be an issue and better code or optimization would be in order.

[dlfrsilver]

Well does it really matter since the game makes no use of the hardware registers for display, gfx or even sound ? That's why everything is slow

[Retro1234]

Silly question im sure - I guess there is some kind of blitter wait so no matter what speed the Amiga is the game is about the same - What about the Atari ST version if this was run on a Atari ST 68060 would it not run super fast.

[dlfrsilver]

i have traced thru the whole code Boo Boo, there is no blitter access in anyway in the game code of Amiga Black Tiger. no blitter wait, everything is software driven by the 68000.

[vulture]

On a related note, the game plays a bit better (faster/smoother) if you set the ntsc tooltype at whdload. Which is not a surprise, but I thought I'd mention it anyway.

[Asman]

Thanks Galahad for explanation.