Jump to content
IGNORED

Newbie Programming Questions


Fushek

Recommended Posts

I don't know if "most." I use it because it seems to be more flexible in some ways, mostly because it allows all colors are available for foreground when using GRAM cards, and also it can address all of GROM.

 

Yep. You lose lower-case in particular, which is why Space Patrol's menu says "SELECT MISSION" in all caps. The rest of the game is in Color Stack mode, but the menus are in FGBG mode.

 

I'm not familiar with any limitation on advancing the color stack.

 

You can't advance it on a tile containing colored squares.

Link to comment
Share on other sites

 

 

You can't advance it on a tile containing colored squares.

 

It won't advance the stack, or will it just not use the color on a tile using colored squares?

 

(I've never used colored squares, so I don't know how they affect the color stack.)

Link to comment
Share on other sites

It won't advance the stack, or will it just not use the color on a tile using colored squares?

 

(I've never used colored squares, so I don't know how they affect the color stack.)

 

The bit normally dedicated to advancing the color stack (bit 13) gets repurposed to specify bit 2 of the color in the lower right corner of the tile. See the diagram on the wiki. Therefore, the STIC ignores it for color stack purposes and will not advance the color stack when it is set.

 

The color stack defines what color #7 displays as for colored square tiles, so this limitation is actually relevant to colored square images. That is, the color stack is visible in colored square tiles (as color #7), but you can't advance the stack.

Edited by intvnut
Link to comment
Share on other sites

 

The bit normally dedicated to advancing the color stack (bit 13) gets repurposed to specify bit 2 of the color in the lower right corner of the tile. See the diagram on the wiki. Therefore, the STIC ignores it for color stack purposes and will not advance the color stack when it is set.

 

The color stack defines what color #7 displays as for colored square tiles, so this limitation is actually relevant to colored square images. That is, the color stack is visible in colored square tiles (as color #7), but you can't advance the stack.

 

Gotcha!

Link to comment
Share on other sites

OK ... this is starting to sink in but I'm having issues with translating this to code. Take the following example:

 

MVI disp_ptr(1,0), R0

XORI #$2000, R0

MVO R0, disp_ptr(1,19)

 

I translate this as:

 

1 - Copy in the value of what's in column 1,0 (which is $0214) into Register 0

2 - Perform a bit adjustment of 0010000000000000 (this adds 1 to the 13th bit which is the color stack advance bit) and place that changed value in Register 0

3 - Copy Register 0 value to column 1,19 (which is $0227)

 

Is there an easier way to simply change the advance bit other than copying from an existing location and is there a way to double (or even triple) advance the color stack to get back to a color that you want? I know that the STIC.cs_advance is out there, but not sure programatically how to utilize it.

Link to comment
Share on other sites

OK ... this is starting to sink in but I'm having issues with translating this to code. Take the following example:

 

MVI disp_ptr(1,0), R0

XORI #$2000, R0

MVO R0, disp_ptr(1,19)

 

I translate this as:

 

1 - Copy in the value of what's in column 1,0 (which is $0214) into Register 0

2 - Perform a bit adjustment of 0010000000000000 (this adds 1 to the 13th bit which is the color stack advance bit) and place that changed value in Register 0

3 - Copy Register 0 value to column 1,19 (which is $0227)

 

Is there an easier way to simply change the advance bit other than copying from an existing location and is there a way to double (or even triple) advance the color stack to get back to a color that you want? I know that the STIC.cs_advance is out there, but not sure programatically how to utilize it.

 

STIC.cs_advance is just a constant, and you can use it in any expression. For example, if you want to make the letter 'A' in white while advancing the color stack, you could write out a crazy expression like this:

 

MVII #STIC.cs_advance + C_WHT + (('A' - $20) SHL 3), R0

 

After that MVII executes, R0 will have the value you need to write to BACKTAB to get that magic A. You can write it as many places as you like.

 

