English Amiga Board Amiga Lore


Go Back   English Amiga Board > Coders > Coders. General

 
 
Thread Tools
Old 12 October 2017, 17:14   #301
zero
Registered User

 
Join Date: Jun 2016
Location: UK
Posts: 125
I count six words moved per scanline for three sprites. No sprite bitmap DMA at all.

So in total you need 6 moves for the sprites, 2 for the road fill and two or three to change the palette. That's 11 per scanline.

Compared to blitting which needs you to wait for the blitter to complete, re-load address registers, calculate shift values and load them, then write the control registers. And do the colour palette changes, the same as my scheme. And on multiple bitplanes if you want grass/road/road markings.

In the best case you need 2 bitplanes, assuming you use dual-playfield to avoid having to share bitplanes with objects. And for the next frame you have to clear at least part of what you previously copied if you have hills.

Oh, and while the blitter is running the CPU is losing memory access slots to DMA, and the blitter isn't available to draw objects.

Last edited by zero; 13 October 2017 at 13:20.
zero is offline  
AdSense AdSense  
Old 13 October 2017, 08:26   #302
redblade
Zone Friend

redblade's Avatar
 
Join Date: Mar 2004
Location: Middle Earth
Age: 33
Posts: 1,030
Quote:
Originally Posted by dlfrsilver View Post
A 6 buttons joystick can be used on Amiga. What's the problem ?
Wouldn't it be rather difficult to read all 6 buttons and the control stick for combos? I'm guessing reading the forward, down, down forward + punch would be a struggle on a standard A500. Might be ok on a CD-32 though? a standard direction + 1 of the 6 buttons would be rather easy, but check maybe 3 buttons at once??
redblade is offline  
Old 14 October 2017, 01:42   #303
TuRRIcaNEd
AKA Mr. Rhythm Master/AIS

TuRRIcaNEd's Avatar
 
Join Date: Aug 2017
Location: London, UK
Posts: 34
Quote:
Originally Posted by redblade View Post
Wouldn't it be rather difficult to read all 6 buttons and the control stick for combos?
Why would it be? There were a whole bunch of beat-em-ups which handled combos on the A500. At a guess it'd be a case of setting up a timeout based on the first input from dead-centre, then reading the sequential inputs into a data structure (an array or queue) and testing for specific sequences, triggering an animation sequence if it matches.

The CD32 controller used the same joystick port plug as all other Amigas (which in turn goes all the way back to the Atari 2600 VCS!), so it follows that 7 data pins are enough to read a D-pad plus 6 buttons.

The Amiga Hardware Reference Manual states that the Amiga handles two buttons (equivalent to left and right mouse), but given that the CD32 controller worked just fine with CD32 games on my A1200 back in the day (and I even wrote a little AMOS test program to check the values from the pad/button/pin combinations), I'd say it could always technically use at least 6.
TuRRIcaNEd is offline  
Old 14 October 2017, 03:32   #304
TuRRIcaNEd
AKA Mr. Rhythm Master/AIS

TuRRIcaNEd's Avatar
 
Join Date: Aug 2017
Location: London, UK
Posts: 34
Quote:
Originally Posted by zero View Post
Compared to blitting which needs you to wait for the blitter to complete, re-load address registers, calculate shift values and load them, then write the control registers.
But the whole point of the Lotus method was that the CPU could be set to calculating the next line of the triangle (quite tricky maths for the humble 68k to do quickly as I understand it) while the blitter did the drawing work on the current line. I guess what I'm trying to say is that you may be right that the method for each individual drawing operation might not necessarily have been the most efficient, but it certainly used a "big picture" approach for all of the operations combined to be as efficient as possible.

Quote:
And do the colour palette changes, the same as my scheme. And on multiple bitplanes if you want grass/road/road markings.
Nope, you can do the sky (minus the horizon/background bitmap), the grass, road and markings with a single bitplane image using the copper's ability to palette switch every 4px, plus alternating the overall palette every few scanlines.

[I have some images which demonstrate how this works, but I need to ask the permission of the person who gave them to me]

Quote:
...assuming you use dual-playfield to avoid having to share bitplanes with objects.
I reserve the right to be wrong, but if I understand things roughly correctly I think dual-playfield mode is a bit too restrictive for this application, and here's my thinking... In dual-playfield mode, we're talking two playfields with 3 bitplanes (i.e. 7 colours + 1 transparent) each. This has quite a bit of potential in terms of nifty side-scrolling and parallax tricks, but it has the drawback of keeping each playfield's palette in a silo (i.e. neither playfield can access the other's palette).

Because the sky/grass/road/markings can be done in a single bitplane using copper palette changes, my feeling is that this makes using one playfield for the sky/horizon/road and the other for objects impractical, as the theoretical foreground (object) playfield needs to display the player's Ferrari, the traffic and the roadside objects and would thus require significantly more palette entries available than the background playfield.

