| |
Oswald
Registered: Apr 2002
Posts: 5094 |
any more breakthroughs?
at DEM I wrote:
"We're so close to the limits, that there's no way to make any more breakthroughs."
Cruzer replied:
"So untrue. More like we have become so old and contend with what we have, that no one bothers to try making any more breakthroughs. Actually I think that's not even true. There has been several breakthroughs since DEM."
what do you think? |
|
... 25 posts hidden. Click here to view all posts....
|
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: but i't not really 9 sprites in one line, now is it?
9 sprites in one RASTER line, correct. 8 sprites in one SPRITE fetch line.
About 41 chars, it was SoundDemon who exploited this, but I don't think he was first. Splitting using $d016 is common and have been used frequently to make 'holes' in $3fff-gfx etc. And it's not reallt 41 chars, it's 40 + 7 pixels. |
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
I think this collection of info on such stuff needs an update:
http://codebase64.org/doku.php?id=base:demo_world_records_and_w..
Anyone? :) |
| |
HCL
Registered: Feb 2003
Posts: 728 |
Yeah, the 41 chars were just bogus. Just holes in the picture :/. |
| |
majorsky
Account closed
Registered: Jun 2004
Posts: 6 |
Hi there...
as I wrote above, I was interested in the latest VIC effects. I digged into Krestage 3 a little bit using X64 Debug version and have two questions:
1. I think 50pixel wide sprites are done by manipulating the Multicolor bits of the sprites.
Am I right?
But why does this work? Has anyone found out?
2. At the bottom of the screen it does look like sprite 0 being displayed in the left for one rasterline and then in the right for one rasterline.
Is this the case or is the VIC showing the sprite on both positions in EVERY rasterline because of internal behaviour?
Thanks in advance!
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
#2: the following is just theory I dont know atmo where sprite fetches exactly happen, but the places are hardwired thats sure:
line x+0: vic reads sprite #1 data on right border
line x+1: sprite #1 gets displayed on left border
line x+1: change X coo, and after sprite #1 read on right border you can display it again.
as said visible rasterlines and "sprite raster lines" do not match. sprite fetches for one rasterline happen on the right and left border, on the right of the line to be displayed -1 and on the line to the left.
in ascii art:
0 1 2 3 .... 60 61 62 63
s4 s5 s6 s7 s0 s1 s2 s3
s0-s3 reads are for the next line, s4-s7 for the current |
| |
majorsky
Account closed
Registered: Jun 2004
Posts: 6 |
Puhhh... difficult to understand to be honest...
I understand now, how the sprite is displayed twice BUT how can you show different sprite designs on the same line, if there is only one sprite data fetch per line?!
Does anyone have some more info about the 50 pixel wide thing? |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
Quote: Puhhh... difficult to understand to be honest...
I understand now, how the sprite is displayed twice BUT how can you show different sprite designs on the same line, if there is only one sprite data fetch per line?!
Does anyone have some more info about the 50 pixel wide thing?
for the left sprite you use the fetch wich happens on the previous line for sprite #1 ( this is on the previos line on the right) and for the right sprite you use the fetch which happens on the current line.
------------------------------------- spr#1fetch ------------
spr#1show-------------------------- spr#1fetch -- spr#1show
see only one fetch per line.
some1 tell perff for god's sake to use fixed with font inside the code tags :) |
| |
majorsky
Account closed
Registered: Jun 2004
Posts: 6 |
OK, so this means, the sprite data can only be changed every second line for both.
Therefore:
---------------------------------- spr#1fetch(a)----------
spr#1show(a)--------------------- spr#1fetch(b)-spr#1show(b)
spr#1show(b)--------------------- spr#1fetch(c)-spr#1show(c)
spr#1show(c)--------------------- spr#1fetch(d)-spr#1show(d)
(x) shows the sprite data, which is fetched and displayed.
But, this scheme would not allow the different shape of SPrite 1 in the left and in the right.
Therefore, to allow something like in Krestage 3, it must be the following:
---------------------------------- spr#1fetch(a)----------
spr#1show(a)--------------------- spr#1fetch(b)-spr#1show(a)
spr#1show(b)--------------------- spr#1fetch(c)-spr#1show(b)
spr#1show(c)--------------------- spr#1fetch(d)-spr#1show(c)
Am I right?
|
| |
assiduous
Account closed
Registered: Jun 2007
Posts: 343 |
how can you do spr#1show(a) after spr#1fetch(b) ? b would have overwritten a. you cant do spr#1show(b) twice in a row either as sprite shift registers are emptied as a sprite is displayed.
the fetches for sprites 0-2 occur in the line preceding the display,for sprites 3-7 in the same line. it is important to note that the sprites in Krestage3 are displayed EVERY 2ND LINE! so the mechanism is simple: in the raster line preceding the first line when the sprites are displayed the sprite0 is fetched as the leftmost one,then in the line displaying the sprite contents the sprite0 is fetched in the right border and immediately displayed as the magic sprite "#9". as it wouldnt allow to display sprite0 in the next line anymore(the shift register is empty at this point!) the line coming after is blank and sprite0 contents fetched during this blank line account for the leftmost sprite in the next "display-line".
so the correct representation of this phenomenon would look as follows:
---------------------------------- spr#0fetch(a)----------
spr#0show(a)--------------------- spr#0fetch(b)-spr#0show(b)
---------------------------------- spr#0fetch(c)----------
spr#0show(c)--------------------- spr#0fetch(d)-spr#0show(d)
hope this helps |
| |
majorsky
Account closed
Registered: Jun 2004
Posts: 6 |
Ok, I already saw, that I was wrong.
Also, I didn't know, that displaying empties the shift registers...
Now, I understand!
Thanks. |
| Previous - 1 | 2 | 3 | 4 - Next |
