31 July 2020, 18:38 | #81 |
Registered User
Join Date: Mar 2012
Location: UK
Posts: 1,893
|
I get a 'can't access page' when I click on the drive link!
|
31 July 2020, 18:49 | #82 |
Prototron
Join Date: Mar 2015
Location: Glasgow, Scotland
Posts: 411
|
|
31 July 2020, 21:59 | #83 |
Registered User
Join Date: Jul 2015
Location: Novi Sad, Serbia
Posts: 1,645
|
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) |
31 July 2020, 22:17 | #84 |
Registered User
Join Date: Mar 2012
Location: UK
Posts: 1,893
|
Thanks got it now!
|
01 August 2020, 00:17 | #85 |
Registered User
Join Date: Jun 2008
Location: somewhere else
Posts: 511
|
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). |
01 August 2020, 01:00 | #86 |
Phone Homer
Join Date: Jun 2006
Location: 5150
Posts: 5,773
|
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. |
01 August 2020, 08:03 | #87 | |
Prototron
Join Date: Mar 2015
Location: Glasgow, Scotland
Posts: 411
|
Quote:
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. |
|
01 August 2020, 09:37 | #88 | |
Registered User
Join Date: Jul 2015
Location: Novi Sad, Serbia
Posts: 1,645
|
Quote:
Sure, I'll wait... take your time, and thanks. Or, as you say, anyone that knows, can do it, and upload here. |
|
01 August 2020, 11:14 | #89 | |
Prototron
Join Date: Mar 2015
Location: Glasgow, Scotland
Posts: 411
|
Quote:
I'm more like a monkey with a typewriter. |
|
01 August 2020, 11:33 | #90 |
Registered User
Join Date: Nov 2004
Location: Germany
Posts: 629
|
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. Last edited by Dan; 01 August 2020 at 11:44. |
01 August 2020, 11:58 | #91 |
Super Member
Join Date: Sep 2014
Location: Wakefield
Age: 48
Posts: 1,334
|
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 ] |
01 August 2020, 12:10 | #92 |
Prototron
Join Date: Mar 2015
Location: Glasgow, Scotland
Posts: 411
|
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. |
01 August 2020, 12:44 | #93 |
Aghnar
Join Date: Jan 2019
Location: France
Posts: 153
|
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 |
01 August 2020, 16:05 | #94 |
Banned
Join Date: Aug 2005
Location: London / Sydney
Age: 47
Posts: 20,420
|
A floppy disk version has been created / uploaded to The Zone!
Streets of Rage (demo-playable) (2020)(Nash, Brick)[AMOS].adfWorks 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... Last edited by DamienD; 01 August 2020 at 17:05. |
01 August 2020, 16:31 | #95 |
Registered User
Join Date: Nov 2004
Location: Germany
Posts: 629
|
Great !
Meanwhile i have saved the 1st level as iff. If i remember right, the Tome extension is using icons to build the map. |
01 August 2020, 16:57 | #96 | |
Total Chaos forever!
Join Date: Aug 2007
Location: Waterville, MN, USA
Age: 49
Posts: 2,186
|
Quote:
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. |
|
01 August 2020, 17:11 | #97 |
Super Member
Join Date: Sep 2014
Location: Wakefield
Age: 48
Posts: 1,334
|
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 ] |
01 August 2020, 17:14 | #98 |
Registered User
Join Date: Nov 2019
Location: Greece
Posts: 992
|
I just tested it on my A500 w/ ACA500+. It is perfectly playable, it only slows down sometimes while scrolling.
|
01 August 2020, 18:10 | #99 | |
Banned
Join Date: Aug 2005
Location: London / Sydney
Age: 47
Posts: 20,420
|
Quote:
... 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). Last edited by DamienD; 01 August 2020 at 18:15. |
|
01 August 2020, 18:11 | #100 |
Aghnar
Join Date: Jan 2019
Location: France
Posts: 153
|
@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 ! |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Streets of Rage 2 with Blitz | Master484 | Coders. Blitz Basic | 48 | 19 April 2020 12:33 |
Streets of Rage I vs II vs III - Which is Best? | ZEUSDAZ | Retrogaming General Discussion | 16 | 15 August 2019 23:53 |
Final Fight vs Streets Of Rage 2 (Which Is Best?) | ZEUSDAZ | Retrogaming General Discussion | 32 | 15 February 2017 20:30 |
Streets of Rage Remake | Retro-Nerd | Retrogaming General Discussion | 10 | 21 April 2011 23:30 |
Streets of Rage for Amiga | The Master | Retrogaming General Discussion | 6 | 17 August 2006 12:26 |
|
|