English Amiga Board


Go Back   English Amiga Board > Main > Amiga scene

 
 
Thread Tools
Old 29 August 2014, 22:18   #21
Retro-Nerd
Missile Command Champion

Retro-Nerd's Avatar
 
Join Date: Aug 2005
Location: Germany
Age: 45
Posts: 10,745
Quote:
Originally Posted by s2325 View Post
Maybe it's possible to use Backbone to redone this game?
Another slow game with unstable fps? No way.
Retro-Nerd is offline  
AdSense AdSense  
Old 30 August 2014, 15:16   #22
dlfrsilver
CaptainM68K-SPS France
dlfrsilver's Avatar
 
Join Date: Dec 2004
Location: Melun nearby Paris/France
Age: 40
Posts: 7,175
Send a message via MSN to dlfrsilver
Quote:
Originally Posted by StingRay View Post
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.

Last edited by dlfrsilver; 30 August 2014 at 15:25.
dlfrsilver is offline  
Old 30 August 2014, 20:07   #23
Asman
68k

Asman's Avatar
 
Join Date: Sep 2005
Location: Somewhere
Posts: 628
Quote:
Originally Posted by saimon69 View Post
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
Code:
	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).
Code:
	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)
Code:
	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.
Code:
	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

Code:
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.

Last edited by Asman; 30 August 2014 at 22:26.
Asman is offline  
Old 30 August 2014, 22:20   #24
dlfrsilver
CaptainM68K-SPS France
dlfrsilver's Avatar
 
Join Date: Dec 2004
Location: Melun nearby Paris/France
Age: 40
Posts: 7,175
Send a message via MSN to dlfrsilver
Pffff..... everything is said here. I wonder if the coder was an ST fanboy....
dlfrsilver is offline  
Old 31 August 2014, 00:56   #25
Asman
68k

Asman's Avatar
 
Join Date: Sep 2005
Location: Somewhere
Posts: 628
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.
Asman is offline  
Old 31 August 2014, 02:07   #26
dlfrsilver
CaptainM68K-SPS France
dlfrsilver's Avatar
 
Join Date: Dec 2004
Location: Melun nearby Paris/France
Age: 40
Posts: 7,175
Send a message via MSN to 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.....

Last edited by dlfrsilver; 31 August 2014 at 03:07.
dlfrsilver is offline  
Old 31 August 2014, 06:19   #27
Retro1234
5150

Retro1234's Avatar
 
Join Date: Jun 2006
Location: Sycophantazia
Posts: 3,777
If the game was totaly cpu dependant couldnt it run faster on higher CPUs -as a nice side affect?
Retro1234 is offline  
Old 31 August 2014, 13:22   #28
leathered
Registered User

leathered's Avatar
 
Join Date: Oct 2011
Location: UK
Age: 41
Posts: 304
Quote:
Originally Posted by Boo Boo View Post
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.
leathered is offline  
Old 31 August 2014, 14:16   #29
Retro1234
5150

Retro1234's Avatar
 
Join Date: Jun 2006
Location: Sycophantazia
Posts: 3,777
When I looked at the Arcade version I just thought how much quicker the sprite animations looked.

Last edited by Retro1234; 31 August 2014 at 14:23.
Retro1234 is offline  
Old 31 August 2014, 14:40   #30
dlfrsilver
CaptainM68K-SPS France
dlfrsilver's Avatar
 
Join Date: Dec 2004
Location: Melun nearby Paris/France
Age: 40
Posts: 7,175
Send a message via MSN to 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....
dlfrsilver is offline  
Old 31 August 2014, 14:59   #31
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 5,591
Quote:
Originally Posted by dlfrsilver View Post
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?


Quote:
Originally Posted by Asman View Post
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.


Quote:
Originally Posted by dlfrsilver View Post
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.


Quote:
Originally Posted by dlfrsilver View Post
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.
StingRay is offline  
Old 31 August 2014, 15:57   #32
dlfrsilver
CaptainM68K-SPS France
dlfrsilver's Avatar
 
Join Date: Dec 2004
Location: Melun nearby Paris/France
Age: 40
Posts: 7,175
Send a message via MSN to 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).

Last edited by dlfrsilver; 31 August 2014 at 16:36.
dlfrsilver is offline  
Old 31 August 2014, 20:46   #33
Havie
Registered User
 
Join Date: Mar 2012
Location: UK
Posts: 261
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.
Havie is offline  
Old 31 August 2014, 21:08   #34
Asman
68k

Asman's Avatar
 
Join Date: Sep 2005
Location: Somewhere
Posts: 628
Quote:
Originally Posted by StingRay View Post
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
Code:
move.w #RoutineNumber,d0
trap #3
Instead of just
Code:
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.
Asman is offline  
Old 01 September 2014, 02:20   #35
Galahad/FLT
Going nowhere

Galahad/FLT's Avatar
 
Join Date: Oct 2001
Location: United Kingdom
Age: 44
Posts: 6,604
Quote:
Originally Posted by Asman View Post
Your post make me to rethink what I'm posted and I still think why they used
Code:
move.w #RoutineNumber,d0
trap #3
Instead of just
Code:
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.
Galahad/FLT is offline  
Old 01 September 2014, 04:09   #36
dlfrsilver
CaptainM68K-SPS France
dlfrsilver's Avatar
 
Join Date: Dec 2004
Location: Melun nearby Paris/France
Age: 40
Posts: 7,175
Send a message via MSN to 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
dlfrsilver is offline  
Old 01 September 2014, 10:44   #37
Retro1234
5150

Retro1234's Avatar
 
Join Date: Jun 2006
Location: Sycophantazia
Posts: 3,777
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.
Retro1234 is offline  
Old 01 September 2014, 11:37   #38
dlfrsilver
CaptainM68K-SPS France
dlfrsilver's Avatar
 
Join Date: Dec 2004
Location: Melun nearby Paris/France
Age: 40
Posts: 7,175
Send a message via MSN to 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.
dlfrsilver is offline  
Old 01 September 2014, 13:13   #39
vulture
Registered User
 
Join Date: Oct 2007
Location: Athens , Greece
Posts: 685
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.
vulture is offline  
Old 01 September 2014, 16:35   #40
Asman
68k

Asman's Avatar
 
Join Date: Sep 2005
Location: Somewhere
Posts: 628
Thanks Galahad for explanation.
Asman is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Black Tiger anata project.Maptapper 1 19 September 2013 08:24
Mace vs. Black Tiger Kodoichi Nostalgia & memories 35 13 April 2011 14:32
Black Tiger Uncle Micko support.Games 6 07 October 2007 04:13
Black Tiger NES NfernalNfluence Retrogaming General Discussion 3 08 May 2007 16:48
[Fixed] Black Tiger dev. haynor666 HOL data problems 2 08 July 2003 09:41

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 15:03.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.38186 seconds with 11 queries