For whom it may concern

That looks very nice! Turning on the phosphor effect in Stella helps.

It's pretty cool, yes!

That looks very nice, but will there be enough time to display sprites over the top also?

 

Chris

That looks very nice, but will there be enough time to display sprites over the top also?

That's a minor problem. I would only use PF1 and PF2, so that would leave enough time, even for multi-colored sprites (or some missiles).

 

Mid-screen sprite repositioning should also work (with a few tricks and some compromises). But scrolling the screen (using SC RAM) seems to be completely impossible now. Uridium uses 136 lines for the dreadnought and scrolling so many lines would require ~12.000-13.000 cycles. To reach about the same scrolling speed that Uridium has, I had to scroll every 2nd frame, but there isn't enough free CPU time for doing that (by far!).

Looks neat - though will the flicker effect work OK when it's shifting left/right?

 

Could fill up the Krok Cart and use a lot of preshifted tables.

Looks neat - though will the flicker effect work OK when it's shifting left/right?

Should work if I sync the scrolling to the flicker (e.g. scrolling only on even frames).

 

Could fill up the Krok Cart and use a lot of preshifted tables.

Hm, but that would quite a lot of data. Each dreadnought is about 12 screens (4*136*12 = 6528 bytes) wide. With 8 scrolling positions, that would be 52225 bytes/dreadnought.

 

Even it would work, IMO that's too much "cheating".

Even it would work, IMO that's too much "cheating".

I can see where you're coming from - but I don't know if I agree that using extra resources is cheating. Do you think Activision was cheating in Pitfall II with the DPC chip?

I can see where you're coming from - but I don't know if I agree that using extra resources is cheating. Do you think Activision was cheating in Pitfall II with the DPC chip?

Here we go again.

 

No, IMO Pitfall II was ok, the Supercharger was ok, Bankswitching was ok too. Just because it was affordable back then (~1984). But I doubt huge RAM-carts where. So that's, where I draw my personal "cheating" line.

BTW: I wonder why the scrolling areas in Uridium and especially Paradroid are that vertically small? They are only 136/128 lines tall.

 

I remember that I had written a simple demo back then, which could scroll the whole screen (~200 lines), without any problems.

Both Paradroid and Uridium were setting new technology standards at the time they came out. As programmers got to know the system better, everything improved over the years.

 

I remember that I had written a simple demo back then, which could scroll the whole screen (~200 lines), without any problems.

 

Well, I guess your scroll demo didn't have to run a complete game at the same time?

Both Paradroid and Uridium were setting new technology standards at the time they came out. As programmers got to know the system better, everything improved over the years.

Sure and I could be wrong, but IIRC full-screen scrolling was already well known back then (1986, e.g. Zaxxon was from 1984).

 

Well, I guess your scroll demo didn't have to run a complete game at the same time?

Of course not. I simply scrolled over the RAM. Still looked quite impressive.

 

But scrolling 1k of data (he didn't have to scroll the Color-RAM, or did he?) requires less than 10,000 cycles every 8th pixel. Uridium and Paradroid scroll much slower (up to ~3 pixel/frame), so with double-buffering you can even split those cycles. And there are more than 16,500 cyles each frame!

Both Paradroid and Uridium were setting new technology standards at the time they came out. As programmers got to know the system better, everything improved over the years.

Sure and I could be wrong, but IIRC full-screen scrolling was already well known back then (1986).

 

Hm... I just had a look at the titles Lemon64 lists for 1985 and there's none even coming close to Uridium, (in fact 90% don't scroll at all.) so at the time it was written it was quite unique. And it must've come out early in 1986, as Alleykat has an 1986 copyright as well. (Alleykat is BTW one of the first games I know that really scrolls the full screen. Haven't counted the lines though.

 

Uridium and Paradroid scroll much slower (up to ~3 pixel/frame), so with double-buffering you can even split those cycles. And there are more than 16,500 cyles each frame!

 

