Streets of Rage 2 with Blitz

[Master484]

Here is another small Blitz 2 tech demo, which shows a few Streets Of Rage 2 characters moving on screen. The ADF is in the attachment, and it should run even on 512K OCS, but if not, then give it more RAM.

The demo is nothing special, just objects that move left and right, to test Blitter performance on BOBs of this size.

Controls:

W,A,S,D --- move Player
Numbers 1 and 2 --- create and delete enemies.

Again a dual playfield setup is used, with an 8 color foreground and 8 color background.

BOBs are of size 40*70, and the test results on a standard OCS A500 are: 8 BOBs + Player run at 50fps.

Which is pretty good I think...In the original Streets Of Rage 2 on MegaDrive, you usually encounter 4 or 5 enemies at a time. So this amount + two players on screen would be possible to achieve with Blitz 2, if 8 color dual playfield setup would be used for the game, and if the coding is smart.

And 8 sprites could still be used for smaller objects, or maybe even combined to get one extra enemy to screen (which could have colors like green and bright yellow, that are missing from the 8 color BOB palette).

---

Here are some more 8 color OCS versions of the Streets Of Rage sprites:



As you can see 8 colors (or actually 7, because transparency counts as a color) is enough when the palette is well designed. Although surely one can see that it's less colors than in the MegaDrive version, but I think that this is the only way to get a game like this to run at 50fps.

And of course the background can still have it's own set of 8 colors, and the palettes can be adjusted between levels, with the background having more freedom on color choices.

Compare this to the 16 color Golden Axe, that was most likely coded with Assembler: 2 or 3 enemies on screen at the same time, and framerate starts to drop at 3 enemies.

---

The demo also uses two "Queues" for screen buffering, which is similar to normal double buffering, but it's lot faster. This 2 Queue method can only be used with Dual Playfields. So I use "QBlits" and two "Queues" and two alternating Bitmaps...no BOB flickering and it's very fast. Old BOB drawings are erased on the first Bitmap while new BOBs are drawn to the second Bitmap, and then it switches these every frame. And we don't have to worry about damage to the background, because all drawing happens on the Front Playfield.

So I would say that Streets of Rage 2 is definitely possible on the Amiga, and one could surely make it with Blitz Basic 2.

And as usual, the source is included in the disk, you can freely use it in your own projects.

[s2325]

Good job How about using Final Fight "remake" engine?

[Master484]

Good job How about using Final Fight "remake" engine?

Yes I tried that remake demo some time ago and the engine seemed pretty fast. And it too was made with Blitz.

So it too could be used, but I like to program everything on my own, so if I one day would seriously start converting Streets Of Rage, I would most likely code my own engine.

[Prosonic]

if someone wants to remake black tiger top game horrible conversion

[s2325]

I think Satan was not bad but it's more mimic than conversion.

[idrougge]

There is more to a game than blitting bobs. Once you add enemy and level logic, you must contend with the slower parts of Blitz.

[Master484]

if someone wants to remake black tiger top game horrible conversion

Indeed, the Amiga version is an embarrasment...one could make a better conversion with AMOS.

The Amiga is capable of making a better version of Black Tiger than the arcade game. If done right, it could be something like a combination of Risky Woods and Death Trap.

---
---

And yes, blitter performance isn't the same as the whole game, but from my experience with the Megaman X Blitz project, most loop time is spent either blitting BOBs or Tiles, or repairing the background graphics after blitting something. But in 8 color dual playfield setup the BOB blitting is two times faster, and there is no background repair at all.

And although in a scrolling street brawler game like this there most likely would also be a tile creation scrolling system, but I noticed that in Sega version the scroll always seems to stop at certain points, and then you fight many enemies, and the scroll doesn't continue until you have beaten the enemies. So all serious fighting with multiple enemies basically happens in static non-scrolling screens.

So the only thing that could cause slowdown is the game code itself...but code can always be optimized, while the blitter speed will always be the same, no matter what we try.

---

Can any of you Assembler coders out there estimate how fast compiled Blitz Basic 2 code is when compared with ASM code? Has anyone ever done any comparison tests or something?

