It is currently Thu Jul 19, 2018 7:00 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 77 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next
Author Message
PostPosted: Sat May 12, 2018 11:09 pm 
Offline

Joined: Tue Feb 07, 2017 2:03 am
Posts: 478
Okay...

C64
320x200 bitmap with 2 colours from the 16 per 8x8 block.
160x200 bitmap with 3 colours from the 16 per 8x8 block + 1 global background per screen.
320x200 char map with 1 colour from the 16 per 8x8 block + 1 global background per screen.
160x200 char map with 1 colour from the lower 8 colours per 8x8 block + 3 global background colours per screen. You can intermix 320x200 1 colour from the lower 8 per 8x8 block + 1 global background per screen.
320x200 char map with 1 colour from the 16 per 8x8 block with 4 background colours to choose from but only 1 per 8x8 block. This comes at the cost of only having 1/4 the amount of chars to select from.

Sprites
8 per raster line
24x21, 1 colour + transparency
12x21 1 colour + 2 colours shared with all 8 sprites + transparency
each sprite can be expanded 2x in the X and/or Y giving you twice the size but same pixel count

Enhanced modes
FLI - this forms a bad line every line so you loose the first 3 char rows to single colour grey, but you get 1 colour per 8x1 and then 3 colours per line at 160x400 interlaced
See also NUFLI, MUFLI XFLI etc for fixes and other compromises
Borders can be opened, allowing sprites to appear in the borders, there is also a single control byte for what is drawn in the border area.
Sprite stretching is also possible allowing you to duplicate Y rows as much as you like

Priority
A Sprite can appear behind char data or in front of char data. In Multi colour mode it can appear in front of background colour + mCol1 but behind Char colour + mCol0 allowing you to put the sprite behind somethings and in front of other things.

Amiga 500 ECS
320x200,320x400,640x200,640x400 2,4,8,16,32,HalfBirght(~64),HAM(~4096) colours
640x480 progressive, 1280x200/256 (NTSC/PAL) 2,4 colours
You can also enable Overscan to paint over the "border" for more pixels
Dual playfields lets you have a 8colour + 7 colour and Transparent screen giving you 2 "planes"
Sprites 16xasTallAsYouLike 3 colours + transparent, you can bolt 2 sprites together to make a 14 colour sprite. There is 8 per line however you can plex sprites on the same scan line to overcome the limit. Sprites are always "lores" so the use pixels as if they are in 320x200
Sprites can be behind the bitmap, above all bitmap or between the playfields in Dual Plane Mode
Blitter this is a fully programmable blitter than also has built in line drawing and polyfill instructions, this allows you to and,or,eor upto 3 planes to a single target plane
Copper this is basically HDMA, its a custom programmable chip that lets you modify any video register whenever you like, however unlike HDMA it is not limited to HBlank and can run anywhere in the frame
The Amiga has hardware windows, (7 or 8 I think ) that allow you to render different parts of the screen in different resolutions and with unique pallets, not used often in games but if you are making a strategy game it can be handy.


Top
 Profile  
 
PostPosted: Sun May 13, 2018 6:39 am 
Offline
Formerly Espozo
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3348
Location: Nacogdoches, Texas
Thank you for finally compiling this! :beer: If you're actually programming for the C64, you should have an explanation for how these limitations exist due to memory, but they should really still have an easy to understand overview...

Character based modes are a lot worse than I would have thought... I don't really know all of the full ramifications of using either bitmap mode but, uhh, it clearly leads to better results: ("Another World" (not the one you're thinking of) on C64) https://youtu.be/fcNxoXwnFWY

One thing I guess you forgot to mention about the Amiga 500, is how much sprite color memory is there? Do you typically have Copper multiplex the sprites, because the majority of Amiga games definitely don't have that 8/4 sprite per line limitation.


Top
 Profile  
 
PostPosted: Sun May 13, 2018 7:29 am 
Offline

