Streets of Rage Amos demo

[DamienD]

How do you start this alain.treesong?

Extracted all files from your archive to hard disk... there's no game exe.

And what's with "Streets_of_Rage_with_intro.AMOS" and "Streets_of_Rage_with_intro_C.AMOS"; both aren't needed are they?

I'd also say drop the "FPS counter" though.

[Dan]

Hi, here is a small info:

When i tried to compile the sourcecode, the include file just wont load.
(the include file is/was the Intro.Amos)

I have tried with and without the path, and it just refused to load.
Then i decided to save the intro as ascii, and merged it manually with the main file, and saved it as:

Streets_of_Rage_with_intro.AMOS

I see, "Streets_of_Rage_with_intro_C.AMOS" is the Amos Pro compiled program (compiled, but runable
only in/from amos editor)
The other (without _C) is the sourcecode of it.

[alain.treesong]

Yes, it is more a version for (amos) coder. So the fps counter is interesting
There is the .amos with all the assets and also an amos compiled one but to be executed in the amos pro editor.
The only difference with the version you used is the counter and the removal of the tome dependencies but the other things are the same.

Anyway, here is a amiga executable version (the assets must be the same that provided with Dan version) to be included after unzip in an adf for example
streetOR.zip

[DamienD]

Originally Posted by alain.treesong

Anyway, here is a amiga executable version (the assets must be the same that provided with Dan version) to be included after unzip in an adf for example
Attachment 68348

You mean same as with what was provided with Dan version; plus the "level1.iff" that you added?

This won't fit on disk without some magic.

[alain.treesong]

Indeed I forgot to say that the level1.iff must be in the "Backgrounds" folder...

So to avoid other pb, here is a complete distrib, with the assets, the .amos, the compiled .amos and the executable file (streetOR) I provided in the last message.
streetOfRage.zip

[Master484]

The flipping is done using the $8000 function when needed. I didn't think it'd be an issue on the Amiga as I've done some Amstrad demos where the sprites are flipped on the fly and it works fine.

Most likely the real time BOB flipping is one of the main reasons for the slowdown. According to the AMOS Pro manual the $8000 function is a hexadecimal version of the "HREV" command. Blitz Basic has a similar command called "XFlip", and it is super slow, and I suspect that the AMOS equivalent is about as slow.

Some computers and consoles have hardware based sprite flipping, and can therefore do it instantly (Amstrad is probably one of them). But when you mirror blitter objects on the Amiga, there is no hardware acceleration of any kind. Even when the image data flipping is done in assembly, from what I have understood, you still need a 128 kilobyte look-up table to do it fast enough.

But if you can somehow fit enough animations into Chip RAM without real time flipping, then maybe you can avoid the problem.

[DamienD]

Originally Posted by DamienD

You mean same as with what was provided with Dan version; plus the "level1.iff" that you added?

This won't fit on disk without some magic.

Originally Posted by alain.treesong

Indeed I forgot to say that the level1.iff must be in the "Backgrounds" folder...

So to avoid other pb, here is a complete distrib, with the assets, the .amos, the compiled .amos and the executable file (streetOR) I provided in the last message.
Attachment 68350

Thanks, but just finished using sorcery to create an .ADF out of your "alternate" version

The following .ADF has now been created / uploaded to The Zone!

Streets of Rage (demo-playable) (2020)(Nash, Brick)[m alain.treesong][AMOS].adf

...unfortunately though, this version no longer works with only 1MB Chip (background is blank).

Works fine with:

Originally Posted by alain.treesong

Here is the result:
For A500 (68000 at 7mhz but with 1meg of chip, 1meg fast) : the fps are between 7 and 17 in the game depending of the displayed sequences
Attachment 68346

For A1200 (vanilla : 020, 2mb chip and no fast) : the fps are between 15 and 25.
Attachment 68347

[DamienD]

Originally Posted by DamienD

I'd also say drop the "FPS counter" though.

@alain.treesong; your version is definitely quicker.

Do you think you could compile a version without the FPS counter; and then I'll then make an .ADF?

[alain.treesong]

@DamienD

Here is a version without the fps counter.
streetOR.zip

It is the same source than the Dan version except the iff instead of using Tome.
So if it is quicker, it probably comes from the compiler.
The compilation uses a version of Amos pro I built from the last version of F.Lionet (2.0) + Amcaf + Amos turbo + little enhancements by Amos Factory.
I link this version :
AMOSPro_Community_2020_1.zip

[DamienD]

Perfect, thank you kindly Alain