Everyone says that Blitz is slower, but exactly how much slower?

And what about basic BOB blitting performance? If this same short example program here would be done with ASM, then how many BOBs could you blit, while keeping the frame rate at 50fps?

[idrougge]

I'm no assembler coder, but I have been forced to use assembler in my Blitz projects. Some of it could be due to my coding style, but switching to asm also forces you to think smarter about how you code.

[dlfrsilver]

Originally Posted by Master484

Indeed, the Amiga version is an embarrasment...one could make a better conversion with AMOS.

The Amiga is capable of making a better version of Black Tiger than the arcade game. If done right, it could be something like a combination of Risky Woods and Death Trap.

Sometimes i wonder if BT original z80 code was not transcoded in 68000 directly..... it's a shit software engine.

[Prosonic]

Originally Posted by dlfrsilver

Sometimes i wonder if BT original z80 code was not transcoded in 68000 directly..... it's a shit software engine.

i own both bootleg and Capcom versions of both BT/BD jamma pcbs, as far as I could play on the amiga version the background layout seemed quite good but no dungeons and they just added stupid amounts of monsters rocks etc to kill I couldn't get to lvl 2 to test further where I can complete the game on arcades such as shame...

sorry to thread hijack

[dlfrsilver]

Originally Posted by Prosonic

i own both bootleg and Capcom versions of both BT/BD jamma pcbs, as far as I could play on the amiga version the background layout seemed quite good but no dungeons and they just added stupid amounts of monsters rocks etc to kill I couldn't get to lvl 2 to test further where I can complete the game on arcades such as shame...

sorry to thread hijack

I understand, capcom games are so complicated coding wise..... so it's difficult to get it right without source code.....

[Shatterhand]

You will need to code AI for the enemies, collision detection, a smart priority algorithm so stuff aren't drawn on top of each other wrongly (like the demo is doing now), and all of this will need cpu time, which may cause slowdown.

One question about how amiga draws things: is it possible to draw a sprite with the depth between two different BOBS on the same playfield? I was under the impression that you draw sprites either on top or behind a playfield, that there would be no way to draw a sprite "between" BOBS on the same playfield.

If I am not wrong (and I really have no idea), then your idea of using sprites for an extra enemy won't work. Actually I believe you wouldn't be able to use sprites for anything but background or foreground scenery, or for a panel for lives/score etc on top of the gameplay area.

[Master484]

One question about how amiga draws things: is it possible to draw a sprite with the depth between two different BOBS on the same playfield? I was under the impression that you draw sprites either on top or behind a playfield, that there would be no way to draw a sprite "between" BOBS on the same playfield.

If I am not wrong (and I really have no idea), then your idea of using sprites for an extra enemy won't work. Actually I believe you wouldn't be able to use sprites for anything but background or foreground scenery, or for a panel for lives/score etc on top of the gameplay area.

I think you're right. Sprites can't be drawn between two BOBs because BOBs are part of the Bitmap, and dual playfield wouldn't really change this. Although I think sprites can be drawn to the area between playfields, or to front or behind playfields, but not between BOBs inside a playfield.

So my idea for using sprites for enemies or gameplay objects wouldn't actually work.

But this would free the sprites for other cool things; the best use for them would be "extra scenery" in the foreground and background, such as the street lamps in the first level or the flashing neon lights. Luckily sprite height is unlimited, so they would work fine for this purpose. And even the rain effect at the boss fight of the first level could be done with sprites.

Here's a gameplay video of the MegaDrive version:

[ Show youtube player ]

As you can see, the scroll stops at certain points on the level, and when I tried the game on an emulator, there is a slight about 100 milliseconds pause when the scroll continues after stopping...I think it creates or loads the next street section during this pause. So it could be that there is no tile creation at all, but each street section is a few screens long pre-made bitmap, and each level is split into multiple bitmaps like this.

Or at least that could be the most smart way to do it on the Amiga, a 4 - 6 screens long bitmap is possible, especially because it's only 3 bitplanes, consuming less RAM. And in fact I think Golden Axe on the Amiga has similar scroll pauses, sometimes with loading breaks.

