Streets of Rage 2 with Blitz

[Master484]

@AlgoRythmic

Thanks for the idea and optimizing the code. Yes, that's a good way to make things faster; Player would be drawn every frame, but enemies only every second frame. So the Player moves at 50fps and enemies at 25fps, but if enemies are split into two alternating groups, then every frame some of them always move, and so it may look faster than 25fps.

So adding an alternating BOB draw system like this might be a good idea, but I think I'll make it so that it only starts when lots of enemies are on the screen, so that all screen updates stay at 50fps until BOB amount reaches the "slowdown zone", and at that point the game switches to 50fps for Player + 25fps for BOBs.

I'll experiment with this method, in the best case we could even get 10+ BOBs to screen at 50fps + 25fps, because most loop time still goes to BOB drawing.

---
---

About the speed of the original game, here is an interesting speedrun video of the MegaDrive version:

[ Show youtube player ]

At 7:20 the speedrunner makes some comments about slowdown on that room, but says that the slowdown only happens in real MegaDrive, and not with emulators. And I too have played this game on a real MegaDrive, and I remember that room with the arcade machines, and I think that there was slowdown there. The many arcade machines most likely cause as much GFX drawing stress as the enemies do, hence the slowdown.

And also about maximum amount of enemies on screen, here is a TAS speedrun on "Mania" difficulty:

[ Show youtube player ]

It would seem that even in Mania mode, the average number of on screen enemies is 5, although occasionally this increases to 6 enemies, but 6 has to be the absolute maximum that the engine is capable of, considering the slowdown in the "arcade machine room".

[Shatterhand]

So adding an alternating BOB draw system like this might be a good idea, but I think I'll make it so that it only starts when lots of enemies are on the screen, so that all screen updates stay at 50fps until BOB amount reaches the "slowdown zone", and at that point the game switches to 50fps for Player + 25fps for BOBs.

This is actually a pretty good idea.

[AlgoRythmic]

Originally Posted by Master484

@AlgoRythmic
but if enemies are split into two alternating groups, then every frame some of them always move, and so it may look faster than 25fps.

This is not the case, I made sure of that not happening actually. If you look carefully in the code that I posted all the BOBs new positions are being processed every frame, even if they're not getting drawn. The same applies for the main character of course. Btw the main char also gets drawn at 25 fps also. if you want it to be drawn @ 50 fps then just remove the If-nest around the blit command of the main char.

-----
Other than that I think that your idea of activating this draw routine only when it's needed is great. You should definitely go for that.

[Master484]

Yes I took a second look at the code, and now I get it.

The current source that I'm working on looks quite different from the first version that I included with my original post, so I cannot directly test the code you posted, but I get the idea; game logic updates 50fps but the BOBs are drawn at 25fps, which indeed allows a larger number of them to screen; a 25 fps frame rate is easier to keep slowdown-free than 50 fps.

The aim for the game is a smooth and constant 50fps update rate, but short switches to 25fps when slowdown threatens is a good idea; it's usually better to have short periods of 25fps than slowdown.

---

Although my idea of making the Player 50fps and BOBs 25fps might not be so easy than I first thought.

For example in your example code, if we remove the If-nest around the Player drawing commands, then Player will be QBlitted every frame, but the "ShowF", Unqueue and Bitmap change events still happen only every second frame.

Maybe if the Player would have it's own Queue, it might work. But even then there would be problems with maintaining the Y order of the characters: if Player is drawn at 50fps and enemies at 25fps, then the Player would be constantly drawn over the enemies, which would break the perspective.

So a simultaneous mixed 50fps/25fps objects drawing may not be possible in a game like this. But normal 50fps to 25fps frame rate switches for all GFX drawing at once are still possible, and I think I'll add such a system.

The only games that I know which use the mix of 50fps for Player and 25fps for other game objects are Battle Squadron and Project-X, and both are shoot'em ups, and both use sprites for the Player ship and bobs for enemies, which makes things easier because sprites are independent from all other screen graphics.

[AlgoRythmic]

Have you tested the source? Coz it works just fine for me with your exact files and directory structure. I didn't change any filenames or directories so it'll work as is. I did however optimized it a bit but the final result is the same apart ofc from the new drawing technique. Just make an executable first on the root of your SoR floppy or your previous SoR working dir on your hd and then compile and run it and see if it works