The entire expression "STIC.cs_advance + C_WHT + (('A' - $20) SHL 3)" gets computed by the assembler at assembly time. (Note: A single character in single quotes evaluates to that character's ASCII value.) You can write out however complex an expression you like, as long as it evaluates to a constant value at assembly time. That means you can't do something like "C_WHT + (R0 SHL 3)", because R0's value isn't known at assembly time.

 

As for that crazy expression up there, that's probably more than you want to type every time you just want to get a letter on the screen. If you just need to create a couple characters this way, you might use the "gen_cstk_card()" or "gen_fgbg_card()" macros in stic.mac. They implement that expression for you.

 

As for advancing the stack two or three times: No can do. In 4-Tris, I actually only needed two colors, so I had to double up the colors in the color stack. I used one color for the background, and one color for color #7 in the "well". To make that work, though, I had to deal with the additional restriction that I couldn't advance the color stack on a colored squares card. So, there's actually a strip of "all bits on" cards to the left and right of the "well" that has the advance bit turned on and foreground color set to black, so that the color stack will be rotated properly for the well itself. If you're curious, here's the code that does that part:

 


       ; Set up color stack advance bits to left and right of the "well".
       ; Also, draw well edges in yellow.
       MVII    #$206, R4
       MVII    #$22F8, R0      ; Black w/ "advance" bit, no colsq
       MVII    #11,    R1      ; 11 rows
       MVII    #$1186, R2      ; Yellow in blocks 0, 2
       MVII    #$3430, R3      ; Yellow in blocks 1, 3
@@csloop:
       MVO@    R0,     R4
       MVO@    R2,     R4
       ADDI    #4,     R4
       MVO@    R3,     R4
       MVO@    R0,     R4
       ADDI    #12,    R4
       DECR    R1
       BNEQ    @@csloop

 

Why $22F8 instead of some expression, or a call to gen_cstk_card()? At the time I wrote it, I had precomputed the value by hand. Back then, AS1600 wasn't quite as powerful and I worked out more on paper by hand, rather than letting the computer do the work. Also, AS1600 didn't have macros back then, so I couldn't have called the macro gen_cstk_card().

 

 

EDIT: I'm not sure why, but AA corrupted every occurrence of the word "expression" above. I think it's fixed now.

Edited by intvnut
Link to comment
Share on other sites

Another way you can set the color stack advance is to first set up your screen, and then go toggle the bit the couple places you need it toggled. I use this approach in Space Patrol, since it was easier that way.

 

For example, the following loop sets up the repeating tile pattern for the "city" backdrop in Space Patrol. The code at the very end goes back and toggles the color stack on the one card that needs it toggled:

 

sp_city_loop.png

 

For that last XORI, you could have used that constant "STIC.cs_advance" like to:

 

 MVI	 TROW+60,R0
 XORI #STIC.cs_advance, R0
 MVO	 R0,	 TRO+60

 

 

BTW, you can browse the Space Patrol source online. That particular bit of code is in gameloop.asm, in the function DRAWGAME. You can also see the other couple places I toggle the color stack.

Edited by intvnut
Link to comment
Share on other sites

To add to what intvnut said, there is no way to advance the color stack artificially to return to the color you want. However, you can do various tricks to manipulate the color stack to get some nice effects.

 

For instance, in Christmas Carol, for the maze screens, I only needed two colors: black for the full background, and yellow for the occasional present which took the space of a full BACKTAB tile (these are just a Yellow cross on a colored box).

 

For this, I set up my color stack like this: C_BLK, C_YEL, C_BLK, C_YEL. As you can see, advancing the stack twice in a row gets me to my original color.

 

To illustrate, consider the following scene from the game:

post-27318-0-97289200-1349257521_thumb.gif

 

On tile BACKTAB(4, 3), there is one of these presents, Yellow ribbon (background) on a Red box (foreground). The BACKTAB for row #4 would be set like:

 

(consider the advance bit of each word, the present tile is in bold):

0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

 

I set the advance bit on the present tile, and also to the next tile to put the stack back on Black.

 

As intvnut suggested, this was all pre-computed. I have the word for each tile in the BACKTAB in an array, and I just iterate through it and copy each tile into the BACKTAB. Something like this:

 

post-27318-0-36874500-1349255756_thumb.png

(NOTE: I can't prevent the forum software from mangling my code, so I post a picture.)

 

When Carol picks up a present, and it is one of these special ones that uses the advance bit, I employ the other technique intvnut mentioned: XOR bit 13 of the tiles to flip them back to zero. Note that I have to flip both the present's and the next tile's bit to get everything back to normal.

 

Fun Fact:
For a while, there was a bug in Carol that sporadically turned half the screen yellow. There was a race condition that could cause the second tile to not have its bit 13 reset. So when the advance bit was cleared on the present tile (returning to black), the next tile still advanced the color stack to yellow--causing a runaway yellow highlight until the next present or until the end of the BACKTAB. Fun!
:)

 

Which reminds me: If you do this, make sure that you update the BACKTAB words for both tiles in an uninterruptible sequence! Using two consecutive
MVO
instructions should suffice, since they are uninterruptible by nature. Otherwise, there is a chance that a VBLANK may interrupt right between the updates, which will cause the screen to flicker for a single frame while in the unfinished state. That was another old bug in Carol that was squashed some time ago.

 

 

The other trick I use is in the title screen. In this case is not so much a trick, but a clever use of the color stack. I used four colors: C_GRN, C_WHT, C_CYN, C_RED. I developed a technique (which is probably very common, but I wasn't aware of it) whereas, in order to skip some colors, I would draw one tile in "reverse video" (complementing the zeros and ones). This way, the FOREGROUND color bits in the word acts as the effective background color of the tile, in reference to the full picture.

 

This is easily demonstrated with a blank background. Using the color stack mentioned above, starting at zero, we start painting the background with blank tiles, which will show up as Green. Say that I want to skip the second color and jump directly to Cyan. Instead of painting a blank tile, I paint a tile with all 1s (a solid block), and set its foreground color to Green. I also set its color stack advance bit.

 

Et voilá! My color stack is now on the third color and I have a color transition from Green to Cyan.

 

On second thought, this is better illustrated with a picture. Consider the Christmas Carol title screen:

 

post-27318-0-60290000-1349257145_thumb.gif

 

Using the color stack mentioned above, how did I switch from White (the background color on the right) back to Green (the background color on the left)? Easy! The last tile on each row is not blank, but a solid block with the advance bit on and a foreground of White. This skips Cyan. The next tile (the first tile on the next row) also have the advance bit on, skipping Red and going right to Green. Cool, uh?

 

That worked out even better because the solid block is available from GROM, saving precious GRAM space. The same is done with the "L" in Carol and the ribbon of the red present at the bottom-right, except these are GRAM tiles drawn in reverse video.

 

By cleverly drawing the background, you can exploit this trick to great profit. :)

 

I hope this helps.

-dZ.

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

Guys, as usual, great stuff. I'll digest this and keep digging and plodding along. It's neat when pieces of this finally "click" but I have a LONG way to go before I can make anything useful ... but one step at a time.

 

 

Using the color stack mentioned above, how did I switch from White (the background color on the right) back to Green (the background color on the left)? Easy! The last tile on each row is not blank, but a solid block with the advance bit on and a foreground of White. This skips Cyan. The next tile (the first tile on the next row) also have the advance bit on, skipping Red and going right to Green. Cool, uh?

 

 

That is a cool trick and one that I could probably use in my current experiment ...

Link to comment
Share on other sites

Guys, as usual, great stuff. I'll digest this and keep digging and plodding along. It's neat when pieces of this finally "click" but I have a LONG way to go before I can make anything useful ... but one step at a time.

 

No worries. I'll offer what I can to help you get on your way. One thing that worked for me though, is rather than making little demos or trying to figure out one single piece in isolation, I started writing a game.

 

Going that way, I then realized that the hard part is not the Assembly Language, nor the intricacies of the EXEC or the STIC. Anybody in this forum or the INTV-Prog list can provide that information. I learned that the hardest part was putting it all together in an effective way that worked for the game I was writing. That's how I came up with P-Machinery in order to make Pac-Man.

 

The rest of the stuff...? People from this list can provide examples, algorithms, and even wholesale code pieces that you can integrate into your own program.

 

Sure it seems daunting, and it is a lot of work, but I found it much more useful rather than to ask a general question such as "how do you get text printed on the screen," to ask instead something like "here's what I got, this is what my game needs, what is the most effective way to go about it within those parameters."

 

There's always more than one way to skin a cat, and a generic method may not suit all game programs equally.

 

That's just what worked for me. Your mileage may vary, of course. :)

 

That is a cool trick and one that I could probably use in my current experiment ...

 

Oh, that screen is a bit more intricate still!

 

For instance, the "O" in "Carol" is a MOB, because I needed it to be in reverse video, but couldn't afford the GRAM. The BACKTAB tile is just a solid block to advance the color stack. Also, the curvy tails at the bottom of the letters "R" are MOBs, all using the same GRAM card. The problem was that the "R" needed a little extension in order to get the tail out, and if I changed the font, it would have affected all other "R"'s used in the rest of the game. MOB overlays to the rescue!

 

The same for the little tail at the bottom of the letter "A" in "Carol" and the "T" in "Presents": They both use the same GRAM card, but since they are oriented on different points within the tile, I overlaid them with MOBs.

 

Then the color transition between the Christmas tree and the Blue present had to be overlaid with a MOB also. There was no way for me to get from Green to Cyan and also have the Dark Blue for the ribbon in there.

 

It's not the most complex title screen, but it's full of little tricks like that. I considered at some point using FG/BG mode instead, but then I wouldn't have been able to use GROM graphic tiles (the very useful solid block!) nor certain color combinations.

 

I think it came out rather well, and fit my original vision. :)

 

