Outrun with frame counter

[FedePede04]

Hi
i have always curious about how many frames outrun was running at.
so i have add a frame counter to Outrun

I go help with the dissembling from Michael Lynn (mlynn1974) ... I have never learn to dissembling so i am so lost in this array

Btw forgot to capture the music and sound so i have add one of my own versions from my outrun new year demo...

[Cyprian]

nice,
would be possible to modify a bit source code to boost a frame rate?

[FedePede04]

nice,
would be possible to modify a bit source code to boost a frame rate?

Thx
i have found a couple of arrays that for sure can be optimized, but i have no ideas how much speed it will provide.

[mlynn1974]

Thanks for the mention Peter!
With Outrun on the ST the road is nice and wide and the sprites scale OK. It's just a bit choppy. I think the ST game engine was written by Ian Morrison (Ice Software) and it was later improved for other road games i.e. Turbo Outrun, Chase HQ 2 and Hydra. There might be some room for improvement.

[mlynn1974]

I have written a program in C# to convert the graphics in FTB format to PI1 for easy editing.

The format is:
Width in words (2 bytes)
Height in pixels (2 bytes)
{Data} : 2 bytes per plane
i.e. word 0: plane 0, plane 1, plane 2, plane 3, word 1: plane 0, plane 1, plane 2, plane 3 etc.

I have yet to write a program to convert the graphics from PI1 back to FTB.

Attached is the PI1 edited in Grafx2 on Windows. The palette is from level 1.
bigtree.ftb is the largest sprite 64x134. I have quickly retouched the Ferrari to get rid of those grey lines and put a proper arcade style white number plate on it.

This would give us the opportunity to improve the graphics without rewriting any of the code!

[FedePede04]

Thanks for the mention Peter!
With Outrun on the ST the road is nice and wide and the sprites scale OK. It's just a bit choppy. I think the ST game engine was written by Ian Morrison (Ice Software) and it was later improved for other road games i.e. Turbo Outrun, Chase HQ 2 and Hydra. There might be some room for improvement.

that was the least i could do, and many thanks again.

I have written a program in C# to convert the graphics in FTB format to PI1 for easy editing.

The format is:
Width in words (2 bytes)
Height in pixels (2 bytes)
{Data} : 2 bytes per plane
i.e. word 0: plane 0, plane 1, plane 2, plane 3, word 1: plane 0, plane 1, plane 2, plane 3 etc.

I have yet to write a program to convert the graphics from PI1 back to FTB.

Attached is the PI1 edited in Grafx2 on Windows. The palette is from level 1.
bigtree.ftb is the largest sprite 64x134. I have quickly retouched the Ferrari to get rid of those grey lines and put a proper arcade style white number plate on it.

This would give us the opportunity to improve the graphics without rewriting any of the code!

don't spend to much time on it right now, i don't have the time for this project at the moment, i have started working on Enduro Racer again.
but i will have a go on this later on, when i have some time, i also think that i can do many of the same thing that i have done on Enduro Racer.
(like blitter sample sound)

so i don't want you to wast your time on a project that maybe not going to happen
but one ting when you convert you graphic, would it be a good idea to store the width and height, so it easier when you converted it back, or that's maybe not a problem.

btw, I did do some optimization on the print road routine, it still need some work before its finish, and its not much speed it have giving so fare

[FedePede04]

ok, i do know that i said that i did not have time to work on this project at the moment. but i have been looking at the code the last couple of days.

here is a point that maybe could be interesting for some...
there have been a lot of talk of that the Amiga was a lazy Atari port.
at one point DML was out and say the the Atari ST was ported from the Amiga(he worked at the game).
i have have found something that is proving the point or point in that directions , i can't say it for sure right now, but nonetheless interesting.

After the horizon graphic have been loaded, it is being converted from the Atari interleaved format to the Amiga ACBM bitplane format.
and the are no reason for doing this, plus it make the Atari slower to output the graphic, due to, that you can only output single words.

i have not been looking on the object output routine yet, so i will update the thread if i find more evidence that support this clam.
i will update this post with the horizon printing routine so you self can see it

[FedePede04]

ok here is the original mountain routine, i have only taken the scroll left and the print routine

Code: Select all

ScrollLeft:
                  NEG.W     D1
                  MOVEA.L   4(A6),A1
                  ADDA.W    #$28,A1
                  CMPI.W    #$11,D1
                  BCS.S       L0113
                  MOVE.W    #$10,D1