As for the main character.. you're right! It won't run @ 50 fps. Obviously I didn't give it much thought . Your idea for using sprites for the main char then seems plausible to me. Edit: ..or not! tbh idk much about sprites.

[Master484]

Testing the source isn't so easy, because I'm programming this using a PC and WinUAE Amiga emulator. So I can't just copy paste the code to my Blitz Editor.

But I tried copying your code to a Windows txt file, and then put that to my WinUAE Amiga's virtual HD, but it didn't work. Although Blitz could open the txt file, and everything seemed OK, but when I tried to compile and run it, it gave me a Syntax Error on the first command, although there was no error in it. I guess that the txt format adds some stuff there that Blitz doesn't like.

Also making an executable didn't work, it again gave a Syntax Error. And then I tried to "Save" the source to another file from Blitz, and this worked, but when I opened this new file, again it gave a Syntax Error, although everything looked fine. I don't know what causes this, but it must be the .txt file that just doesn't work directly like that on an Amiga.

---

But I trust that your code works, I looked it through and it definitely looks like a working method. And it inspired me to make some speed tests with different variable types, which will be included to the next version.

And sprites can be used, but not for any of the walking game characters because of the Y perspective drawing order system that is also being added to the next version.

[AlgoRythmic]

You can enable "Clipboard sharing" under Miscellaneous settings in Winuae and paste any text you copy from PC apps to blitz with Right Amiga key+V.

That's good to know for the sprites - you learn something new every day Btw do you use any inline assembly? That would be another way to further optimize the code especially later on when you'll have enemy AI and other computational dependent game mechanics.

[nogginthenog]

Originally Posted by Master484

But I tried copying your code to a Windows txt file, and then put that to my WinUAE Amiga's virtual HD, but it didn't work. Although Blitz could open the txt file, and everything seemed OK, but when I tried to compile and run it, it gave me a Syntax Error on the first command, although there was no error in it. I guess that the txt format adds some stuff there that Blitz doesn't like.

Use NotePad++ on Windows. It detects the line endings. Amiga uses LF (chr 10) only. Windows uses CR+LF (chr 13 + chr 10).

[Master484]

@AlgoRythmic

Ok, I got the code working now, I had no idea that WinUAE had that kind of "Clipboard sharing" option. It gave me one "no current object" error at the bob drawing routine, but adding a simple FirstItem before the loop solved it, and rest of the code runned fine.

So, the results looked OK to me, I counted 15 or 16 enemies + the Player running at 25fps. Adding more enemies than this caused the first signs of slowdown.

From the movement of the BOBs one can quickly see that it's running at 25fps, but that is the case of all 25fps games, there is no real way to make it look any smoother than this.

But the drawing power increase at 25fps is significant, and therefore this system should be used, but only when the screen gets crowded. I'll add that 50/25fps on-the-fly switch to the next version, and then we'll see how the frame rate changes look in action.

I would estimate that even with AI and collisions in place, 10 enemies on screen is quite possible at 25fps. Although of course we dont even need that many, but all small stuff too like weapons, pickups and everything else also need to be BOBs, because sprites can't be integrated to the BOB Y perspective system. So the reality might be that we need to switch into 25fps quite often.

---

And about inline assembly, currently I'm not using any, and can't, because I have zero skills in Assembly.

And I would rather keep it 100% Blitz Basic, so that the source code remains understandable and useful for normal people, who for example want to learn how to code games like this for the Amiga, using an easy Basic language like Blitz. This is one reason why I avoid adding assembly to my projects, the other reason being that it's hard and I don't want to learn it.

Use NotePad++ on Windows. It detects the line endings. Amiga uses LF (chr 10) only. Windows uses CR+LF (chr 13 + chr 10)

Ok, good to know about the Windows txt file line endings, now I know why it's so hard to read data lines from them.

[Shatterhand]

Are you *really* going for it? I was under the impression you were more like "Let me do a tech demo and see what the Amiga could do"

If you are really into doing this port, it's going to be a massive job. And an awesome one for sure, I wouldn't mind helping with whatever I can help (not much I guess, but still )

[Master484]

Are you *really* going for it? I was under the impression you were more like "Let me do a tech demo and see what the Amiga could do"

