Streets of Rage Amos demo

[Havie]

I get a 'can't access page' when I click on the drive link!

[Brick Nash]

Originally Posted by Havie

I get a 'can't access page' when I click on the drive link!

Try again, I think It was set to restricted before. Sorry.

[d4rk3lf]

It says "please insert volume HD0 in any drive", when I try to run exe inside adf
(emulation with Winuae, later, I will try it on my A500)

[Havie]

Thanks got it now!

[hitchhikr]

Maybe you could try with the Sega Master System sprites and tiles ( [ Show youtube player ]), they are smaller and have less colours, therefore probably more affordable for an A500 remake (tiles and sprites are 8x8 though, it would require more work to staple them together).

Also i see in the character sheets that they are only facing one direction, (left to right) are you flipping them & generating the masks by code or is AMOS doing it all by itself ? (i hope the sprites aren't flipped in real-time because that would be a serious bottle neck).

[Retro1234]

I'd love to have a look if I had the time
alpine9000 raised an interesting points about Sprite priority but this can be done in Amos iirc

I always thought I could beat Blitz for blitting Bobs in Amos if I wrote a routine using Paste Bob and re-stored the screen with pasting tiles instead of using the Bob commands, maybe one day I have look.

another thing I wanted to try that I saw in some examples was someone had writen all the movement with Amal and it was very smooth and I mean he stopped and started it like he wasn't even using Amal if that makes any sense.

[Brick Nash]

Originally Posted by d4rk3lf

It says "please insert volume HD0 in any drive", when I try to run exe inside adf
(emulation with Winuae, later, I will try it on my A500)

Ahh there must be some problem with the paths. Sorry, I didn't think it would matter with a compiled version, but I guess it does. I'm away for the weekend so I'll try to do another one when I get back, or maybe someone else could do their own compile from the source. It should be easy, just search the code for "Load" or "BLoad" commands and change the paths to the right assets folders.

hitchhikr - 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. I don't think I'd want to try another one from scratch, except maybe if I knuckled down and learned assembly. That's a big task though, although I do know Z80 well enough, so maybe 68K won't be such a jump.

Priority is done by Changing Bob numbers when needed, but ATM it only works with one of the enemies as I hadn't figured out a system yet.

[d4rk3lf]

Originally Posted by Brick Nash

Ahh there must be some problem with the paths. Sorry, I didn't think it would matter with a compiled version, but I guess it does. I'm away for the weekend so I'll try to do another one when I get back, or maybe someone else could do their own compile from the source.

Well, not all of us are programmers, and I wouldn't know, how to compile.
Sure, I'll wait... take your time, and thanks.
Or, as you say, anyone that knows, can do it, and upload here.

[Brick Nash]

Originally Posted by d4rk3lf

Well, not all of us are programmers, and I wouldn't know, how to compile.
Sure, I'll wait... take your time, and thanks.
Or, as you say, anyone that knows, can do it, and upload here.

I'd hesitate to call myself a programmer, although I understand now why programmers are a bit eccentric.

I'm more like a monkey with a typewriter.

[Dan]

Hi, there were few troubles with the sourcecode, the most ununderstandable was that the include file could not be loaded ... for whatever reasons.

But its sorted now.

I'v compiled the Game, but it does not fit on a single ADF, (i haven't checked which assets are used/unused) so i have included them all.

Extract the attached archive somewhere, then mount the folder "sora" as a bootable harddrive.

In the Cli window, type SORA to start it.

If you have a workbench installation with functioning HD, you should be able to open the SORA folder and to start it with it's icon.

The (probably) fixed sourcecode (to use relative paths) is attached as well. But the assets are in the sora.7z archive.

[Superman]

Thanks for sharing this and to Dan for releasing a fix. Here it is running on my A600 with Furia acceleration. It runs very well

[ Show youtube player ]

[Brick Nash]

Dan - Thank you very much for taking the time to help.

Superman - That's really cool to see it on actual hardware. Not sure why that first enemy is flashing, that should only happen when his energy is all gone and a "Die" variable is activated. Still, it's awesome as the A600 was my main machine back in the day.

[alain.treesong]

Hello,

I had a look into the source (the original provided by Brick Nash).
Indeed a set of path to fix.
In addition to removing the links to HD0, there are directories to modify (the intro directory and the sounds directory) because the hierarchy is not correct.

For the include, an absolute path must be set.I didn't find how to put a relative path.

After that it works on an A500 config, almost :-) : I had to set 1mega of chip and 1mega of fast.
But in reality memory is a false problem.
I looked at the code very quickly and I see that with better bank and screen management, we should be able to make it work with 512meg of chip and 512kb of fast.

The current screen is huge (1024 wide) because there is no "infinite" scroll routine. It could be implemented with an algo based on a double screen (and not a triple one).

