Multi-Colored Playfield Demo

[SeaGtGruff]

Here is a demo that uses "interlaced" flickering to get a four-color screen using just the background and playfield colors. The screen isn't interlaced in the normal TV sense of the word, because there are only 262 (not 262.5) scan lines per field/frame. However, the colors and data bits (pixels) of the two frames are alternated, so each frame essentially contains lines from two different fields which are interlaced together, thus making the flickering undetectable (at least on my TV, to my eyes).

 

The colors look very dark on an emulator (the screenshot is from Stella, using the z26 palette), but they look brighter on an actual TV (although of course the brightness and contrast settings will make a difference). I need to tweak the colors a bit, because they didn't come out looking like they did in the color-mixing utility that I wrote, possibly because my color-mixing utility doesn't "interlace" the flickered colors. And if I make a game using this technique, I plan to have different versions-- NTSC and PAL for actual TVs, NTSC and PAL for the z26 emulator palette, and NTSC and PAL for the Stella emulator palette-- so that each version will look okay on the intended hardware/software.

 

The kernel is a no-brainer, but creating the data tables for the three playfield registers is a royal pain in the neck, so I intend to write a utility that will take a text "map" (or possibly a bitmap image) and generate the appropriate data tables from it.

 

The kernel in this demo uses indirect,Y addressing, and the entire screen is stored in ROM, but my goal is to create a set of "tiles" in ROM, which will be copied into expansion RAM, and possibly copy part of the kernel into zero-page RAM so I can use a faster addressing mode through self-modifying code. The various screens in a game would be defined by giving the number of the desired tile for each area of the screen. The current demo is based on a tile size of 5x32 (i.e., 5 playfield pixels wide and 32 scan lines tall), which divides the screen into 48 blocks-- 8 across and 6 down (how's that for a 4:3 aspect ratio? ). But since that doesn't work out so great for the playfield registers (4 playfield pixels wide would work out much better), I might end up dividing the screen into 40x24 blocks, like the GRAPHICS 0 mode on an 8-bit Atari computer, and then create tiles of varying sizes depending on the need. For example, the trees in this demo are 5 playfield pixels wide, but other objects might need to be only 4 pixels wide, or 16 scan lines tall, etc. The kernel allows the colors to be changed from one scan line to the next, so that different rows of tiles could use different color schemes. The player sprites would also use interlaced flickering to get multiple colors, but since some of the colors would depend on the background colors, the different color zones would ideally need to have the same background colors. In this demo, the background colors were chosen so that they combine to produce brown, because I figured that brown would be a color that could probably be useful in any horizontal color zone or multi-colored player.

 

The multi-colored players would move around a block at a time (i.e., where the screen is made up of 40x24 blocks), and the playfield would have to be updated while the player sprites move around, since the flickered player colors would vary depending on whether they're on top of the background or the playfield. Also, the screen would not scroll horizontally and vertically as in Ultima or Zelda, but would instead change when the player moves off the edges, as in Adventure. Collisions could not be based on the collision registers-- at least, not collisions between the players and the playfield-- but would instead need to be based on the players' block coordinates and the values of the playfield tiles or screen blocks.

 

Thus, there are a lot of problems that would need to be resolved-- storing the screens in a manner that doesn't take up too much ROM, building and dynamically updating the screen in expansion RAM, detecting collisions between the players and the playfield objects, changing all the necessary colors and graphics of the playfield and players on each line, etc. This demo uses a simple non-reflected playfield, but ideally I'd like to have an asymmetrical playfield if possible, although an alternative would be to set the reflected/non-reflected playfield option on each scan line (similar to the way that Tutankham for the 2600 has some rows of playfield pixels which are reflected, and some which are non-reflected). If necessary, the screen may need to be restricted to just the PF1 and PF2 registers, which would allow slightly more than 6 tiles across (if the tiles are 5 wide), so that there will be more time to make the necessary changes on each scan line. That would actually produce a more squared screen display. And of course there would be more time to do everything if it weren't necessary to alternate the colors on each scan line, so it might be necessary to use non-interlaced flickering.

 

Anyway, I don't know if I'll ever successfully develop an RPG adventure game using this technique, but I wanted to make this demo just to see how well the screen turned out.

 

Michael

 

Multi_Colored_Playfield.asm.txt

Multi_Colored_Playfield.asm.bin

[+Andrew Davie]

Very good! I, too, like 'interlacing' like this, but it doesn't appear to be popular with others, possibly because of how it looks on emulators. I believe it's only on the real hardware (and TV) that really counts. I would encourage you to further explore the creation of multicoloured playfields using interlacing. Perhaps you can come up with a generic system that can display any image.

Cheers

[SeaGtGruff]

Very good! I, too, like 'interlacing' like this, but it doesn't appear to be popular with others, possibly because of how it looks on emulators. I believe it's only on the real hardware (and TV) that really counts. I would encourage you to further explore the creation of multicoloured playfields using interlacing. Perhaps you can come up with a generic system that can display any image.

Cheers

Thank you! I know there was another multi-colored playfield demo that someone posted-- either in the AtariAge forums, or probably on the Stella list-- and I can't remember who wrote it (Thomas?), but I remember that they mentioned you as having demonstrated that the idea was feasible, so I gather that you must have done a demo, too? I can't find that demo for the life of me, but it was of an aircraft carrier, seen from above, with jets on the deck-- at least, that's sort or what it looked like to me, but I may be wrong.

 

What I've found is that if you choose the colors carefully, you get a more colorful range of mixtures. For example, if you choose dark red and dark green for the two background colors, you get a brown background, and then you can choose the two playfield colors so that one of them mixes with the dark red to get a reddish color (red, orange, purple, whatever), and the other one mixes with the dark green to get a greenish color. Throw in the player colors, and you get even more mixtures, as I've shown in other posts. You'd want to use the players for moving objects (people, animals, etc.), but you could use the missiles for adding more colors to the background objects.

 

The demo I did actually looks pretty good in the z26 emulator with the screen rate synched to the monitor's rate, but the colors look darker than they do on a TV, because the colors in the emulator's palette aren't as bright and vibrant as they are on a TV.

 

I'd like to create different tiles in a variety of color choices-- trees, mountains, swamps, deserts with cacti, houses or other buildings, etc. I tried making a mockup of a building in a paint program, but the size of the playfield pixels doesn't lend itself too well to making a good brick texture, so I tried using two alternating brick colors-- dark red and brown, with light gray lines in between the rows. I was able to get dark red, brown, light gray, and light blue, so I'll see if I can post an example of a house that isn't too ugly.

 

But first I need to make a utility for converting a text map or bitmap into data statements, because it's very tedious to do it by hand. For the forest, I made a text map using L for light green, D for dark green, B for brown, and Y for yellow, then I converted the Ls, Ds, Bs, and Ys into 0s and 1s for the two frames, depending on whether I needed to display the playfield pixels or the background on that frame, and then I had to take alternating lines from each frame to create the two interlaced frames, divide everything up into the PF0, PF1, and PF2 bytes, and reverse the bits in the PF0 and PF2 bytes. After doing all of that, it wasn't too surprising that I ended up with errors, and had to carefully hunt for all of the places where 0s needed to be changed to 1s, or vice versa, to correct the mistakes.

 

I'd also like to make a utility that runs on the 2600 itself, for choosing colors and designing tiles.

 

I remember you once mentioned that you'd written special routines to update the changed portions of the screen in Boulderdash, without having to redraw the entire screen, and I think that's the sort of thing that will need to be done to update an RPG screen as the people move around.

 

Obviously, an RPG or other game using this sort of technique will require a bankswitching method that provides a lot of ROM and plenty of expansion RAM, so I'm going to need to learn how to use John's 4A50 bankswitching method. And the Chimera's queues should also be very useful for this sort of thing, although I'm a bit unclear on what the Chimera is, exactly (a cartridge? a device that will plug into an I/O port? a board that will need to be installed inside the 2600? or something else?).

 

I suspect the main reason this sort of technique isn't being used much (yet?) isn't the flickering, so much as the tedium involved with constructing the appropriate data tables, coupled with the need for special hardware or cartridge formats to pull it off in a manner that enables actual games to use it. It's much more easily doable on an 8-bit Atari computer, but I'd like to see it done on a 2600, too.

 

Michael

[+Andrew Davie]

I did a few demos, but not the carrier one you mention.

Hills shows interlaced background (the sun/hills/clouds) and two large interlaced marios.

tunnelcycle shows various primary colours in a circle.

I have also mixed colour cycling with playfield interlacing, as shown in the attached spiralwords demo.

Cheers

A

 

PS: Also found 'car' which is my attempt to convert a photo of my old car to a full screen image.

spiralwords.bin

tunnelcycle.bin

hills.bin

car.bin

[LS_Dracon]

Great demo SeaGtGruff I really like this

Edited January 29, 2007 by LS_Dracon

[SeaGtGruff]

I did a few demos, but not the carrier one you mention.

Hills shows interlaced background (the sun/hills/clouds) and two large interlaced marios.

tunnelcycle shows various primary colours in a circle.

I have also mixed colour cycling with playfield interlacing, as shown in the attached spiralwords demo.

Cheers

A

 

PS: Also found 'car' which is my attempt to convert a photo of my old car to a full screen image.

Wow! I like the Hills demo; it looks like you could create a nice landscape picture with this technique. And I also like the Car, especially considering how limiting a 40-pixel-wide playfield is. I've often thought it should be possible to create some pretty decent "picture art" on the 2600-- portraits, still lifes, landscapes, etc.-- even without flickering. But with interlaced flickering, one should be able to create pictures which are downright stunning (for the 2600).

 

Michael

[mos6507]

When you flicker an entire screen I think it's a little tough on the eyes. When you flicker smaller shapes over a solid background I think it's easier to take. Like imagine how Suicide Mission would look with the graphics inverted.

 

Also, the graphics has to really warrant the flicker. If you can get by with color changes on every scanline, which usually means aligning your graphics vertically into zones, you are much better off doing that. In your demo, if the trees were more spaced out then you could have a row of just tree bottoms and a row of just tree tops. You've made a big sacrifice just to get a 3rd color. The 2600 already has a wide color palette you should try to use. It just can't do too many on a single scanline.

[SeaGtGruff]

When you flicker an entire screen I think it's a little tough on the eyes.

That is very true for E.T. Book Cart, but not for this example, because the "interlacing" or alternating of the colors greatly reduces the noticeable flicker. However, it also depends on what you're using to run this example on-- an actual Atari 2600/7800 on a TV, or z26, or Stella-- and what kind of settings you're using.

 

On my 2600 and TV, it looks great-- there is essentially no observable flickering. But the brightness and contrast on my TV set are both set to 50%-- which is actually ideal for my Atari, as determined by displaying all 128 colors at once and adjusting the controls so white ($0E) is white, black ($00) is black, yellow ($1A or whatever) is yellow, etc. If you've got the brightness and contrast on your TV turned way up high, the flickering might be more noticeable on a real Atari, but it's nowhere near as noticeable as it would be without "interlacing" the colors.

 

It also looks great in the z26 emulator with the screen refresh synched to the monitor's rate, although the colors are darker than on an actual Atari.

 

Also, the graphics has to really warrant the flicker. If you can get by with color changes on every scanline, which usually means aligning your graphics vertically into zones, you are much better off doing that. In your demo, if the trees were more spaced out then you could have a row of just tree bottoms and a row of just tree tops. You've made a big sacrifice just to get a 3rd color. The 2600 already has a wide color palette you should try to use. It just can't do too many on a single scanline.

My demo wasn't a very good example, on two accounts-- the forest of trees really doesn't illustrate the full capabilities of this method very well; and the simple kernel that I wrote for this demo takes too long to load and store the data. I'm not sacrificing to get a third color-- I'm sacrificing to get four colors (COLUBK1+COLUBK2, COLUBK1+COLUPF2, COLUPF1+COLUBK2, and COLUPF1+COLUPF2). If I'd had the dirt path make turns to go up or down between the rows of trees, it would have been a lot easier to see that any given playfield pixel position can be any of the four colors shown.

 

Creating an actual game with this technique isn't feasible yet, but should be feasible once 4A50 carts are available (especially if they allow executing code from expansion RAM, which is something I think John had mentioned as a possibility), or once Chimera carts are available (especially if queues can be read from zero-page addresses). The idea I'm shooting for is to load all four color registers on every scan line, in addition to loading the graphics for both players and an asymmetrical playfield (PF1 and PF2 only). If code can be executed from expansion RAM, then I'd like to unroll the entire kernel and store the graphics and color data within the kernel, so that the data can be loaded using immediate addressing, because then it would require only 5 cycles for each load/store. Alternately, if the data can be stored in zero-page queues, then the kernel could be in a loop as usual, and it would require 6 cycles for each load/store.

 

I'll be the first to admit that this may be an unworkable pipe dream, but I'm still interested in trying to push the envelope as much as possible-- even if it's beyond what is feasible/practical.

 

Michael

Edited February 6, 2007 by SeaGtGruff