If you are really into doing this port, it's going to be a massive job. And an awesome one for sure, I wouldn't mind helping with whatever I can help (not much I guess, but still )

Right now the plan is still to just do a small Blitz tech demo; even though it may sound like that I'm planning to do the entire game, but I'm rather brainstorming with ideas of how things might work in the actual full game.

So in this demo, after it's completed, there will be a simple scrolling street (a repeating 2 screen bitmap), with enemies that you can create by pressing 1 and 2 on the keyboard. There will be some basic AI for the enemies, and a simple walk + punch + damage animations for the Player and the enemies. And the 50/25fps frame rate mix system will also be tested. And maybe the sprite ideas for the streets lamps and the rain will be included too.

And after it's ready, I'll post it here, with the source. It'll be a demonstration of the power of Blitz, and the proof that Amiga can easily handle this sort of game using the 8 color dual playfield mode, and a good tutorial / game engine skeleton for anyone who wants to do a game like this.

---

But most likely I won't start doing the whole game at this point. I already have another big project in progress (Megaman X), and it's better to concentrate on that, or otherwise I'll just end up with many unfinished projects. But it's fun to do quick "could Blitz handle it?" demos like this one, and the "Stardust tunnel demo".

The Megaman X project itself is massive, and the fact is that it'll take me years to complete. But working only on it also limits my programming hobby to just one project, and so I find it refreshing to do quick demos like this once in a while.

But after making this tech demo, I'll probably return to the Megaman X project. So this will just be "one street" of Streets Of Rage, not the entire game.

And IF I some day start converting the whole Streets of Rage 2, that will be after the conversion of Megaman X is completed. So it would be years from now.

But of course, if some of you feel like making the full Streets Of Rage 2 conversion, then you're free to use the code of this engine demo after it's ready. Although it would be a big project for sure.

[AlgoRythmic]

Hi Master!
I've noticed that when you lower the bplanes in the Slice command from 6 to 5 no discoloring occurs on either of the playfields and is of course faster. Now since I'm no Amiga technical specifications expert idk why this is happening. A google search revealed that 6 bplanes is the right number of bplanes for OCS dual-playfield. BB2 guide tho says "up to" 6 bplanes when setting up dual playfield Slices.

Just wanted to throw that out there.

Oh and one more thing. 15-16 is not the number that I get with no slowdown. more like 9 or 10 (including main player bob). When testing for accurate A500/A1200 speeds on Winuae you have to enable "cycle-exact" under Chipset options or use the default Winuae A500 configuration on "best combatibility".

[Master484]

@AlgoRythmic

Ok thanks, that's an interesting observation on the Slice bitplanes...I'll test it, but I'm pretty sure that 6 bitplanes is the right number...but maybe it allows 5 planes, because in the current demo not all 8+8 colors are used. So some colors may in fact disappear, but it can't be seen because those colors not yet used in any gfx.

Oh and one more thing. 15-16 is not the number that I get with no slowdown. more like 9 or 10 (including main player bob). When testing for accurate A500/A1200 speeds on Winuae you have to enable "cycle-exact" under Chipset options or use the default Winuae A500 configuration on "best combatibility".

I have to test this too. But I have never used cycle-exact when playing games on WinUAE, and I think all of them run at the same speed as the real Amiga originals do, for example in Turrican 2 the waterfall slows down the game exactly as it does on a real Amiga. And Elite 2 is as slow as in real Amiga, and so are Golden Axe and all Tiertex productions.

Could it be that you have the Blitz "run-time debugger" turned on when testing the code? It makes everything run at half speed or even slower, although surely you already knew this.

But anyways, I'll test what results I get with cycle exact turned ON.

[Samurai_Crow]

I don't know Blitz BASIC but I know that in dual playfield mode each playfield is 3 bitplanes for OCS and ECS max. You should be blitting only that many planes on each playfield. AGA goes up to 4 each.

[AlgoRythmic]

@Master484
Yeah ofc I know of all these things about running Winuae games and of course about the runtime debugger too Still I know for sure that Blitz programs and especially anything that has to do with blitting gfx in Blitz behave a lot faster in Winuae than the real stock machines without the cycle exact option turned on... unfortunately

[Raislin77it]

Originally Posted by AlgoRythmic

