Jump to content
IGNORED

Color Cycling in IntyBASIC?


First Spear

Recommended Posts

Hey all. A few other platforms have the simple notion of "color cycling" where colors in a given area or in a given shape can be (custom) rotated through a palette when different events occur. I was wondering how that might be possible in IntyBASIC. Now that you guys have schooled me a bit on how graphics are actually made, I was wondering about this next step. In Dreadnaught Factor and Christmas Carol, shapes that share a single GRAM card are animated by changing the single shape in GRAM instead of stepping through all BACKTAB images and changing them.

 

Thanks.

  • Like 1
Link to comment
Share on other sites

Due to the way things are addressed, I can't think of a way to do this other than individually changing each card separately. GRAM only holds the sprite data and not the color information.

 

The closest the Intellivision comes to this is Color Stack mode, which is cycling within a screen - not really what you're talking about. What you describe reminds me of some tricks used on the NES.

Edited by freeweed
Link to comment
Share on other sites

There's two ways to color cycle w/out changing a bitmap or BACKTAB.

 

The first is just to change the color number associated with a sprite (MOB). That's how I show the explosion on the tank in Space Patrol.

 

The second is to set up the display so you can color-cycle one (or more) of the slots in the color stack. That's how I color-cycle the squares in 4-Tris when clearing lines.

 

I don't know how to do either in IntyBASIC, but maybe an IntyBASIC expert can translate those approaches appropriately.

Link to comment
Share on other sites

For MOB color, that's easy. When you call SPRITE you can add in any value you want, to set the color. This can be a variable (it's how I do it generally). So that's simple enough to change based on an event. It won't change until you call SPRITE again, of course, but that should be one of the more frequent calls in a program unless the MOB is pretty much not moving.

 

For the color stack, I don't think you can use variables to control the MODE command. You'd have to issue it explicitly depending on the event. Which would mess with screen re-drawing and potentially your game timing, depending on a few things.

 

When you do it in ASM, I assume you're writing to registers directly to control this? IntyBASIC allows some of this, if you're clever and know what you're doing - but not for everything. It depends on how nanochess implemented a command.

Link to comment
Share on other sites

Hey all. A few other platforms have the simple notion of "color cycling" where colors in a given area or in a given shape can be (custom) rotated through a palette when different events occur. I was wondering how that might be possible in IntyBASIC. Now that you guys have schooled me a bit on how graphics are actually made, I was wondering about this next step. In Dreadnaught Factor and Christmas Carol, shapes that share a single GRAM card are animated by changing the single shape in GRAM instead of stepping through all BACKTAB images and changing them.

 

Thanks.

 

Actually, Christmas Carol uses both techniques for animation: Certainly the sprites are animated by cycling their GRAM card, but these are objects with unique GRAM cards allocated for them. The snowflake animation, which is probably what you were referring to, are animated by updating their BACKTAB card.

 

Christmas Carol's framework permits the allocation of GRAM into "blocks" which can be assigned to objects. In the case of the animated snowflakes, a block of 6 contiguous cards is allocated for the animation frames.

@@SNOWFLAKE:
:0       :1       :2       :3       :4       :5
........ ........ ........ ........ ........ ........
...#.... ...#.... ........ #......# #..#..#. #.....#.
.#.#.#.. ...#.... ...#.... ........ .#...#.. .#.#.#..
..###... ..###... ..###... ...#.... ...#.... ..#.#...
#######. #######. .#####.. ..###... ##...##. #.###.#.
..###... ..###... ..###... ...#.... ...#.... ..#.#...
.#.#.#.. ...#.... ...#.... ........ .#...#.. .#.#.#..
...#.... ...#.... ........ #......# #..#..#. #.....#.

There is also a table that contains the BACKTAB address for all snowflakes on each level.

SNOFLK_ATAB     PROC ; "M" means "Maze"
@@M1:
                DECLE $0222                     ; Position: (14,  1)
                DECLE $022D                     ; Position: ( 5,  2)
                DECLE $02C2                     ; Position: (14,  9)
                DECLE $02CA                     ; Position: ( 2, 10)
