English Amiga Board Amiga Lore


Go Back   English Amiga Board > Coders > Coders. General

 
 
Thread Tools
Old 19 September 2013, 21:36   #41
Codetapper
2 contact me: email only!

Codetapper's Avatar
 
Join Date: May 2001
Location: Auckland / New Zealand
Posts: 3,128
Quote:
Originally Posted by Mrs Beanbag View Post
The only bit of parallax I'd be keen to keep is the bit with the giant sun in the background, because that has a lot of character and is quite distinctive. One could do that with two sprites to define the edges of the sun (changing the X-position of the sprites on each line), with the copper changing the background colour to fill in between them.
The only problem with that technique is if you are using colour 0 as black, setting sprites to appear behind the bitplanes and changing colour 0 to the yellow of the sun when required, it means you cannot include colour 0 in any objects that may overlay the sun. You can get around it by having a second black (or near black) palette entry, or refrain from using black.

Other techniques like having the sprites appear above certain bitplanes cause further problems with objects being obscured by the sun or having to do a lot of extra blitting.
Codetapper is offline  
AdSense AdSense  
Old 20 September 2013, 00:24   #42
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Quote:
Originally Posted by Michael Parent View Post
That is indeed an awesome solution for the big sun back layer Lonewolf10!
Yeah, thanks Lonewolf10, that's some good thinking there.

Quote:
Originally Posted by Codetapper View Post
The only problem with that technique is if you are using colour 0 as black, setting sprites to appear behind the bitplanes and changing colour 0 to the yellow of the sun when required, it means you cannot include colour 0 in any objects that may overlay the sun. You can get around it by having a second black (or near black) palette entry, or refrain from using black.
The background behind the sun is a dark red anyway, so you'd need another palette entry for black in any case.

Last edited by TCD; 10 February 2015 at 00:00. Reason: Back-to-back posts merged.
Mrs Beanbag is offline  
Old 09 February 2015, 23:56   #43
tarr
Registered User
tarr's Avatar
 
Join Date: Sep 2006
Location: Italy
Posts: 72
After all these years, after lionheart, kid chaos, mr nutz, jim power and other great games experenced amiga coders still think that the amiga c
ould not run a 50 fps rygar?
tarr is offline  
Old 10 February 2015, 08:16   #44
Hewitson
Registered User
Hewitson's Avatar
 
Join Date: Feb 2007
Location: Melbourne, Australia
Age: 34
Posts: 2,235
Of course it could, even the 64 does. The issue is doing a perfectly accurate reproduction of the arcade game. It's likely that some compromises would have to be made on the graphics.
Hewitson is offline  
Old 10 February 2015, 11:42   #45
sandruzzo
Registered User
 
Join Date: Feb 2011
Location: Italy/Rome
Posts: 1,101
The only way to answer to all questions is to do it!
sandruzzo is offline  
Old 13 February 2015, 22:16   #46
saimon69
Bedroom musician

 
Join Date: Apr 2014
Location: los angeles,ca
Posts: 652
ok am not a coder but this is how i would treat things in paper, then don't know about how feasible it is.

Plus am tihnking at OCS/ECS machines

First to gain time i would treat things at 25fps so to have a full 16 color for backgrounds, then other 16 for enemies.
Background parallax layer is pretty generic so can even be a rolling bitmap pushed in the holes of foreground
sunset you could use a sprite 4 well chosen colors sohuld be enough
sky we use a opperlist same for lower ground part with lava.

Player could be two 16c sprites plus shield as some 4c sprites (shield rotates so not too much definition)

If someone is willing to expand/debate on this let me know.

Last edited by saimon69; 13 February 2015 at 22:17. Reason: typos
saimon69 is offline  
Old 13 February 2015, 22:29   #47
Galahad/FLT
Going nowhere

Galahad/FLT's Avatar
 
Join Date: Oct 2001
Location: United Kingdom
Age: 44
Posts: 6,504
I think the best effort would be to pick an arcade machine thats doable, and hey.... do it.
Galahad/FLT is online now  
Old 13 February 2015, 22:34   #48
saimon69
Bedroom musician

 
Join Date: Apr 2014
Location: los angeles,ca
Posts: 652
in my opinion rygar is doable as number of colors, music and stuff on screen; was 1986 hardware so not that powerful: will need some tricks but can be done
saimon69 is offline  
Old 14 February 2015, 07:20   #49
sandruzzo
Registered User
 