L0113:        MOVEQ     #3,D5
L0114:        MOVEA.L   A1,A2
                  MOVE.W    2(A6),D0
L0115:        MOVEA.L   A1,A0
                  MOVEQ     #9,D4
                  CLR.L       D2
L0116:        MOVE.W  -(A1),D2
                  MOVE.W  D2,D3
                  SWAP      D3
                  ROL.L     D1,D2
                  MOVE.W  D2,(A1)
                  MOVE.W  -(A1),D3
                  MOVE.W  D3,D2
                  SWAP      D2
                  ROL.L      D1,D3
                  MOVE.W   D3,(A1)
                  DBF         D4,L0116
                  ADDA.W   #$50,A1
                  CLR.W     D2
                  ROL.L      D1,D2
                  OR.W       D2,-(A0)
                  DBF          D0,L0115
                  MOVEA.L  A2,A1
                  ADDA.W   #$1900,A1
                  DBF         D5,L0114
L0117:            RTS
;----------------------------------------------------------------------

;----------------------------------------------------------------------
PR_MOUNT:       
        BSR         L010C
                  MOVE.W  HORIZON,D2
                  MOVE.W  2(A6),D0
                  SUB.W     D0,D2
                  MOVE.W  D2,TOPY
                  MOVE.W  MAXYOM,D1
                  SUB.W    D2,D1
                  BHI.S      L0119
                  ADD.W    D1,TOPY
                  BRA        L011D
L0119:        CMP.W    D1,D0
                  BCS.S     L011A
                  MOVE.W    D1,D0
L011A:        MULU      #$A0,D2
                  ADD.L     LOG_SCR,D2
                  MOVEA.L   D2,A0
                  MOVEA.L   4(A6),A1
                  MOVEA.L   A1,A2
                  MOVEA.L   A1,A3
                  MOVEA.L   A1,A4
                  ADDA.W    #$1900,A2
                  ADDA.W    #$3200,A3
                  ADDA.W    #$4B00,A4
L011B:        MOVEQ     #9,D1
L011C:        MOVE.W    (A1)+,(A0)+
                  MOVE.W    (A2)+,(A0)+
                  MOVE.W    (A3)+,(A0)+
                  MOVE.W    (A4)+,(A0)+
                  MOVE.W    (A1)+,(A0)+
                  MOVE.W    (A2)+,(A0)+
                  MOVE.W    (A3)+,(A0)+
                  MOVE.W    (A4)+,(A0)+
                  DBF       D1,L011C
                  DBF       D0,L011B
L011D:            RTS


[FedePede04]

and here is my first optimize code:

Code: Select all

;------------------------------------------------------------
;         Move Moutain to the left
;------------------------------------------------------------
MoveMoutainLeft:           
            Move.l   4(A6),A0      ; Y offset In Mountain Clip Art
            Neg.w   D1
            Cmp.w   #$11,D1
            Bcs.s   L010E
            Moveq   #$10,D1
            
L010E:           
            Lea      160(A0),A0
            Move.w   2(A6),D7   ;    Height
L0110:           
            Move.l   A0,A1
            Moveq   #19,D0
            
            
            Moveq   #0,D2
            Moveq   #0,D3
            Moveq   #0,D4
            Moveq   #0,D5
ScollLoop:      
;-bp1
            Moveq   #0,D6
            Move.w   -(A1),D6
            Swap   D6
            Ror.l      D1,D6
            Or.w      D6,D2   
            Move.w   D2,(A1)
            Swap   D6
            Move.w   D6,D2

;-bp2
            Moveq   #0,D6
            Move.w   -(A1),D6
            Swap   D6
            Ror.l         D1,D6
            Or.w          D6,D3   
            Move.w   D3,(A1)
            Swap   D6
            Move.w   D6,D3
;-bp3
            Moveq   #0,D6
            Move.w   -(A1),D6
            Swap   D6
            Ror.l      D1,D6
            Or.w      D6,D4   
            Move.w   D4,(A1)
            Swap   D6
            Move.w   D6,D4
;-bp4
            Moveq   #0,D6
            Move.w   -(A1),D6
            Swap   D6
                Ror.l   D1,D6
            Or.w   D6,D5   
            Move.w   D5,(A1)
            Swap   D6
            Move.w   D6,D5
            
            
            
            Dbra   D0,ScollLoop      
            
            Or.w   D2,-2(A0)      
            Or.w   D3,-4(A0)      
            Or.w   D4,-6(A0)      
            Or.w   D5,-8(A0)      
            
            Lea      160(A0),A0
            Dbra   D7,L0110      
            
            
            Rts
    
