Jump to content
  • entries
    39
  • comments
    621
  • views
    148,385

A flicker experiment


Thomas Jentzsch

4,994 views

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. icon_smile.gif (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.

flicker_v001.bin

22 Comments


Recommended Comments

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

 

Chris

Link to comment
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:

Link to comment

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.

Link to comment
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. :ponder:

 

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

Link to comment
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?
Link to comment
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.

Link to comment

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.

Link to comment

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

Link to comment
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. :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!

Link to comment
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 :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.

Link to comment
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.

Link to comment
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?

Link to comment
Aha, so you mean "scrolling vertically and horizontally at the same time" with "fullscreen"? ;)

No, just scrolling (almost) the full screen. :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.

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.

Link to comment
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:

Link to comment
Definitely not comparable to Uridium :ponder:

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

Link to comment
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.

 

 

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.

Link to comment
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.

Link to comment

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.

Link to comment
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.

Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...