-dZ.

Link to comment
Share on other sites

No worries. I'll offer what I can to help you get on your way. One thing that worked for me though, is rather than making little demos or trying to figure out one single piece in isolation, I started writing a game.

 

Going that way, I then realized that the hard part is not the Assembly Language, nor the intricacies of the EXEC or the STIC. Anybody in this forum or the INTV-Prog list can provide that information. I learned that the hardest part was putting it all together in an effective way that worked for the game I was writing. That's how I came up with P-Machinery in order to make Pac-Man.

 

 

That's kinda what I'm starting and I'm trying to understand the roadblocks that I'll encounter. For instance, my original grandiose idea has already come down to Earth as I realize my limitations on the amount of GRAM that I have available.

 

My game idea:

I'm a lover of D&D and the old Choose Your Own Adventure books and I'm trying to wrap that all together into a game. Now, this isn't an action game by any stretch as I plan a companion book/pdf (I have published short stories in the past), and I want to make the Intellivision into the "turn based action" like an old role playing game from the golden days of role playing. Take for instance the main screen that I'm playing with:

 

post-31049-0-04087100-1349381303_thumb.jpg

 

I plan to have the hero (lower left) and whatever is relevant to the right (monster, etc). During combat, the options will be up top and will trigger an MOB (fireball or whatever) coming from the hero to the monster. The monster will then attack until someone is dead. Various passages from the book will lead down various paths and will trigger changes in health, armor, sword and magic in the lower right. Choose wisely, live to fight another day, die and you'll have to start all over again.

 

