Krestage 3

[vapourmile]

This is excellent. Reminds me of one of the mysteries of the 64.. if sprites in the top and bottom border were once 'impossible', the what explains the $3fff trick mentioned in this demo? (For those who don't know, if you wrote a top-bottom border routine on the 64, you'd reveal a mystery character underneath it which you could re-define with an address at $3fff. Theoretically, it should never have been seen. My guess: It's a secret bonus for those who discover you can do it.

[doeterniettoe123]

Their blureu demo is also awesome.

[fuckutube65]

Here's how it works: Crossbow realized that the VIC already loads new sprite data before it reaches the end of the rasterline, so he just moves one sprite to the very right after it's already been displayed - and then it is displayed again, only this time with the new pattern. Quite ingenious, i really wonder why in all these years of faking more than 8 sprites horizontally, nobody has ever thought of this before!

[doeterniettoe123]

@fuckutube65 Thanks! That's really cool. Do you also know how the 50 pixel wide sprites at the top of the screen are fabricated?

[fuckutube65]

@doeterniettoe123 Yeah. If you set a register (i think it was sprite x-expansion) at just the right time, the last column gets doubled. so he has 2 extra pixels per sprite.

about blureu: thanks, make sure to also check out "Wired", just released on X2010! ;-)

dk/Crest

[doeterniettoe123]

@fuckutube65 I downloaded wired.reu and enabled REU in Vice 2.2, but how do I run the demo? Autostart disk/tape image doesn't work.

A completely different question: if I remember correctly, there was an illegal 6510 opcode which operation depended on the place where it was put in memory. E.g.: take the LSB of the memory location where the opcode is stored, perform an AND with the acumulator and store the result in the address that follows the opcode. Is there an opcode like that?

[fuckutube65]

@doeterniettoe123 : You need nuvieplayer.prg to run it. If it says "no valid data found" just make sure VICE hasn't overwritten the full REU with an empty one - or cleared it, which it likes to do when restarting VICE. As for the opcode: dunno, I'm not a coder, but Graham's opcode-list on oxyron,de is rather complete, check there!

[doeterniettoe123]

@fuckutube65 Thanks, it works. Great collection of pictures! Contains some real gems! The show is a bit long too watch in one go though. It would be better to break it up into a couple of episodes where you could choose from when the demo is started.

[fuckutube65]

@doeterniettoe123 Yeah, originally it was a bit shorter, but we figured 1.5 seconds per image was a bit too fast! ;-) Try hitting space and go through the pics manually with +/-, the readme forgets to mention this feature!

[doeterniettoe123]

can anybody explain in detail how he did this?

[rovku]

@doeterniettoe123

I don't know, my guess it's the same technique used when multiplexing sprites in Y. Sprites 2-8 are set up normally, but data+pos of the 1st sprite are set in code. Then wait until the raster passes before you set a new data+pos BEFORE the raster reaches that new position. This could explain why the 9th sprite on the far right side, and why they are not moving. But, again, I'm only guessing.

tl;dr: My guess is that he is reusing sprites with heavily optimized code.

[MustNotRead]

nice demo. and the tune is dope like soap on a rope!

[dbug64]

Very nice music too. :-)

[hemflit]

Fucking amazing.

Robbie, I doubt the the left side drop has anything to do with it, it looks more like an emulator artifact, something that would be off-screen on a real machine. (Then again, I am talking out of my ass.)

[robbiew73]

@hemflit - no the drop on the left will still happen on a real C64.. it's because of his alternate line trick.. like he explains in his scroller when you read it... I didn't read it the first time around..

[robbiew73]

interesting.. wonder how much raster-time is left over after pushing the "9th sprite" into view. You can make out the drop on the left hand side, presumably that's how the 9th is displayed, using an alternate-line trick.

It would have been nice to see where each sprie actually ended, to see if the "50 pixels" is an exageration of the truth and it isn't simply just a grey coloured rasterline behind the sprites and each sprite is still 2 pixels apart. Also, would be good to see some movement.. ;)

[boranksk]

9 sprite on a rasterline :)