28 January 2020, 12:30 | #41 | |
Going nowhere
Join Date: Oct 2001
Location: United Kingdom
Age: 50
Posts: 8,994
|
Quote:
Some of those things or one or two, people would have been ok with back in the day. But thats not what Tiertex did, they cut back on EVERYTHING in the conversion until very little remained. I dont expect McGeezer to do a 1:1 conversion because no-one is paying him even Tiertex wages to do it, a couple of compromises here and there, and seeing his skill with Rygar, its plain to me that a much superior conversion is likely. Some compromises dont equate a failed conversion, but Tiertex compromised everywhere, and thats the difference. |
|
28 January 2020, 12:41 | #42 |
Inviyya Dude!
Join Date: Sep 2016
Location: Amiga Island
Posts: 2,773
|
We are talking about a "conversion" that ran around 4 frames a second in a small part of the screen.
I'd like to know how it's even possible for that game to be that slow, even if you are redrawing everything every frame. Add to that, that the Amiga version looks incredibly ugly. This conversion is pure shite. |
28 January 2020, 12:43 | #43 |
Zone Friend
Join Date: Dec 2005
Location: Australia
Age: 50
Posts: 2,616
|
Given what the A500 was pushed to by the end of it's life I think from my personal opinion that a stock 1MB A500 could have EASILY handled Rolling Thunder as a near perfect port.
|
28 January 2020, 13:33 | #44 |
Registered User
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 525
|
If I was making this game for the A500, then I think I would do it this way:
Both the enemies and the Player would be BOBs. The fences and wire meshes would be normal background tiles, but I would also have BOB versions of them, so that when someone goes behind them I can then draw that fence part in the front. And in the beginning of the frame I would sort all moving objects into two groups: those who are behind a fence, and those that are in front of it. And then I just draw the "behind" group first, and then draw the fence pieces, and finally draw the "front" group objects. A sorting system like this is needed to draw everything in the correct Z-order; because often you have stuff like: an enemy behind a fence, and another enemy in the front of the fence, at that same spot, which means 3 layers of objects that have to be drawn in the correct order. And in addition to this, in some levels there are opening doors that are behind those fences, creating a fourth layer of moving objects. --- And about the enemy graphics, them I would handle this way: for most frames I would separate the boots from the main body. The reason is that the boots can be made with 3 colors, so they can be 2 bitplane BOBs. Every enemy will then use these same boots. This in a way "shortens" the enemy graphics height by some 10 pixels. And for the rest of the body I would try to make a unified 8 color palette for all enemy types, if possible. Also when the enemies die, this I would simplify by using only 3 shades of gray for all those frames when the enemy "melts" into the ground, so that all enemies can then use this same death animation. And also the player's pants I would make with those same 3 shades of gray. This would make about half of the player a 2 bitplane BOB, saving a lot of chip RAM. And sprites I would maybe use for the bullets, in combination of BOBs if all sprites are already in use. Or maybe sprites could be used to bring more color to the backgrounds if the game uses 16 color mode. The ceiling fans could be sprites, or maybe the sprites could be behind the playfield, and used for the opening doors, or stuff like that. And I think some enemy types never go behind the fences or come from doors...so they could be sprites. And 25 FPS with occasional slowdowns would be an acceptable frame rate...still much better than the 4 FPS of the Tiertex version. |
28 January 2020, 14:04 | #45 | |||
Registered User
Join Date: Dec 2014
Location: germany
Posts: 439
|
Quote:
Quote:
Quote:
|
|||
28 January 2020, 15:36 | #46 | |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,411
|
Whoops! Missed that bit
Quote:
It's certainly something worth re-testing though. Especially as other playfield related registers work in single playfield mode just fine (f.ex. the playfield shift values). Hmmm, a pity I'm not at my PC right now. Last edited by roondar; 28 January 2020 at 15:50. |
|
28 January 2020, 19:03 | #47 | |
Registered User
Join Date: May 2003
Location: mercury
Posts: 577
|
Quote:
I think a Port of Karnov would be possible.. |
|
28 January 2020, 19:17 | #48 |
Ex nihilo nihil
Join Date: Oct 2017
Location: CH
Posts: 4,884
|
@Galahad : I know and you're right. Simply this is how I percieved the exchanges. Anyway, thanks for re-pointing the situation
|
28 January 2020, 19:28 | #49 |
Junior Member
Join Date: Aug 2001
Location: France
Posts: 1,385
|
|
28 January 2020, 19:54 | #50 |
Banned
Join Date: Aug 2005
Location: London / Sydney
Age: 47
Posts: 20,420
|
|
29 January 2020, 10:45 | #51 |
CaptainM68K-SPS France
|
Well very honestly, Rolling Thunder is not a game i would port on A500. Too many colors, and the sprites are really big.
Otherwise, if A500, the only way would be to use a dynamic loading system, like the one used on St dragon and ninja warriors, which would allow to gain memory permanently, and also keep the amount of colors highest possible. |
29 January 2020, 11:11 | #52 | |
Inviyya Dude!
Join Date: Sep 2016
Location: Amiga Island
Posts: 2,773
|
Quote:
First off, no parallax that eats into DMA time whatsoever. Then, there are rarely more than 3 enemies on screen at the same time. Size around 48x50. Which leaves the colours. I would do a prototype that checks how many bitplanes are possible with 4 48x50 sized BOBs on screen with a triple buffer. I feel this might be very doable on a plain A500 with at least 16 colours, but maybe even 32. in 50 fps off course. |
|
29 January 2020, 11:20 | #53 | |
Going nowhere
Join Date: Oct 2001
Location: United Kingdom
Age: 50
Posts: 8,994
|
Quote:
It shouldnt really have been used on SWIV, it would have been far better to have the game copying from ram instead. |
|
29 January 2020, 12:17 | #54 |
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
I'm quite confident that the processing power behind the A500 is capable of getting all the required enemies on screen, it's roughly 6 * 48x64px x 4 bitplanes ... however that's not what the key problem is.
The key problem is getting all the sprites into chip ram. One available option is to take the Tiertex graphics and re-program the game with them instead (I would fix the display size though to 192 height). Unless I can find a solution to have one enemy set from the arcade sprites but with different colours then only AGA will be able to do it simply because it has the required chip ram. |
29 January 2020, 12:43 | #55 | |
CaptainM68K-SPS France
|
Quote:
And yes as Graeme pin pointed, the data size is a problem :/ many differents sprites/elements to crave in ram..... |
|
29 January 2020, 21:16 | #56 |
J.M.D - Bedroom Musician
Join Date: Apr 2014
Location: los angeles,ca
Posts: 3,529
|
I did chose this image because is crowded; see how enemy uses two colors for body, three for hood, two for pants ,three for badge and gun, two for gloves. Ninjas use just two colors overall. I wonder how feasible is to split an enemy in several parts to save space and then recombine him for display |
29 January 2020, 21:51 | #57 | |
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
Quote:
(which might be necessary). |
|
29 January 2020, 21:59 | #58 |
68k
Join Date: Sep 2005
Location: Somewhere
Posts: 828
|
@saimon69
Great example to explain how save memory for enemy sprites. as far as I remember all four enemies from your screenshots share the same frames but differ colours. Its very easy to do this on Amiga. One enemy frame has 32x64x4 stored as four 1 bpl frames/blocks (as sequence), frame = 4 blocks (block0, block1, block2, block3), more technically there are four memory blocks 32x64 pixels ( 4 * 64 = 256 bytes). So enemy frame takes 1024 bytes. Of course you need mask which takes 256 bytes. To blit enemy you need 4 blits. blit 1 - block0, blit 2 - block1, blit 3 - block2, blit 4 - block3 If you change order of blocks then you will have enemy with differ colors blit 1 - block1, blit 2 - block0, blit 3 - block2, blit 4 - block3 But I am pretty sure that trick is well known for programmers But the problem is to organize colors in proper way, I think. Even with this idea I am think that 512KB CHIP is not enough. Too many objects with many frames, especially I mean about later levels when objects with differ levels are mixed. |
29 January 2020, 22:43 | #59 | |
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
Quote:
Attached is the frames I have extracted for the main sprite. To do this I used MAME and disabled the tiles, recorded the video and then used.. Code:
ffmpeg -i video.avi -r 60/1 frames%03d.png The hero guy I can get into 412 lines at 4 bitplanes... (82Kb). What is the feeling around a 1mb chip ram A500/OCS? I know back in the day I had an expansion that gave me 1mb chip and 1 mb fast total. Geezer |
|
29 January 2020, 23:47 | #60 | |
Going nowhere
Join Date: Oct 2001
Location: United Kingdom
Age: 50
Posts: 8,994
|
Quote:
1Meg chip came with the later 1.3 Kickstart about 6 months before the A500+ came out I think. |
|
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 |
|
|