Is it feasible to do? That's what I'm playing with and trying to determine. So, I will have many "pages" within the Intellivision that will produce different text and options on the screen. "You may either go: (1) North or (2) South" and based on that you will need to read the passage from the book to find out what happens.

 

Get a magic sword? I can change the sword color of the hero.

 

Will people like something like this? I have no idea ... but if I'm going to try to do this, then I want something that I love to come out of it!

Edited by Fushek
Link to comment
Share on other sites

Instead of on-screen I'd consider using the INTVs main advantage: controller overlays. Also, you could include a choose your own adventure-like book with the flavor text. I think Dragon Wars for the PC and NES did this.

The question of text is one of system ROM limitations and the cart size limitations. Who can you get to make the cart? What size will they support?

Link to comment
Share on other sites

Instead of on-screen I'd consider using the INTVs main advantage: controller overlays. Also, you could include a choose your own adventure-like book with the flavor text. I think Dragon Wars for the PC and NES did this.

The question of text is one of system ROM limitations and the cart size limitations. Who can you get to make the cart? What size will they support?

 

I would not worry about ROM size. The new cartridge designed by by Joe Z. allows for up to 42K of ROM data.

 

I think that's going to be the de facto standard for Intellivision cartridges.

 

 

 

EDIT: Siri ate the "not" in "would not."

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

 

