IntyBasic Questions and another "New" Game

[fsuinnc]

Ok, it's not much, but I am trying to make an IntyBasic game. Sort of a Stunt Cycle game.

Thanks to all for the great tips, posts of code and suggestions and the tools. I have learned a lot looking at all the examples and have stolen code from just about everyone.

 

At this point I have a lot of things that I haven't figured out but I will start with the two or three that are really killing me.

 

1. What is the best way to know that I have left the screen and need to change direction? Starting from left to right I change when the sprite X position is more than 170. Not sure that's good but it seems to work. Going right to left I am checking for the X position to be less than 5. This works if I am going pretty slow (Right arrow key pressed) but if I am going faster (down arrow) it doesn't work and I continue moving right to left.

2. Collisions. I haven't messed with it a lot. How do I check if sprite 0 has had a collision with a background pixel? The manual says

   “bit 8 means collision against background pixel (pixel set)”

   What does “(pixel set) mean?”

   I have “if level = 3 and COL0=HIT_BACKGROUND then gosub jump”

 

If any one has examples or advice on either or both of these I would appreciate it and that alone will probably keep me busy for a while. But I think I also would like to know more about Fractional Movement. It seems to make sense to me conceptually but as I try to accomplish using 16 bit variables for calculating the move but then using just the lower 8 bits for the actual movement (if that is even close to right). If there is a short example I would appreciate it.

 

what I have so Far IntyKnInty.bas

[GroovyBee]

What is the best way to know that I have left the screen and need to change direction? Starting from left to right I change when the sprite X position is more than 170. Not sure that's good but it seems to work. Going right to left I am checking for the X position to be less than 5. This works if I am going pretty slow (Right arrow key pressed) but if I am going faster (down arrow) it doesn't work and I continue moving right to left.

I suspect its because you are using an 8 bit variable for the X position. Change line 38 to :-

 

Dim #Spritex (

And change al references to SpriteX to use the 16 bit variable and the problem should go away.

 

Collisions. I haven't messed with it a lot. How do I check if sprite 0 has had a collision with a background pixel? The manual says

bit 8 means collision against background pixel (pixel set)

What does (pixel set) mean?

I have if level = 3 and COL0=HIT_BACKGROUND then gosub jump

A "pixel set" means any non-zero value in the sprite's card. Even if you set the foreground colour of the GRAM/GROM card in BACKTAB to black, it will still register a sprite/background hit in the sprite's collision register.

 

COL0 to COL7 are a snapshot of collision detect registers for sprites 0 to 7 taken during the last vertical blank interrupt. They are bit masks so its not advisable to make a direct comparison but use a bitwise AND mask instead. e.g.

 

		if level = 3 and (COL0 AND HIT_BACKGROUND) then gosub jump

[+DZ-Jay]

Hi fsuinnc, and welcome to the wonderful world of Intellivision programming!

 

 

Ok, it's not much, but I am trying to make an IntyBasic game. Sort of a Stunt Cycle game.

Thanks to all for the great tips, posts of code and suggestions and the tools. I have learned a lot looking at all the examples and have stolen code from just about everyone.

 

At this point I have a lot of things that I haven't figured out but I will start with the two or three that are really killing me.

 

1. What is the best way to know that I have left the screen and need to change direction? Starting from left to right I change when the sprite X position is more than 170. Not sure that's good but it seems to work. Going right to left I am checking for the X position to be less than 5. This works if I am going pretty slow (Right arrow key pressed) but if I am going faster (down arrow) it doesn't work and I continue moving right to left.

2. Collisions. I haven't messed with it a lot. How do I check if sprite 0 has had a collision with a background pixel? The manual says

   “bit 8 means collision against background pixel (pixel set)”

   What does “(pixel set) mean?”

   I have “if level = 3 and COL0=HIT_BACKGROUND then gosub jump”

 

