Beginner help with IntyBasic

[dalves]

Hey DZ, thank you for your description and information. In the version of Worm War 1 I'm trying to make, the blocks that enter the field of play I knew I would have to create using Backtab. I'm thinking I could use the background collision/Space Armada approach to get this to work. I mentioned Astrosmash because it seemed like there could be a lot of targets on screen at a time and I didn't know if they did that by multiplexing or a combination of MOB/Backtab targets. The choppy movement of the player's ship and spinning asteroids in Astrosmash made me wonder if they weren't MOBs but were drawn with Backtab animations.

 

As always, I am very grateful for you all taking the time to provide answers and information. I think I'll try the background collision detection in Worm War 1 first and see if I can get it to work the way I hope it will. I'll be sure to post a ROM and/or BAS file for anyone who is interested.

[+DZ-Jay]

Hey DZ, thank you for your description and information. In the version of Worm War 1 I'm trying to make, the blocks that enter the field of play I knew I would have to create using Backtab. I'm thinking I could use the background collision/Space Armada approach to get this to work. I mentioned Astrosmash because it seemed like there could be a lot of targets on screen at a time and I didn't know if they did that by multiplexing or a combination of MOB/Backtab targets. The choppy movement of the player's ship and spinning asteroids in Astrosmash made me wonder if they weren't MOBs but were drawn with Backtab animations.

 

As always, I am very grateful for you all taking the time to provide answers and information. I think I'll try the background collision detection in Worm War 1 first and see if I can get it to work the way I hope it will. I'll be sure to post a ROM and/or BAS file for anyone who is interested.

 

No worries.

 

By the way, hardware collision detection is convenient, but they have a rather large drawback, especially for action/arcade games: they are one frame behind the game's action. Depending on the game, this may or may not be acceptable.

 

To explain, consider how a typical game engine works. At the start of a frame N, it does the following:

1. Acquires user input and updates player state
2. Applies enemy AI logic and updates enemy state
3. Checks for collisions and updates world, player, and enemy state
4. Render frame to screen based on updated game state
5. Wait for frame N + 1 and repeat

The problem is that hardware collision detection occurs on step #4 when the STIC generates the video frame, which means that it happened much too late for the current frame to include it. You have to essentially wait until frame N + 1 for the collision registers to be made available, but by then, the game state has changed.

 

Thus, hardware collision detection is always one frame behind the rest of the game's action, so when you are testing the collision registers, you are getting the values that resulted from the computations of the previous frame. This may result in some logical paradoxes within the game, as well as manifest itself as strange glitches.

 

If your game requires fast "twitchy" reflexes and frenetic arcade action, it may be better to implement collisions in software, over which you have full control. Sometimes the differences are subtle but perceivable, even if not necessarily consciously; and could be the difference between a brilliant game and one that is merely "good enough."

 

-dZ.

[dalves]

Hey guys, I was wondering if there is a way to advance the Color Stack more than one step? In a game I am working on I am using Color Stack mode to change the colors between the sky, ground,etc.

 

(MODE 0,STACK_CYAN,STACK_TAN,STACK_BROWN,STACK_BLUE)

 

I'm using Cyan for the sky, Tan and Brown, as the ground colors, and I was hoping to use Blue for a pond in the middle of one of the screens. The problem I'm having is trying to use the CS_ADVANCE to draw the pond, but then need to get back to Tan to color the ground again. Below is an example of what I'm trying to do.

 

Cyan

____________

 

Tan-Tan-Tan

Tan - Blue - Tan

Tan-Tan-Tan

 

I know I could just use PRINT or BACKTAB with BLUE as the color to draw the water without advancing the color stack, but I was hoping to use one of my GRAM cards to draw waves on the water. This is where using the Color Stack would come in handy if I could advance it more than one step. I've also thought I may have to switch to Foreground/Background mode, but trying to see if there may be a way to work this out in Color Stack. Any insight would be greatly appreciated.

[+DZ-Jay]

Hey guys, I was wondering if there is a way to advance the Color Stack more than one step? In a game I am working on I am using Color Stack mode to change the colors between the sky, ground,etc.

 

(MODE 0,STACK_CYAN,STACK_TAN,STACK_BROWN,STACK_BLUE)

 

I'm using Cyan for the sky, Tan and Brown, as the ground colors, and I was hoping to use Blue for a pond in the middle of one of the screens. The problem I'm having is trying to use the CS_ADVANCE to draw the pond, but then need to get back to Tan to color the ground again. Below is an example of what I'm trying to do.

 

Cyan

____________

 

Tan-Tan-Tan

Tan - Blue - Tan

Tan-Tan-Tan

 

