Streets of Rage Amos demo
 

Hi everyone!

Thought I'd try a small demo of Streets of Rage 1 using Amos Pro 2.0 and see how far I could get. It just has one enemy who never dies and I think a third of the level, but it's only a demo.

https://www.youtube.com/watch?v=TN2yDu-JOIQ

It works fine until it starts scrolling and then it slows down to a cow's pace, which I'm guessing is just down to Amos hitting its limits or simply bad programming by me (I'm guessing the latter). I'm using some weird techniques to animate meta bobs by using horizontally sliced images, so maybe that's too slow. Either way, it doesn't matter. (BTW, the health bar flicker is cause by Frapps recording and doesn't usually appear).

I was going to do some of Koshiro's music in Protracker and maybe try and animate the backgrounds, but I don't think I'll bother continuing with it now.

I'm Happy enough though. It's nice seeing the game run on an Amiga (I always thought it'd be a well suited game to the system), and it was a lot of fun to do.

Cheers!

Info:
16 Colours
Some Amcaf commands were used for controls and sounds
Backgrounds were built and displayed using in Tome4

Amos for Windows stock settings:
68040
AGA

Sorry to hear you won't continue working on this.
Because it already looks nicer then all beat em up's on Amiga (except Golden Axe maybe).

What I find interesting is that the slowdown remains even when you stop scrolling, it happens when the screen is not to the far left anymore. That would hint to me that code is constantly active every frame that really shouldn't be the moment you first trigger scrolling to happen.

But nice tech demo in any case. I'd take it at least one step further and put multiple enemies on screen without letting the game scroll, just to see what will happen then.

Looks pretty nice actually

Thanks folks.

gimbal - I'm a terrible programmer so it could very well be the case of something running when it's not supposed to. I did find it a bit odd that it was so slow given the 68040 setting so maybe it could be improved. I'll probably tweak it a bit further as I had a whole moveset planned out, but ATM it's too slow to invest time to do anything significant. I was in the middle of working out how to get objects which could switch between bad guys, so 2 enemies on screen will probably be the next step.

How are you doing the scrolling - is it hardware based as in theory this wouldn't cause slow down. This looks really good and the fact you have collision detection working then you're a long way down the line.

If you sort scrolling you might get your motivation going...

It's just done with a "Screen Copy" command in Amos, which I think uses the Blitter, and it activates when the player's X coordinate is over a certain point of the screen viewport.

I'd definitely keep going if I could get it faster, but I was always aware of the limitations of both Amos and my ropy coding. I'm brand new to scrolling techniques too, but I've only been at the project for two weeks so who knows.

I don't know enough about AMOS as I'm more of an assembler person.

The technique for horizontal scrolling is very simple and requires for little DMA time.

Consider you have a 320x256 screen, each tile is 16x16 pixels. When you place the tile you start at 0,0 (top left) and then work along the x axis plotting the tiles till you have 20 tiles, then you go to the next row and place the next 20 tiles...all the way till you get 16 tiles depth giving you 256 pixels.

Now when you scroll, you modify the BPLCON1 register for both odd and even bitplanes, this adjusts the fine scroll of the display. if you were scrolling right, you would add $11 to BPLCON1 and place a 16x16 tile at position 19,1, as you scroll further... you plot the tile at 19,2... 19,3 on each video frame.

When you reach the 16th tile ($FF in BPLCON1) you will add two to the Bitplane screen address and reset BPLCON1 to 0.

It is really that simple.

For scrolling left you just do things in reverse but instead of plotting at column 19 you plot at column 0.

I've seen AMOS games do this sort of thing so it is surely possible.

Geezer

AMOS can natively do smooth panning with the Screen Offset command (at least, that is the AMOS PRO command to do this. Pretty sure it's the same command in AMOS, might be called a little differently).

However, this moves an entire screen not a part of it. To use this with a score panel, the top panel and the game are need to be separate screens. It also doesn't wrap around automatically (so once you hit the size of the screen it'll give an error if you try to increase it further) and does not support the "corkscrew scrolling" manyassembly programs use. So you need to do things a bit differently.

The way I did it back in the day was to define a screen twice as wide as I wanted to display. Then, while I was scrolling along to the right, I'd add the new tiles to the right of the screen and to the left side of the screen (as space became available). This way, when I reached the maximum width of the screen, all I'd need to do was reset the screen offset to zero.

The key to do this efficiently is to not draw all the tiles at the same time, but to spread them out over different frames. So if your tiles are 16x16 pixels and you want to scroll at a speed of one pixel per frame, you draw no more than 1 tile to both sides per frame. This method will work at full 50Hz speed even on an A500 and without compiling.

Note that I do not know how to do this with TOME.

I know a little assembler but not much. Amos pretty much does the gruntwork automatically after a bit of setting up, but yes I've seen it done quite fast as well so it's probably just my code being ham fisted. Cheers for the info though! I should really dive into assembler at some point.


The technique I'm using is basically drawing the whole map on a hidden screen and then copying parts of it to the viewport as needed. I think there's another way in the manual that just draws a 16 tile column to the right of the screens edge and that gets scrolled along and then another added when needed (I think that's the same as what you're saying) but I'd need to look into it further. The section with the healthbars is a separate screen anyway so that's not a problem.

Yeah, maybe I should keep on with this as it seems like there are a few more options out there which could speed things up. :)

Not sure how other feels, but beat em up like this, with static screen would be perfectly acceptable to me. :)

But then again, I understand, it's your motive to learn optimizing further, not only do the stuff you already know. :)

Looks cool - i'm a big fan of both AMOS and Streets of Rage.

I'm sure those on the AMOS Factory/AMOS Pro FB group would be willing to look at the source and see if the scrolling routine could be fixed to give a good pace.


That technique described by roondar, used with the hardware scrolling should produce some pretty great results. I'd never thought of working it that way.

Firstly, excellent demo!

Secondly, this might actually be a nice project for Streets of Rage clone - maybe call it something else for licencing issues such as Streets of AMOS! Would you be willing to open source it, I think it would be a shame for it to end, and if others are saying there is scope for improving scrolling, then might be possible to achieve a full level (with more enemies)...

Hungry Horace - That's a good idea. I keep forgetting about the Amos Factory group, so I might post the source on the forums there and see if any kind soul can maybe point out what's wrong.

lesta_smsc - If I ever finished it, I was going to call it something like "The Road of Anger" and have a slightly different moveset than the Megadrive game. Ultimately, it was really just to see if I could build an engine for these types of games in Amos, as the Amiga was a bit lacking in the beat 'em up department. I actually have two enemies on screen now (collisions are ropy though as they are sharing global variables) and it doesn't seem to move any slower. So yeah, there's possibilities.

I'm kind of motivated to try again after all the cool information from everyone, so thanks all! :)

Looks good so far Brick_Nash!

You can absolutely get this to scroll in AMOS without any slow down by using a wide hardware screen. You could get round the limits of that by having the playing walk off the 'section' at the end of the hardware screen and in to a new zone. This is actually quite common in beat em ups from Final Fight to Double Dragon (I suspect some did that because they were using the same method).

I'm using a hidden screen which is 800 pixels wide and scrolling through that using screen copy to the viewport. Not sure if that's the same thing, but I think I get what you are on about with the sections.

Anyway, I've uploaded the source to the Amos Factory forums and hopefully someone will take a peek and tell me what I'm doing wrong.

Using Screen Copy to scroll is very slow. The Amiga has special hardware to scroll (which does not copy the screen). This scrolling hardware is used by the Screen Offset command.

The good news is that if your bitmap/level is 1008 pixels or less wide, you can use Screen Offset without worrying about tiles or anything: just show the 800 pixel wide hidden screen and move it about using the Screen Offset command.

Edit: I'm sure that AMOS comes with a few examples that do just this.

Screen Copy is slow. The X-unlimited scrolling trick is to have a double-width screen plus 3 tile widths. The idea is to blit a tile to the side scrolling on behind the border and the same tile to the side you're scrolling away from also. The reason you blit behind is so you'll have an exact copy of the background image on both sides of the screen by the time you reach the edge of the screen.

roondar & Samurai_Crow - thank you for the info.

EDIT: The Screen Offset instruction really worked! The scrolling is whizzing along now, although the bobs are a bit more flickery than before (not much though). There's definitely issues with my code though as I'm trying it on a 68000 OCS setting and the speed is up and down at times during the attack combos.

I was basically following the "fine scrolling" guide in the Amos Game Maker's manual as it was the only one I had on hand, and it used Screen Copy to scroll.

The full level is something like 3000 pixels wide, but it said in the manual you could easily swap between screens holding different parts of a map when a certain point is reached (which I think was what roondar was saying earlier).