That's kinda what I'm starting and I'm trying to understand the roadblocks that I'll encounter. For instance, my original grandiose idea has already come down to Earth as I realize my limitations on the amount of GRAM that I have available.

 

My game idea:

I'm a lover of D&D and the old Choose Your Own Adventure books and I'm trying to wrap that all together into a game. Now, this isn't an action game by any stretch as I plan a companion book/pdf (I have published short stories in the past), and I want to make the Intellivision into the "turn based action" like an old role playing game from the golden days of role playing. Take for instance the main screen that I'm playing with:

 

post-31049-0-04087100-1349381303_thumb.jpg

 

I plan to have the hero (lower left) and whatever is relevant to the right (monster, etc). During combat, the options will be up top and will trigger an MOB (fireball or whatever) coming from the hero to the monster. The monster will then attack until someone is dead. Various passages from the book will lead down various paths and will trigger changes in health, armor, sword and magic in the lower right. Choose wisely, live to fight another day, die and you'll have to start all over again.

 

Is it feasible to do? That's what I'm playing with and trying to determine. So, I will have many "pages" within the Intellivision that will produce different text and options on the screen. "You may either go: (1) North or (2) South" and based on that you will need to read the passage from the book to find out what happens.

 

Get a magic sword? I can change the sword color of the hero.

 

Will people like something like this? I have no idea ... but if I'm going to try to do this, then I want something that I love to come out of it!

 

That's a great idea, and I think it's doable on the Intellivision.

 

Since that type of game is driven by multiple states during gameplay, I wonder if P-Machinery's built-in state machine and task scheduler could help you with at least the basic scaffolding of a game framework...

Link to comment
Share on other sites

That's kinda what I'm starting and I'm trying to understand the roadblocks that I'll encounter. For instance, my original grandiose idea has already come down to Earth as I realize my limitations on the amount of GRAM that I have available.

 

My game idea:

I'm a lover of D&D and the old Choose Your Own Adventure books and I'm trying to wrap that all together into a game. Now, this isn't an action game by any stretch as I plan a companion book/pdf (I have published short stories in the past), and I want to make the Intellivision into the "turn based action" like an old role playing game from the golden days of role playing. Take for instance the main screen that I'm playing with:

 

post-31049-0-04087100-1349381303_thumb.jpg

 

I plan to have the hero (lower left) and whatever is relevant to the right (monster, etc). During combat, the options will be up top and will trigger an MOB (fireball or whatever) coming from the hero to the monster. The monster will then attack until someone is dead. Various passages from the book will lead down various paths and will trigger changes in health, armor, sword and magic in the lower right. Choose wisely, live to fight another day, die and you'll have to start all over again.

 

Is it feasible to do? That's what I'm playing with and trying to determine. So, I will have many "pages" within the Intellivision that will produce different text and options on the screen. "You may either go: (1) North or (2) South" and based on that you will need to read the passage from the book to find out what happens.

 

Get a magic sword? I can change the sword color of the hero.

 

Will people like something like this? I have no idea ... but if I'm going to try to do this, then I want something that I love to come out of it!

 

Fushek,

 

I'm curious to know what limitations you are encountering with GRAM. That screen looks rather simple.

 