Join Date: Feb 2011
Location: Italy/Rome
Posts: 1,101
I think is could be dono with a lot of good. We could use a tecnique like Lionheart to have a lots of color on screen. With a little flicker we could easly have 16 color for each playfield on OCS/ECS. But all must go on 50fps
sandruzzo is offline  
Old 18 February 2015, 17:56   #50
sandruzzo
Registered User
 
Join Date: Feb 2011
Location: Italy/Rome
Posts: 1,101
someone would like to see it for real on amiga? With Gfx I could try to do it..
sandruzzo is offline  
Old 18 February 2015, 18:03   #51
dlfrsilver
CaptainM68K-SPS France
dlfrsilver's Avatar
 
Join Date: Dec 2004
Location: Melun nearby Paris/France
Age: 40
Posts: 7,063
Send a message via MSN to dlfrsilver
you mean if someone can rip the tiles in IFF format, you try ?
dlfrsilver is offline  
Old 18 February 2015, 18:04   #52
sandruzzo
Registered User
 
Join Date: Feb 2011
Location: Italy/Rome
Posts: 1,101
Quote:
Originally Posted by dlfrsilver View Post
you mean if someone can rip the tiles in IFF format, you try ?
Yes I could do it. We need just to plan it. What would ne the target platform
? Ocs/Ecs or Aga?
sandruzzo is offline  
Old 19 February 2015, 04:58   #53
Nekoniaow
Banned

 
Join Date: Dec 2014
Location: Montreal
Posts: 129
Quote:
Originally Posted by Codetapper View Post
  1. Would you go for 32 colours/half-brite/dual playfield mode?
  2. What memory requirements do you think you could achieve?
  3. What would you use the 8 sprites for?
  4. Would you drop the parallax layer or make it smaller?
  5. Do you think you could make a version of the game running at 50 frames per second or you'd go for 25 (or perhaps 25 for updating everything but smooth scrolling the screen at 50fps to fake it)
  6. How would you handle the water animation? Would you use colour cycling?
  7. Would you double, triple or even single buffer the screen?
Coders, step up to the plate and scribble down your initial thoughts!
  1. Screen mode:
    I would not forego DMA bandwidth and colours on the altar of parallax scrolling.
    Even if one could manage to faithfully reproduce the original colours using only a palette of seven you would barely have enough DMA time available to cookie cut blit all the monsters. This said, what counts is the number of colours per scanline and Rygar can have way more than seven just on the foreground: uglies and scenery reach way higher than that.
    I would start prototyping with five bitplanes then scale that down if the blitter load becomes too much to handle even with double buffering.
    In order to save DMA bandwidth for blitter use I would reduce bitplane depth on the bottom part of the screen, clearly the lava does not require more than three bitplanes (even maybe just two) and the part just above might just need one more. One could possibly reuse the same palette entries for both during the parts where no monsters roam in that place but I'm not sure it's worth the hassle.
  2. Memory:
    If you stream everything from disk as the game progresses (which frankly all games written today ought to do) then 512k should be enough. Out of kindness for A1000 users maybe we should try a 256k version.
  3. Sprite usage:
    Main character and its weapon of course.
    I would reserve the rest for parallax scrolling assistance: when vertical walls scroll in/out or when a vertical section of tree is in the foreground.
  4. Parallax:
    It does not seem that hard to reproduce in many situations. There are many parts of the game where the foreground overlaps the background only over a relatively thin horizontal slice which means that all parts of the background which lie above can simply be hardware scrolled. For these parts you don't even need to use repeating sprites as you suggested. The third image of your initial post (cf http://eab.abime.net/showpost.php?p=908453&postcount=1) is a good example of it and this kind of situation is quite frequent.
    It could be troublesome to handle transitions to places with walls but they don't seem to contain a lot of baddies moving so maybe that can be blit (these are full copies except for the last word so they are DMA efficient). Also the texture of the walls is very repetitive so repeating sprites could possibly be used there.

    Even the places with trees in the foreground do not seem above reach: sprites could be used for the portion of the trees which are purely vertical and they could be repeated horizontally by sacrificing accuracy to the original. It's not that all obvious though but it's worth trying.

    The second to last level seems the hardest as the foreground playfield extends vertically and has quite a few holes. This said blitting parallax scrolling is usually efficient if you deal with large holes: only the first and last word of the blit need to be cookie cut, the middle portions can just use A and D, also you don't need to copy all bitplanes unless you are clearing objects from the previous frames.
  5. frame rate: 50 fps or nothing, it makes a huge difference in the feel of the game. Sacrifice everything else.
  6. Water animation.
    I would try to stay closer to the original and thus not use colour cycling.
    For the early level part I would simply be heavy handed and double/triple buffer the slices of the screen where water flows since the water animation seems at most three frames long.
    Since it concerns only a limited fraction of the screen and it's already likely that double buffer should be used anyway then this would be a very cheap way to animate without actually copying anything.
  7. buffer depth: I would likely double buffer in order to smooth out the complexities of blitting multiple monsters and possibly parts of the parallax scrolling. But I would double buffer only the parts of the screen which require it: no point in double buffering the top of the screen where very few things happen. Only the middle bottom part usually needs it.

