Normal sized Sprite question

[boardgamebrewer]

In constants.bas:

REM -------------------------------------------------------------------------
REM Note: Add these constants to the sprite command's X parameter.
REM -------------------------------------------------------------------------
CONST HIT				= $0100		'  the sprite's collision detection.
CONST VISIBLE				= $0200		' Make the sprite visible.
CONST ZOOMX2				= $0400		' Make the sprite twice the width.

REM -------------------------------------------------------------------------
REM Y
REM -------------------------------------------------------------------------
REM Note: Add these constants to the sprite command's Y parameter.
REM -------------------------------------------------------------------------
CONST DOUBLEY				= $0080		' Make a double height sprite (with 2 GRAM cards).
CONST ZOOMY2				= $0100		' Make the sprite twice (x2) the normal height.
CONST ZOOMY4				= $0200		' Make the sprite quadruple (x4) the normal height.
CONST ZOOMY8				= $0300		' Make the sprite octuple (x8) the normal height.
CONST FLIPX				= $0400		' Flip/mirror the sprite in X.
CONST FLIPY				= $0800		' Flip/mirror the sprite in Y.
CONST MIRROR				= $0C00		' Flip/mirror the sprite in both X and Y.

ZOOMY2 is defined as twice normal height, but from my understanding that this is the 'normal width' setting

 

What am I missing?

[+DZ-Jay]

In constants.bas:

REM -------------------------------------------------------------------------
REM Note: Add these constants to the sprite command's X parameter.
REM -------------------------------------------------------------------------
CONST HIT				= $0100		'  the sprite's collision detection.
CONST VISIBLE				= $0200		' Make the sprite visible.
CONST ZOOMX2				= $0400		' Make the sprite twice the width.

REM -------------------------------------------------------------------------
REM Y
REM -------------------------------------------------------------------------
REM Note: Add these constants to the sprite command's Y parameter.
REM -------------------------------------------------------------------------
CONST DOUBLEY				= $0080		' Make a double height sprite (with 2 GRAM cards).
CONST ZOOMY2				= $0100		' Make the sprite twice (x2) the normal height.
CONST ZOOMY4				= $0200		' Make the sprite quadruple (x4) the normal height.
CONST ZOOMY8				= $0300		' Make the sprite octuple (x8) the normal height.
CONST FLIPX				= $0400		' Flip/mirror the sprite in X.
CONST FLIPY				= $0800		' Flip/mirror the sprite in Y.
CONST MIRROR				= $0C00		' Flip/mirror the sprite in both X and Y.

ZOOMY2 is defined as twice normal height, but from my understanding that this is the 'normal width' setting

 

What am I missing?

 

Good question. We had a debate over this when discussing the SDK years ago. The consensus then was that, even though sprites are half the resolution of background cards, they are their own thing, and exist in their own space. In other words, that "half resolution" is actually the true vertical resolution of a sprite. Thus, ZoomY2 doubles its vertical resolution, ZoomY4 quadruples it, and ZoomY8 multiplies it by eight.

 

Horizontal resolution, on the other hand, can only be doubled.

 

We didn't wish to complicate matters by trying to describe things in terms of the overall pixel area (and in fact, the STIC nomenclature actually treats the flags as multipliers), so the constants describe zoom factors of the base resolution of a sprite, which just happens to stand at half the height of background cards.

 

I hope that clears it up.

 

-dZ.

[boardgamebrewer]

Yes, understood.

Thanks for the quick reply!

 

Now studying the differences between colorstack and fg/bg mode. I think I understand, and have successfully modified a game to change it over from mode 0 to mode 1 as an exercise.

 

Currently looking for more info on "Coloured squares mode" which is used in colorstack I think.

[boardgamebrewer]

Currently looking for more info on "Coloured squares mode" which is used in colorstack I think.

 

Found colouredsquares.bas! Interesting!

[+DZ-Jay]

Yes, understood.

Thanks for the quick reply!

 

Now studying the differences between colorstack and fg/bg mode. I think I understand, and have successfully modified a game to change it over from mode 0 to mode 1 as an exercise.

 

Currently looking for more info on "Coloured squares mode" which is used in colorstack I think.

 

Coloured Squares mode is not strictly a screen mode at all, but like you suggest, an extension of Color Stack mode. You apply "Coloured Square" to each individual background card by setting two bits, #11 and #12. Essentially, it takes the place of a Color Stack card with a "pastel" color (values higher than 7, i.e., bit #12 set to "1") on a GROM card (i.e., bit #11 set to "0").

 