By the way, I have a Perl script I created that generates GRAM/BACKTAB data from ASCII files describing the graphics. That's what I use for the title and screen mazes in Christmas Carol. One of its features is that it compares the entire picture and generates data for only unique tiles. It also compares all unique tiles against the ones available in GROM and uses those instead.

 

At the end of execution, it provides as output how many unique GRAM tiles were found.

 

The way I design my screens is that I draw it first very elaborately with all the fancy stuff I want, and then check out how many tiles it uses. Then I go back and see if I can reduce the count by reusing tiles and reducing some detail. I also check if any of my unique tiles look sorta kinda like GROM tiles, and decide whether it would still be acceptable to replace them with the stock ones and still keep the overall style.

 

I go round-and-round like that until I finally fit within the limits.

 

The script supports only the Color Stack, but allows you to define the colors and the advance bit of each tile.

 

What I get at the end is the full set of data needed to draw the script with the routine I posted earlier.

 

If you think this could help you, I'd be willing to share the scripts. Send me a PM if you're interested.

 

-dZ.

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

I had a similar idea to this. I'm also a pretty big role-playing and gamebook fanatic (as a kid, I "authored" at least 100 of them myself), and I was thinking of making an Ultima-style role-playing game that would come with a gamebook as well. However, instead of it being an integral part of gameplay, you would be presented with side quests which you could embark upon in the book. Successful completion would provide you with codewords, which could be used to bring objects into the game or trigger certain events that would be beneficial (or perhaps not) to the players in-game experience.

I think this is well worth exploring. What series are you a fan of? If you haven't checked out Bloodsword, it's one of the best (and most unique) gamebooks I've ever had the pleasure of reading.

Link to comment
Share on other sites

I had a similar idea to this. I'm also a pretty big role-playing and gamebook fanatic (as a kid, I "authored" at least 100 of them myself), and I was thinking of making an Ultima-style role-playing game that would come with a gamebook as well. However, instead of it being an integral part of gameplay, you would be presented with side quests which you could embark upon in the book. Successful completion would provide you with codewords, which could be used to bring objects into the game or trigger certain events that would be beneficial (or perhaps not) to the players in-game experience.

I think this is well worth exploring. What series are you a fan of? If you haven't checked out Bloodsword, it's one of the best (and most unique) gamebooks I've ever had the pleasure of reading.

 

That's great... I had a typewriter myself as a kid and I remember writing several as well. I don't think that any survived to today, unfortunately. My novel (Game of the Gods) that I wrote in high school still exists though! It was never published, but a 250 page novel in high school was a great accomplishment (or just a sign that I was a complete geek).

 

Haven't read the Bloodsword series (a quick google of it looks like it's up my alley) but I was a huge fan of the Fighting Fantasy series (Deathtrap Dungeon is a classic). Read many of the Lone Wolf and other misc ones as well.

 

Your Ultima game sounds like one I'd buy ... put me on the pre-order list! My favorite was always the Bard's Tale series which is what I was going to initially go for in my initial design ideas.

 

post-31049-0-08085700-1349442378_thumb.jpg

 

I thought that I would change the picture on the right every page with a new picture but figured that I'd quickly run out of room in the GRAM with all the custom pictures.

Link to comment
Share on other sites

Fushek,

 

I'm curious to know what limitations you are encountering with GRAM. That screen looks rather simple.

 

By the way, I have a Perl script I created that generates GRAM/BACKTAB data from ASCII files describing the graphics. That's what I use for the title and screen mazes in Christmas Carol. One of its features is that it compares the entire picture and generates data for only unique tiles. It also compares all unique tiles against the ones available in GROM and uses those instead.

 

At the end of execution, it provides as output how many unique GRAM tiles were found.

 

The way I design my screens is that I draw it first very elaborately with all the fancy stuff I want, and then check out how many tiles it uses. Then I go back and see if I can reduce the count by reusing tiles and reducing some detail. I also check if any of my unique tiles look sorta kinda like GROM tiles, and decide whether it would still be acceptable to replace them with the stock ones and still keep the overall style.

 

I go round-and-round like that until I finally fit within the limits.

 