@Master484
Yeah ofc I know of all these things about running Winuae games and of course about the runtime debugger too Still I know for sure that Blitz programs and especially anything that has to do with blitting gfx in Blitz behave a lot faster in Winuae than the real stock machines without the cycle exact option turned on... unfortunately

yep, if u want to be sure about the "real" speed, check the cycle-exact button on winuae, otherwise you get a "pc boost" of your blitz examples

and to have 8+8 color for the dual playfield you must enter 6 bitplanes on the initcoplist command.

you can use less then 8 color per playfield, but the right number to put in initcoplist is always 6 (or 8 for aga machines), because on amiga you can't group bitplanes at your choice, for a dual-playfield you use the full odd and the full even bitplanes , you cannot mix them (for example you cannot create a 2 bitplanes background and a 4 bitplanes foreground, only 3+3 or 4+4 for aga)

[Master484]

Ok, I tested the bitplanes thing and tried to lower the number of bitplanes from 6 to 5, but it gave me a "too many bitplanes to draw" error. So 6 is the right number to use. Although in some cases it could be that putting a 5 there might not cause an error, but it's risky...I think that the only reason why it worked for you, is if you had removed the back playfield bitmap, or the "ShowB" command was removed (as it maybe was in the altered source that you posted, but I don't remeber if that was the case).

---

I also tested the WinUAE Cycle Exact mode with my current development version, with these results:

Cycle Exact OFF : Player + 6 BOBS at 50fps
Cycle Exact ON : Player + 3 BOBS at 50fps

So yes, you guys are right, in this "reality check" Amiga emulation mode we indeed hit slowdown quite a lot sooner.

All CPU operations seem to take about 40% more time when Cycle-Exact is turned ON. And this in turn decreases the number of BOBs we can draw during a frame.

I somehow thought that this would be the case, everything was running so fast that I wondered how even Blitz can be *this* fast, it seemed 2X faster than Assembler lol.

---

But despite this "reality mode" we are still doing pretty good, and the 50fps/25fps switch techique can still easily give us at least the Player + 5 BOBs at a reasonable speed. And even if everything else fails, then I guess full 25fps all the time is acceptable for a game like this.

I think I now understand the challenges of Amiga game creation a little bit better, and why so many commercial games run at 25fps, or use split frame rates like "Player at 50fps + everything else at 25fps".

And also I tested my other Blitz projects with Cycle Exact: both Stardust Tunnel and Megaman X still runned at 50fps, but slowdown was 2x easier to achieve. Not good, but not so bad either.

Also theoretically the screen size can be decreased to get a little bit more speed. But I tested making the Slice Width 256 instead of 320, and it gave only small speed increase, so I don't think it's worth it.

I currently have two Slices in the screen, one 320*32 single playfield Slice on the top, where I put a status panel, and a 320*224 dual playfield game screen Slice under it, which looks pretty cool. But you'll get to see it only after everything else is ready too.

[AlgoRythmic]

@Master484
Which version of BB2 are you using? I use the Ultimate Blitz CD one from the Zone. The one with the SuperTED and all the latest updates. Perhaps thats why you're getting some of these errors? idk

On a different note.. At some point u said that u were testing new variable types. So.. are you using BB2 pointers yet? I've read somewhere that they're allegedly faster and I've been using them all the time ever since but I haven't stress tested them yet

Anyways, I've altered your source to use pointers. I could post it here for you to check out if you'd wanted.. or not. it's up to you. I don't want you to feel like I'm hijacking your post or anything.. I myself am far from what you call an advanced Blitz programmer and I'm still in the process of learning how to code in Blitz in a more efficient way. and I think that the faster way to achieve that is through these conversations and the exchange of information that we're having.. and posting some source code ofc always help! coz I think it's easier for ppl to jump right into it and make some optimizations or suggestions. And not to mention ofc that we might be potentially, helping out some ppl new to Blitz to better understand and use this powerful yet very much under-documented(imo) BASIC language... Just wanted to get that out! \m/

[Master484]

Which version of BB2 are you using?

Blitz 2.1 with TED 1.1...This is the ADF version of Blitz 2, that I got from BackToRoots years ago, when the site was still operational.

I know that better versions exist, and people have recommended the Ultimate CD version to me, but I've been too lazy to try it out; this version works fine, so I've been just using it.