Maybe I'll make a quick scrolling level with basic gameplay and AI in place, so that we'll get a better idea. Shouldn't take longer than a week.

---

And about the question on Blitz speed vs Assembler speed: it would be cool if someone would make speed comparison tests on compiled AMOS code vs compiled Blitz 2 code vs compiled Assembler code, on basic tasks such as different math operations, variable handling, condition checking, loops and BOB blitting, with source codes available on each of three tests, so that everyone can evaluate the tests and verify the results on their own.

Then we would have some facts on the table on where the slowness of AMOS and Blitz is mostly located, and how serious it is, from a game making perspective.

[LuMan]

WRT Bobs - one good thing about games of this type is that the bitmap Y-position for the bob also equates to the Z-position (into the screen), so a quick bubble-sort for viewable bobs will result in the paste order, ensuring that the bobs towards the 'front' of the play area are drawn last.

Sadly, you can only put sprites in front of, or behind, the bitmap for each bitmap. But I like your idea for other sprite usage, such as streetlamp and rain.

Interested to see how this project pans out.

[Master484]

WRT Bobs - one good thing about games of this type is that the bitmap Y-position for the bob also equates to the Z-position (into the screen), so a quick bubble-sort for viewable bobs will result in the paste order, ensuring that the bobs towards the 'front' of the play area are drawn last.

Yes, although a small offset correction to the drawing Y position is still needed for each character, because they can have different heights. So instead of the Blitting position Y we have to check the "feet Y" coordinate, that is the Y point where the bottom pixel row of the characters feet is located.

But other than that, it should be quite simple and semi-automatic; each frame a "drawing list" is constructed according to the feet Y, and the characters whose feet are higher on the screen are drawn first.

[Shatterhand]

The game does this slight pause on real hardware too. I had an original cartridge of this, and I finished this game like dozens of times on every difficulty level (including the secret "Mania" one).

Actually, playing on Mania you can really see the power of the Mega-Drive, because the screen may get *really* cluttered with baddies and from what I recall it never shows a hint of slowdown.

But just to let you know, even arcade Final Fight does have a few slowdowns here and there. Most people will accept slowdowns if they aren't abound and for good reasons

[dlfrsilver]

the slight pause is due to the decompression of the Art assets

Nothing to worry about

[LuMan]

Originally Posted by Master484

Yes, although a small offset correction to the drawing Y position is still needed for each character, because they can have different heights. So instead of the Blitting position Y we have to check the "feet Y" coordinate, that is the Y point where the bottom pixel row of the characters feet is located.

But other than that, it should be quite simple and semi-automatic; each frame a "drawing list" is constructed according to the feet Y, and the characters whose feet are higher on the screen are drawn first.

Absolutely. Good point

Can't you also adjust the bob handle in Blitz 2? I'm sure you can set it bottom/left. Means you can do away with the offset for character height.

EDIT: Yes you can. A quick flick throough the manual throws up 'Handle Shape #,x,y'

Of course, if you want to be really showy, then have the Y movements a bit bigger at the bottom of the play area, and give your perspective a bit of a 3D feel

[Master484]

Yes, the Handle Shape command is very useful in a game like this, it basically allows us to make those offset calcultions when shapes are loaded, instead of the actual game loop.

I now have an Y ordering system in place, which works 100% and takes about 15% of loop time. Currently 6 BOBs + the Player run at 50fps, with the appearance of the 7th BOB causing slowdown.

But when we enter the "slowdown zone", I can add more BOBs without further slowdown, until about the 15th or 16th BOB, at which point the game enters the next "slowdown zone". And this is good, because the first slowdown zone is still playable, it runs about the same speed as Golden Axe with 3 nasties on screen.

So it's looking OK so far, I'll now try to add some AI and collision detection, which most likely cost us one or two BOBs more, leaving 4 or 5 BOBs + Player at 50fps, which is the same as the MegaDrive version at "Normal" difficulty.

[AlgoRythmic]