The script supports only the Color Stack, but allows you to define the colors and the advance bit of each tile.

 

What I get at the end is the full set of data needed to draw the script with the routine I posted earlier.

 

If you think this could help you, I'd be willing to share the scripts. Send me a PM if you're interested.

 

-dZ.

 

I would definitely be interested. I was starting to do something similar in Excel (I'm an accountant, what else would I use?). I'll PM you later as I'm currently at work and I really should get back to it before the CFO comes in and asks why I'm playing around on an Atari website ... then I'd have to politely inform him that it's for the Intellivision and then I'd have to explain what an Intellivision is ... blah blah blah.

Link to comment
Share on other sites

 

I thought that I would change the picture on the right every page with a new picture but figured that I'd quickly run out of room in the GRAM with all the custom pictures.

 

Note that you do not need to load all the tiles for all pictures at once. You can easily just load the necessary tiles for each page.

 

That's how I do the mazes in Carol: on each level, the stage number is used as an index to the data table to load only the tiles needed.

 

P-machinery simplifies this by allowing you to define an "initialization" routine to load tiles. It also encapsulates somewhat the allocation of GRAM tiles to blocks. For instance, one block could be used for the monster graphics, and another for the scenery graphics.

 

It's crude, but effective. :)

Link to comment
Share on other sites

Note that you do not need to load all the tiles for all pictures at once. You can easily just load the necessary tiles for each page.

 

Also, if you have any animations, you don't need to store all the animation frames in GRAM. You can sequence them through GRAM as the animations occur, so you're only tying up 1 or 2 GRAM slots per MOB.

  • Like 1
Link to comment
Share on other sites

Note that you do not need to load all the tiles for all pictures at once. You can easily just load the necessary tiles for each page.

 

That's how I do the mazes in Carol: on each level, the stage number is used as an index to the data table to load only the tiles needed.

 

P-machinery simplifies this by allowing you to define an "initialization" routine to load tiles. It also encapsulates somewhat the allocation of GRAM tiles to blocks. For instance, one block could be used for the monster graphics, and another for the scenery graphics.

 

It's crude, but effective. :)

 

Oh ... that changes things a bit. Maybe time to go back to my original idea and start working through again.

Link to comment
Share on other sites

I would definitely be interested. I was starting to do something similar in Excel (I'm an accountant, what else would I use?). I'll PM you later as I'm currently at work and I really should get back to it before the CFO comes in and asks why I'm playing around on an Atari website ...

 

In looking at my scripts, the output generated makes the assumption that the data will be used by the library of macros and GRAM Block allocation in P-Machinery. For instance, a sample output is this:

 

; ...

BTAB_DATA(TrapScene , $00, $0000, $0000, mGROM), BTAB_ADDRESS( 0, 0)
BTAB_DATA(TrapScene , $00, $0002, $0000, mGRAM), BTAB_ADDRESS( 1, 0)
BTAB_DATA(TrapScene , $01, $0002, $0000, mGRAM), BTAB_ADDRESS( 2, 0)
BTAB_DATA(TrapScene , $00, $0000, $0000, mGROM), BTAB_ADDRESS( 3, 0)
BTAB_DATA(TrapScene , $00, $0000, $0000, mGROM), BTAB_ADDRESS( 4, 0)

; ...

 

You don't have to use P-Machinery, but you will have to use the macros it offers, such as BTAB_DATA() and BTAB_ADDRESS(). Also the symbol "TrapScene" corresponds to an allocated block that resolves to "GRAM_BLOCK.TrapScene".

 

You could also modify the scripts to generate raw output (without the macros). However, the beauty of this whole system I built is that it's fully integrated, and that it is intelligible when you read it casually.

 

In any case, I have the "build-scene" script ready for you, if you want it. I also can help you in setting up the macro libraries from P-Machinery so that you can take advantage of these scripts.

 

These are very simple and convenient to use. For instance, GRAM allocation works like this: There are four main macros (among others):

 

RESET_GRAM
DEFINE_BG_GRAM(TitleScene, TITLE_SCENE)
DEFINE_GRAM_BLOCK(FontUpper, 26)
DEFINE_SPRITE_GRAM(Sprite0, vDouble)

  • RESET_GRAM: Resets the allocation pointer to the beginning of GRAM (you may want to allocate different sets of tiles for different parts of your game, for instance).
  • DEFINE_BG_GRAM: Allocates a block of GRAM for background scenery. This expects the name of a data block generated by the build-scene script, which defines the size of the block and its position.
  • DEFINE_GRAM_BLOCK: Allocates a block of GRAM of the specified number of tiles.
  • DEFINE_SPRITE_GRAM: Allocates a block of GRAM for a sprite. This can be a single-resolution (1 tile), or double-vertical-resolution (2 tiles).

Every time you call one of these macros, the allocation pointer moves forwards, keeping track of how many tiles you've used. It will generate an error when you go beyond 64, as you would expect. Calling RESET_GRAM lets you define a new set of blocks.

 

These macros are built-into the infrastructure of P-Machinery, but can be used on their own if you wish.

 

 

then I'd have to politely inform him that it's for the Intellivision and then I'd have to explain what an Intellivision is ... blah blah blah.

 

Oh, I know how that goes! :)

 

-dZ.

Link to comment
Share on other sites

  • 1 month later...

Woot! Minor victory!

 

I was able to add MOB's to my program (note the red eyes of my skeleton)!

I was also able to advance the stack properly with the recommendations from everyone here. Thanks again!

 

Next, I need to start looking into creating movement for MOB's. I'm not planning on the movement being controlled by the controller at this point, just assigned within the program. For instance, maybe a treasure will sparkle, etc. Also, spells and attacks, I was thinking could lead from the hero on the left to the monster on the right or vice versa (a fireball MOB staring from the hero and exploding on the monster).

 

Any recommendations on where to learn more about static movement (not controller movement)?

post-31049-0-21331800-1352413433_thumb.jpg

Link to comment
Share on other sites

Any recommendations on where to learn more about static movement (not controller movement)?

 

Just a quick bit of insight to get you started thinking on this. There's two things to consider here:

 

1. Changes in appearance.

2. Changes in position

 

You mention:

 

For instance, maybe a treasure will sparkle, etc.

 

That's primarily (or entirely) a change in appearance--ie. animation. You can get this by updating the GRAM over time, or modify the MOB to point to a sequence of GRAM cards over time.

 

You also mention:

 

Also, spells and attacks, I was thinking could lead from the hero on the left to the monster on the right or vice versa (a fireball MOB staring from the hero and exploding on the monster).

 

That's primarily a change in position. For that, you need to update the X and Y positions over time.

 

Both are "movement", but you'll probably want to tackle each separately, or at least understand each separately before you try to combine them.

Link to comment
Share on other sites

It's looking cool!

 

One thing I want to add to what intvnut said: For both changes in positions and changes in appearance, you should consider how to handle non-integer values. For instance, you can animate a sprite by updating it's GRAM tile over time, but how often should you update it? The same for moving a sprite.

 

If you prepare a routine in your game say, that updates sprite positions on every frame, how should it determine how far to move the sprite every time?

 

This is one of those things where it pays to plan ahead how you want to do things in a more holistic way, rather than concentrating on one particular aspect in isolation. You can spend some effort in testing and building code that will move a sprite say, one pixel on every frame, but you'll probably end up throwing most of it away if you then realize that your game needs variable speeds for different sprites, and that the speeds do not necessarily fit neatly as integer number of frames per second.

 

These are "solved problems" in that there are standard ways of implementing them. It may be a good idea to think of this part of your game not as "How do I move a sprite in the abstract?", but rather like "How are my sprites going to move in my game, and how do I accomplish that within the framework I am building for my game?"

 

Just keep in mind that even if you decide to move in a simple way such as one pixel every frame, you need to make sure the routine that does this fits neatly within all the other stuff your game may be doing on each frame.

 

Just my 2 cents. :)

 

-dZ.

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