Finally, I got another pb but because of my Amos config (which runs on a 500 emulation) : I don't have the Tome extension (and doesnt want it :-)) . So here it doesn't matter because it's only used to create the scenery at the beginning of the level. So I took a quick look at how the map Tome banks work. So I read it manually (with peek instr to retrieve the icon id), but there must be a pb because the scenery is displayed in a corrupted way. Well it's not a problem for this test. Besides if someone can give me an iff corresponding to the screen, it would allow me to have a clean picture (make "save iff" in direct mode from screen 0)

After that the intro and game can run.

What can I say first is that there is a HUGE work here. The Amos code (intro + main game) without the banks is 150 Kb which is quite important. There are hours and hours of work here
And the game, even it is a kind of engine works.
So congratulations, Brick !


It remains the story of the speed.
With a A500 accurate, config, without compilation, it is about 4 or 5 fps...
When I compile it, I have between 11 and 17 fps. That's not bad because there are probably a lot code improvements that can be done.

You can see here a screen shot with a display of fps I added :


So personnaly, I am not interested in an ocs game running on an accelerated OCS Amiga because my real A500 is a "standard" one (512kb chip, 512kb fast). Of course I can understand that people are ok with a game running on a "big" amiga.

I think this proto can give something really good on a standard A500.
So I can encourage Brick Nash to continue its dev. Or perhaps someone else ?
I have no time for that because of my current game project and some demo/intro I code sometimes.

But here are some ideas :
- the game can be set in a 25 fps update strategy, keeping the scroll in 50 fps.
It can be done in Amos by desactiving the automatic bob update and making the screen swap every 2 vbl but keeping the screen offset for the scroll (which is running on the physical buffer) every vbl. This is the algo I used in the small Intro "Merry and Happy" in the beast part (https://www.pouet.net/prod.php?which=84427), which has sprites (the beast) and the scroll in 50 fps but bobs (the buffalo) in 25 fps. So this works with Amos :-).
- with a great graphist, refactor the game to implement a background in 8 colors and a foreground (the bobs) in 8 colors. The current game here is in 16 colors but it is not so colorfull so I think it is possible to split that. Moreover some copper addition with the (limited) amos command can add colors. The goal of that is that the background doesn't need double buffer (memory improvement) and the bobs in the foreground don't have to save the backgroud under them (and it is simpler to manage the x,y) which make the display faster (using the set bob command)

Again, thanks Brick for the work. Hope someone will work on that.

Aghnar

[DamienD]

A floppy disk version has been created / uploaded to The Zone!

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

Works great in WinUAE using an AGA configuration (2MB Chip & 4MB Fast RAM)

Edit: I should add that it will also work with a standard A500+ configuration, but quite slowly...

[Dan]

Great !

Meanwhile i have saved the 1st level as iff.
If i remember right, the Tome extension is using icons to build the map.

[Samurai_Crow]

Originally Posted by Dan

Great !



Meanwhile i have saved the 1st level as iff.

If i remember right, the Tome extension is using icons to build the map.

Correct. Icon Paste will do that job for an infinite scroller.

Re:sprites
They should be left for spot animation since they can access colors 16-31 in the palette but are too narrow to represent characters.

Re:speed
This is the tricky part. Shallowing the background palette to 7 static colors plus a coppershaded background color won't look as nice but will speed up the blitter. Also, using 7 colors for the bobs in dual-playfield mode will allow the bobs to be double-buffered independently of the background images (which can be single buffered). I'm not sure if the dual playfield mode will be useful with such a shallow palette depth, however.

[Superman]

I did another test using DamienD’s ADF and it unfortunately gurus on my A500. I suspect it needs more than 1mb ram.

[ Show youtube player ]

[manossg]

I just tested it on my A500 w/ ACA500+. It is perfectly playable, it only slows down sometimes while scrolling.

[DamienD]

Originally Posted by Superman

I did another test using DamienD’s ADF and it unfortunately gurus on my A500. I suspect it needs more than 1mb ram.

[ Show youtube player ]

From WinUAE the game works (very slowly) with a standard A500+ configuration i.e:

... Chipset = Full ECS
... ROM = KS ROM v2.04 (A500+) rev 37.175 (512k)
... RAM = 1MB Chip

Edit: just tested with an A500 config. It will work with 1MB Chip but not 512KB Chip & 512KB Slow (same issue as in your video).

[alain.treesong]

@Superman
Yes 1mb chip is necessary (the total amount memory necessary is probably between 1,5 and 2 mb) but this can be fixed of course (it is a 16 colors game in a not so big viewport).

@Dan
Thanks for the iff
So here is a new version (amos and compiled) built from your updated code.
I replace the use of tome by the load of the iff you attached and added a small quick fps counter.
streetOR.7z

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


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


But of couse as I said in my previous message, it is possible to improve this a lot and make it work very well on a a500 standard.
Great job Brick !