I know I could just use PRINT or BACKTAB with BLUE as the color to draw the water without advancing the color stack, but I was hoping to use one of my GRAM cards to draw waves on the water. This is where using the Color Stack would come in handy if I could advance it more than one step. I've also thought I may have to switch to Foreground/Background mode, but trying to see if there may be a way to work this out in Color Stack. Any insight would be greatly appreciated.

Unfortunately, the Color Stack can only be advanced by one element a time. However, with some imagination and a neat bag of tricks, you can draw some very complex scenes using the Color Stack.

 

Specifically relevant to your question, a technique I use to "skip" a color in the stack is to use "reverse video." That is, you advance the stack one card early and use a card that reverses the pixel pattern so that the foreground is drawn with the background color and vice versa. Then, on the next card, you advance the stack again, restoring the pixel pattern of the card.

 

Using this technique you can skip one or more colors. The price is potentially one custom card in GRAM for the "reverse video" pattern of each color you are skipping (if they do not exist in GROM already).

 

Does this make sense?

 

dZ.

[dalves]

Thanks DZ, I believe I understand what you mean. Are there any examples of how using the reverse video would be written, or is it simply that I would draw a revered GRAM card and use a BACKTAB command to place it at the same location to advance the color stack?

 

I was thinking changing from Color Stack to Foreground/Background mode may be my solution, but I realized that some of my graphics use some of the higher color numbers for both the foreground and the background.

[+DZ-Jay]

Thanks DZ, I believe I understand what you mean. Are there any examples of how using the reverse video would be written, or is it simply that I would draw a revered GRAM card and use a BACKTAB command to place it at the same location to advance the color stack?

 

I was thinking changing from Color Stack to Foreground/Background mode may be my solution, but I realized that some of my graphics use some of the higher color numbers for both the foreground and the background.

There are no automatic solutions. It's actually how you said: draw a card in GRAM representing the reverse video and set a BACKTAB location to it with the stack advance bit on.

 

There are a couple of threads around here were I describe the technique (among others) as I employed it on my own graphics. It may be worth a search.

 

dZ.

[dalves]

Thanks DZ, I will try that and I'll search the forum as well. Thanks again for the information and help.

[+DZ-Jay]

Thanks DZ, I will try that and I'll search the forum as well. Thanks again for the information and help.

 

No worries, it's my pleasure. Here's an old post I found with some details:

http://atariage.com/forums/topic/222570-intybasic-compiler-v05/?p=3060995

 

-dZ.

[dalves]

Thanks DZ. I searched the forums for "Reverse Video" and found a few posts where you described how to get more out of Color Stack, but this link seems to be more in depth. I tried doing the reverse video trick this morning, but might have done something wrong because it didn't do what I was expecting. I did try using a user made solid 8x8 GRAM card as a solid color while doing the Stack Advance. That seems to have some promise.

 

Random question: Is there a max ROM size for an Intellivision game? I read somewhere that the LTO Flash (Which I have) can hold ROMs up to 42k. I didn't know if that was the max ROM size that can be used in an emulator. The open world game I'm currently working on has 900 screens and already has a ROM size of about 35k, and there is still so much I have to add to it. I know I can do things to streamline my code and knock the file size down, but I didn't know if 42k would be the cap I'd have to stay under.

[+DZ-Jay]

Random question: Is there a max ROM size for an Intellivision game? I read somewhere that the LTO Flash (Which I have) can hold ROMs up to 42k. I didn't know if that was the max ROM size that can be used in an emulator. The open world game I'm currently working on has 900 screens and already has a ROM size of about 35k, and there is still so much I have to add to it. I know I can do things to streamline my code and knock the file size down, but I didn't know if 42k would be the cap I'd have to stay under.

 

The Intellivision memory model is a bit strange. It has a wide memory map, scattered across various non-contiguous segments. Essentially, what we do in home-brew games is to take over segments which were originally meant for expansion modules or other reserved uses, and use them for our own purposes.

 

All that said, there are various ways to organized your memory model, but over time the programming community has come up with a common strategy that offers 42K of usable ROM. An important detail to note is that the "K" in that term means "Kilodecles" -- a "decle" being the unit of memory of the Intellivision, representing a 16-bit word -- not "Kilobytes," as many assume.

 

Unfortunately, like I mentioned above, this is not a continuous block of memory, but 5 segments of varying sizes.

 

42K should be enough for any Intellivision game. After all, Mattel and the classic publishers made do with no more than 8K or 16K. However, in a pinch, you can use a technique called "bank-switching" which allows you to overlay up to 16 banks on each segment. That's a total of 42K x 16, which comes up to more than half a Megabyte.

 

-dZ.

[dalves]

Thanks DZ, I appreciate it. I think I was falling into the thought of it being Kilobytes instead of Kilodecles. My open world game I'm working on is currently 900 screens (30 horizontal x 30 vertical). My fear was getting it almost done and then finding out the game is too big, but I will cross that bridge when I come to it. I'm hoping to have something more playable soon that I can post.