Hi!
Someone suggested elsewhere in this forum that you can go for higher number of objects if you draw half the bobs in one frame and the rest of them the other frame.

Well I tried to do that with your code and I think I got it working properly.
Granted it's not that smooth but maybe you or somebody else could find a use for it or maybe even improve upon it. Personally I don't mind it that much and I would be interested to know how it fares on a real machine since I don't currently own one.

Anyway here it is:

WBStartup ; makes the program startable from icons and autoboot

DEFTYPE .w

;--------------------------
BitMap 3,260,220,3   ; temporary bitmap for image loading

LoadBitMap 3,"DemoGFX/SORenemy2.iff"
GetaShape 20,0,10,40,71
LoadBitMap 3,"DemoGFX/SORaxel2.iff"
GetaShape 21,0,10,39,73
LoadBitMap 3,"DemoGFX/SORtile2.iff"
GetaShape 23,0,10,16,16
Free BitMap 3
;--------------------------

LoadPalette 0,"DemoGFX/DemoPaletteSORf8b8.iff"

PalRGB 0,0,0,0,3  ; turns color 0 (transparent background color)
                  ; to blueish black

#UP = $11
#DOWN = $21
#LEFT = $20
#RIGHT = $22
#KEY_2 = $2
#KEY_1 = $1

#ZERO = 0
#ONE = 1

#PLAYER_SPEED = 3
#PLAYER_RIGHT_BOUNDARY = 260
#PLAYER_BOTTOM_BOUNDARY = 120

#ENEMY_SPEED = 2
#ENEMY_LEFT_BOUNDARY = 3
#ENEMY_RIGHT_BOUNDARY = 250

#MAXIMUM_BOBS = 49

;TTTTTTTTTTTTTTTTTTTTTTTT

NEWTYPE .ship     ; although they arent really ships
x.w
y.w
animframe.b
direction.b
displacement.b
name.b
End NEWTYPE

Dim List go.ship(100)



;ResetList go()
;a = FirstItem(go())
;a = AddItem (go())   ; dummy item, always have one at the start
                     ; of all lists to avoid problems

;TTTTTTTTTTTTTTTTTTTTTTTTT


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

VWait 250 ; waits 5 seconds before BLITZing the Operating System
BLITZ
BlitzKeys On

Slice 0,44,320,256,$fffa,6,8,16,448,448

; single playfied = $fff8
; dual playfield  = $fffa

Use Palette 0

BitMap 3,448,384,3   ; 3 bitplane BACK PLAYFIELD

BitMap 0,448,384,3   ; 3 bitplane FRONT PLAYFIELD
BitMap 1,448,384,3   ; with two bitmaps for double buffering

Queue 0,50           ; But we use Queues instead of Buffers
Queue 1,50           ; So we have 2 Queues for 2 Bitmaps

buf.b  = 0           ; buffer and bitmap counters
bmap.b = 0           ; notice that we will call the Queues
                     ; with the name "buf", for sake of
                     ; clarity

Use BitMap 0         ; cleans bitmaps
Cls
Use BitMap 1
Cls

Gosub LevelBuild

ShowB 3,0,0 ; shows bitmap 0 in back playfield
ShowF 0,0,0 ; shows bitmap 1 in front playfield


.variables

x.w = 0
y.w = 0
drawcounter.w = 1
p.w = 0

PL1_X.w = 0  ; player xy
PL1_Y.w = 0

a.w = 0      ; helper variables
b.w = 0
c.w = 0
d.w = 0
e.w = 0
f.w = 0
g.w = 0
t.w = 0

yesx.b=0
yesy.b=0
enemiesonscreen.b=1

skipcounter.b = 0
moveclock.w = 0



t = 20


.mainloop

Use BitMap buf

;OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
Repeat

VWait


If skip_me_first.b
  ShowF buf,#ZERO,#ZERO
  buf = #ONE - buf
  Use BitMap buf        ; swaps the Bitmap where objects
  UnQueue buf
EndIf


skip_me_first = #ONE - skip_me_first