;----------------------------------------------------------------------
;         Printer Horizont
;----------------------------------------------------------------------
PR_MOUNT:       
            Lea      MountainHeader,A6
            Move.w   MOUNT_NO,D0
 
            Lsl.w   #3,D0
            Add.w   D0,A6

            Move.w   HORIZON,D2
            Move.w   2(A6),D0
            Sub.w   D0,D2
            Move.w   D2,TOPY
            Move.w   MAXYOM,D1
            Sub.w   D2,D1
            Bhi.s   L0119
            Add.w   D1,TOPY
            Bra      L011D
L0119:         
            Cmp.w   D1,D0
            Bcs.s   L011A
            Move.w   D1,D0
L011A:         
;----------------------------------------------------------------------
            Lsl.w   #5,D2      ;Mul160
            Move.w   D2,D1
            Lsl.w   #2,D2
            Add.w   D1,D2
;----------------------------------------------------------------------

            Move.l   LOG_SCR,A0
            Add.w   D2,A0   
            Move.l   4(A6),A1
            
;   Printer Mountain
L011B:         
            Movem.l   (A1)+,D2-D7/A2-A3
            Movem.l   D2-D7/A2-A3,(A0)
            Movem.l   (A1)+,D2-D7/A2-A3
            Movem.l   D2-D7/A2-A3,32(A0)
            Movem.l   (A1)+,D2-D7/A2-A3
            Movem.l   D2-D7/A2-A3,64(A0)
            Movem.l   (A1)+,D2-D7/A2-A3
            Movem.l   D2-D7/A2-A3,96(A0)
            Movem.l   (A1)+,D2-D7/A2-A3
            Movem.l   D2-D7/A2-A3,128(A0)

            Lea      160(A0),A0
            Dbf      D0,L011B
L011D:         RTS


Here is the code about in text format only the code about i just a bit nicer in the tabs....

Outrund source code.txt

[mlynn1974]

That's a nice find! Does it improve the frame rate?

It's possible that the Amiga version was started at the same time and they shared some graphics, but the Amiga version wasn't released until a year after the ST. DML worked at Ice Software on Chase HQ 2 long after Outrun had been released and the game engine had probably been improved for Turbo Outrun and Hydra before getting to Chase HQ 2.

I am thinking about the road map and the road drawing code. In an interview with Iain Morrison I think I read about way points and that the road is interpolated from these points. In some respects it reminds me of Nightmare Rally and Outrun on the Spectrum. The game is choppy because of the low frame rate and\or a high step rate going through the map, or the road is very low resolution to save memory. I don't understand the code enough to say if it's going through the map faster (e.g. step+=7) because of the low frame rate or if that's the full resolution of the map. If the frame rate was improved could the step rate could be reduced to improve smoothness?

The original Outrun road and map is large and detailed (see Cannonball) and would require too much CPU time to render on an ST.

[FedePede04]