Joined: Tue Feb 07, 2017 2:03 am
Posts: 478
So the Commodore 64 has a 2Mhz bus, the VIC chip gets 1 half cycle the CPU gets the other. Its a shared RAM system. The VIC is limited to see 16K at a time. the VIC has a private 4bit bus to CRAM which is made up of Nybbles.

For each char the VIC needs, CRAM data, Char number and then 8 char bytes to draw it. So to get all the data it needs 4bits of CRAM, 8bits of Char num and then 8bits of Each char for that line it is to draw
Code:
Cycl-# 6                   1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 3 3 4 4 4 4 4 4 4 4 4 4 5 5 5 5 5 5 5 5 5 5 6 6 6 6
       3 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1
        _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
    ø0 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
       __
   IRQ   ________________________________________________________________________________________________________________________________
       ________________________                                                                                      ____________________
    BA                         ______________________________________________________________________________________
        _ _ _ _ _ _ _ _ _ _ _ _ _ _ _                                                                                 _ _ _ _ _ _ _ _ _ _
   AEC _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _________________________________________________________________________________ _ _ _ _ _ _ _ _ _

   VIC i 3 i 4 i 5 i 6 i 7 i r r r r rcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcg i i 0 i 1 i 2 i 3
  6510  x x x x x x x x x x x x X X X                                                                                 x x x x x x x x x x

Graph.                      |===========01020304050607080910111213141516171819202122232425262728293031323334353637383940=========

X coo. \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
       1111111111111111111111111110000000000000000000000000000000000000000000000000000000000000000111111111111111111111111111111111111111
       89999aaaabbbbccccddddeeeeff0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff000011112222333344445555666677778888999
       c048c048c048c048c048c048c04048c048c048c048c048c048c048c048c048c048c048c048c048c048c048c048c048c048c048c048c048c048c048c048c048c048

c Access to video matrix and Color RAM (c-access)
g Access to character generator or bitmap (g-access)
0-7 Reading the sprite data pointer for sprite 0-7 (p-access)
s Reading the sprite data (s-access)
r DRAM refresh
i Idle access

x Read or write access of the processor
X Processor may do write accesses, stops on first read (BA is low and so is RDY)
This is a DMA steal case. There are 40chars per Row, and they take 40 clocks to draw. The VIC and CPU are in perfect sync.
Code:
Cycl-# 6                   1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 3 3 4 4 4 4 4 4 4 4 4 4 5 5 5 5 5 5 5 5 5 5 6 6 6 6
       3 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1
        _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
    ø0 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
       __
   IRQ   ________________________________________________________________________________________________________________________________
       ________________________                                                                                      ____________________
    BA                         ______________________________________________________________________________________
        _ _ _ _ _ _ _ _ _ _ _ _ _ _ _                                                                                 _ _ _ _ _ _ _ _ _ _
   AEC _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _________________________________________________________________________________ _ _ _ _ _ _ _ _ _

   VIC i 3 i 4 i 5 i 6 i 7 i r r r r r g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g i i 0 i 1 i 2 i 3
  6510  x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x

Graph.                      |===========01020304050607080910111213141516171819202122232425262728293031323334353637383940=========

X coo. \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
       1111111111111111111111111110000000000000000000000000000000000000000000000000000000000000000111111111111111111111111111111111111111
       89999aaaabbbbccccddddeeeeff0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff000011112222333344445555666677778888999
       c048c048c048c048c048c048c04048c048c048c048c048c048c048c048c048c048c048c048c048c048c048c048c048c048c048c048c048c048c048c048c048c048

