Making Backgrounds and Shapes (IntyBASIC-ish)

[+Tarzilla]

Intybasic comes with a scroll.bas sample file that shows you. There is no magic in Intybasic that saves you from understanding how the scrolling hardware works. Draw a screen. Tell the system to hardware scroll in what direction and by how many pixels. Loop. After 8 pixels have moved you have to replace the column or row that is now empty with tiles. The sample uses print commands to replace these tiles Iirc.

 

 

crappybkg.bmp

 

This image runs thru IntyColor just fine.

 

Using the stub produced by IntyColor and a few lines of code and we endlessly scroll, using the last few columns of the screen that are stored in SCREEN data to repeat the image.

crappytut.bas

Note that this file isn't to be taken as a best practice, just to illustrate the concept.

 

 

Safecracker does the same thing, but you'll notice it always scrolls diagonally by scrolling left right 1 pixel, then up down 1 pixel, never truly diagonally in one motion.

 

As for the way the Safecracker screens are designed, look at this:

 

Notice all the diagonals? These along with some custom ones and creative use of colors makes the 3d effect.

Print GROM 104 and 105 side by side and color the two colors appropriately and you have the top of a 3d building....

 

All you need is some format to keep a map of the entire area and slice in the column and row that is new to the screen as the hardware scrolling moves the currently displayed pixels.

[intvnut]

 

 

crappybkg.bmp

 

This image runs thru IntyColor just fine.

 

Using the stub produced by IntyColor and a few lines of code and we endlessly scroll, using the last few columns of the screen that are stored in SCREEN data to repeat the image.

crappytut.bas

Note that this file isn't to be taken as a best practice, just to illustrate the concept.

 

 

Safecracker does the same thing, but you'll notice it always scrolls diagonally by scrolling left right 1 pixel, then up down 1 pixel, never truly diagonally in one motion.

 

As for the way the Safecracker screens are designed, look at this:

 

GROMSNAP.png

Notice all the diagonals? These along with some custom ones and creative use of colors makes the 3d effect.

Print GROM 104 and 105 side by side and color the two colors appropriately and you have the top of a 3d building....

 

All you need is some format to keep a map of the entire area and slice in the column and row that is new to the screen as the hardware scrolling moves the currently displayed pixels.

 

 

BTW, the IntelliWiki has a slightly better GROM image that I spent way too much time drawing in Visio, as I recall.

 

 

 

Also, the show_grom utility will output text or HTML + GIFs. The -x and -y flags can be used to blow up the GIF size in the HTML output version. Run show_grom with no flags for usage info:

Usage:  show_grom [flags] grom.bin

        Recognized flags:

        -o outfile  Specify output file (writes to stdout by default)
        -d #        Digit display mode for card #'s
                    1  Decimal only (default)
                    2  Hexadecimal only 
                    3  Hexadecimal and Decimal
        -h          HTML output (default is ASCII)
        -x #        Displayed width for GIFs       (HTML mode only)
        -y #        Displayed height for GIFs      (HTML mode only)
        -r #        Cards per row                  (HTML mode only)
        -f #        Relative font size for labels  (HTML mode only)
        grom.bin    Pathname for GROM.BIN file to show contents of

[+DZ-Jay]

And for those who read ASCII, attached is the ROM data I use in my tile ripper script.

 

grom.txt

[First Spear]

So, can GRAM be bank-switched or swapped somehow? In a game like Christmas Carol, or even Armor Battle, it appears that there are a limited number of finite shapes drawn on a number of finite boards. 64 shapes in GRAM and that's it. But can that set of 64 be exchanged with a whole different set within a single program? And if not, if the set is limited to a "cartridge", could a game be made up of different cartridges that are swapped on/out to give more background capability along with MOB re-use to make a game seem like its on a larger play area?

 

Of course, this is still all within the realm of IntyBASIC.

 

Thanks.

[First Spear]

So, can GRAM be bank-switched or swapped somehow? In a game like Christmas Carol, or even Armor Battle, it appears that there are a limited number of finite shapes drawn on a number of finite boards. 64 shapes in GRAM and that's it. But can that set of 64 be exchanged with a whole different set within a single program? And if not, if the set is limited to a "cartridge", could a game be made up of different cartridges that are swapped on/out to give more background capability along with MOB re-use to make a game seem like its on a larger play area?

Of course, this is still all within the realm of IntyBASIC.

Thanks.

I think that B-17 Bomber gates memory locations to the screen in certain circumstances when you are flying in order to show llak. If that is true, then could images first be created in a program, stored in memory on the cartridge in general, and then replace GRAM completely for new backgrounds?

[+nanochess]

So, can GRAM be bank-switched or swapped somehow? In a game like Christmas Carol, or even Armor Battle, it appears that there are a limited number of finite shapes drawn on a number of finite boards. 64 shapes in GRAM and that's it. But can that set of 64 be exchanged with a whole different set within a single program? And if not, if the set is limited to a "cartridge", could a game be made up of different cartridges that are swapped on/out to give more background capability along with MOB re-use to make a game seem like its on a larger play area?

 

Of course, this is still all within the realm of IntyBASIC.

 

Thanks.

 

There is no bank-switching or swapping for GRAM.

 

The GRAM is loaded copying data from ROM or RAM, in IntyBASIC this is acomplished using:

' The simple shape program. Dec/13/2014
DEFINE 0,1,my_shape
WAIT

PRINT AT 20 COLOR 7,"\256"

loop:

GOTO loop