So now in The Zone! you will find:

... Streets of Rage (demo-playable) (2020)(Nash, Brick)[m alain.treesong][AMOS][with FPS].adf [your old file]
... Streets of Rage (demo-playable) (2020)(Nash, Brick)[m alain.treesong][AMOS].adf [your newest file]

[Retro1234]

Nash managed to display the background as a Map but you've replaced it with an IFF? this is a step backwards.

[Brick Nash]

Wow, lot been happening in a few hours!

alain.treesong - thank you for the new version and all your advice. It's great to hear stuff like that because I have no clue what to even look for in my code to be able to optimise it, so that's valuable information.

Dan and DamianD - thank you also for helping to compile properly to adf. I've still no clue what to do really.

Just to say, I noticed that there was a couple of bugs in the demo from watching Superman's much appreciated playthrough. The flashing enemy is a mystery as it's fine on my PC, but the other bug was that the enemies will get trapped in their "punch" state until hit again (something that I was working on but never finished). If the player scrolls the screen past them while this happens the enemies won't re-spawn as the remaining enemy will be off screen still punching away. I've fixed this by using alain's new source, so they will break out of punching if the player is outside the attack range.

I don't know how to compile it as fast as alain's version, but this is the fixed (uncompiled) source (FPS counter deactivated as well):
https://drive.google.com/uc?export=d...7RmmdgRQt-3ubr

Regarding the flipping, if it's that much of a bottleneck I could write something in the slicer which imports the chunks off the sheet, then uses HREV to flip it, draw it on a hidden screen, then re-import it into the bank. This would save having another sheet and would be done in loading time, so it wouldn't affect the game.

As for displaying the entire map level, I've not worked that out yet. Creating a big screen and just scrolling through it is the only method I know, but that's limited to 1023 pixels wide (that's why I split the level map into three chunks). The full level map is there, (L1_16x16_TOP.map) but I don't know how to apply it.

Anyway, thanks for all the effort and interest folks!

[alain.treesong]

Hi all,

@DamienD

In fact, to be honest, it is more the source of Brick (of course) and Dan because Dan fixed all the path problems and integrates the include. I only add the iff instead of the use of Tome and the fps counter.
So we can say it more a version like that :-) :
Streets of Rage (demo-playable) (2020)(Nash, Brick)[m EAB members][AMOS]


@Retro1234
The iff is temp. solution to replace the use of Tome. Tome is too slow to be used in a game like that.
So it is not a backward. But that's sure not big progress ;-)


@Brick Nash
To do an infinite horizontal scroll, here is an algo you can use:

- open a double width screen + a little margin. For example 320*2+32.
+--------+--------+
+A B C D|A B C D
+--------+--------+
---^player

The player sees the first ABCD image at the begining

- then, while scrolling with screen offset, build the following of the scenery by copying icon E (paste icon or better f paste icon from Amos Turbo)
+-+--------+------+
+E|B C D E | B C D
+-+--------+------+
---------^player
You have to copy also E in the beginning of the screen. Now the player sees BCDE

- Continue the process until the scroll has reached 320 :
+--------+--------+
+E F G H|E F G H
+--------+--------+
------------- ^player
Now the player sees EFGH but in the right part of the screen. So we can't scroll more at right. BUT we have built exactly the same image in the left part of the screen, so if we scroll offset to 0, the player can't see the difference but he is now came back at the beginning of the screen
+--------+--------+
+E F G H|E F G H
+--------+--------+
----^player

So we can continue the same process infinitely.


Another thing : I see in the code the use of the bob instruct in the main loop.
The bob initializes all the things so it is a relative slow process.
The idea is more to initialize the bobs at the beginning and then in the main loop to modifty the postions and image by using amal. It is faster.


To finish with that, because I have another project in the works, here's one last thing:
I speak about splitting the render into two parts : the back with the scenery and the front for the bobs. The problem is that we lose the 16 colors palette to a palette 8 + 8 (in fact 8 + 7). So I try to reduce the scenery to 8 colors + rainbow. Here is the result. Not so bad for an image which was not designed for this palette :



So perhaps the solution can be studied

Bye bye.
Aghnar

[DamienD]

Originally Posted by Brick Nash

Just to say, I noticed that there was a couple of bugs in the demo from watching Superman's much appreciated playthrough. The flashing enemy is a mystery as it's fine on my PC, but the other bug was that the enemies will get trapped in their "punch" state until hit again (something that I was working on but never finished). If the player scrolls the screen past them while this happens the enemies won't re-spawn as the remaining enemy will be off screen still punching away. I've fixed this by using alain's new source, so they will break out of punching if the player is outside the attack range.

