| |
Wile Coyote
Account closed
Registered: Mar 2004
Posts: 646 |
Limitations - Sprites in the Borders
hello,
I was thinking, has anyone drawn up a doc with (pictures :)explaining *all known* possibilities with placing sprites into the border areas of the screen.
I know:
8 sprites can be placed in the upper and lower borders.
7 sprites can be placed in the side borders.
I was thinking, what about the corner borders,is that classed as a sideborder or a top or bottom border (8 sprites).
Another question :) when 7 sprites are placed into the sideborders can the 8th free sprite be placed into the main (center) screen areas or by opening up the side borders, is the option for an 8th sprite not available.
I am asking these questions as i am thinking about designs that use the border areas :)
thanks
/wec
|
|
| |
tlr
Registered: Sep 2003
Posts: 1732 |
All restrictions are based on raster line, not column.
You can consider the corners the same as the upper/lower border. i.e 8 sprites.
These sprites can of course all have different x/y-expansion, different x- and y-positions, multicolor/hires and so on.
A number of these parameters could change on every rasterline if desired.
The center area of the top and bottom border is covered by an idle-fetch byte. These are 8 repeated pixels (black or background).
They may be changed dynamically and combined with different background colors to create graphics (mainly in the Y-direction). |
| |
Jetboy
Registered: Jul 2006
Posts: 234 |
One good example of what can be done is Deus Ex Machina
Notice, that to cover the lower border, most of the sprites has to be x-expanded.
Anything I can do to help? |
| |
Oswald
Registered: Apr 2002
Posts: 5032 |
there's not really such thing as corner borders. the sideborders are in reality one border starting at the right side and ending at the left side in the next rasterline throughout the whole height of the screen. The top/ bottom borders are aswell one single border starting at the bottom of the screen and ending in the next frame at the top. (think of it in the way as the electron beam draws up the screen)
you can place 8 sprites on the sideborders the restriction factors are: not enough free cycles for the cpu to open the border on badlines and that some of the sprite data is fetched while the side border is displayed, thus you might get distorted/no gfx at specific sprites.
last, notice that sprites can be freely multiplexed, the only restriction here is that you cant have more than 8 sprites on a single rasterline.
read the vic article for confusing in depth details.
edit: X coord 0 of the sprite is not to the left enough to cover the left sideborder u have to set the 9th bit of the x coord and use some ridiculously high x coord value to have the sprite to show up more to the left than xcoord=0. |
| |
Wile Coyote
Account closed
Registered: Mar 2004
Posts: 646 |
Quote: One good example of what can be done is Deus Ex Machina
Notice, that to cover the lower border, most of the sprites has to be x-expanded.
Anything I can do to help?
The intro picture of Deus Ex Machina is very well thought out.
.at the moment Tlr i'm just looking into design ideas :) |
| |
Wile Coyote
Account closed
Registered: Mar 2004
Posts: 646 |
Quote: there's not really such thing as corner borders. the sideborders are in reality one border starting at the right side and ending at the left side in the next rasterline throughout the whole height of the screen. The top/ bottom borders are aswell one single border starting at the bottom of the screen and ending in the next frame at the top. (think of it in the way as the electron beam draws up the screen)
you can place 8 sprites on the sideborders the restriction factors are: not enough free cycles for the cpu to open the border on badlines and that some of the sprite data is fetched while the side border is displayed, thus you might get distorted/no gfx at specific sprites.
last, notice that sprites can be freely multiplexed, the only restriction here is that you cant have more than 8 sprites on a single rasterline.
read the vic article for confusing in depth details.
edit: X coord 0 of the sprite is not to the left enough to cover the left sideborder u have to set the 9th bit of the x coord and use some ridiculously high x coord value to have the sprite to show up more to the left than xcoord=0.
thanks for that, you kinda lost me when at this point:
"X coord 0 of the sprite is not to the left enough to cover the left sideborder u have to set the 9th bit of the x coord and use some ridiculously high x coord value to have the sprite to show up more to the left than xcoord=0."
So to play it safe my best bet is to design with 7 sprites in mind :)
As for desiging an image that makes use of border sprites, i guess it is better to leave the carving up of the sprite (data within a sprite) to the coder ;)
|
| |
JackAsser
Registered: Jun 2002
Posts: 1995 |
Also, if you wanna use sprites in the sideborder together with badlines (i.e. char data or bitmap data) you're limited to only 4 sprites per raster line iirc. At least not as high as 7.
Bad line = 40c
Sprite setup = 1-3c
Cycles per sprite = 2c
Cycles per line = 63c
Minimum cycles requires for removing the sideborder = 8c (higly theoretical)
63-40-1-8 = 14c
14/2 = 7 sprites, but this assumes 1 cycle sprite setup time and 8 cycles for removing the sideborder, I'm sceptical... F.e. to make use of the 2 cycles in the sprite setup time you need to use a RMW-instruction to remove the border which will in practice make the border removal 10cycles, i.e. nothing gained.
Anyways, my VIC-schooling has taught me that 4 sprites in the sideborder + normal badlines is the max you can get. I'd like to hear a nice theoretical explanation for this though...
7 sprites + sideborder and char graphics is possible only if you dis-allow new badlines to form. The $d011 trick required to do this unfortunatly collides with sprite fetch 0, hence only sprites 1-7 are usable (I use this trick in Panta Rhei and LCP Memories f.e.). But not allowing badlines to form, limits the graphics possibilities quite alot, although having a WEC logo which is rather simple is not a problem at all, if you have that in mind.
|
| |
tlr
Registered: Sep 2003
Posts: 1732 |
Quote: The intro picture of Deus Ex Machina is very well thought out.
.at the moment Tlr i'm just looking into design ideas :)
Actually that was Jetboy's post, but I can help out too if you like. :)
Breakpoint 06 c64 Graphics Seminar does some explanation on how the Deus Ex Machina picture was created (in Photoshop), and much more.
Basically you can have 7 (usually just 4) sprites per line in the "screen" part of the y-coordinates, and 8 in the rest.
There are many restrictions based on this. I haven't seen anybody manage FLI every line with 7 sprites in the border for example.
If you stay on the standard VIC-II modes (MultiColor/Hires) + sideborder you'll be safe. Otherwise I suggest you present an idea, and then someone codes a viewer to test if it is possible to display it before you draw it.
Oswalds comment about the X-coordinates is just that coordinate 0 is not the leftmost location.
Also what usually limits you from displaying many sprites in the "screen" area is that every 8th line is a "badline", i.e less raster time to open the border.
There are ways to manipulate these badlines (e.g FLI which adds them).
You could for example work with the restriction that some parts of the screen have more sprites, but doesn't open the border in some of the raster lines. Note that when not opening the border in a line, the border color will show one raster line lower on the left side than on the right side.
|
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
I have to agree with JackAsser, under normal circumstances you won't get more than 4 sprites in the sideborders.
Quote:I haven't seen anybody manage FLI every line with 7 sprites in the border for example.
And I haven't seen anybody managing FLI every line with even 1 sprite in the border. |
| |
tlr
Registered: Sep 2003
Posts: 1732 |
Quote: I have to agree with JackAsser, under normal circumstances you won't get more than 4 sprites in the sideborders.
Quote:I haven't seen anybody manage FLI every line with 7 sprites in the border for example.
And I haven't seen anybody managing FLI every line with even 1 sprite in the border.
@Graham: I stand corrected.
I must admit I stopped coding demos for the c64 in 1988, although I followed the developments since then. ;)
|
| |
Wile Coyote
Account closed
Registered: Mar 2004
Posts: 646 |
Quote: Actually that was Jetboy's post, but I can help out too if you like. :)
Breakpoint 06 c64 Graphics Seminar does some explanation on how the Deus Ex Machina picture was created (in Photoshop), and much more.
Basically you can have 7 (usually just 4) sprites per line in the "screen" part of the y-coordinates, and 8 in the rest.
There are many restrictions based on this. I haven't seen anybody manage FLI every line with 7 sprites in the border for example.
If you stay on the standard VIC-II modes (MultiColor/Hires) + sideborder you'll be safe. Otherwise I suggest you present an idea, and then someone codes a viewer to test if it is possible to display it before you draw it.
Oswalds comment about the X-coordinates is just that coordinate 0 is not the leftmost location.
Also what usually limits you from displaying many sprites in the "screen" area is that every 8th line is a "badline", i.e less raster time to open the border.
There are ways to manipulate these badlines (e.g FLI which adds them).
You could for example work with the restriction that some parts of the screen have more sprites, but doesn't open the border in some of the raster lines. Note that when not opening the border in a line, the border color will show one raster line lower on the left side than on the right side.
thanks, although there is nothing to help out with at the moment. I have simply been thinking about possibilities and clever design :)
So 4 sprites is the way to go. 4 sprites for the side borders and the other 4 sprites can be used on the (main) screen (or should that be 3 (7 total)).
..and what about hires, multi colour, expanded sprites. Can this affect the timing? or is a sprite a sprite :)
Crossbow spoke of displaying a sprite, but not a whole sprite (during Krestage or Krestage 2). I'll have to see the demo again, i think he speaks of displaying only the first 16 or 18 pixels of the sprite.
|
| |
tlr
Registered: Sep 2003
Posts: 1732 |
Quote:So 4 sprites is the way to go. 4 sprites for the side borders and the other 4 sprites can be used on the (main) screen (or should that be 3 (7 total)).
Only 4 sprites in total on a given raster line with the normal screen open. That is 4 sprites that can be either in the border or in the middle of the screen.
Typical example of the simplest form is the first part of Bonanza.
Quote:..and what about hires, multi colour, expanded sprites. Can this affect the timing? or is a sprite a sprite :)
A sprite is a sprite. If a sprite is active on a given line it affects timing.
Quote:Crossbow spoke of displaying a sprite, but not a whole sprite (during Krestage or Krestage 2). I'll have to see the demo again, i think he speaks of displaying only the first 16 or 18 pixels of the sprite.
I don't remember the height, but I don't think you will benefit from this on a static image.
A sprite can change it's x-pos and color on a raster line in the middle of it so you can emulate this anyway.
|
| |
enthusi
Registered: May 2004
Posts: 675 |
Look for ESCOM-pictures.
Iirc they use all borders with xy-expanded sprites.
Wait I will check.
Airwolf
Nice example.
Most look worse :)
Anyway - there you go. |
| |
tlr
Registered: Sep 2003
Posts: 1732 |
Quote: Look for ESCOM-pictures.
Iirc they use all borders with xy-expanded sprites.
Wait I will check.
Airwolf
Nice example.
Most look worse :)
Anyway - there you go.
ESCOS. Expanded Screen COnstruction Set |
| |
JackAsser
Registered: Jun 2002
Posts: 1995 |
Phat moving ESCOS by HCL in Totally Stoned 2 ... FYI. |
| |
Wile Coyote
Account closed
Registered: Mar 2004
Posts: 646 |
Quote: Quote:So 4 sprites is the way to go. 4 sprites for the side borders and the other 4 sprites can be used on the (main) screen (or should that be 3 (7 total)).
Only 4 sprites in total on a given raster line with the normal screen open. That is 4 sprites that can be either in the border or in the middle of the screen.
Typical example of the simplest form is the first part of Bonanza.
Quote:..and what about hires, multi colour, expanded sprites. Can this affect the timing? or is a sprite a sprite :)
A sprite is a sprite. If a sprite is active on a given line it affects timing.
Quote:Crossbow spoke of displaying a sprite, but not a whole sprite (during Krestage or Krestage 2). I'll have to see the demo again, i think he speaks of displaying only the first 16 or 18 pixels of the sprite.
I don't remember the height, but I don't think you will benefit from this on a static image.
A sprite can change it's x-pos and color on a raster line in the middle of it so you can emulate this anyway.
The height thing, i thought the benefit could be from the added color made available :)
So how do you explain the note to *Don't Meet Crest*
There appears to be a character logo, rasterbars and 7 sprites. The sprites bunch up and appear to overlap each other and enter into the side borders. Mind you it could be an illusion, as while the 7 sprites appear to be on the same horizontal line, the sprites bunch up as they enter the side border, so maybe only 4 sprites are in the one location.
|
| |
Oswald
Registered: Apr 2002
Posts: 5032 |
in the dont meet crest note there are simply NO badlines :D I may be wrong here, but AFAIK it uses linecrunch, which is normally used to scroll the screen upwards, but you can also display with it about 56 different gfx lines (switching amongst csets and banks). well someone else will explain it more deeply :) |
| |
JackAsser
Registered: Jun 2002
Posts: 1995 |
Quote: The height thing, i thought the benefit could be from the added color made available :)
So how do you explain the note to *Don't Meet Crest*
There appears to be a character logo, rasterbars and 7 sprites. The sprites bunch up and appear to overlap each other and enter into the side borders. Mind you it could be an illusion, as while the 7 sprites appear to be on the same horizontal line, the sprites bunch up as they enter the side border, so maybe only 4 sprites are in the one location.
Havn't checked the code, but I say this is a classic example of avoiding badline. If I would have done it I would have chosen ECM mode. And at every 7th line repeat the char row to avoid bad lines, switch $dd00 and $d018 to select graphics. To get the borders brown I would have used a character with the third BG-color in ECM mode and let it be brown, at char column 39. Remeber the bgcolor of the char in column 39 defines the color of the border "under" the normal border, both in bitmap and in ECM mode. (bg color of a char in normal char mode is always $d021, but can vary in bitmap and in ECM mode).
But then again, I'm perhaps completly off here, it is still Crossbow code... :D
edit: forget about bitmap and ECM.... that's in single color only... :D someone else crack this...
|
| |
Oswald
Registered: Apr 2002
Posts: 5032 |
Jack, it can be multicolor chars / bitmap easily... |
| |
JackAsser
Registered: Jun 2002
Posts: 1995 |
@oswald: indeed, just not switch gfx every line, but every 7th line. But how do you get the borders brown (and open) without using ECM or hires bitmap? Does he really put a $d021 split there?
|
| |
tlr
Registered: Sep 2003
Posts: 1732 |
Quote: @oswald: indeed, just not switch gfx every line, but every 7th line. But how do you get the borders brown (and open) without using ECM or hires bitmap? Does he really put a $d021 split there?
Yes, split...
x=$0b
sta $d016,x
:) |
| |
JackAsser
Registered: Jun 2002
Posts: 1995 |
Ahh! Removing border AND setting single colour at the same time! Splendid! =D |
| |
tlr
Registered: Sep 2003
Posts: 1732 |
Quote: Ahh! Removing border AND setting single colour at the same time! Splendid! =D
Actually I'm not so sure that X is $0b anymore. I kind of misread it. I'll look some more. ($1200)
EDIT: Actually it looks like it is a Multicolor bitmap with two $d021 split points.
What are the criteria for the color below the border in this case?
Is it the last one present before the border, or something else?
|
| |
JackAsser
Registered: Jun 2002
Posts: 1995 |
@tlr: uhm, still havn't checked the code but if you, when opening the borders also disabled multicolor, then the border color will be fetched from the bg-nybble of the screen data. Then when you changed d016 again u simply at the same time switch back multicolor mode. Hence you open the border AND change bg-color of the border at the same time. I.e. no $d021 involved at all. |
| |
tlr
Registered: Sep 2003
Posts: 1732 |
He loads $d016 with $1f.
Border open is inc $d016, and then later $1f => sta $d016,x.
This does what you say, but $20 is defined as the reset bit in my books (which seems to do nothing in VICE).
Is this safe on all revisions of the VIC-II?
|
| |
Oswald
Registered: Apr 2002
Posts: 5032 |
I have never ever heard of a reset bit in d016 :) |
| |
tlr
Registered: Sep 2003
Posts: 1732 |
From mapping the c64:
Quote:Bit 5: Bit 5 controls the VIC-II chip Reset line. Setting this bit
to 1 will completely stop the video chip from operating. On older
64s, the screen will go black. It should always be set to 0 to insure
normal operation of the chip.
Maybe it's only available on the very old VIC-II's (i.e 5 luma levels).
My original c64 was one of those. (i.e 9,8,7,1,7,8,9 looks like gold!)
It's in the attic right now though.
Roland has one of them...
|
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
The VIC-II's reset bit is a pretty mysterious thing. I have never encountered in real life, perhaps only the very early NTSC VIC-II's have it. I'm pretty certain that no PAL VIC-II has it, although you can never be sure... |
| |
tlr
Registered: Sep 2003
Posts: 1732 |
But it is still a read/writeable bit?
Very odd indeed...
|
| |
tlr
Registered: Sep 2003
Posts: 1732 |
BTW, while poking around with $d016 I just noticed that the 38 column mode is borked in VICE (WinVICE 1.17 and 1.19 tested).
It covers 7 pixels to the left and 9 pixels to the right instead of 8, 8. :)
POKE53270,0 I reported it to the team just now.
EDIT: Or is it supposed to be this way? CCS64 is the same....
I have forgotten way too much stuff. :P
Note that the PAL C64 DTV covers 8/8... so I guess that one is wrong then?
|
| |
Jetboy
Registered: Jul 2006
Posts: 234 |
@_@
Just checked it on a real thing (its good to have real thing at work).
well... on standard c64 its 7-9 too.
so it seems there is no bug.
but all the time up to now i was sure it's 8-8 @_@
|
| |
Jetboy
Registered: Jul 2006
Posts: 234 |
Sorry for double posting.
At least now i finaly understand why opening sideborders works.
|
| |
Style
Registered: Jun 2004
Posts: 498 |
why was it so hard to understand? :)
|
| |
Smasher
Registered: Feb 2003
Posts: 512 |
oh yeah, 10 yrs later necro-posting! :)
so: sideborder sprites at badline, using no fld or similar tricks, no reu (hehe), etc... 4 is still the practical not theoretical max you can get, or? |
| |
Flavioweb
Registered: Nov 2011
Posts: 447 |
If i understand things correctly, is possible to have 7 sprites (from 0 to 6) using INC $D016 at cycle 10 of the line (because of last 2 Write cycles of INC) to open border:
./victimer -b -s 127
| 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 |
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 4 5 6 7 8 9 0 1 2 3 |
| |===========01020304050607080910111213141516171819202122232425262728293031323334 353637383940===========| |
--|----------------------------------------------------------------------------- -------------------------------------------------|
| x x x W W W W W w |
| r r r r rcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgcgc g |
ss|3sss4sss5sss6sss7 0sss1sss2sss|
| i i i |
--|----------------------------------------------------------------------------- -------------------------------------------------|
| ^(close sideborder) ^(open sideborder)
| ^---FLI-----------------> ^-----^(double line)
| ^---DMA Delay--------------------------------------------------------------^
badline sprenable=7f
CPU: 3 (+ 5= 8)
VIC: 54 (+ 1=55)
63
x - CPU regular cycles
W - CPU write cycles
w - CPU 3rd write cycle
c - VIC video ram
g - VIC color ram
0..7 - VIC sprite pointer fetches
s - VIC sprite data accesses
i - VIC idle accesses |
| |
Joe
Registered: Apr 2002
Posts: 224 |
You can do quite a lot with the restrictions. Here are two examples from last year, coded by Firehawk/Hoaxers.
Disconnect, October |
| |
soci
Registered: Sep 2003
Posts: 474 |
If i understand things correctly, is possible to have 7 sprites (from 0 to 6)
I assume PAL VIC-II here.
It's not sprites 0 to 6 but 1 to 7 and can be done with a SCPU for example. (Popel Premiere)
Once I've tried to write between the end of character DMA and sprite 0 DMA (using custom hardware) but it's futile. AEC is low in that "gap" so the write ends up in RAM and not in the VIC-II.
So it seems the maximum is 7 sprites on a bad line if you want to open the border with a PAL VIC-II.
No I haven't tried to route around the PLA to see if the VIC-II accepts the write or not. Went too far already ;)
However with a NTSC VIC-II it might work as there's a wider gap and even BA opens for a cycle.
Did anyone tried 8 sprites with open border and badlines on NTSC using a SCPU? In VICE it seems doable, but it does not mean it really can be done.
It could be a world-first! ;) |
| |
Oswald
Registered: Apr 2002
Posts: 5032 |
8 sprites without badlines is not possible? sprite 0 conflicts with the d016 write needed ? |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Nah. 8 sprites is very well possible without badlines. Just use any RMW instruction to avoid the sprite 0 DMA,ie DEC $D016: INC $D016. |
| |
Digger
Registered: Mar 2005
Posts: 422 |
Resurrecting this thread.
Any examples of:
8 sprites over no-badline bitmap (duplicated first charline color RAM attributes)
with side borders
no line-crunching
? |
| |
Mixer
Registered: Apr 2008
Posts: 423 |
>8 sprites over no-badline bitmap (duplicated first charline color RAM attributes)
I believe that the line repeat and side border opening cannot be done at the same time as the line repeat needs to be done around the cycles where the border is opened. At least not on stock c-64. Not sure about REU. |
| |
Krill
Registered: Apr 2002
Posts: 2857 |
Quoting MixerAt least not on stock c-64. Euro-PAL-G C-64, that is. =)
Cf. https://csdb.dk/forums/?roomid=11&topicid=128036#139183
(Not sure why linecrunching or not is relevant for the question, but the actual goal IS 8 sprites over entire screen with open borders, no? =D) |
| |
Digger
Registered: Mar 2005
Posts: 422 |
Quoting Krill(Not sure why linecrunching or not is relevant for the question, but the actual goal IS 8 sprites over entire screen with open borders, no? =D)
I want a full 200px high bitmap available, with line-crunch this won't be possible.
But I can live with 7 sprites over no-badline bitmap, with open side-borders.
That should work without sprite 0 and no line-crunch right? ;-) |
| |
Digger
Registered: Mar 2005
Posts: 422 |
There was a Crest demopart (or a hidden part) with 7 "ALKAIDA" sprites flying over a Crest logo. The side-borders were opened but it didn't look like they were b/c of a logo background AFAIR.
Which demo was that? |
| |
Digger
Registered: Mar 2005
Posts: 422 |
Found it – it's in the note of Don't meet Crest |
| |
HCL
Registered: Feb 2003
Posts: 717 |
Quote: Found it – it's in the note of Don't meet Crest
Logo is made of linecrunch-bitmap in multi-color, which is possible with open borders and 7 sprites (d017-stretched). The faked side-border is the 39:th tile that is stretched into the border, which is an effect that appears when opening the border with single-color bitmap. |