Sprites need 1 fetch for their PTR ( like tile in NES) and then 3 bytes to fetch a row 24bits. this is done in the borders of which the borders are wide enough to fetch 8 sprites worth. Again it does a DMA steal so it grab 4 bytes is "2 cycles"
The reason why the resolution drops to 160 vs 320 is it would have to halt the CPU for the entire screen in order to get double the data down the bus.
A Screen uses 1000 bytes for the screen map, colour is stored in CRAM which is seperate from the 64K, and the char set is 256*8 = 2K of data. So a Screen with chars take 3K a bitmap is 1000x8.
Hires uses the Screen map to hold 2 nybbles for the 2 colours, aaaabbbb this lets it fetch 2 colours per 1 byte.
Multicolour uses the Screen map to hold both multicolours and then CRAM to hold the extra colour. Again this does not change the bandwitdh needed.
EEBM is a hires char mode, so uses 1000 for the screen map, 64x8 for the chars. So it uses the chars in the screen as
XXaaaaaa XX = background colour 0-2 and then aaaaaa = char what they should have done is still keep all 256 just have it so each "bank of 64" could have a different colour.
Every single step, trick, feature, access, memory access of the VIC-II is documented here in extreme detail http://www.zimmers.net/cbmpics/cbm/c64/vic-ii.txt
But basically the vic gets 1 byte per character per line normally, and 4 bytes of data per sprite per line. This is 7 out of 8 lines, on the other line it DMA steals and gets 2bytes + 4bits of private bus per character. You can sacrifice CPU and force the VIC to "bad line" every line and hence it gets all new data per line for more colours. Or you can stop it from doing "bad lines" and shift the screen down ( see FLD) or even stop it for ever and hold a image in just its internal buffers and trash RAM for the extreme demo trick )


Top
 Profile  
 
PostPosted: Sun May 13, 2018 7:33 am 
Offline

Joined: Tue Feb 07, 2017 2:03 am
Posts: 478
Amiga 500
Most games don't use sprites, they suck. Or you use them for hud, cursors, background layers etc to which you Plex them in the same row using the copper.
The "sprites" you see are BOBs Blitter OBjects, you use the blitter chip to shift and move around bits of bitmap really fast and build the games image that way. hence Shadow of the beast has really big things as its not bound by sprite limits but a fill limit which it can work around by offseting the planes start to make a "cylinder scroller"( I think this was Shadows big trick, it was the first to do it ) and things like that. It eats RAM, can eat DMA but gives total freedom.


Top
 Profile  
 
PostPosted: Sun May 13, 2018 8:10 am 
Offline
Formerly Espozo
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3348
Location: Nacogdoches, Texas
Oziphantom wrote:
The "sprites" you see are BOBs Blitter OBjects, you use the blitter chip to shift and move around bits of bitmap really fast and build the games image that way.

Hmm... The only thing is, wont sprites then have to share the BG colors? That's fine for 6bpp, but not really for 3bpp...

It sounds like you'd have to go to town with the Amiga's windows if you want a reasonably colorful image in dual playfield mode.


Top
 Profile  
 
PostPosted: Sun May 13, 2018 8:16 am 
Offline

Joined: Tue Feb 07, 2017 2:03 am
Posts: 478
Yes, they must share the palette, I think even the sprites have some palette overlap, not really done that much hardcore A500 stuff.

Dual Platfields can usually end up as 1 = background, 2 = "sprites"


Top
 Profile  
 
PostPosted: Sun May 13, 2018 8:18 am 
Offline
Formerly Espozo
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3348
Location: Nacogdoches, Texas
Hmm... I'm assuming performance will be shit if you just try and render two layers and objects to one 6bpp bitmap...


Top
 Profile  
 
PostPosted: Sun May 13, 2018 8:49 am 
Offline

Joined: Tue Feb 07, 2017 2:03 am
Posts: 478
you have ~1 million bits per second, so it depends on how you want to use them.


Top
 Profile  
 
PostPosted: Sun May 13, 2018 9:39 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7443
Location: Chexbres, VD, Switzerland
TmEE wrote:
Both of those machines are framebuffer based, without any tiles and whatnot (except C64 in its character modes). Framebuffer sits in main memory that is shared by CPU, and accessible as normal RAM to the CPU.

Not necessarly. The C64 can also work with a tilemap-like scheme, and that's what the vast majority of games uses I think, if you want to scroll you have pretty much no choice.