Heya Brick,

I have experienced the "enemies will get trapped in their punch state until hit again", but never the one that Superman's video shows.

Great that this is now fixed

Originally Posted by Brick Nash

I don't know how to compile it as fast as alain's version, but this is the fixed (uncompiled) source (FPS counter deactivated as well):
https://drive.google.com/uc?export=d...7RmmdgRQt-3ubr

Now all we need is someone to compile your fixed version and I'll make another .ADF

Originally Posted by alain.treesong

@DamienD

In fact, to be honest, it is more the source of Brick (of course) and Dan because Dan fixed all the path problems and integrates the include. I only add the iff instead of the use of Tome and the fps counter.
So we can say it more a version like that :-) :
Streets of Rage (demo-playable) (2020)(Nash, Brick)[m EAB members][AMOS]

Good idea

[d4rk3lf]

Ok, I recorded video on my A500 with Aca500+
It's 68000 processor that can go up to 42Mhz.
It has 1MB Chip ram, and 7MB other ram.

I tested all speeds, at 7,21,28, and 42Mhz.

It was with Dan file he uploaded (thanks Dan), because I haven't seen alain.treesong version by the time I recorded.

Here it is:
[ Show youtube player ]

Personally, I haven't felt difference between 28, and 42Mhz, and even on highest speed, it can slow down from time to time (I suspect, it's because of the 1MB chip ram).
On 14Mhz, it's a little sluggish (when all 3 enemies are around).

However
Never, anytime in my life, I've played beat em up on my Amiga, with this great gameplay (not even Golden Exe).
Brick Nash did amazing job on gameplay. Amiga desperately needs beat em ups like this.

Originally Posted by DamienD

I have experienced the "enemies will get trapped in their punch state until hit again"

Yeah bro.
Exactly like in my video at 1:05, right?
I noticed they get stuck like that, sometimes.

[DamienD]

Originally Posted by d4rk3lf

Personally, I haven't felt difference between 28, and 42Mhz, and even on highest speed, it can slow down from time to time (I suspect, it's because of the 1MB chip ram).

No it's not RAM related. The same thing happens if you run the game with an AGA (2MB Chip & 4MB Fast RAM) configuration.

As soon as there are 2 or 3 enemies on screen; the game slows down.

[Samurai_Crow]

AmosPro redraws all bobs each frame. Graphics.library generates a damage list in contrast.

[Brick Nash]

Originally Posted by DamienD

Heya Brick,
Now all we need is someone to compile your fixed version and I'll make another .ADF

You can try with this if you want?

I downloaded and installed alain.treesong's faster compiler and is used it with the updated code to create a CLI file (I think that's what was used on the disk).

This version fixes the punch issue and I've also made the player hitbox a bit more generous as I noticed that folk were getting stuck between enemies while punching and nothing was colliding.

I've NO idea if it'll work, because the installation of the compiler was a bit flaky, but it's maybe worth a try?

https://drive.google.com/uc?export=d...vQKHzVMnMsE4K7

And this is an updated version of the uncompiled source:
https://drive.google.com/uc?export=d...7RmmdgRQt-3ubr

Originally Posted by d4rk3lf

Never, anytime in my life, I've played beat em up on my Amiga, with this great gameplay (not even Golden Exe).
Brick Nash did amazing job on gameplay. Amiga desperately needs beat em ups like this.

Cheers for the kind words dude! I just wish it ran a bit faster on lower spec machines.

[Retro1234]

Ok I agree, I never liked Tome but did like Shadow Software.
Yeah you can scroll faster without Tome, Tome is just software scrolling. But don't in general like demos with just IFF unless it's a static screen etc.


an easier way of horizontal scrolling is the corkscrew and if your only scrolling right its even easier and there was someone on this forum I can't find the thread found a way to disable the screen bob clipping so if it works you won't even need to reposition the Bobs.

found it http://eab.abime.net/showthread.php?t=87636

But this won't actually be faster than how he was doing if I understand he was opening one large screen 1024 horizontally and filling it with tiles? and then Hardware scrolling(screen offset) to the end then re-populating it? so this won't actually be faster,but smaller size bitmaps and slightly less memory.

but be great if someone had the time and swapped out the main hero for a Sprite instead of a bob and gave him the speed increase he wanted.

[d4rk3lf]

I will join Flat Earth Society, if no one continue developing this.