@@M2:
                DECLE $0245                     ; Position: ( 9,  3)
                DECLE $0293                     ; Position: ( 7,  7)
                DECLE $02CA                     ; Position: ( 2, 10)
                DECLE $02D5                     ; Position: (13, 10)
@@M3:
                DECLE $0221                     ; Position: (13,  1)
                DECLE $0240                     ; Position: ( 4,  3)
                DECLE $024C                     ; Position: (16,  3)
                DECLE $0290                     ; Position: ( 4,  7)
                DECLE $02CA                     ; Position: ( 2, 10)
                DECLE $02D9                     ; Position: (17, 10)

                ...

A timer is triggered periodically which starts the animation sequence by iterating through the snowflakes table for the current level, incrementing their BACKTAB GRAM index by one; something like this:

// C pseudo-code:
for (i=0; i<MAZE.SnoflkCount; i++)
{
  btab_ptr = SNOFLK_ATAB[Level][i];
  *btab_ptr += (1 << 3);
}

' BASIC pseudo-code:
FOR I = 0 TO (MAZE.SnoflkCount - 1)
  btab_ptr = SNOFLK_ATAB(Level, I)

  POKE btab_ptr, ((PEEK btab_ptr) + 
NEXT I

Now, as for colour cycling, Christmas Carol does this too. If you check out the title screen, the stars and baubles on the Christmas Tree twinkle and change colours. This is done by doing something similar to the above snowflake animation, but instead of switching the GRAM index, we switch the colour attribute of the BACKTAB word:

 

There are two sets of baubles, let's call them "Set1" and "Set2." As with the techniques mentioned above, there is a lookup table that defines the positions of the bauble sets:

TREE_LITE_ADDR  PROC
                ; --------------------------------------
                ; Set #1: Small baubles 1
                ; --------------------------------------
@@Set1:         DECLE   BTAB_ADDRESS($02, $00)
                DECLE   BTAB_ADDRESS($01, $04)
                DECLE   BTAB_ADDRESS($03, $05)
                DECLE   BTAB_ADDRESS($04, $08)
                DECLE   BTAB_ADDRESS($07, $06)
                DECLE   BTAB_ADDRESS($07, $09)
                DECLE   BTAB_ADDRESS($00, $09)
                DECLE   BTAB_ADDRESS($0A, $09)
                DECLE   BTAB_ADDRESS($02, $0A)
                DECLE   BTAB_ADDRESS($09, $0A)
@@Count1:       EQU     ($ - @@Set1)

                ; --------------------------------------
                ; Set #2: Small baubles 2
                ; --------------------------------------
@@Set2:         DECLE   BTAB_ADDRESS($03, $01)
                DECLE   BTAB_ADDRESS($03, $04)
                DECLE   BTAB_ADDRESS($00, $05)
                DECLE   BTAB_ADDRESS($06, $06)
                DECLE   BTAB_ADDRESS($01, $08)
                DECLE   BTAB_ADDRESS($06, $09)
                DECLE   BTAB_ADDRESS($05, $0A)
                DECLE   BTAB_ADDRESS($0A, $0A)
@@Count2:       EQU     ($ - @@Set2)
                ENDP

Likewise, there are two palettes defined, let's call them "Red," which includes a range of orange, red, and purples; and "Blue," which includes tones like cyan, blue, and light blue:

TREE_LITE_COLOR PROC
@@Red:          DECLE   X_PUR
                DECLE   X_RED
                DECLE   X_ORG
                DECLE   X_YEL
                DECLE   X_WHT
                DECLE   X_WHT
                DECLE   X_YEL
                DECLE   X_ORG
                DECLE   X_RED

@@Blue:         DECLE   X_BLU
                DECLE   X_LBL
                DECLE   X_CYN
                DECLE   X_YEL
                DECLE   X_WHT
                DECLE   X_WHT
                DECLE   X_YEL
                DECLE   X_CYN
                DECLE   X_LBL
                ENDP

Notice that the palettes cycle through the range, going all the way to white and back again. This simulates the brightening of the lights, which makes them twinkle.

 

It is then a matter of iterating through the entries on each set and updating their colour value, determined by incrementing an index to the appropriate palette table.

 

The rest is careful scripting and timing to make it play to the music. The effect is rather effective.

http://vimeo.com/53806088

Edited by DZ-Jay
  • Like 1
Link to comment
Share on other sites

For MOB color, that's easy. When you call SPRITE you can add in any value you want, to set the color. This can be a variable (it's how I do it generally). So that's simple enough to change based on an event. It won't change until you call SPRITE again, of course, but that should be one of the more frequent calls in a program unless the MOB is pretty much not moving.

 