From an aesthetic standpoint, I don't think I can remap the Ferrari into less than 7 palette entries without compromising the look-and-feel more than I'd like to. Admittedly using 7 palette entries for a single object sounds somewhat wasteful on the face of it - but on the one hand that sub-palette contains black (universally useful elsewhere), light grey (certainly re-usable) and 3 red/pink shades which could also probably be pressed into service elsewhere on the screen. If worse came to worst, the vast majority of the time those colours aren't required until about Y-co-ordinate 175 (or thereabouts) and you could poke them in with the copper at that scanline - though this would make the high-speed crash animation (where the car is drawn vertically above that line) a bit of a headache.

In general I'm thinking roughly along these lines - single-playfield 4-bitblane mode, with COLOR00 and 01 used for the sky/road/markings, 02 through 09 used for the Ferrari (including the black and light grey which can be used extensively for other objects), 10 through 12 for roadside objects and 13 through 15 for the traffic. I'm hoping to use sprites for the HUD and the couple in the player's car, which will use various combinations of COLOR16 through 31.

Admittedly I haven't worked out the best way to deal with the horizon graphics yet, but frankly we've got many bridges to cross before that becomes a showstopper!

Quote:
And for the next frame you have to clear at least part of what you previously copied if you have hills.
Using a variant of the Lotus method you're redrawing the whole frame every time anyway.

Quote:
Oh, and while the blitter is running the CPU is losing memory access slots to DMA, and the blitter isn't available to draw objects.
Two passes - one for the road, the other for the objects.

Obviously if anyone can spot any gaping flaws in my approach, please tell me!
TuRRIcaNEd is offline  
Old 16 October 2017, 10:57   #305
zero
Registered User

 
Join Date: Jun 2016
Location: UK
Posts: 125
Quote:
Originally Posted by TuRRIcaNEd View Post
Why would it be?
Because you don't understand how the CD32 6 button controller works.

To read the extra buttons it uses a serial protocol. That serial protocol has very significant overhead.

What are these A500 games that support it?
zero is offline  
Old 16 October 2017, 11:10   #306
zero
Registered User

 
Join Date: Jun 2016
Location: UK
Posts: 125
Quote:
Originally Posted by TuRRIcaNEd View Post
But the whole point of the Lotus method was that the CPU could be set to calculating the next line of the triangle (quite tricky maths for the humble 68k to do quickly as I understand it) while the blitter did the drawing work on the current line.
No. On an A500 only the CPU or the blitter can access memory, not both at the same time. So if the blitter is copying data then you have a choice: stop the CPU until it finishes or share bandwidth between the CPU and blitter and both run slower.

The blitter is not free. Using it slows down the CPU. Even on the A1200 you only have a small instruction cache.

The calculations are actually not too bad at all. Lookup tables make it pretty fast. It's the rendering that makes it slow.

Quote:
Nope, you can do the sky (minus the horizon/background bitmap), the grass, road and markings with a single bitplane image using the copper's ability to palette switch every 4px, plus alternating the overall palette every few scanlines.
That scheme would waste half the colour palette and only give you a horizontal resolution of 80 for the road.

Quote:
[I have some images which demonstrate how this works, but I need to ask the permission of the person who gave them to me]
Please do.

Quote:
In general I'm thinking roughly along these lines - single-playfield 4-bitblane mode, with COLOR00 and 01 used for the sky/road/markings, 02 through 09 used for the Ferrari (including the black and light grey which can be used extensively for other objects), 10 through 12 for roadside objects and 13 through 15 for the traffic.
How are you going to make the road use only two colours if you are only rendering into one bitplane for it?
zero is offline  
Old 16 October 2017, 22:08   #307
TuRRIcaNEd
AKA Mr. Rhythm Master/AIS

TuRRIcaNEd's Avatar
 
Join Date: Aug 2017
Location: London, UK
Posts: 34
Quote:
Originally Posted by zero View Post
No. On an A500 only the CPU or the blitter can access memory, not both at the same time.
So you load the values required for the calculation into the data registers, no? Based on what I've been told, the Lotus code was structured such that the next thing to be blitted would always be held in address register a4. That way the CPU should barely have to touch the memory (if at all) whilst the blit is being performed.

Quote:
That scheme would waste half the colour palette and only give you a horizontal resolution of 80 for the road.
With respect, how would it waste half the colour palette? The dual-playfield method would waste more by snaffling two palette entries for transparency (one each per playfield) and restrict each playfield to 8 palette entries which can't be shared.

As far as using the copper to change palette entries horizontally for the road, presuming COLOR00 is being used for the "tarmac" and COLOR01 for the "markings", it's only COLOR01 you'd need to change, and because most of each strip is COLOR00, that can be done inbetween the markings without sacrificing resolution, if I'm not mistaken...

Quote:
How are you going to make the road use only two colours if you are only rendering into one bitplane for it?
Single bitplane is effectively two colours, no? Strictly speaking it would be taking single bitplane data and rendering it into a 4-bitplane display buffer.

As far as the CD32 controller goes, thanks for the heads-up on the serial data feed. Note that I didn't say A500 games used the CD32 controller, I specifically said that some games I had on my A1200 used the CD32 controller (Gloom is one that springs to mind). I might be mis-remembering what I tested with my AMOS program on the A500 (we are talking about 24-25 years ago now...) and later on the A1200 - it could have been a 3-button Mega Drive joystick we had lying around.