If any one has examples or advice on either or both of these I would appreciate it and that alone will probably keep me busy for a while. But I think I also would like to know more about Fractional Movement. It seems to make sense to me conceptually but as I try to accomplish using 16 bit variables for calculating the move but then using just the lower 8 bits for the actual movement (if that is even close to right). If there is a short example I would appreciate it.

 

what I have so Far IntyKnInty.bas cycle game.jpg

 

I will let others more familiar with IntyBASIC provide code samples and more direct answers, but below are a few tips related to your questions:

• The display is 160 pixels wide. Actually, it's just 159, since the rightmost column is not rendered by the STIC (video chip). However, the actual sprite screen space is 8 pixels wider, so it's 167 pixels wide. These are X positions 0 through 166.
• The extra 8 pixels are hidden from the display typically behind the left border.
• Sprite's positions are counted from their top-left corner. That means that for an 8-pixel-wide sprite, position x=zero is exactly beyond the left edge of the screen; while position x=1 would show the rightmost 1-pixel column on the left edge. This allows the sprite to smoothly move in and out of the screen.
• This means that the visible screen area is actually between positions x=8 and x=166, inclusively. So, to check for an out-of-bounds sprite, you must check if it's position is "x < 8" (or "x <= 7") or "x > 166".
• What the manual means about the collisions is that the sprite does not interact with arbitrary background positions but only with background graphics where pixels are actually drawn ("pixel set"). That is, in a background tile where you have one colour for the foreground and one colour for the background, only the bits that paint the foreground colour are the ones that interact. The background colour does not affect collisions in any way. This should be obvious, although the wording is confusing.

[GroovyBee]

I fixed a few other issues with your code :-

 

IntyKnInty.bas

 

I also added some constants to make changing how much of the player avatar is off the screen a bit easier.

[fsuinnc]

Thanks, both of you for the advice and help.

 

I fixed a few other issues with your code :-

IntyKnInty.bas

I also added some constants to make changing how much of the player avatar is off the screen a bit easier.

 

I am not complaining but, I don't see any changes. I think you re-posted my file (or I am doing something wrong when I download it).

[GroovyBee]

Thanks, both of you for the advice and help.

No problem. Glad to help.

 

I am not complaining but, I don't see any changes. I think you re-posted my file (or I am doing something wrong when I download it).

Sorry! My mistake, I blame the lack of tea . Heres the file with the changes :-

 

IntyKnInty.bas

[fsuinnc]

Tea? When do you sleep? you seem to be available almost 24/7. (Somewhere between awesome and scary).

[+DZ-Jay]

Tea? When do you sleep? you seem to be available almost 24/7. (Somewhere between awesome and scary).

That's the difference between an ordinary, run-of-the-mill bee and a GroovyBee.

[fsuinnc]

Excellent point.

[GroovyBee]

Tea? When do you sleep? you seem to be available almost 24/7. (Somewhere between awesome and scary).

I sleep in my lair... err.... cave... err.... hive! Thats it!

[GroovyBee]

The other thing I did notice in the code is the hard coded delay. Ideally you want to use some fixed point arithmetic to get rid of that and game will become much smoother. I think fractional movement would make a good IntyBASIC example. I'll work on that when I get some time.

[+DZ-Jay]

The other thing I did notice in the code is the hard coded delay. Ideally you want to use some fixed point arithmetic to get rid of that and game will become much smoother. I think fractional movement would make a good IntyBASIC example. I'll work on that when I get some time.

I think Oscar already provided an example in one of the sample programs that come with IntyBASIC.

[freewheel]

I suspect its because you are using an 8 bit variable for the X position. Change line 38 to :-

 

Dim #Spritex (

And change al references to SpriteX to use the 16 bit variable and the problem should go away.

 

Didn't look at the code, but why would you need a 16 bit variable to track 160-odd possible X values? Is he doing something weird here?

 

