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: 126
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: 35
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: 35
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: 126
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: 126
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: 35
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: 126
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: 35
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; 18 October 2017 at 00:28.
TuRRIcaNEd is offline  
Old 18 October 2017, 18:13   #310
zero
Registered User

 
Join Date: Jun 2016
Location: UK
Posts: 126
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  
Old Yesterday, 20:57   #311
TuRRIcaNEd
AKA Mr. Rhythm Master/AIS

TuRRIcaNEd's Avatar
 
Join Date: Aug 2017
Location: London, UK
Posts: 35
Quote:
Originally Posted by zero View Post
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.
The question is how you propose to use the sprites for that. I may be misunderstanding, but it seems like a hell of a lot of complexity any way I see it. Could you elaborate on how you'd use them?
TuRRIcaNEd is offline  
Old Yesterday, 22:52   #312
coder76
Registered User

 
Join Date: Dec 2016
Location: Finland
Posts: 19
This problem is probably possible to solve with sprite multiplexing, under OCS/ECS you can cover whole screen with a single sprite, by writing manually each 16 bit spritedata into sprite POS and DAT registers. But there is only time for the copper to change one of the DAT registers, so only 1 color is possible, and in lores, only 4 bitplanes can be used, or else bitplane DMA starts using too many cycles, and copper is slowed down to much.

The copperlist would look as following, for one sprite (spr0datb is set to 0 somewhere else)

dc.w waitY,$fffe ;first line of spritedata
dc.w spr0pos, yposxpos
dc.w spr0data,data00
dc.w spr0pos, yposxpos
dc.w spr0data,data01
...
dc.w waitY,$fffe ;second line of spritedata
dc.w spr0pos,yposxpos
dc.w spr0data,data10
dc.w spr0pos,yposxpos
dc.w spr0data,data11
...
end of copperlist

Here, ypos and xpos must be filled in with CPU with correct values, and gaps can be left, so that the sprite doesn't need to cover every pixel on screen. Only one sprite can be multiplexed in this way at a time, and the rest of sprites should be still available for normal use. There should also be time for color changes with copper on start of each line, before sprite data starts.

The idea with 3 sprites and attempting to cover all road markings with those won't work well, as they are just 16 pixels wide and the road is bending in x-direction. Reusing sprites in y-direction leaves a gap of 1 pixel between sprites, if done with spriteDMA, so you will possibly get holes in road markings.

Last edited by coder76; Yesterday at 23:16. Reason: looks like only 1 color sprite is possible with this method
coder76 is offline  
Old Today, 09:48   #313
zero
Registered User

 
Join Date: Jun 2016
Location: UK
Posts: 126
Look at the road bitmap. The edges and road markings are just lines of a given width. The width doesn't even change between most lines, only occasionally. So all you need to draw them are some 1 pixel high sprites that are the width of the line, and a copperlist to set the X coordinate every line.

You don't need bitmap DMA for them, when you want to change the width of the line you can just write that data directly into SPRxDAT with the copper.

coder76 has the right idea. I'd use multiple sprites though, as none of the road markings or edges are ever more than 16 pixels wide anyway.
zero is offline  
Old Today, 11:03   #314
sandruzzo
Registered User
 
Join Date: Feb 2011
Location: Italy/Rome
Posts: 1,105
On Aga, we can use copper only for changing shift register and bitmap pointer for each roads' scan line! If we use a pre animated road, we can archive full texture road!
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
general movie discussions gimbal OT - Entertainment 2077 Yesterday 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 17:48.


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