[+DZ-Jay]

Thanks DZ, I appreciate it. I think I was falling into the thought of it being Kilobytes instead of Kilodecles. My open world game I'm working on is currently 900 screens (30 horizontal x 30 vertical). My fear was getting it almost done and then finding out the game is too big, but I will cross that bridge when I come to it. I'm hoping to have something more playable soon that I can post.

 

It's a very common mistake, the Intellivision is quirky that way. In any case, my recommendation is always to do what you need to do first, then we can figure out how to compress or encode the data more efficiently if necessary. Most of the time it turns out not to be necessary.

 

Even when it is indeed necessary, you can just get away with bank-switching different mutually exclusive sections of your game, like the title screen or the game over phase.

 

That is, unless you did the math already and know as a fact that your game won't fit. We could start coming up with clever packing/compression solutions for your data.

 

One thing to consider is that the 5 segments in the "standard" 42K memory map are not contiguous and are of different sizes, anywhere from 2K to 16K. This means that it may take some planning to accommodate your data accordingly.

 

There are some very knowledgeable people in this forum, so we could help you with all that. I'm not really an IntyBASIC guy, so I'll let others provide sample code and debugging assistance; but in the meantime, just do what you need to do to get your game going. Spending too much time planning and dwelling on such low-level "what if" issues just gets in the way.

 

-dZ.

[+Tarzilla]

Also, you say 300 screens, are the similar in some way? Can they be represented by meta tiles (say 4x4) so you make map data smaller? Are they like the dungeons in the first Zelda game where the walls are mostly the same but for doors and hidden bombing spots? A lot of pre planning can save a lot of crunching later.

[dalves]

The 900 main screens that make up the map are mostly similar. Using a similar background and changing the foreground subtlety to create the illusion that you are passing through different areas. I am doing this using my very limited programming knowledge. Below is kind of an example of what I'm doing for the 900 screens.

 

If screennumber=200 then screenground=1:#groundcolor=cs_brown:screenfill=12:landmark=5

 

Screenground is made up of a couple gravel patterns. Screenfill would be a series of numbered print screens that would add rocks, trees, and other items. Landmark is added to draw specific buildings, or structures in the game. When I checked this morning, my .bas file was 68k. I know I can shrink the file size just by reducing the size of current variable names. I also think I may have some overall code that could use some cleaning up and just be written more efficiently. The game is still in the "Sketching" stages.

[+Tarzilla]

The 900 main screens that make up the map are mostly similar. Using a similar background and changing the foreground subtlety to create the illusion that you are passing through different areas. I am doing this using my very limited programming knowledge. Below is kind of an example of what I'm doing for the 900 screens.

 

If screennumber=200 then screenground=1:#groundcolor=cs_brown:screenfill=12:landmark=5

 

Screenground is made up of a couple gravel patterns. Screenfill would be a series of numbered print screens that would add rocks, trees, and other items. Landmark is added to draw specific buildings, or structures in the game. When I checked this morning, my .bas file was 68k. I know I can shrink the file size just by reducing the size of current variable names. I also think I may have some overall code that could use some cleaning up and just be written more efficiently. The game is still in the "Sketching" stages.

The size of the bas file is not relevant. The final compiled rom size is. Shortening variable names will do nothing except make your life more difficult!

If you are using if statements to do all your screen draws, that is very inefficient., look at fixed arrays in rom to hold background types, colours etc.

[+nanochess]

If you're using an IF statement for each screen, then you can do this:

 

screenground = room_screenground(screennumber)

 

' Room data, first one is for room 0

room_screenground:

DATA 1,1,1,1,1,1,1,1

' ...

 

And same for the other variables. Saving BIG bytes

[dalves]

I believe when I checked the ROM size yesterday it was about 40k. I know there are more efficient ways to do the code, and I need to learn them. The use of DATA and PEEK/POKE are things I've always had kind of a mental block for and I know I should take the time to learn and not worry that I may spend a little less time "Creating" for the time being. As a musician, I used to compare my programming ability to a kid who is learning to play guitar for the first time. As soon as that kid learns how to play a power chord, he has the ability to "Fake" his way through any song. He will be a better musician if he learns how to play chords like a G minor 7th, but he's so happy that he can play songs at all, that he neglects learning more... I would say that's a pretty accurate description of me when it comes to programming...

 

I was hoping to have something playable that I could post soon, but right now the game is not much more than having your character be able to walk across a 900 screen map that changes biomes and time of day. I'm implementing "Health", "Hunger", and "Thirst" meters that are effected by temperature, biomes, and tasks. The missions and battles were going to be added later.

