SeaGtGruff Posted January 29, 2007 Share Posted January 29, 2007 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 Quote Link to comment Share on other sites More sharing options...
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.