(That means that one of the limitations of Color Stack mode is its inability of using "high color" on GROM cards.)

 

Enabling Coloured Squares on a card treats it as a block of four large pixels (affectionally called "bloxels" for blocky pixels):

  8x8 pixel card
    ____|____
   /         \

   +----+----+
   |    |    |
   |  0 |  1 |
   +----+----+
   |    |    |
   |  2 |  3 |
   +----+----+

The color and card information fields on the BACKTAB word then split into groups of 3-bits (0 to 7) for the colors of each one of the bloxels (except for the last bloxel, who only gets two bits):

    13   12   11   10    9    8    7    6    5    4    3    2    1    0    
  +----+----+----+----+----+----+----+----+----+----+----+----+----+----+  
  |Pix3|  1 |  0 | Pix. 3  | Pix. 2 color | Pix. 1 color | Pix. 0 color |  
  |Bit2|    |    | bit 0-1 |    (0-7)     |    (0-7)     |    (0-7)     |  
  +----+----+----+----+----+----+----+----+----+----+----+----+----+----+  

For more information, check out the file "stic.txt" included with the IntyBASIC SDK in the "Documents/Tech" folder.

 

-dZ.

Edited September 2, 2018 by DZ-Jay

[+DZ-Jay]

 

Found colouredsquares.bas! Interesting!

 

Ah yes, GroovyBee provided that example with some re-usable functions that encapsulate "plotting" bloxels, treating the screen as a large blocky area.

 

-dZ.

[+DZ-Jay]

There's also a sample program created by user Catsfolly that attempts to make use of the Coloured Squares mode for making large sprites. It's quite amusing, if limited in its practicality.

 

I'll try to find it in the forum and post a link later.

 

-dZ.

[+DZ-Jay]

Oh, I forgot a bit of warning. Be aware of the following caveats mentioned in the "stic.txt" document:

 

• Colors 0 through 6 display directly from the Primary Color Set.
• Color 7 actually displays the current color on the top of the color-stack.
• Colors 0 through 6 behave as "on" pixels that will interact with MOBs. Color 7 behaves as "off" pixels and does not interact with MOBs.

[boardgamebrewer]

I don't have IntyBasic SDK yet, as I mainly work off a mac, but if there is interesting docs in there, I'll install it on my other system.

 

Thanks for all the info, it is great! I'm contemplating a new game, and just want to start off graphically in the best way.

[+DZ-Jay]

I don't have IntyBasic SDK yet, as I mainly work off a mac, but if there is interesting docs in there, I'll install it on my other system.

 

Sorry, the "stic.txt" is also included as part of the SDK-1600, the distribution of the jzIntv emulator and as1600 assembler. That's actually where it comes from originally.

 

Check the "doc/programming" folder of the SDK-1600 for it.

 

Thanks for all the info, it is great! I'm contemplating a new game, and just want to start off graphically in the best way.

 

It's my pleasure. By the way, just a word of advice from my experience -- but feel free to let your mileage vary:

• FG/BG mode allows for more colourful scenes because of its individual application of foreground and background colours per card. However, it limits your graphics to the 64 custom GRAM cards and the "low-end" GROM (mostly ASCII characters). This is suitable for many uses, but the 64 custom cards and ASCII characters limit the graphical expressivity of the scene.
• Color Stack mode gives you access to the full GROM set, which includes many geometric shapes that can be used judiciously in place of custom cards, extending your graphical abilities of expression. It, however, trades that graphical flexibility for access to colors. Your GRAM cards can use as foreground any of the 16 colors, but the GROM cards are limited to only the lower 8 (the extra bit is used to enable Coloured Squares). The background colour of either is then limited to the four-colour stack, which can only be used in sequence by advancing one slot per card.
• In my opinion, the biggest limitation of the Intellivision is in its graphics resolution, and how 64 custom cards are hardly enough to express much graphical detail in a 20x12 card scene. Therefore, my preference has always been to use Color Stack and mix my scene with GROM and GRAM cards in interesting ways.
• Do not be afraid of the 4-color Color Stack itself -- it is much more versatile than most people give it credit for, and many colourful scenes can, and have been, created. All it takes is clear understanding of the techniques and some creativity and hard work.

-dZ.

Edited September 2, 2018 by DZ-Jay