my_shape:
    BITMAP "01111110"
    BITMAP "11011011"
    BITMAP "11111111"
    BITMAP "11100111"
    BITMAP "11111111"
    BITMAP "10111101"
    BITMAP "11000011"
    BITMAP "01111110"

Esentially in each frame you can load GRAM and, for example, make the face animated while using only ONE GRAM shape.

[+DZ-Jay]

So, can GRAM be bank-switched or swapped somehow? In a game like Christmas Carol, or even Armor Battle, it appears that there are a limited number of finite shapes drawn on a number of finite boards. 64 shapes in GRAM and that's it. But can that set of 64 be exchanged with a whole different set within a single program? And if not, if the set is limited to a "cartridge", could a game be made up of different cartridges that are swapped on/out to give more background capability along with MOB re-use to make a game seem like its on a larger play area?

 

Of course, this is still all within the realm of IntyBASIC.

 

Thanks.

 

There are 64 slots in GRAM for custom tiles, and each one can be loaded individually at any point during a program. Well, not quite: the only limitation is that GRAM can only be accessed during the Vertical Retrace Blanking Period (a.k.a. VBLANK), which conveniently is what sets the pace of game engines at 60 times a second for NTCS consoles, and 50 times a second for PAL.

 

If you notice, Christmas Carol changes the tiles used to construct the maze at different times. In fact, there are actually four "ice-cube" sets. This constraint is self-imposed. There was nothing stopping me from changing the tiles on every single level, except the time and effort I was willing to put into that.

 

The way that Christmas Carol's framework was devised (and the way that most games work) is that you allocate sections of GRAM for particular elements, such as sprites, background graphics, animations, etc. As I mentioned before, the way that I use this feature is by pre-allocating blocks and assigning them to objects. Some of these are loaded once during initialization of a game phase, others are dynamically cycled during program execution.

 

For instance, in Christmas Carol, I allocate seven tiles for the maze background tiles (the "ice-cube" set), which are statically loaded at the initialization of a level, and persist until the next one. Seven tiles is a convenient number for maze games, for it lets you create diverse patterns. Here's an example of an "ice-cube" set:

1. Left-top corner
2. Right-top corner
3. Right-bottom corner
4. Left-bottom corner
5. Left-edge horizontal
6. Right-edge horizontal
7. junction/solid

:1       :2       :3       :4       :5       :6       :7
....#### #####... ######.. ..###### .####### ..####.. .######.
...#.### ######.. ####.#.. ..##.### ##.##### ..#.##.. #.....##
..###### ###.##.. ######.. ..###### ####.##. ..##.#.. #.#..#.#
..###### ..####.. ###.#... ..#.##.. ...###.. ..####.. ##..#..#
..####.# ..####.. .##.#... ....#... ........ ..#.##.. #..#.#.#
..##.#.# ..##.#.. .#...... ....#... ........ ..####.. #...#.##
..#.##.. ..#.##.. .#...... ........ ........ ..##.#.. #..#.#.#
..##.#.. ..##.#.. ........ ........ ........ ..####.. .######.

Moreover, as also mentioned before, the main technique that I used to animate sprites and background objects in my game was to swap the GRAM cards that they point to periodically. This is typically called "GRAM cycling."

 

To further illustrate the point of switching GRAM tile sets, consider the different phases of the Christmas Carol game:

• During the title screen, mostly graphic tiles are loaded to draw the Christmas Tree.
• During the credits sequence, a custom font set is loaded to display all the text.
• In the practice menu screen, another custom set of graphic tiles are loaded to draw the menu, along with the tile set of the level selected, in order to display a little vignette of it.
• For the main game play, the maze tile sets are loaded, along with a few other dynamic objects that are "cycled" periodically. Among these are the sprites, the custom fonts for the score display, etc.

Edited December 13, 2014 by DZ-Jay

[freewheel]

So, can GRAM be bank-switched or swapped somehow? In a game like Christmas Carol, or even Armor Battle, it appears that there are a limited number of finite shapes drawn on a number of finite boards. 64 shapes in GRAM and that's it. But can that set of 64 be exchanged with a whole different set within a single program? And if not, if the set is limited to a "cartridge", could a game be made up of different cartridges that are swapped on/out to give more background capability along with MOB re-use to make a game seem like its on a larger play area?

 

Of course, this is still all within the realm of IntyBASIC.

 

Allow me to answer in very simple terms: yes, you absolutely can exchange GRAM within a single program. And yup, in IntyBASIC. You just call DEFINE whenever you want to change out some cards.

 

The only real limitations are that you can only do 16 cards at a time (if you use the music player anyway, otherwise it's 18) before you have to call WAIT - which is basically what they're talking about with Vblank and such. So you can "only" do 60 DEFINEs per second. That is a hell of a lot of GRAM data being changed about, if you think about it

 

Incidentally, the reason you don't see it very much in old games is that ROM was expensive. A full set of 64 GRAM cards is 512 bytes, which is a huge chunk of a cartridge such as Armor Battle - nearly 10% of the entire game! (Someone correct me if I'm wrong on the math here) These days that's peanuts, which is why you see so much more complexity and variety in graphics in modern homebrew. Within Goatnom, for example, I'm currently using 5 completely different sets of 64 GRAM cards, all within the same game. The title screen, for example, uses nearly an entire set of 64 cards itself! These get swapped out for other cards as soon as you start the game. There's another set used for the starting story intermission, another set for the "game over" screen, etc.

 

Now, doing this within the gameplay itself gets tricky (you have to watch your timing and you can seriously slow things down if you do it wrong) but it's certainly doable. Usually you see people swapping GRAM for title screens and things like that, or for new level data. So the loading of the new cards happens without interfering with gamplay.