[+Tarzilla]

I believe when I checked the ROM size yesterday it was about 40k. I know there are more efficient ways to do the code, and I need to learn them. The use of DATA and PEEK/POKE are things I've always had kind of a mental block for and I know I should take the time to learn and not worry that I may spend a little less time "Creating" for the time being. As a musician, I used to compare my programming ability to a kid who is learning to play guitar for the first time. As soon as that kid learns how to play a power chord, he has the ability to "Fake" his way through any song. He will be a better musician if he learns how to play chords like a G minor 7th, but he's so happy that he can play songs at all, that he neglects learning more... I would say that's a pretty accurate description of me when it comes to programming...

 

I was hoping to have something playable that I could post soon, but right now the game is not much more than having your character be able to walk across a 900 screen map that changes biomes and time of day. I'm implementing "Health", "Hunger", and "Thirst" meters that are effected by temperature, biomes, and tasks. The missions and battles were going to be added later.

You probably won't need peek or poke as everything you'll probably need is in the constants.bas file, make sure you

INCLUDE CONSTANTS.BAS

at the top of your code

[+DZ-Jay]

Also... are you using the IntyBASIC SDK?

[dalves]

I am using the IntyBASIC SDK and I do include the Constants.bas as well.

 

I was thinking this morning that I may need to build a test program to see what statements I use, and the way I write them, are adding more to the ROM size and then find ways to work around it. I am using a lot of "IF" and "PRINT" statements and I know there are things I can do to be more efficient. I've attached the latest .BAS file if anyone is curious. Bear in mind this is still very much in the "Sketching" phase and the code is messy and not as organized as I would like. I did try to label things with names that make it easier to follow what they are doing.

GBU8.BAS

[+nanochess]

It looks promising

[mmarrero]

...I am using a lot of "IF" and "PRINT" statements and I know there are things I can do to be more efficient. I've attached the latest .BAS file if anyone is curious.

 

I converted the source code to DATA, storing SCRNGND, SCRNFILL, and LNDMARK, and modified the ScreenCheck function to use the data. I recommend declaring constant values to make level data more readable, for example, CONST L_GhostTown = 11... ...DATA 2,0,L_GhostTown.

GBU8_New2.BAS

[+Tarzilla]

I like the attempt at things on the horizon with that building getting bigger as you move up. I can see tons of gameplay possibility with this design. The map screen could show the whole map or even just the areas you have visited. At some point you may want to look into using ECS or JLP/LTO Flash! extra ram to make it easy to hold a 30x30 array to keep track of where you have been, and if you use the Flash saving ability of JLP/LTO then you can write that and other games variable to flash memory to let the player save and come back later.

[dalves]

Thanks for the kind words and feedback. mmarrero thank you SO much for changing the .bas file to show how I could use DATA to process that information. That helps a ton. It makes it easier for me to understand how it is working when I see it applied to code I was writing. I'm wondering if I may want to draw the mountains and backgrounds using DATA in the future. That may be the next test. I wasn't sure if PRINT statements add more to the ROM size than #BACKTAB statements do, or if they're about the same.

 

The Good, The Bad, And The Ugly is one of my favorite movies of all time, and making a game based on it has been more fun than it has felt like work. I was hoping to make it in the style of GTA or Red Dead Redemption, where you have missions you can complete in order to finish the game, or it can be open world where you just fight, and find food and water to survive. Like the movie, I'm hoping to have clues to where the money is buried depend on which character you play as. Still a lot of work to be done, but it's been fun and I'm hoping it will be a good game when its done with some decent replay value.

 

I meant to ask another question. If I use CONT1.KEY= command to scroll through text dialog in the game, it sees a single press of the key like I pressed it two or three times. Do I need a WAIT command to have it see the press of that keypad button as a single press? Or do I need to add a command to turn the KEY off after it's pressed?

Edited November 9, 2017 by dalves

[mmarrero]

It's in IntyBasic manual, CONT1.KEY should WAIT (to decode and debounce), but you should first loop until CONT1.KEY=12 (keypad not pressed).

You can definitely add more variety, I recommend using 4-bit values (values from 0 to 15) - for example, DATA 9,10,11,15 can be represented in hexadecimal as DATA $9ABF. For LNDMARK data, you'll need a look-up table to convert from 0..15 to actual values, for example: LNDMARKtbl: DATA 21,11,131.

Your game has a good concept, reminds me in some ways the 2600 games Adventure, Superman, and ET which have replay value. Pitfall and River Raid levels use random numbers with a constant seed (sequence is always the same) and I have always disliked their levels... no difficulty ramp-up, no clever/tricky levels, no clear areas/themes/landmarks, etc. I think Old West adventure games are unusual (I can only think of Red Dead and Freddy Pharkas).