Jump to content





Photo

A flicker experiment

Posted by Thomas Jentzsch, 07 April 2006 · 64 views

Programming Damned Tag Clouds
After reading Manuel's blog and trying out Uridium after a long time again, I wondered if that typical Braybrook look could somehow be transformed to the 2600. For the dreadnought, we'd have to use playfield grahics. Obviously we would need more than just two colors (foreground and backgroud) there. From Andrew's experiments we know, that flicker can help here.By mixing the constant background with two different foreground colors (changing every line) and switching the order of the foreground colors each frame (30Hz flicker!) we get four results. Depending on the colors you choose, you get four different shades which is exactly the number we need. Now only the resolution is a "little bit" too low. But with some clever redesign, this should be managable. :) (scrolling is another story...)Attached is a (very!) first result. Opinions are very welcome.Note: It only works when you are running the emulator in sync with the monitor. Else you will notice a lot of flicker and disturbances. It works nice on my TFT, the results may differ on other monitors or on TV.

Attached Files






That looks very nice! Turning on the phosphor effect in Stella helps.
  • Report
It's pretty cool, yes!
  • Report
That looks very nice, but will there be enough time to display sprites over the top also?

Chris
  • Report

cd-w, on Sat Apr 8, 2006 2:48 PM, said:

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!). :ponder:
  • Report
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.
  • Report

SpiceWare, on Sat Apr 8, 2006 6:15 PM, said:

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).

Quote

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. :ponder:

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

Thomas Jentzsch, on Sat Apr 8, 2006 11:51 AM, said:

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?
  • Report

SpiceWare, on Sun Apr 9, 2006 6:04 AM, said:

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. :ponder:

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.
  • Report
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.
  • Report
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.

Thomas Jentzsch, on Sun Apr 9, 2006 8:08 AM, said:

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? :ponder:
  • Report

Cybergoth, on Sun Apr 9, 2006 11:24 AM, said:

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).

Quote

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. :ponder:

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!
  • Report

Thomas Jentzsch, on Sun Apr 9, 2006 9:57 AM, said:

Cybergoth, on Sun Apr 9, 2006 11:24 AM, said:

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.

Thomas Jentzsch, on Sun Apr 9, 2006 9:57 AM, said:

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...hte/uridium.jpg :ponder:

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.
  • Report

Thomas Jentzsch, on Sun Apr 9, 2006 9:57 AM, said:

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"? :ponder:

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.
  • Report

Cybergoth, on Sun Apr 9, 2006 12:20 PM, said:

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?

Quote

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?
  • Report

Cybergoth, on Sun Apr 9, 2006 12:31 PM, said:

Aha, so you mean "scrolling vertically and horizontally at the same time" with "fullscreen"? ;)
No, just scrolling (almost) the full screen. :ponder:

Quote

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.
  • Report

Thomas Jentzsch, on Sun Apr 9, 2006 10:35 AM, said:

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 :ponder:
  • Report

Cybergoth, on Sun Apr 9, 2006 12:41 PM, said:

Definitely not comparable to Uridium :ponder:
I suppose Uridium was just the first game, which brought everything together and very close to perfection.
  • Report
"King for a day" I guess. A little later it was an old hat already, when Wizball and others came out :ponder:
  • Report

Thomas Jentzsch, on Sun Apr 9, 2006 1:35 AM, said:

SpiceWare, on Sun Apr 9, 2006 6:04 AM, said:

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. :ponder:

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.


Quote

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.
  • Report

SpiceWare, on Sun Apr 9, 2006 7:50 PM, said:

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.
  • Report