English Amiga Board


Go Back   English Amiga Board > Other Projects > project.Amiga Game Factory

 
 
Thread Tools
Old 28 January 2020, 12:30   #41
Galahad/FLT
Going nowhere

Galahad/FLT's Avatar
 
Join Date: Oct 2001
Location: United Kingdom
Age: 46
Posts: 7,617
Quote:
Originally Posted by malko View Post
Reading you makes me wonder how really "bad" were some OCS conversions from BitD. Maybe not that much after all...
Not really. People accept compromises have to be made, maybe less enemies onscreen, maybe smaller enemies, maybe remove some anim frames to keep ram requirements simple.

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.
Galahad/FLT is offline  
Old 28 January 2020, 12:41   #42
Steril707
Tigerskunk!

Steril707's Avatar
 
Join Date: Sep 2016
Location: Amiga Island
Posts: 1,515
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.
Steril707 is offline  
Old 28 January 2020, 12:43   #43
blade002
Zone Friend
blade002's Avatar
 
Join Date: Dec 2005
Location: Australia
Age: 46
Posts: 2,538
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.
blade002 is offline  
Old 28 January 2020, 13:33   #44
Master484
Registered User
Master484's Avatar
 
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 433
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.
Master484 is offline  
Old 28 January 2020, 14:04   #45
chb
Registered User

 
Join Date: Dec 2014
Location: germany
Posts: 253
Quote:
Originally Posted by chb View Post
You could mask your player sprite - slower, but still faster than a bob with two masks (shape and foreground), and additional colors.
Quote:
Originally Posted by roondar View Post
You could solve the solve the issue of hardware sprites moving between objects by masking out part of the sprite data with the Blitter as and when needed. This is clearly slower than just using a hardware sprite, but still much faster than using a bob.


Quote:
Originally Posted by roondar View Post
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.
Oh, that's very cool, thanks for the info! I guess this means priorities behave exactly like in dual playfield with regard to the bitplanes, but colors like in single playfield mode? That would mean that e.g. for 2 + 2 bpl mode colors 0,2,8,10 would go behind the sprites (because bits in plane 1 and 3 are 0, so transparent in dpf) and the rest in front of them, when sprites are setup to be between PF1 and PF2. Hmmm, that would even be quite usable for some scenarios. Don't know if it helps for Rolling Thunder, as the enemies can also go behind a lot of things and have to be drawn with bobs, but interesting anyway!
chb is offline  
Old 28 January 2020, 15:36   #46
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,984
Quote:
Originally Posted by chb View Post
Whoops! Missed that bit

Quote:
Oh, that's very cool, thanks for the info! I guess this means priorities behave exactly like in dual playfield with regard to the bitplanes, but colors like in single playfield mode? That would mean that e.g. for 2 + 2 bpl mode colors 0,2,8,10 would go behind the sprites (because bits in plane 1 and 3 are 0, so transparent in dpf) and the rest in front of them, when sprites are setup to be between PF1 and PF2. Hmmm, that would even be quite usable for some scenarios. Don't know if it helps for Rolling Thunder, as the enemies can also go behind a lot of things and have to be drawn with bobs, but interesting anyway!
That's how I remember it, yes. But: please be aware that although I'm relatively sure this works, I'm still talking about one of many random tests I did over three years ago. So it's also possible I'm mixing stuff up here. Hence my caveat

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.
roondar is offline  
Old 28 January 2020, 19:03   #47
JudasEZT
Registered User
JudasEZT's Avatar
 
Join Date: May 2003
Location: mercury
Posts: 571
Quote:
Originally Posted by Solo Kazuki View Post
And in many cases that's the reason of bad ports. Cut here, cut there, reduce colors, drop some frames, lower memory requirements, etc. And the next "worse than..." game will appear.

Mind that (i suppose) it's about graphic reductions, not engine itself...
Nah.. its a matter of taste. It doesnt mean that make a conversion have to be a bad Tiertex game.

I think a Port of Karnov would be possible..
JudasEZT is offline  
Old 28 January 2020, 19:17   #48
malko
Ex nihilo nihil

malko's Avatar
 
Join Date: Oct 2017
Location: CH
Posts: 2,803
@Galahad : I know and you're right. Simply this is how I percieved the exchanges. Anyway, thanks for re-pointing the situation
malko is offline  
Old 28 January 2020, 19:28   #49
Frog
Junior Member

Frog's Avatar
 