Last edited by TuRRIcaNEd; 16 October 2017 at 22:54.
TuRRIcaNEd is offline  
Old 17 October 2017, 12:59   #308
zero
Registered User

 
Join Date: Jun 2016
Location: UK
Posts: 125
Quote:
Originally Posted by TuRRIcaNEd View Post
So you load the values required for the calculation into the data registers, no? Based on what I've been told, the Lotus code was structured such that the next thing to be blitted would always be held in address register a4. That way the CPU should barely have to touch the memory (if at all) whilst the blit is being performed.
Holding the data values in registers doesn't help much because the CPU still needs to fetch instructions from RAM. It also means you can't use a lookup table so how are you going to perform this floating point calculation efficiently without an FPU?

I think what that comment about Lotus means is that A4 is used to communicate with an interrupt triggered when the blitter finishes or something like that. Otherwise it makes no sense.

Quote:
With respect, how would it waste half the colour palette? The dual-playfield method would waste more by snaffling two palette entries for transparency (one each per playfield) and restrict each playfield to 8 palette entries which can't be shared.
It's simple binary mathematics. Say you have 3 bitplanes, 8 colours (to keep it simple). So each pixel's colour is determined by 2 bits, one from each bitplane. And you want to draw the road using only one of those bits.

Here is every possible combination of bitplane 0, 1 and 2:
210
---
000
001
010
011
100
101
110
111

As you can see, changing any bit narrows the choice of the other bits to half the available colours. This is true no matter how many bitplanes you have, each bitplane will always "select" half the palette.

For example, if you render the road on bitplane 0. A 0 is grass, road is 1. Then everything drawn over the grass (0) will use even colours and every drawn over the road (1) will use odd colours. If you switch to bitplane 2 then everything drawn over grass will use colours 0-3, and everything drawn over the road will use colours 4-7.

Quote:
Strictly speaking it would be taking single bitplane data and rendering it into a 4-bitplane display buffer.
So you want to do 4x blitter copies per line, plus copperlist for colour changes... And you think that will be faster than just a copperlist for colour changes a sprite positioning (no bitplane DMA for sprites).
zero is offline  
Old 17 October 2017, 23:04   #309
TuRRIcaNEd
AKA Mr. Rhythm Master/AIS

TuRRIcaNEd's Avatar
 
Join Date: Aug 2017
Location: London, UK
Posts: 34
Quote:
Originally Posted by zero View Post
And you think that will be faster than just a copperlist for colour changes a sprite positioning (no bitplane DMA for sprites).
I didn't say that, I was simply saying that my intention is to start with tried-and-tested methods which, frankly, I stand a chance of understanding.

With a bit of luck we'll have the basis for a simple tech demo sometime early next year - I certainly intend to stick it up on GitHub, so if you want to take it and try implementing your idea, you'd be more than welcome to!

[PS. I do understand how bitplanes work, sir... As I said, the idea is to do it with multiple passes, drawing the road first (while noting object positions), then blitting the horizon/sky, finally drawing the objects in reverse. The objects blitted over the road will reset the planar values in that case I believe...]

[PPS :
Quote:
Originally Posted by zero View Post
Please do. [show the images demonstrating the Lotus road technique]
OK, so in my earlier post I showed the single-bitplane image used as the blit source (this is Lotus 2, but the principle is the same):
Quote:
Originally Posted by TuRRIcaNEd View Post
If I understand this correctly, the following two images show what is generated with the alternate-scanline copper switch turned off. Firstly with a white kerb (COLOR01 = white or light grey) :

Then with a red kerb (COLOR01 = red, then dark grey for the tarmac, then red again for the opposite kerb):


With the copper alternating those values at the required number of scanlines you get this :


Note that the "kerb" is relatively thick horizontally compared to the road markings (at least 4px until some way into the distance). As I understand it this is probably to allow for the OCS/ECS copper's 4px "resolution" when it comes to mid-scanline palette changes.

]

Last edited by TuRRIcaNEd; Yesterday at 00:28.
TuRRIcaNEd is offline  
Old Yesterday, 18:13   #310
zero
Registered User

 
Join Date: Jun 2016
Location: UK
Posts: 125
Your solution ultimately isn't that dissimilar to mine, the main difference being that you want to use bitmaps and I want to use sprites for the road markings and edges.

So if you just changed to using sprites instead of bitmaps you would save a massive amount of blitting, and get some extra colours for free potentially due to sprite palette mapping.
zero 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
general movie discussions gimbal OT - Entertainment 2077 Today 20:22
Japanese Console/Computer RPG discussions Retro-Nerd Retrogaming General Discussion 2 02 April 2009 01:32
Given the recent Scanlines discussions... DamienD request.UAE Wishlist 26 26 April 2007 17:36
Wii Virtual Console / Xbox Live Arcade? killergorilla HOL suggestions and feedback 2 06 March 2007 17:20
Landover's Amiga Arcade Conversion Contest Frog News 1 28 January 2005 23:41

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 20:27.


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