Also a few notes in response to the kittens who said "hey easy for an Amiga" :

Rygar has a lot more than 32 colours on screen and more importantly per scanline: something the copper cannot help you cope with. With dual playfield, one is limited to 15 colours per scanline, and for this particular game it means that foreground scenery and monsters must share 7 colours together: this cannot possibly be good looking.
Edit: Note that Lionheart's monsters are designed with this limitation in mind: they share the same colours as the foreground layers, however Rygar's monsters contain many colours which are not part of the foreground layer.

Also in dual playfield mode you have zerovery little DMA bandwidth available for the blitter and CPU while the screen is being displayed: everything must be done during the off-screen moments and that is not much given how many creatures move onscreen at times.

Doing parallax scrolling in four or five bitplanes without the help of dual playfield is usually very hard if the structure of the playfields does not lend itself to it. Thankfully Rygar level design lends itself to it nicely in many places (but not all!).

Finally note that the C64 has it very easy contrary to the Amiga because it does have a tiled screen mode: by just updating 40x20+ characters the whole screen can be redrawn. And a tiled mode makes parallax scrolling very easy as well since you can encode the parallax effect in the tiles.
The Amiga is not powerful enough to redraw the whole screen each frame so it cannot do full screen parallax scrolling in five bitplanes unless the layout of the screen is very accommodating.

Quote:
Originally Posted by Codetapper View Post
The 5th pic with the sun could possibly be done with a copperlist changing the background colour to yellow near the middle of the screen and use sprites 6 and 7 to hide the colour change.
Why do you say "hide" the colour change?
The copper can wait anywhere on screen so you can change the background color at any pixel you want. Unless you want to have colourful edges you don't need sprites at all except for the top and bottom lines, and then you need only one since you can reuse it vertically.

Quote:
Then you'd only have to blit the thin black strip.
You don't even have to blit it.

If the sun is pure background colour then there is nothing to blit. Just set another colour of the background to black and you're done, hardware scroll that layer at a different speed than the bottom part and that's it.

Quote:
Originally Posted by phx View Post
Although I know about this technique, and suggested it myself, I never used it.

Did you collect any experience about the impact it has on the game's performance? For example when I'm repositioning 2 sprites on the whole 320x240 display area, will the CPU and Blitter lose a lot of cycles to access the Chip RAM bus? Is it noticeable in a way, that you can for example only blit 20 16x16 BOBs instead of 50?
The copper can only work on odd cycles so at most it will steal 4 DMA words per 16 pixels which is the equivalent of 4 bitplanes. With 6 bitplanes, in EHB or HAM and one copper move instructions per 16 pixels you consume as much DMA as 8 bitplanes total and have zero blitter or CPU DMA available while displaying.

If you are using a 4 bitplanes mode, moving two sprites so they fill the screen will consume one move per 16 bit, that is the equivalent of two bitplanes. It can give very nice results but it's actually quite costly. Hence my remarks about "sprite repeat counters" in this thread: http://eab.abime.net/showpost.php?p=...&postcount=177.

