calimero wrote:Do not spent time on PC version; there are already World of Tanks
It's not the same fun to play with 6 players on a 2D game on the same computer than to play with 50 distant players on a 3D game.
Everybody, even who never play to video game, can immediately play to Dynabuster or Tankblaster but how long to play to World of tank ?
calimero wrote:Btw what is "auto generated sprite routine"?
And how it speeds up "graphic display of Falcon is slow."?
It's is a demomaker technic give to me by Axel Follet / MCS (Megatracker author) than I was to the university with him.
Generic display code move 1 pixel by one pixel from an memory address to another address memory.
If the sprite to display have a large size it's take a long time. What is more a pixel take 2 byte in 16 bits mode.
The solution is to convert the sprite to show to a series of "move" from an memory address to another. One move per pixel. So there is no sprite stored in memory but only code.
At 16 Mhz 1 cycle of CPU is 1/16000000 s = 62.5 * 10^-9 s = 62.5 ns
To do 60 frames per second (to have a fluid display) you only have 1/60 = 0.0167 second !
To do 30 frames per second you only have 1/30 = 0.0333 second !
So all the sprite must be displayed in less than 0.0333 second.
Imagine you have 4 pixels to display. In 68000 in 16 bits bits that's do 2 long = 4 words = 16 bits :
A generic display (get and put in GFA basic, C, or basic assembler) of sprite do something slow like :
move.w (a0)+,(a1)+
bcc <label>
that's take : 12 cycles of CPU (at 16 Mhz) by move.w + 10 cycle by bcc !!!
= 12 * 4 + 10* 4 => 88 cycle of CPU only for 4 pixel. Impossible to a fluid game with that.
move.w means move 1 word = 1 pixel.
bcc is jump function who have to handle width and height of the sprite to show but which take a lot of time.
So you be quick you have to not use jump command ! For that you must know all pixel of you sprite and only display than without have to calculate them width and height with "jump" function. In reality it is worst than that because high level language use a lot of function to show one pixel.
It could be better with a serie of move :
move.w (a0)+,(a1)+
move.w (a0)+,(a1)+
move.w (a0)+,(a1)+
move.w (a0)+,(a1)+
Which take 12x4=48 cycle of CPU for 4 pixels .
=> Only 2 times quicker than generic display !!!
Better use a serie of move.w. 1 move.w = 1 pixel :
move.w d0,(a1)+
move.w d1,(a1)+
move.w d2,(a1)+
move.w d3,(a1)+
which take 4x8=32 cycles of CPU for 4 pixels. It is that do a standard display.
Better same with movem will be :
Movem.w d0-d3,(a1)+
which take 12+4x4=28 cycles of CPU
You win 4 cycle of CPU to display 4 pixels.
You can do better with movem like :
Movem.w d0-d3,-(a1)
which take 8+4x4= 24 cycle of CPU.
But more complicated because it's work inverted.
So if you have a sprite with more than 4 pixels width using "movem" will be quicker !!
There is other tips to accelerate display of a sprite.
So all sprite are "converted" to optimised code. When you want to add a new sprite you have to convert it to code with a little program. After in C you only have to jump to this code with two coordinate (a memory address) to display it. With that Tank blaster was not far to display all sprites at 30 images per second. I could have all coded in assembler but on Falcon (same in STE/ST) all computer time is taken by display. So nothing to gain to code it in full assembler. C and assembler work fine together.
I'am not sure of my syntax because I haven't done 68030 it since 18 years !
Look here :
http://mikro.naprvyraz.sk/docs/mikro/030_stram.htmlhttp://atariste.free.fr/asm/assembleur10j04.htm
Great stuff!
) music distorted issue.
