27 January 2020, 13:23 | #21 |
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
I cant port something that will run at 25fps.
|
27 January 2020, 13:36 | #22 |
Inviyya Dude!
Join Date: Sep 2016
Location: Amiga Island
Posts: 2,770
|
I'd say A500 512k/512k, but I am biased...
|
27 January 2020, 18:29 | #23 | |
Registered User
Join Date: Sep 2004
Location: Poland
Posts: 1,301
|
Quote:
No, it's not working perfectly. When more bigger enemies are on screen game tends to slowdown (e.g. alien-like ones at 3:00~3:30). I had once five of them, game was like slideshow in this moment. |
|
27 January 2020, 20:07 | #24 | |
68k
Join Date: Sep 2005
Location: Somewhere
Posts: 828
|
Quote:
Now I see three options: 1. crunch gfx data and decrunch in fly. 2. store some gfx data in SLOW and use processor to paste it on screen 3. increase requirments to 2mb CHIP - best option for me. Finally I think that I was pretty naive when I started thinking about version for A500 with 0.5 MB CHIP only |
|
27 January 2020, 20:27 | #25 |
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
I have a couple of ideas also and would like some input, however before that please could a mod move the thread to a technical section - or steer me to make a new thread?
Cheers, Geezer |
27 January 2020, 20:38 | #26 |
Banned
Join Date: Aug 2005
Location: London / Sydney
Age: 47
Posts: 20,420
|
Tell me exactly which posts out of this two pronged discussion you want moved to a new "coders" thread and it will be done my friend
|
27 January 2020, 20:49 | #27 |
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
|
27 January 2020, 21:08 | #28 |
Global Moderator
Join Date: Nov 2001
Location: Derby, UK
Age: 48
Posts: 9,355
|
|
27 January 2020, 22:15 | #29 |
J.M.D - Bedroom Musician
Join Date: Apr 2014
Location: los angeles,ca
Posts: 3,520
|
If i remember clearly most RT enemies could be easily split in two - from waist and up; you can do game internals at 25 and enemies update at 50 in Team 17 style and you can use 16 colors for sprites and enemies (plus a subpalette system like powder to save RAM) since RT has no parallax; main hero can have its own 16 colors palette (would even say 8 since the bottom is black pants)
OK i went to check a longplay and i might be wrong in the splitting in two; however some splitting of parts could help since most enemies are identical; the arcade game goes around this because of its 16 color palette per sprite system, an amiga game could take this on a different take and split like two sprites for body, two for head, two for feet, two for gloves or a mix between sprites and bitmap (is getting complex to describe so maybe not a good idea) - Metro siege does split body parts and assembles together but has less enemies and a slower game dynamic. Last edited by saimon69; 27 January 2020 at 22:22. |
27 January 2020, 22:27 | #30 |
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
The masked enemies can be deceptively large (64x58 pixels)... and they are 16 colours.
I'm tinkering with trying to get different colours out of the same bitmap using a 5 bitplane screen but using only 16 colours... like blitting 5 bitplanes then going back and removing one of the bitplanes using the masked bits. It's not going well and this is deceptively tough on the constraints of a an A500. The game will have to run at 50 frames otherwise it will fail. The main sprite I can probably handle with attached hardware sprites and the blitter. The fence as well can be managed with hardware sprites and the priorties changed in the playfield when the guy jumps over... the problems is, the enemies can jump over them too. This isn't easy by any stretch. |
27 January 2020, 22:31 | #31 |
Banned
Join Date: Aug 2005
Location: London / Sydney
Age: 47
Posts: 20,420
|
|
27 January 2020, 23:13 | #32 |
Registered User
Join Date: May 2003
Location: mercury
Posts: 577
|
For A500, instead of a port, would be much better a Conversion adjusting elements for convenience.
Best option could be by reducing the numbers of frames of some anims, and even its size. Also repaint graphics and change whatever be needed. All the colours of RollingThunder could fit in a simply 16 colours palette with no problem. But I see the fences a problem. I think this game would need a real 8-way scroll, because there are parts which scrolls intensively in diagonal. Anyway it would be a reasonable sacrifice if its substituted for a wise fake 8 way scroller. The bigger problem I see is to make fences with sprites. I think fences are too wide to be able to reproduce with sprites. Maybe a layout with DualPlayfield would work for that.. just it will make that paint graphics will be more difficult due to palette limitations. ( as grafician I love that challenge ) So a good layout for having fences would be: Layer 1 - Background 7 colours - Tiles with main stage graphics Layer 2 - Foreground 8 colours - with enemies, enemies projectyles, fences and some obstacles Layer 3 - 1P Sprites and Player Bullets ( maybe flickering the bullets to allow more bullets aligned in same Y-coordinates ) The priority of 1P Sprites channels could be switched respect fences.. I think Last edited by JudasEZT; 27 January 2020 at 23:25. |
27 January 2020, 23:25 | #33 | |
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
Quote:
The arcade sprites are 56 pixels in height and the display is 224 pixels high. They chose to reduce the sprites to 32 pixels and thr display to 128 pixels thus keeping the aspect ratio. I dont want any gfx artists doing any work on this, any work done will be from the arcade board so no repainting of anything. |
|
28 January 2020, 09:49 | #34 |
Inviyya Dude!
Join Date: Sep 2016
Location: Amiga Island
Posts: 2,770
|
|
28 January 2020, 10:04 | #35 |
Coder/webmaster/gamer
Join Date: Oct 2001
Location: Canberra/Australia
Posts: 2,632
|
Maybe it should be a multiload when running on a 512K machine; that way not all graphics data needs to kept in RAM at all times.
|
28 January 2020, 10:38 | #36 | |
Registered User
Join Date: Sep 2004
Location: Poland
Posts: 1,301
|
Quote:
I'm with Graeme about "as close as possible" conversion. Nowadays is AGA chipset and OCS/ECS users can use SAGA driver with Vampire cards. Even RTG (8bit modes are possible on AGA) if it's needed. So today is much less reason than in past to forcing reductions. Mind that (i suppose) it's about graphic reductions, not engine itself... |
|
28 January 2020, 10:56 | #37 |
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
|
28 January 2020, 11:08 | #38 | ||
Registered User
Join Date: Dec 2014
Location: germany
Posts: 439
|
Quote:
You can change priorities between sprites by assigning them to different channels, but I doubt you can do everything that goes in front of the player with sprites, even when multiplexing them. You could mask your player sprite - slower, but still faster than a bob with two masks (shape and foreground), and additional colors. I'd guess in the end you'd need to foreground-mask everything moving, maybe keeping a per-tile flag table in ram so you can quickly determine if a bob in some position may need masking or not. If tiles are bigger than every bob, checking four tiles is enough. May give a lot of false positives, though. Quote:
To be fair, the problem of priorities remains on AGA, but it's probably much easier to work around it with 15 +16 color dual playfield and bigger sprites. And more bandwidth left for the blitter. |
||
28 January 2020, 11:50 | #39 | ||
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,411
|
Quote:
The point about sprite priorities reminds me of something I tested ages ago. Not 100% sure anymore... But I seem to recall you can use the sprite to PF1/PF2 priority settings even when running in single playfield mode. If I'm remembering that correctly, you could (with a lot of fiddling and limitations in colour use) have a sprite display between graphics. Of course, it's questionable whether or not this actually is all that useful in the real world but I thought I'd mention it. Masking out the sprite data, however, will definitely work. Quote:
Last edited by roondar; 28 January 2020 at 11:54. Reason: Rewrote the sprite masking bit to be more clear |
||
28 January 2020, 12:09 | #40 |
Ex nihilo nihil
Join Date: Oct 2017
Location: CH
Posts: 4,860
|
Reading you makes me wonder how really "bad" were some OCS conversions from BitD. Maybe not that much after all...
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Rolling Thunder | Dustyarddog | Games images which need to be WHDified | 5 | 30 January 2020 21:24 |
New Sh*t Game Time video: Rolling Thunder (Amiga) | ZEUSDAZ | Retrogaming General Discussion | 5 | 11 April 2017 00:56 |
Rolling Thunder vs Thunder Jaws | Solo Kazuki | HOL data problems | 1 | 20 June 2016 07:09 |
Rolling Thunder ++ | sareks | support.Games | 9 | 16 September 2010 17:09 |
Rolling Thunder | NfernalNfluence | support.Games | 31 | 05 August 2008 13:42 |
|
|