| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
Release id #48577 : Krestage 3 - More Weird Stuff -
It's the emulators which should be fixed to run this release, not the other way round :) |
|
| |
Acidchild
Registered: Jan 2002
Posts: 476 |
go john, go :) |
| |
wreg
Account closed
Registered: Mar 2004
Posts: 679 |
you are welcome to take your time and add something to vice whatever emu you think should be improved
until you do so, we prefer the quick fix, that was again fixing the release! :) |
| |
BAR.
Account closed
Registered: Apr 2002
Posts: 324 |
Now all emulators & their programmers have a demo to mess with until Roland will bring out the next hit. ;) |
| |
Burglar
Registered: Dec 2004
Posts: 1101 |
Quote: Now all emulators & their programmers have a demo to mess with until Roland will bring out the next hit. ;)
so true ;)
but I'd like to see a vid of the demo though! |
| |
BAR.
Account closed
Registered: Apr 2002
Posts: 324 |
Sorry I only have videos about Smash-Design Demos here.. ;)
|
| |
ready.
Registered: Feb 2003
Posts: 441 |
has anybody written how these demo tricks work in detail? I couldn't find much information about them, just scener's ideas spread around the forum. |
| |
Skate
Registered: Jul 2003
Posts: 494 |
@ready.: I've examined 50 pixel wide sprites. Sprite x positions are important on that trick. Trick is based on sprite multicolor mode register ($d01c). If you set $d01c at the last column of the expanded sprite (i guess), you can show one extra pixel. But it is not exactly fetching extra pixels from memory. You set $d01c values for each sprite each rasterline. routine looks something like.
lda ...
sta $d01c
lda ...
sta $d01c
lda ...
sta $d01c
lda ...
sta $d01c
lda ...
sta $d01c
...
...
...
lda ...
sta $d01c
lda ...
sta $d01c
lda ...
sta $d01c
lda ...
sta $d01c
lda ...
sta $d01c
...
...
...
after first lda sta, you need to spend 7 cycles for the next sprite position (according to sprite x positions in Krestage 3). so crossbow used memory addressing like below;
lda #$00
sta $d01c
lda $50
sta $d01c
lda $50
sta $d01c
lda $50
sta $d01c
lda $50
sta $d01c
...
...
...
for each sprite, you (weirdly) set sprite's bit to $d01c to set 25th pixel on. other values doesn't work. I mean for the first sprite set value is 1, for the second it's 2, for the third it's 4, for others 8,16,32,64,128 etc...
to set all 25th pixels in a line, you need to do something like;
lda #$01
sta $d01c
lda #$02
sta $d01c
lda #$04
sta $d01c
lda #$08
sta $d01c
lda #$10
sta $d01c
...
...
...
to spend 7 cycles between two STAs, crossbow's routine looks like below (all 25th pixels are set)
lda #$01
sta $d01c
lda $52
sta $d01c
lda $53
sta $d01c
lda $54
sta $d01c
lda $55
sta $d01c
...
...
...
$52 = 2
$53 = 4
$54 = 8
$55 = 16
That's how it works but I don't know the reason of this VIC behaviour. Probably emulator developers examined this issue better than me. If crossbow doesn't explain the trick, I believe they can.
9th sprite trick is already explained very well several times. I'm not going into that. I never examined the removing FLI bug while scrolling bla bla trick. Actually, I'd like to hear an explanation on that.
edit: an example mistake is fixed. |
| |
ready.
Registered: Feb 2003
Posts: 441 |
thanks Skate, I have also found several explanations for the 9th sprite, still not anything detailed for the 50 pixels sprites before yours.
But I was wondering if there was any official explanation by Crossbow, but as you said, there's none yet. |
