English Amiga Board


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

 
 
Thread Tools
Old 27 January 2020, 13:23   #21
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 1,696
I cant port something that will run at 25fps.
mcgeezer is offline  
Old 27 January 2020, 13:36   #22
Steril707
Tigerskunk!

Steril707's Avatar
 
Join Date: Sep 2016
Location: Amiga Island
Posts: 1,357
I'd say A500 512k/512k, but I am biased...
Steril707 is offline  
Old 27 January 2020, 18:29   #23
Solo Kazuki
Registered User
Solo Kazuki's Avatar
 
Join Date: Sep 2004
Location: Poland
Posts: 739
Quote:
Originally Posted by d4rk3lf View Post
Not sure how this relevant is, but Amiga game Deliverance had a very large sprites.
I was very impressed when I discovered it recently.
Works perfectly on A500

[ Show youtube player ]

Yeah, the sprites are probably 25fps... oh well... that's why I said I don't know how relevant is.

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.
Solo Kazuki is offline  
Old 27 January 2020, 20:07   #24
Asman
68k

Asman's Avatar
 
Join Date: Sep 2005
Location: Somewhere
Posts: 717
Quote:
Originally Posted by mcgeezer View Post
And this is what worries me, some of the enemy animations are huge.
I'll take the first step and extract all the graphics and see where things stand.
I'll report back here but it isn't clear cut - however I am keen on a "what could have been scenario for the A500".
Indeed, i just checked albatros https://www.spriters-resource.com/ar...r/sheet/32986/ and there are about 90 frames (89 if I count correct). So even if we assume 48x64x4 then it takes 136704 bytes (89 frames). Also I tried to count maskers frames in MAME and I failed, too many heads, other bodies and so on.. but I assume that there is also about 70 or more frames for one type of maskers. There are for sure 3 differ types so finally 210 frames (one frame 32x64x4) takes 215040 bytes. What about tiles, masks for enemies, balcony, mesh.

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
Asman is offline  
Old 27 January 2020, 20:27   #25
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 1,696
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
mcgeezer is offline  
Old 27 January 2020, 20:38   #26
DamienD
Global Moderator

DamienD's Avatar
 
Join Date: Aug 2005
Location: London / Sydney
Age: 43
Posts: 16,865
Quote:
Originally Posted by mcgeezer View Post
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
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
DamienD is offline  
Old 27 January 2020, 20:49   #27
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 1,696
Quote:
Originally Posted by DamienD View Post
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
I think everything from and including post #31 would be ideal buddy.

Nice one!
mcgeezer is offline  
Old 27 January 2020, 21:08   #28
BippyM
Global Moderator

BippyM's Avatar
 
Join Date: Nov 2001
Location: Nottingham, UK
Age: 44
Posts: 8,948
Quote:
Originally Posted by DamienD View Post
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

I've just logged in to sort this.. Thanks pal
BippyM is offline  
Old 27 January 2020, 22:15   #29
saimon69
J.M.D - Bedroom Musician

 
Join Date: Apr 2014
Location: los angeles,ca
Posts: 1,302
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.
saimon69 is offline  
Old 27 January 2020, 22:27   #30
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 1,696
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.
mcgeezer is offline  
Old 27 January 2020, 22:31   #31
DamienD
Global Moderator

DamienD's Avatar
 
Join Date: Aug 2005
Location: London / Sydney
Age: 43
Posts: 16,865
Quote:
Originally Posted by mcgeezer View Post
I think everything from and including post #31 would be ideal buddy.

Nice one!
Done
DamienD is offline  
Old 27 January 2020, 23:13   #32
JudasEZT
Registered User
JudasEZT's Avatar
 
Join Date: May 2003
Location: mercury
Posts: 570
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.
JudasEZT is offline  
Old 27 January 2020, 23:25   #33
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 1,696
Quote:
Originally Posted by JudasEZT View Post
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.
I’m beginning to see why Tiertex did what they did with the display.

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.
mcgeezer is offline  
Old 28 January 2020, 09:49   #34
Steril707
Tigerskunk!

Steril707's Avatar
 
Join Date: Sep 2016
Location: Amiga Island
Posts: 1,357
Quote:
Originally Posted by mcgeezer View Post
I’m beginning to see why Tiertex did what they did with the display.
I never thought I'd read that sentence on this forum...

(btw, what happened with your new AGA game, Geezer? )
Steril707 is offline  
Old 28 January 2020, 10:04   #35
Minuous
Coder/webmaster/gamer
Minuous's Avatar
 
Join Date: Oct 2001
Location: Canberra/Australia
Posts: 2,029
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.
Minuous is offline  
Old 28 January 2020, 10:38   #36
Solo Kazuki
Registered User
Solo Kazuki's Avatar
 
Join Date: Sep 2004
Location: Poland
Posts: 739
Quote:
Originally Posted by JudasEZT View Post
For A500, instead of a port, would be much better a Conversion adjusting elements for convenience.
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.

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.


Quote:
Originally Posted by Steril707 View Post
Quote:
Originally Posted by mcgeezer View Post
I’m beginning to see why Tiertex did what they did with the display.
I never thought I'd read that sentence on this forum...
Mind that (i suppose) it's about graphic reductions, not engine itself...
Solo Kazuki is offline  
Old 28 January 2020, 10:56   #37
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 1,696
Quote:
Originally Posted by Steril707 View Post
I never thought I'd read that sentence on this forum...

(btw, what happened with your new AGA game, Geezer? )
No graphics guy mate.

Might still keep it on the back burner though.
mcgeezer is offline  
Old 28 January 2020, 11:08   #38
chb
Registered User

 
Join Date: Dec 2014
Location: germany
Posts: 228
Quote:
Originally Posted by mcgeezer View Post
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.
The problem here, if I'm not mistaken, are the priorities in single playfield mode. Sprites can only go in front of or behind everything that is bitmap (well, apart from color 0 of course), so you cannot have your player sprite in front of the background but behind some other bitmap object. And the player goes behind a lot things (fences, meshes, stairs, enemies..) while being still in front of some background graphics. Most consoles have priorities per tile, something the Amiga is sorely missing.

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:
This isn't easy by any stretch.
Yep. And if you go AGA people will still complain because the game graphics look very simple (and quite awful IMHO), so they assume it should be easy on OCS.

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.
chb is offline  
Old 28 January 2020, 11:50   #39
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,710
Quote:
Originally Posted by chb View Post
The problem here, if I'm not mistaken, are the priorities in single playfield mode. Sprites can only go in front of or behind everything that is bitmap (well, apart from color 0 of course), so you cannot have your player sprite in front of the background but behind some other bitmap object. And the player goes behind a lot things (fences, meshes, stairs, enemies..) while being still in front of some background graphics. Most consoles have priorities per tile, something the Amiga is sorely missing.
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.


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:
Yep. And if you go AGA people will still complain because the game graphics look very simple (and quite awful IMHO), so they assume it should be easy on OCS.
This is oh so true. I guess it's just hard to see at a glance whether or not a system can do stuff.

Last edited by roondar; 28 January 2020 at 11:54. Reason: Rewrote the sprite masking bit to be more clear
roondar is offline  
Old 28 January 2020, 12:09   #40
malko
Ex nihilo nihil

malko's Avatar
 
Join Date: Oct 2017
Location: CH
Posts: 2,674
Reading you makes me wonder how really "bad" were some OCS conversions from BitD. Maybe not that much after all...
malko 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 02:34.


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