The confusing thing with C64 is that when switching to 2BP mode (either BG or sprites) they use two bits for the colours of two consecutive pixels, effectively halfing the horizontal resolution, but in the official documentation they call the two consecutive pixels "a pixel", even though this is wrong. There's no 160x200 mode, it's just 320x200 with every BG pixel being duplicated. The proof that the resolution is still high internally is that you can fine-position sprites.


Top
 Profile  
 
PostPosted: Sun May 13, 2018 9:56 am 
Offline

Joined: Mon Apr 16, 2007 10:07 am
Posts: 117
lidnariq wrote:
That makes more sense... it's also not what the c64 wiki says here

The C64 wiki is wrong. Here's a quote from the C64 Programmer's Reference Guide:
Quote:
MULTI-COLOR BIT MAP MODE

Like multi-color mode characters, multi-color bit map mode allows you to display up to four different colors in each 8 by 8 section of bit map. And as in multi-character mode, there is a sacrifice of horizontal resolution (from 320 dots to 160 dots). Multi-color bit map mode uses an 8K section of memory for the bit map. You select your colors for multi-color bit map mode from (1) the background color register 0, (the screen background color), (2) the video matrix (the upper 4 bits give one possible color, the lower 4 bits an other), and (3) color memory.

I fixed the wiki entry.

_________________
Insert witty sig. here...


Top
 Profile  
 
PostPosted: Sun May 13, 2018 9:57 am 
Offline

Joined: Tue Feb 07, 2017 2:03 am
Posts: 478
the image resolution is 160x200 its displayed on a 404x312 screen, but the image it self is only 160 pixels wide. You can't have a half pixel, you can scroll it to the left by 1 pixel, but there is still only 160 addressable pixels.

A sprite is only 12 pixels wide, you can't set a half pixel, you can place it anywhere on the 404x312 resolution of the VIC-II with a single pixel resolution, however the sprite it self only has 12 individual pixels.


Top
 Profile  
 
PostPosted: Sun May 13, 2018 10:30 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20265
Location: NE Indiana, USA (NTSC)
Which leads to a philosophical question: Are the sub-screen columns in Super NES pseudo-hires "pixels" or "half pixels"?


Top
 Profile  
 
PostPosted: Sun May 13, 2018 4:21 pm 
Offline

Joined: Sun Mar 19, 2006 9:44 pm
Posts: 953
Location: Japan
Oziphantom wrote:
Amiga 500
Most games don't use sprites, they suck. Or you use them for hud, cursors, background layers etc to which you Plex them in the same row using the copper.

Most graphically impressive Amiga games (ab)use sprites in several clever ways. I urge you to check out the analyses Codetapper has made here:

http://codetapper.com/amiga/sprite-tricks/

_________________
http://www.chrismcovell.com


Top
 Profile  
 
PostPosted: Sun May 13, 2018 10:22 pm 
Offline
Formerly Espozo
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3348
Location: Nacogdoches, Texas
Oziphantom wrote:
you have ~1 million bits per second, so it depends on how you want to use them.

So, 320 * 200 = 64,000 pixels,
1,000,000 / 60 frames / 6 bpp = 2,778. Ouch...

ccovell wrote:
Oziphantom wrote:
Amiga 500
Most games don't use sprites, they suck. Or you use them for hud, cursors, background layers etc to which you Plex them in the same row using the copper.

Most graphically impressive Amiga games (ab)use sprites in several clever ways. I urge you to check out the analyses Codetapper has made here:

http://codetapper.com/amiga/sprite-tricks/

Could one make more elaborate backgrounds by changing sprite attributes while plexing them, or is this not possible?


Top
 Profile  
 
PostPosted: Sun May 13, 2018 10:52 pm 
Offline

Joined: Sun Mar 19, 2006 9:44 pm
Posts: 953
Location: Japan
Espozo wrote:
Could one make more elaborate backgrounds by changing sprite attributes while plexing them, or is this not possible?

I think Brian The Lion was dynamically replacing 1 bitplane of the cloud sprite, as the beam traced horizontally. Limited things can be done, though not in many bitplanes.

_________________
http://www.chrismcovell.com


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 77 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: JRoatch and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group