When you think about it it's wasted DMA because the time spent to update one sprite position every 16 pixels could be used to draw a two bitplanes playfield in full parallax (if the hardware had eight planes registers) while this technique only allows to draw a repeating background of width 64128 pixels at most.

Last edited by TCD; 19 February 2015 at 06:41. Reason: Back-to-back posts merged.
Nekoniaow is offline  
Old 19 February 2015, 09:24   #54
sandruzzo
Registered User
 
Join Date: Feb 2011
Location: Italy/Rome
Posts: 1,101
Why don't do it for Both Ecs/ocs and Aga? I would allow us to have a good conversion for ecs/ocs and perfect one for Aga..

Maybe we can use sprite even for enemies, at least the ones that fly up to the screen.

If Someone can provide my some gfx, I can try to put something on the screen and see how it works.

with dual-playfield mode we can use the second layer to hold some enemies and have them with differt colors from the ones on the foreground layer

Last edited by TCD; 21 February 2015 at 13:50. Reason: Back-to-back posts merged.
sandruzzo is offline  
Old 21 February 2015, 13:10   #55
sandruzzo
Registered User
 
Join Date: Feb 2011
Location: Italy/Rome
Posts: 1,101
A great amiga game: Ruff 'n' Tumble.


http://www.lemonamiga.com/games/details.php?id=920

We could use +512 k of real fast ram, in order to speed up a little this game. And again in order to aid blitter to go full gas we can try to use triple buffer, so we can have a better cookie-cut stuff.

Any fellow amiga graphics that have the good will to do it? I can program this conversion.

Last edited by TCD; 21 February 2015 at 13:49. Reason: Back-to-back posts merged.
sandruzzo is offline  
Old 21 February 2015, 15:14   #56
dlfrsilver
CaptainM68K-SPS France
dlfrsilver's Avatar
 
Join Date: Dec 2004
Location: Melun nearby Paris/France
Age: 40
Posts: 7,063
Send a message via MSN to dlfrsilver
I can do my best to allow you to get a perfect rip of Rygar Graphics
dlfrsilver is offline  
Old 21 February 2015, 18:10   #57
Hewitson
Registered User
Hewitson's Avatar
 
Join Date: Feb 2007
Location: Melbourne, Australia
Age: 34
Posts: 2,235
I feel the need to argue with many of the posts in this thread. Is an accurate conversion of Rygar not possible with most coders? Possibly. Is it possible with someone who has a C64 level of dedication? Absolutely.
Hewitson is offline  
Old 21 February 2015, 21:00   #58
Rebel-CD32
Amiga will never die!
Rebel-CD32's Avatar
 
Join Date: Nov 2004
Location: Gold Coast, Australia
Age: 36
Posts: 516
Send a message via MSN to Rebel-CD32
If somone can provide all of the graphics assets I'd love to help by coming up with the optimal palette, colour-reducing and remapping the graphics. It may not sound like much, but by doing this process manually I can produce superior results to any automatic colour-reduction feature in graphics software.
Rebel-CD32 is offline  
Old 21 February 2015, 21:18   #59
sandruzzo
Registered User
 
Join Date: Feb 2011
Location: Italy/Rome
Posts: 1,101
Wow we have a team Here! I'm on it. We do the best. We just have to do some tecnicall choices. We go for 32 colors or 16 color, and play aroud with copper?

About screen size I'll keep the original, so we can spare some cicles to use for blitting and stuff like that
sandruzzo is offline  
Old 21 February 2015, 21:20   #60
sandruzzo
Registered User
 
Join Date: Feb 2011
Location: Italy/Rome
Posts: 1,101
For the main player we have zero issue: we are going to use 4 hw sprite with 16 color.
sandruzzo is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
rygar? Prosonic support.Games 7 09 June 2013 14:18
two more that borrow heavily from Rygar & Black Tiger NfernalNfluence Nostalgia & memories 5 30 September 2012 18:57
SCIENCE 451-RYGAR: same disks mrodfr project.TOSEC (amiga only) 0 26 December 2006 15:38
Wordworth conversion vertigo support.Apps 5 09 December 2003 14:46

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 01:50.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.32076 seconds with 13 queries