[+Black_Tiger]

Good question. We had a debate over this when discussing the SDK years ago. The consensus then was that, even though sprites are half the resolution of background cards, they are their own thing, and exist in their own space. In other words, that "half resolution" is actually the true vertical resolution of a sprite. Thus, ZoomY2 doubles its vertical resolution, ZoomY4 quadruples it, and ZoomY8 multiplies it by eight.

 

Horizontal resolution, on the other hand, can only be doubled.

 

We didn't wish to complicate matters by trying to describe things in terms of the overall pixel area (and in fact, the STIC nomenclature actually treats the flags as multipliers), so the constants describe zoom factors of the base resolution of a sprite, which just happens to stand at half the height of background cards.

 

I hope that clears it up.

 

-dZ.

Can you please confirm that I understand sprites sizes correctly. The way you have described it makes the most sense, but I keep seeing people say that sprites can be one of two sizes (8 x 8 and 8 x 16) and they can be doubled horizontally.

 

With what I've also read about there being a cap of 64 total cards at once and that sprites take from this, it leads to believe that sprites are strictly 8 x 8 and between the vertical and horizontal stretching combinations, these are all of the possible pixel-equivalent sprite sizes that an actual 8 x 8 sprite can be displayed as:

 

Sprite resolution: 8 x 8, 8 x 16, 8 x 32, 8 x 64, 16 x 8, 16 x 16, 16 x 32, 16 x 64

 

All appearing on screen at half the pixel size of the cards.

 

Here is a mockup I made:

 

[mr_me]

Those objects are all 8x8 with various stretches applied. There is a stic register bit that tells the stic to use two cards to define a moving object. That's two 8x8 cards making one 8x16 object that can be stretched up to 8x vertically, the height of eight background cards.

 

Edit:. And pixel widths should be double that is shown in the mockup.

Edited October 7, 2018 by mr_me

[+DZ-Jay]

Can you please confirm that I understand sprites sizes correctly. The way you have described it makes the most sense, but I keep seeing people say that sprites can be one of two sizes (8 x 8 and 8 x 16) and they can be doubled horizontally.

 

With what I've also read about there being a cap of 64 total cards at once and that sprites take from this, it leads to believe that sprites are strictly 8 x 8 and between the vertical and horizontal stretching combinations, these are all of the possible pixel-equivalent sprite sizes that an actual 8 x 8 sprite can be displayed as:

 

Sprite resolution: 8 x 8, 8 x 16, 8 x 32, 8 x 64, 16 x 8, 16 x 16, 16 x 32, 16 x 64

 

All appearing on screen at half the pixel size of the cards.

 

Here is a mockup I made:

 

 

OK, I'm sorry for the confusion and I am guilty of perpetuating that.

 

The actual technical reality is that a sprite can be of either "single-vertical resolution" or "double-vertical resolution." The "zoom" factors are then applied to this base resolution.

 

Therefore, there are three controls for sprites size:

• Vertical resolution - Y register bit #7. Clear = single; Set = double.
• Y Zoom factor - Y register bits #8 and #9.
• X Zoom factor - X register bit #10. Clear = normal (8 pixels); Set = double (16 pixels)

The combined bits give you the following sizes:

                YRES  YSIZ4  YSIZ2    MOB Resolution   Displayed height
                  0     0      0          8 x 8            4 pixels
                  0     0      1          8 x 8            8 pixels
                  0     1      0          8 x 8           16 pixels
                  0     1      1          8 x 8           32 pixels
                  1     0      0          8 x 16           8 pixels
                  1     0      1          8 x 16          16 pixels
                  1     1      0          8 x 16          32 pixels
                  1     1      1          8 x 16          64 pixels

A "single-vertical resolution" sprite is 8x8 pixels with no zoom factor. It takes a single 8x8 pixel card from either GRAM or GROM. It will appear as a "squashed" object, because the vertical size of pixels is 1/2 of their horizontal size.

 

A "double-vertical resolution" sprite is 8x16 pixels with no zoom factor. It takes two contiguous 8x8 pixel cards from either GRAM or GROM, but they most start at an even-number address (i.e., their card number must be an even number). It will appear as a "square" object, because the vertical size of pixels is 1/2 their horizontal size. Therefore, it will look like it fits in an 8x8 background block, but you will have twice as many pixels vertically, giving you increased detail.

 