On a different note.. At some point u said that u were testing new variable types. So.. are you using BB2 pointers yet? I've read somewhere that they're allegedly faster and I've been using them all the time ever since but I haven't stress tested them yet.

Anyways, I've altered your source to use pointers. I could post it here for you to check out if you'd wanted.. or not. it's up to you.

I have never used BB2 pointers, although I have seen them in the manual. Maybe I should test them too for speed, and if they're faster in something, then maybe I should use them.

You can post the source if you like, but I have my hands full with the current version that I'm making, and I wouldn't want to make performance tests with the old source version. But if you can first test it yourself, and find out that the pointers are surely faster, then in that case you should post it here.

Source optimization suggestions are always welcome, and once I upload the next version here, then you'll have much more stuff to analyze. But it'll still take some time, because I'm adding way more stuff than I originally intented.

---

About the speed tests, my current development version has three speed tests in it that can be activated by uncommenting Gosubs in the main loop. They test the speed of Integers (.w) against Bytes (.b) , NEWTYPE variables ( like "go()\X" ) , and Constants.

And the results that I got were that Integer variables are faster than NEWTYPE variables, and surprisingly Integers are also faster than Byte variables. But Constants on the other hand were faster than integer variables. Also I tested Constants vs directly given numbers; they were equally fast.

So doing multiple operations with NEWTYPE variables should be avoided at all costs, and use integers whenever possible.

But Bytes too were slower than Integers, and I don't know why, I always thought that they would be faster. Maybe it has something to do with the Amiga having a 16-bit processor...aren't Bytes 8-bit values and integers 16-bit values? So maybe this is why integers are faster. Or at least in Blitz they seem to be so, and I made these tests with cycle-exact too.

---

And not to mention ofc that we might be potentially, helping out some ppl new to Blitz to better understand and use this powerful yet very much under-documented(imo) BASIC language

I agree, Blitz doesn't have enough good code examples or tutorials. It's a great language, and incredibly powerful for Basic made for a 7mhz computer. And it's easy too, but needs more well documented code examples, especially game examples that show cool stuff like this running on the screen.

Blitz and AMOS are basically the only options for random people out there, who want to make games for the Amiga. These two programs are our Unity and Game Maker: they're easy, Basic, and highly capable. And we should make it as easy as possible for people to pick either one of them up and start making games. The SNES and the MegaDrive can only dream about having programs like these.

[Master484]

Maybe it's actually best to just upload the latest development version here, so here goes, the ADF + the source is in the post attachment.



Controls remain the same: WASD to move, 1 and 2 to create enemies.

This is still Work-In-Progress, but some new stuff is already in place and working:

1.
The back bitmap now scrolls when Player moves in the right half of screen. It's a 2 screen repeating scroller that jumps back to the first bitmap halve after reaching the second halve. Notice that Bobs dont actually move with the scroll (because they're in Front Playfield), but we put a scroll correction to their X coord every frame, so they seem to move with the scroll.

2.
All Objects are now drawn using a separate Drawing List NEWTYPE thing, and they are given a XY "Handle" at object loader, which allows them to be drawn according to their lower left corner.

3.
The Y prespective sorting routine has been added, and it works great. First it splits all objects according to "smaller or bigger than Player Y", and puts them to either to start or end of the drawing list. And at the actual sorting process, Bubble Sort is used. Although Blitz also has a "SortList" command, but it gave me a Syntax error every time, so I made my own routine.

4.
There is an in-built analysis mode, press "8" and "9" to activate it. Colored lines will be generated to the left side of screen, and they tell the position of the display beam at various points. 2 Blue lines indicate the start and end of GFX draw, and 2 red lines are the Y sort routine. And white line is the "all done" mark, after this the program just waits at "VWAIT".

5.
The enemy hands are drawn separately from the main body. This may not be necessary now, but later it is, both to save RAM and to lessen Blitter load, especially with large enemies.

6.
And as mentioned earlier the screen now has two Slices, one for status panel and one for the game area.

---

Performance right now: Player + 3 BOBs at 50fps. Looking good, now I just add some animation frames, AI and collisions, and the 25fps switch.

And check out the "SPEEDTESTS" in the source, they're a great way of repeating all sorts of tests 500 times per frame, and with the debugger lines you can easily see the impact.