Well, Andrew significantly sped up both games in their + versions, so I guess he just didn't know it any better when he originally wrote them. Hey, Uridium was praised back in the day just for updating the screen at 50Hz:

http://www.kultpower.de/powerplay_testberichte/uridium.jpg

 

But I feel the scrollspeed in this regard is more or less independent from the # of lines you do. I'd assume while he managed speed up the scrolling, he didn't manage to reduce all other computings significantly enough to enhance the viewport as well.

Sure and I could be wrong, but IIRC full-screen scrolling was already well known back then (1986, e.g. Zaxxon was from 1984).

 

Aha, so you mean "scrolling vertically and horizontally at the same time" with "fullscreen"?

 

Zaxxon should still be a whole lot easier than Gribbly/Paradroid though. They have free and smoothly accellerated 8-ways scrolling, not just right/up at constant speed.

Hm... I just had a look at the titles Lemon64 lists for 1985 and there's none even coming close to Uridium, (in fact 90% don't scroll at all.) so at the time it was written it was quite unique.

How about e.g. Boulderdash?

 

Well, Andrew significantly sped up both games in their + versions, so I guess he just didn't know it any better when he originally wrote them.

Probably. I suppose the tricks where kept secret as long as possible.

 

Are there any comments on this topic from Andrew himself?

Aha, so you mean "scrolling vertically and horizontally at the same time" with "fullscreen"?

No, just scrolling (almost) the full screen.

 

Zaxxon should still be a whole lot easier than Gribbly/Paradroid though. They have free and smoothly accellerated 8-ways scrolling, not just right/up at constant speed.

IMO variable speed is just icing on the cake. Unless you have to use double buffering it makes no difference if you scroll at a slow, constant or at a fast, variable speed.

How about e.g. Boulderdash?

 

It's not accelerated, and the whole game is probably done without a single sprite. No collision detection (sprite-sprite / sprite-background) , no parallax effect, no nothing. Boulder Dash is technically a total no-show, just brilliant game-design. Definitely not comparable to Uridium

Definitely not comparable to Uridium

I suppose Uridium was just the first game, which brought everything together and very close to perfection.

"King for a day" I guess. A little later it was an old hat already, when Wizball and others came out

I can see where you're coming from - but I don't know if I agree that using extra resources is cheating. Do you think Activision was cheating in Pitfall II with the DPC chip?

Here we go again.

 

No, IMO Pitfall II was ok, the Supercharger was ok, Bankswitching was ok too. Just because it was affordable back then (~1984). But I doubt huge RAM-carts where. So that's, where I draw my personal "cheating" line.

That's cool. Also I think it would take more than 52225 per dreadnought because you can destroy things on them and would need additional graphics to show them destroyed.

 

 

Should work if I sync the scrolling to the flicker (e.g. scrolling only on even frames).

Hmm... If you're going to make the 2 frames in sync, you could scoll each frame separately. That might give you the time you need.

 

EvenVerticalBlank
  jsr ShiftEven
EvenKernel
 jsr ShowEven
EvenOverscan
 jsr gamelogic
 jmp OddVerticalBlank

...

OddVerticalBlank
 jsr ShiftOdd
OddKernel
 jsr ShowOdd
OddOverscan
 jsr gamelogic
 jmp EvenVerticalBlank

 

This psuedo code is just for example - I doubt you'd actually use seperate kernels and all, just change pointers for what's being updated.

Hmm... If you're going to make the 2 frames in sync, you could scoll each frame separately. That might give you the time you need.

That's what I am doing in Paradroid, completely using Overscan for scrolling. Even then I can only scroll 30 rows each frame. A read-modify-write requires 16 cycles/byte when using a SC, plus some overhead.

Ouch - hadn't looked into SC programming yet so didn't realize the read/write penalty was that high. I guess this would have to be done using a Super Chip or RAM Plus type of cartridge.

I guess this would have to be done using a Super Chip or RAM Plus type of cartridge.

AFAIK that would be still at least 10 cycles, because the read and write addresses would still differ.