Card mirroring and palette variants?

[+Black_Tiger]

I've looked around online about what I'm looking for info on, but unfortunately as with my original sprite research, what I've read has been very inconsistent.

 

1: Mirroring/flipping cards.

 

Can the Intellivision mirror background cards and if so, how many ways and what are any limitations/trade-offs?

 

Do sprites/MOBs follow different rules?

 

I'm looking to confirm or rule out both horizontal and vertical mirroring. Something like a quarter circle or ball could turn a single card into a 16 x 16 pixel circle/ball if both are supported.

 

 

 

2: Palette variants/cycling.

 

Can multiple variants of a palette be used for a particular card and if so, what are the restrictions? I'm hoping that the same card can be used with many alternate palettes in the same scene without taking more than one card from the 64 total limit.

 

In particular, a solid single color card would go a long way if it didn't eat up the total card limit for each element of solid colors.

 

What about coloring/palette cycling of the same card/background element? Can the cards depicting something glowing or on fire cycle through several palettes to produce the illusion of animation?

 

If palette variants are possible without counting as unique cards, can you change the pixels of one of the 2 visible colors to the same as the other visible color? An basic example would be what visually appears to be a red pixeled object against a black background. Can the red pixels be changed to black as well, while cycling through misc color palettes?

 

Do sprites/MOBs have different rules than background cards?

 

 

I'd really appreciate any info narrowing down my understanding of what can be done with cards overall.

 

Thanks.

[+Lathe26]

1 hour ago, Black_Tiger said:

I've looked around online about what I'm looking for info on, but unfortunately as with my original sprite research, what I've read has been very inconsistent.

 

1: Mirroring/flipping cards.

 

Can the Intellivision mirror background cards and if so, how many ways and what are any limitations/trade-offs?

 

Do sprites/MOBs follow different rules?

 

I'm looking to confirm or rule out both horizontal and vertical mirroring. Something like a quarter circle or ball could turn a single card into a 16 x 16 pixel circle/ball if both are supported.

 

 

 

2: Palette variants/cycling.

 

Can multiple variants of a palette be used for a particular card and if so, what are the restrictions? I'm hoping that the same card can be used with many alternate palettes in the same scene without taking more than one card from the 64 total limit.

 

In particular, a solid single color card would go a long way if it didn't eat up the total card limit for each element of solid colors.

 

What about coloring/palette cycling of the same card/background element? Can the cards depicting something glowing or on fire cycle through several palettes to produce the illusion of animation?

 

If palette variants are possible without counting as unique cards, can you change the pixels of one of the 2 visible colors to the same as the other visible color? An basic example would be what visually appears to be a red pixeled object against a black background. Can the red pixels be changed to black as well, while cycling through misc color palettes?

 

Do sprites/MOBs have different rules than background cards?

 

 

I'd really appreciate any info narrowing down my understanding of what can be done with cards overall.

 

Thanks.

Here's the short answers:

• The background graphics follow different rules than MOBs
• MOBs can mirrored vertically and horizontally while the background can not.
• Cards stored in GRAM have no color by themselves.  Their colors are set by the bits in the BACKTAB (for background graphics) and by bits in the STIC registers (for MOBs).  Thus palette variation and cycling is easy to do (no need to have multiple copies of the same card in GRAM for color changes).
• For the background graphics, you can set both colors to the same if you want.
• There are color limitations that depend on whether you are using Foreground/Background Mode, Color Stack Mode, and/or using Color Squares.

I recommend reading http://wiki.intellivision.us/index.php?title=STIC for details on setting the values in the BACKTAB for controlling the background graphics.  Take a close look at the different modes to see whether there are 3-bits or 4-bits for setting the foreground color and the background color (when the latter is even possible).  Good online references for the STIC registers are escaping me at the moment.

[mr_me]

Here's a reference on the stic that includes the registers for mob attributes.

http://spatula-city.org/~im14u2c/intv/jzintv/doc/programming/stic.txt

[carlsson]

I assume Black Tiger comes from VDP Land (i.e. Colecovision) where characters in text mode are defined in groups of 8 which all share the same background and foreground colour, meaning if you want a graphic on the background using different foreground colours you need to define it multiple times. As already explained, the STIC does fortunately not work in the same way, colour data is stored independently of the pattern data.

[+Black_Tiger]

On 11/22/2019 at 9:38 AM, Lathe26 said:

Here's the short answers:

• The background graphics follow different rules than MOBs
• MOBs can mirrored vertically and horizontally while the background can not.
• Cards stored in GRAM have no color by themselves.  Their colors are set by the bits in the BACKTAB (for background graphics) and by bits in the STIC registers (for MOBs).  Thus palette variation and cycling is easy to do (no need to have multiple copies of the same card in GRAM for color changes).
• For the background graphics, you can set both colors to the same if you want.
• There are color limitations that depend on whether you are using Foreground/Background Mode, Color Stack Mode, and/or using Color Squares.

I recommend reading http://wiki.intellivision.us/index.php?title=STIC for details on setting the values in the BACKTAB for controlling the background graphics.  Take a close look at the different modes to see whether there are 3-bits or 4-bits for setting the foreground color and the background color (when the latter is even possible).  Good online references for the STIC registers are escaping me at the moment.

Thanks, I was going to next ask if MOBs can be both vertically and horizontally mirrored, but that article specified.

[+Black_Tiger]

On 11/22/2019 at 9:43 AM, mr_me said:

Here's a reference on the stic that includes the registers for mob attributes.

http://spatula-city.org/~im14u2c/intv/jzintv/doc/programming/stic.txt

Thanks, that doc makes things surprisingly simple and easy to understand.

[eddhell]

lol...Black_Tiger is hitting all the same questions I have, about 24 hrs. ahead of me....instead of asking i just wait on his posts!

we must have similar ideas at almost the same time...

 

Seems like more people lately are trying to learn to program homebrew for their favorite old systems (and realizing how hard it really is)....maybe because the newest games are all overblown graphics and same cookie cutter gameplay?  Or maybe just nostalgia, hoping to make the games you wanted to see back then?

[eddhell]

oh, and after reading the book several times, searching and reading tons of posts, reading, reading, and reading......the Inty_Workshop tool helped me the most, answered most of my questions immediately, and gave me a more visual representation and understanding of the limits of GROM and GRAM cards.

[+cmadruga]

13 hours ago, eddhell said:

Seems like more people lately are trying to learn to program homebrew for their favorite old systems (and realizing how hard it really is)....maybe because the newest games are all overblown graphics and same cookie cutter gameplay?  Or maybe just nostalgia, hoping to make the games you wanted to see back then?

I think the barrier to entry when it comes to Intellivision has never been lower, and it's a great time to start developing! I'm sure you will get lots of help and encouragement from folks here.

Edited November 27, 2019 by cmadruga

[carlsson]

Yes. This subforum currently contains 694 threads (minus those in the respective contest subforums). Out of those, optimistically 90 threads have not been posted to since the advent of IntyBASIC in the beginning of 2014. Sure, a fair amount of the remaining ~600 threads cover CP1610 programming, hardware, Aquarius stuff etc but I'd be willing to say that 60-70% of all the discussion in this subforum is related to IntyBASIC.

Edited November 27, 2019 by carlsson