For the color stack, I don't think you can use variables to control the MODE command. You'd have to issue it explicitly depending on the event. Which would mess with screen re-drawing and potentially your game timing, depending on a few things.

 

When you do it in ASM, I assume you're writing to registers directly to control this? IntyBASIC allows some of this, if you're clever and know what you're doing - but not for everything. It depends on how nanochess implemented a command.

 

You may be able to change the color stack with POKE statements shortly after a WAIT statement. The color stack is at locations $28 - $2B and the border color is at $2C. (40 - 44 decimal.)

 

These locations are POKE-able for ~2000 cycles after a vertical retrace, so by the time WAIT returns (and IntyBASIC finishes its housekeeping), you probably still have a few cycles to POKE new values there.

 

I don't remember if IntyBASIC loads the color stack every frame or just after a SCREEN statement. I think it's just after a SCREEN statement.

Link to comment
Share on other sites

 

You may be able to change the color stack with POKE statements shortly after a WAIT statement. The color stack is at locations $28 - $2B and the border color is at $2C. (40 - 44 decimal.)

 

These locations are POKE-able for ~2000 cycles after a vertical retrace, so by the time WAIT returns (and IntyBASIC finishes its housekeeping), you probably still have a few cycles to POKE new values there.

 

I don't remember if IntyBASIC loads the color stack every frame or just after a SCREEN statement. I think it's just after a SCREEN statement.

 

IntyBASIC updates the mode in each frame.

 

You need only to put this statement in your program and it will take effect in next frame:

MODE 1,expr,expr,expr,expr

MODE 1,0,1,2,3   ' For example


Link to comment
Share on other sites

 

 

IntyBASIC updates the mode in each frame.

 

You need only to put this statement in your program and it will take effect in next frame:

MODE 1,expr,expr,expr,expr

MODE 1,0,1,2,3   ' For example


 

Well there ya go - if it takes more than static constants, this works just fine for the intended purpose.

 

At least in terms of the color stack. It's not quite the color cycling someone may want, but it's halfway there.

  • Like 2
Link to comment
Share on other sites

 

Well there ya go - if it takes more than static constants, this works just fine for the intended purpose.

 

At least in terms of the color stack. It's not quite the color cycling someone may want, but it's halfway there.

 

 

It can be useful for making the screen flash, I suppose. (Say, in response to a large explosion or lightning.)

 

In 4-Tris, I used a quirk of colored-squares mode to allow using the color stack for color cycling. Color 7 in colored-squares mode comes from the color stack.

 

In the stack itself, I set slots 0 and 2 to black. I put color-stack advances to the left and right of the "well" in the middle. Slots 1 and 3 then could be used set the color displayed for color 7. While a piece was falling, I set the color to match the piece's color while it was falling. (This made it easier to distinguish the piece's pixels from the others already in the well. Or, at least, that was my reasoning at the time.)

 

When I cleared a line, I drew it in color 7 and color-cycled slots 1 and 3, making for an impressive animation.

 

The point of all that is: Depending on how you lay out the screen and how you use color stack, cycling the color stack could actually be useful.

 

But, you're right, it's not as useful as you might hope most of the time.

  • Like 1
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

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