This is the reason that we say that a sprite can be either 8x8 or 8x16, referring to their base resolution. You can then double (x2) their horizontal size; and you can double (x2), quadruple (x4), and octuple (x8) their vertical size.

 

Obviously double-vertical resolution sprites give you more detail, but at the cost of consuming two cards from memory. Personally, I always strive to go for double-vertical resolution for main objects whenever possible, since it makes them more expressive and detailed. However, since there are only 64 cards available in Graphics RAM for use at any one time, this is a trade off between providing higher detail on the sprite or on the background.

 

I tend to animate sprites "in place," by cycling their GRAM card; thus conserving precious GRAM by assigning at most 2 cards per object.

 

I hope this clears it up. Let me know if you still have questions.

 

-dZ.

Edited October 7, 2018 by DZ-Jay

[+Black_Tiger]

I think that I understand better now how they reach their potential display sizes.

 

 

Is this correct?:

 

8 x 16 "double vertical resolution" sprites would be more detailed vertically than my mockup when stretched, because the vertical stretching is increasing 2 cards instead of one and essentially visually multiplying from a 16 pixel tall base object instead of an 8 pixel tall object.

 

Horizontal resolution is the same as background cards and can still be be doubled horizontally. So a sprite can appear as wide as 2 background cards.

 

 

Do 8 x 16 "double vertical resolution" sprites count as 1 or 2 of the 8 sprites displayed onscreen at once limit?

 

 

Thanks for your help guys.

[mr_me]

An 8x16 sprite object counts as one of the eight.

[+DZ-Jay]

Is this correct?:

 

8 x 16 "double vertical resolution" sprites would be more detailed vertically than my mockup when stretched, because the vertical stretching is increasing 2 cards instead of one and essentially visually multiplying from a 16 pixel tall base object instead of an 8 pixel tall object.

 

A double-vertical resolution sprite will be drawn using 16 pixels, taken from two contiguous cards, one on top of the other. The base size of these pixels will be one scan-line, or half the height of a background card. The 16 pixels will fit in the height of one background card. This is why it gives you higher resolution: 16 pixels in the space of 8.

 

A single-vertical resolution sprite will be drawn using 8 pixels from a single card. Its base size will also be one scan-line, so it will look squashed, half the size of a background card.

 

In either case, you can then apply the Zoom factors to increase the height of the pixels by doubling them each time.

 

Horizontal resolution is the same as background cards and can still be be doubled horizontally. So a sprite can appear as wide as 2 background cards.

 

Correct. However, this is not the same as the double-vertical resolution. Each of the 8 horizontal pixels will be doubled in size.

 

Do 8 x 16 "double vertical resolution" sprites count as 1 or 2 of the 8 sprites displayed onscreen at once limit?

 

They always count as a single object. You have 8 sprite objects available, each of which can be set to be either single or double vertical resolution.

 

-dZ.

Edited October 8, 2018 by DZ-Jay

[intvnut]

I drew a number of pictures several years ago to try to capture the effect of the various size flags on the MOBs. These are on IntelliWiki, but since I never wrote the article they were intended to be a part of, they only show up in the unused files page.

 

The short, short version, from how I prefer to think about it:

• One bit (YRES) selects between an 8x8 vs. 8x16 bitmap for the MOB. If you select an 8x16 bitmap, it needs to start on an even-numbered GRAM/GROM card #.
• MOBs can use half-height pixels vertically when at their smallest vertical scale factor. These pixels are half the height of pixels in BACKTAB. I prefer to think of these as half-height pixels, as everything else in the architecture (including MOB coordinates) works at the same granularity as pixels in BACKTAB. (159x96)
• The bitmap size (YRES) for a MOB (8x8 or 8x16) is separate from its vertical scaling (YSIZE = 1x, 2x, 4x, 8x).

Here are the pictures I mentioned. They aren't great, but they aren't horrible either. Setting YSIZE=01 gives you vertical pixels that are the same height as BACKTAB pixels. For reference, a MOB with YRES=1/YSIZE=00 and a MOB with YRES=0/YSIZE=01 both give you a MOB that is the same dimensions as a single BACKTAB card. The YRES=1/YSIZE=00 MOB will cram a 8x16 bitmap into that space, while the YRES=0/YSIZE=01 MOB will fill the space with an 8x8 bitmap.

 

 

Also note that horizontal stretching (XSIZE != 0) merely stretches pixels in a MOB as well.

Edited October 8, 2018 by intvnut