I have been optimized some of the code the last couple of days, I can't see much improvement yet :'(
i even replaces the horizon code, with a blitter draw routine, i have also optimize the line on the road, and some of the print object routine. but still around the same frame.

if i turning off all the object draw, it will maxium hit 16fps, but is between 12-16 fps, so i wonder what takes all the time.
but i have to look more at the code to understand what happen in it.

in the vbi routine they have a system, that show how long it takes to render a routine so that game run after this. but i have not figure it out yet, maybe there is a smarter way top do this, but that have to come later, not main goal it to get some more fps.

if at one point we change the graphic, we need to do something more with the car, the lady looks bald
maybe we could replaces the car with the original one

[Cyprian]

you can analyze the code with Hatari Profiler and generate a nice graphs
https://hatari.tuxfamily.org/doc/manual.html

[FedePede04]

you can analyze the code with Hatari Profiler and generate a nice graphs
https://hatari.tuxfamily.org/doc/manual.html

thanks for the link to the manual.
i will try to take a look later on, to see if its something that i can figure out, there are still many thing that can easy be optimize
Right now i am in the process of learning the print object code, and it look like that i can gain some good speed
can probably also gain some on the OSD.

[wongck]

Wow such amazing stuff.... reverse engineering it and optimising it.... truly amazing.

[Hazzardus]

Wow, never would have thought back in the day it was actually that slow. Used to really enjoy playing it on my ST and thought it was almost arcade perfect, same with Double dragon, until I got home from a week at Pontins where most of my money was spent on those two games. Never got over it after that. How bad the ports of both of those games were never hit me before because I was used to 8bit, and the ST was 16BIT POWER!!! Just like the Arcades

Super Hang-On still stands up as a decent early port though, so did Space Harrier 1.

I did pay full price for Line of Fire when that came out, as I loved the arcade so much

[FedePede04]

one place i think i found some that can give some speed, is the string routine.
I turn it off, and the frame raise about 2 fps.
of cause the new one will also take some time, but not 2 frames

i will look at it more closely at it, tonight and tomorrow , and also on the print object routine, and see if i can make the blitter do the work

[FedePede04]

one place i think i found some that can give some speed, is the string routine.
I turn it off, and the frame raise about 2 fps.
of cause the new one will also take some time, but not 2 frames

i will look at it more closely at it, tonight and tomorrow , and also on the print object routine, and see if i can make the blitter do the work

ok i must have been drunk, when i wrote this, the string routine did not take 2 fps, but it took a good amount of times

The Red raster is the old string routine its printing the score and Time Lab.

In the new one, is blue raster color is for the Score printing
and the green one is the Time Lab...

STeem.jpg

btw don't mind the mess on the screen, i am in the process of changing the OSD to it look more like the arcade version...

[Cyprian]

thats alot of CPU time.
is it only conversing string process or also print them on the screen?

[FedePede04]

thats alot of CPU time.
is it only conversing string process or also print them on the screen?

no it both conversing and printing, but i have never seen so a complicate string routine.
it would probably be ok in a text program, but wast of time in game.

right now i am not using the blitter for 8x8 char, do you think it would be an advantage to use the blitter for 8x8 chars?

[dhedberg]

Wow. So sad to see how poorly crafted a lot of the games were. Seems like almost no time or thought was spent on design and optimization of code.

[Cyprian]

right now i am not using the blitter for 8x8 char, do you think it would be an advantage to use the blitter for 8x8 chars?

it depends on how source data are organized, how many bitplanes should be touched and whether source should be masked with destination.
In case of the sky, if I'm not wrong it is always blue, therefore there is no need to do masking there, and just do straight copy.

[FedePede04]

funny some of the code look ok optimized, like they are using Branch .s and moveq and so on, but there are really also some stupid things going on. (i have only seen the top of the iceberg)

(not sure about this) but It look like there are also some clever thing in it. the information about the object height and width is included in the object, so i think it would be pretty easy to replaces the object with others and the game would still work.

but i think that it was more impotent to get the game out of the door, instead of make it to run good, plus if they did optimized after, the would be a risk of insert a lot of new errors. and last maybe they not the best coders in the first places
and when i am done, i am sure that some could probably optimize ever further

[FedePede04]

right now i am not using the blitter for 8x8 char, do you think it would be an advantage to use the blitter for 8x8 chars?

it depends on how source data are organized, how many bitplanes should be touched and whether source should be masked with destination.
In case of the sky, if I'm not wrong it is always blue, therefore there is no need to do masking there, and just do straight copy.

right now they are "and" and "or" with the background, i have been thinking the same to just copy it to the screen.
it will also depend, if some of the object will be replaces, with higher objects.
so for time be, i will let it be as it is.

But i was thinking if there was any speed advantages using the blitter, on really small object.
there was not scrolled / skewed
i have not used the blitter so much yet, so i don't know all its advantages and disadvantages.
but from what i would think, its not here to get the big gained, but i could be wrong.

my print loop for a single char look some thing like this.

Code: Select all

         
A0 is the pointer to the mask
A4 pointer to the graphic
A5 Screen pointer         
            Moveq   #7,D6
SingleCharLoop:
            Move.w   (A0),D4
            Swap   D4
            Move.w   (A0)+,D4
            Movep.l   (A5),D5
            And.l   D4,D5
            Or.l      (A4)+,D5
            Movep.l   D5,(A5)
            Lea      160(A5),A5
            Dbra   D6,SingleCharLoop


[Cyprian]

the BLiTTER is word oriented, therefore when a source data are also word oriented then it could be faster.

In your case, a source data (mask and 8x8 chars) are byte oriented. In that case we have to do two blits - the first one for even source data (with skew 0) and the second one for odd source data (with skew 8 ). Therefore in that case the BLiTTER could be slower.

[FedePede04]

thanks
it also the conclusion that i came to, but i had to asked one that know this stuff, and i know that you have been working with the blitter for a long time.
i also think its better to save the blitter for the Object and the road

thanks again