Join Date: Aug 2001
Location: France
Posts: 1,321
Quote:
Originally Posted by JudasEZT View Post
I think a Port of Karnov would be possible..
Karnov is a wonderful game.
Wardner can be possible to be ported on amiga imo too.
Frog is offline  
Old 28 January 2020, 19:54   #50
DamienD
disengaged
DamienD's Avatar
 
Join Date: Aug 2005
Location: London / Sydney
Age: 43
Posts: 17,513
Quote:
Originally Posted by Frog View Post
Wardner can be possible to be ported on amiga imo too.
Wardner is friggin' awesome. Would be very cool to have an Amiga port

.Same as Legend of Hero Tonma or Blood Bros.

...but we are getting way off topic here.
DamienD is offline  
Old 29 January 2020, 10:45   #51
dlfrsilver
CaptainM68K-SPS France
dlfrsilver's Avatar
 
Join Date: Dec 2004
Location: Melun nearby Paris/France
Age: 43
Posts: 8,440
Send a message via MSN to dlfrsilver
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.
dlfrsilver is offline  
Old 29 January 2020, 11:11   #52
Steril707
Tigerskunk!

Steril707's Avatar
 
Join Date: Sep 2016
Location: Amiga Island
Posts: 1,515
Quote:
Originally Posted by dlfrsilver View Post
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.
I'd object here.
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.
Steril707 is offline  
Old 29 January 2020, 11:20   #53
Galahad/FLT
Going nowhere

Galahad/FLT's Avatar
 
Join Date: Oct 2001
Location: United Kingdom
Age: 46
Posts: 7,617
Quote:
Originally Posted by dlfrsilver View Post
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.
The type of loading used in those games is not some kind of free no penalty resource, valuable DMA resources are lost for that loading process, and not suited to high action games.

It shouldnt really have been used on SWIV, it would have been far better to have the game copying from ram instead.
Galahad/FLT is offline  
Old 29 January 2020, 12:17   #54
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 1,832
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.
mcgeezer is offline  
Old 29 January 2020, 12:43   #55
dlfrsilver
CaptainM68K-SPS France
dlfrsilver's Avatar
 
Join Date: Dec 2004
Location: Melun nearby Paris/France
Age: 43
Posts: 8,440
Send a message via MSN to dlfrsilver
Quote:
Originally Posted by Galahad/FLT View Post
The type of loading used in those games is not some kind of free no penalty resource, valuable DMA resources are lost for that loading process, and not suited to high action games.

It shouldnt really have been used on SWIV, it would have been far better to have the game copying from ram instead.
Well indeed. However, NW and STD ran with 512k of chip only. Wonder what it would do with 2mb of ram.

And yes as Graeme pin pointed, the data size is a problem :/

many differents sprites/elements to crave in ram.....
dlfrsilver is offline  
Old 29 January 2020, 21:16   #56
saimon69
J.M.D - Bedroom Musician

 
Join Date: Apr 2014
Location: los angeles,ca
Posts: 1,420


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
saimon69 is offline  
Old 29 January 2020, 21:51   #57
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 1,832
Quote:
Originally Posted by saimon69 View Post


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
It would mean I have to upgrade the shit out of my sprite driver.

(which might be necessary).
mcgeezer is offline  
Old 29 January 2020, 21:59   #58
Asman
68k

Asman's Avatar
 
Join Date: Sep 2005
Location: Somewhere
Posts: 727
@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.
Asman is offline  
Old 29 January 2020, 22:43   #59
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 1,832
Quote:
Originally Posted by Asman View Post
But I am pretty sure that trick is well known for programmers But the problem is to organize colors in proper way, I think.
yep - this is what I've been looking at. With each block having a 2 bit/4 colour combination I can't get the colours to work properly.

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
which has produced alot of frames that I've then extracted.

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
Attached Thumbnails
Click image for larger version

Name:	albatross_sprites.png
Views:	91
Size:	19.0 KB
ID:	66047  
mcgeezer is offline  
Old 29 January 2020, 23:47   #60
Galahad/FLT
Going nowhere

Galahad/FLT's Avatar
 
Join Date: Oct 2001
Location: United Kingdom
Age: 46
Posts: 7,617
Quote:
Originally Posted by mcgeezer View Post
yep - this is what I've been looking at. With each block having a 2 bit/4 colour combination I can't get the colours to work properly.

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
which has produced alot of frames that I've then extracted.

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
I think there are more 512kchip/512kslow machines than there are 1meg chip.

1Meg chip came with the later 1.3 Kickstart about 6 months before the A500+ came out I think.
Galahad/FLT is offline  
 


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

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 19:30.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Page generated in 0.10149 seconds with 14 queries