;skipcounter = 1 - skipcounter
;If skipcounter>1 Then skipcounter=0

;moveclock+1
;If moveclock>200 Then moveclock=0


Gosub KeyboardRead


;VVVVVVVV
;VVVVVVVV


;DOUBLE BUFFER WITH 2 QUEUES
;QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ

         ; empties Queues 1 and 2 at their turn

;bmap = 1 - bmap
                       ; are drawn this frame

;QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ


;BOB DRAW
;----------------------------------------------
;----------------------------------------------

 ; enemy draw


ResetList go()




 ;WWWWWWWWWWWWWWWWWWWWWWWWWWWWW
 ;While NextItem (go())



skip_again.b = skip_me_first


For objects.b = #ZERO To enemiesonscreen - #ONE

  If go()\x < #ENEMY_LEFT_BOUNDARY Then go()\displacement = -go()\displacement

  If go()\x > #ENEMY_RIGHT_BOUNDARY Then go()\displacement = -go()\displacement


   go()\x + go()\displacement


   skip_again = #ONE - skip_again

   If skip_again
   QBlit buf,t,go()\x,go()\y
   EndIf

   NextItem go()







Next objects

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

;

 ;Wend
 ;WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW

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

 ; Player draw
 ;-------------------------
 If skip_me_first
 QBlit buf,21,PL1_X,PL1_Y
 EndIf
 ;-------------------------

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


;SSSSSSSSSSSS

;ShowB 3,0,0
;SSSSSSSSSSSS



Until RawStatus($45) ; ESC
;OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO


Goto EndProgram

;++++++++++++++++++++++++++++++++++++++++++
;++++++++++++++++++++++++++++++++++++++++++
;++++++++++++++++++++++++++++++++++++++++++
;++++++++++++++++++++++++++++++++++++++++++



;********************
.KeyboardRead
;********************

If RawStatus(#UP) Then PL1_Y-#PLAYER_SPEED    ;W
If RawStatus(#DOWN) Then PL1_Y+#PLAYER_SPEED    ;S
If RawStatus(#LEFT) Then PL1_X-#PLAYER_SPEED    ;A
If RawStatus(#RIGHT) Then PL1_X+#PLAYER_SPEED    ;D

If PL1_X<#ZERO Then   PL1_X=#ZERO    ; player bounds
If PL1_X>#PLAYER_RIGHT_BOUNDARY Then PL1_X=#PLAYER_RIGHT_BOUNDARY
If PL1_Y<#ZERO Then   PL1_Y=#ZERO
If PL1_Y>#PLAYER_BOTTOM_BOUNDARY Then PL1_Y=#PLAYER_BOTTOM_BOUNDARY

If RawStatus(#KEY_2)  ; add one ship
 If enemiesonscreen<#MAXIMUM_BOBS
  a = AddItem (go())
  enemiesonscreen+#ONE
  go()\x=10+Rnd(#PLAYER_BOTTOM_BOUNDARY)
  go()\y=10+Rnd(#PLAYER_BOTTOM_BOUNDARY)
  go()\name = #ONE
  go()\displacement = #ENEMY_SPEED
  go()\direction = #ZERO
 End If
End If

If RawStatus(#KEY_1)   ; delete one ship
 If enemiesonscreen>#ONE
  a=LastItem (go())
  KillItem go()
  enemiesonscreen-#ONE
 End If
End If


Return

;++++++++++++++++++++++++++++++++++++++++++
;++++++++++++++++++++++++++++++++++++++++++



;************************
.LevelBuild
;************************

Use BitMap 3
Cls

x = 0 : y = 112
a = 0 : b = 0


Repeat

 Repeat
  Block 23,x,y
  x+16 : a+1
 Until a=18

 x = 0 : y + 16
 a=0 : b+1

Until b=7



Return

;++++++++++++++++++++++++++++++++++++++++++
;++++++++++++++++++++++++++++++++++++++++++



;********************
.EndProgram
;********************

AMIGA
NPrint ""
NPrint "Enemies on Screen: " + Str$(enemiesonscreen-1)
End