One of the great things about these old platforms is that almost everything can be tracked in a single byte, because almost nothing goes above 255! (Except for score, typically).

 

My guess from the description is that fast moves the MOB past x=0, so he ends up with x=254 or something and the comparison is failing. Easier ways around that then a 16 bit variable, no?

[GroovyBee]

My guess from the description is that fast moves the MOB past x=0, so he ends up with x=254 or something and the comparison is failing. Easier ways around that then a 16 bit variable, no?

Given that the OP wants to move to fractional movement at some point its better to have everything 16-bits for now. Its not a very complex game, so I don't imagine 16-bit RAM space being a tight squeeze any time soon.

[freewheel]

Given that the OP wants to move to fractional movement at some point its better to have everything 16-bits for now. Its not a very complex game, so I don't imagine 16-bit RAM space being a tight squeeze any time soon.

 

Makes sense. I was just wondering if I was missing something else.

[fsuinnc]

 

Didn't look at the code, but why would you need a 16 bit variable to track 160-odd possible X values? Is he doing something weird here?

 

One of the great things about these old platforms is that almost everything can be tracked in a single byte, because almost nothing goes above 255! (Except for score, typically).

 

My guess from the description is that fast moves the MOB past x=0, so he ends up with x=254 or something and the comparison is failing. Easier ways around that then a 16 bit variable, no?

I would agree with GB that I doubt I will run short of 16 bit variables and, you are correct that the MOB was going past 0 (x=254, etc.) and the comparison was failing.

I would be interested in knowing other ways around the problem. (though the 16 bit variables are working for now).

 

Even the IntyBasic code is often confusing to me but if you know of an example or sample program that does something different that I could look at that would be great.

 

in truth it has taken me hours and many baby steps to accomplish what I know others could do much more quickly and with cleaner results but this is the most fun I have had programming since my Atari 400 back in 1980 or so. after 30 years of Green Screen business programs and reports it's nice to look forward to being on a computer..

 

I am starting to think that I might be able to make this into a (not very original) game so any ideas or comments are welcome.

 

most recent version:

IntyKninty.bas intykninty.rom

[+nanochess]

I would agree with GB that I doubt I will run short of 16 bit variables and, you are correct that the MOB was going past 0 (x=254, etc.) and the comparison was failing.

I would be interested in knowing other ways around the problem. (though the 16 bit variables are working for now).

 

Even the IntyBasic code is often confusing to me but if you know of an example or sample program that does something different that I could look at that would be great.

 

in truth it has taken me hours and many baby steps to accomplish what I know others could do much more quickly and with cleaner results but this is the most fun I have had programming since my Atari 400 back in 1980 or so. after 30 years of Green Screen business programs and reports it's nice to look forward to being on a computer..

 

I am starting to think that I might be able to make this into a (not very original) game so any ideas or comments are welcome.

 

most recent version:

IntyKninty.bas intykninty.rom

 

Cool! It reminded me of a Compute! magazine game I saw a looot of time ago

 

Don't forget to send it for the IntyBASIC contest

[GroovyBee]

I am starting to think that I might be able to make this into a (not very original) game so any ideas or comments are welcome.

Looking good. A small bug report: If you are crawling along and you get to the ramp the bike just jumps up into the air, lands, and then ploughs through the buses and far ramp.

[fsuinnc]

Looking good. A small bug report: If you are crawling along and you get to the ramp the bike just jumps up into the air, lands, and then ploughs through the buses and far ramp.

 

Thanks. I currently have it set to jump one time and then upon landing set a constant speed and drive off. I am working on how to figure out if the jump was successful or not and then show a crash or celebrate or whatever.

 

I am trying to get the best way to know if the jump is successful. I know collisions is one way and collisions with a bus will be a crash but I am guessing I will calculate a landing range for x coordinate based on speed at take off and if they land in the range then they are safe.

 

I am also trying to figure out what a good speed is for minimum and max and how to incorporate wheelies.