IntyBASIC compiler v0.7 (now with IntyColor)

[vprette]

Nice box!

 

I am still trying to get the basic gameplay working. After that I will look at ways to expand it.

Maybe I could have a "classic mode" and an "advanced" mode?

Thanks for your suggestions. Having different enemies and even a boss would fit well with an advanced mode...

 

the gameplay is very addictive and I think you can have a fantastci game adding advanced items

[+nanochess]

And now is available IntyBASIC v0.8 including a nice music player

 

http://atariage.com/forums/topic/229168-now-available-intybasic-compiler-v08/

[Cybearg]

I'm posting some more questions here because I don't want people to ignore some earlier questions I had by me making a double-post.

 

1. I'm trying to use PEEK($0200 + tileNum) to determine what tiles are at a certain location, but the values I get seem nonsensical. For instance, tile \209 shows up as 138 while tile \208 shows up as 130. What gives? Why doesn't PEEK return "208"?

 

2. How does one define a 16-bit variable? I want a variable to hold the score, but it maxes out at 255, since it's apparently an 8-bit integer. How can I get a 16-bit integer?

 

3. At present, I am displaying the score like so:

	PRINT AT 3 COLOR 6, ((scoreA %10) + 16)*8+6
	PRINT AT 2 COLOR 6, (((scoreA %100) / 10) + 16)*8+6
	PRINT AT 1 COLOR 6, (((scoreA %1000) / 100) + 16)*8+6
	PRINT AT 0 COLOR 6, (((scoreA %10000) / 1000) + 16)*8+6

This is, of course, clumsy and kind of inefficient. Is there a better way?

 

4. When using screen scrolling, is there a way to avoid HUD scrolling, or would one have to scroll and then print the HUD every frame to prevent that?

 

5. When scrolling, is there a way to dynamically change which DATA statement the new cards are being read from? For instance, let's say I have 3 or 4 DATA statements with backgrounds that I want to be drawn in at random intervals during scrolling. How could this be done?

Edited September 22, 2014 by Cybearg

[+nanochess]

I'm posting some more questions here because I don't want people to ignore some earlier questions I had by me making a double-post.

 

1. I'm trying to use PEEK($0200 + tileNum) to determine what tiles are at a certain location, but the values I get seem nonsensical. For instance, tile \209 shows up as 138 while tile \208 shows up as 130. What gives? Why doesn't PEEK return "208"?

What you're reading depends on the STIC format for characters, it includes the color.

 

2. How does one define a 16-bit variable? I want a variable to hold the score, but it maxes out at 255, since it's apparently an 8-bit integer. How can I get a 16-bit integer?

Prefix every 16-bit variable with # in fact this is a completely different variable, '#var' and 'var' aren't the same.

 

3. At present, I am displaying the score like so:

	PRINT AT 3 COLOR 6, ((scoreA %10) + 16)*8+6
	PRINT AT 2 COLOR 6, (((scoreA %100) / 10) + 16)*8+6
	PRINT AT 1 COLOR 6, (((scoreA %1000) / 100) + 16)*8+6
	PRINT AT 0 COLOR 6, (((scoreA %10000) / 1000) + 16)*8+6

This is, of course, clumsy and kind of inefficient. Is there a better way?

 

Not yet.

 

4. When using screen scrolling, is there a way to avoid HUD scrolling, or would one have to scroll and then print the HUD every frame to prevent that?

Nope, in fact many Intellivision games work around it. Like Dracula.

 

5. When scrolling, is there a way to dynamically change which DATA statement the new cards are being read from? For instance, let's say I have 3 or 4 DATA statements with backgrounds that I want to be drawn in at random intervals during scrolling. How could this be done?

In IntyBASIC v0.8 just I've corrected SCREEN to allow you to choose an origin via expression, so you can select a zone from a screen "made" of DATA

[Cybearg]

Great to hear so many of my needs are in the to-do list.

 

Another question (mostly one of practical advice):

 

As you pointed out, the problem with those numbers were that it included the color. D'oh! With that in mind, what would be the most efficient algorithm for determining the card index of where a card intersects with a sprite? I've been trying this crude algorithm which is messy (as you see), slow, and inaccurate:

temp1 = (((presX - 6) /  % 20) + ((presY + 20) / 12) * 20
result = PEEK($0200 + temp1) / 8

Any suggestions from you more experienced coders on a better algorithm to account for converting the sprite's location to an index on an 8x8 grid? Ideally, accounting for near-hits and near-misses on both the right and left side of the sprite.

[catsfolly]

Great to hear so many of my needs are in the to-do list.

 

Another question (mostly one of practical advice):

 

As you pointed out, the problem with those numbers were that it included the color. D'oh! With that in mind, what would be the most efficient algorithm for determining the card index of where a card intersects with a sprite? I've been trying this crude algorithm which is messy (as you see), slow, and inaccurate:

temp1 = (((presX - 6) /  % 20) + ((presY + 20) / 12) * 20
result = PEEK($0200 + temp1) / 8

Any suggestions from you more experienced coders on a better algorithm to account for converting the sprite's location to an index on an 8x8 grid? Ideally, accounting for near-hits and near-misses on both the right and left side of the sprite.

I'd probably go with something like:

if ((presX > 160) OR (presY > 98)) THEN result = 0 : goto bale:

val = (presY /8) * 4
result = peek( $200 + val + (val * 4) + (presX/8))/8

bale:

I haven't tested this, but it's based on the Clowns and Balloons code.

You can add offsets to the x and y coordinates before doing the calculations (depending on where your "hotspot" is... )

 

Multiplies and divides by powers of two (up to 16) are done with shifts, so they are faster than other kinds of multiplies and divides.

[Cybearg]

Thanks for the info, cats! That, with a bit of tweaking, worked great!

 

Is there any way to limit which rows are scrolled when scrolling the playfield? I have some playfield elements (such as UI and things like the moon) which shouldn't be scrolled. I could, of course, print over them, but that's just a big waste of cycles. What would be the best way to go about this?

[catsfolly]

Thanks for the info, cats! That, with a bit of tweaking, worked great!

 

Is there any way to limit which rows are scrolled when scrolling the playfield? I have some playfield elements (such as UI and things like the moon) which shouldn't be scrolled. I could, of course, print over them, but that's just a big waste of cycles. What would be the best way to go about this?

Unfortunately, this is a big limitation of the Intellivision's smooth scrolling system - it always scrolls the whole screen. If you want some elements to not scroll, you have to resort to tricks.

 

Some of these tricks are:

 

1. Don't use the smooth scrolling - just scroll things 8 pixels at a time. The Colecovision has no smooth scroll registers, so all of their scrolling is done this way (but their pixels are a little smaller than the Intellivision...) (I think the Rick Dangerous game works like this...)

2. Only draw the UI elements when the screen is not scrolling. Erase them when the scrolling starts.

3. Draw UI elements with motion objects and counter scroll them.

4. Counter scroll and redefine the UI element's gram cards every frame. (Usually only can be done for 1 directional scrolling).

5. Fake the scrolling by rewriting gram cards (like Defender or Space Patrol). This generally limits the fake scrolled areas to two colors.

 

That's all the tricks I can think of now - I'm sure there must be more...

 

Catsfolly

[Cybearg]

Would it be inefficient to clear and redraw static elements each frame? For the UI, I'd basically have to write a full row and re-print each frame. For static elements like stars, I'd need to clear, check if the scroll covered them, and then draw each one by one. Are all of those peek and poke statements as inefficient as they sound?

[catsfolly]

Would it be inefficient to clear and redraw static elements each frame? For the UI, I'd basically have to write a full row and re-print each frame. For static elements like stars, I'd need to clear, check if the scroll covered them, and then draw each one by one. Are all of those peek and poke statements as inefficient as they sound?

The trouble is, you can't really "draw" things on the Intellivision screen. The screen is not a bitmap, it is an array of characters.

 

 

If I want to "draw" an "A", I put the character code for an "A" in one of the positions in the screen memory ("backtab"), and an "A" shows up.

 

If I set the smooth scrolling horizontal register to say, 3, then 3 blank lines are added to the left of the screen display, and all of the characters on the screen move to the right by 3 pixels. If I erase and redraw any of the characters at that point. they will still be moved over 3 pixels to the right...

 

Does this make any sense?

 

Catsfolly

[Cybearg]

Ah, I see. That makes sense, albeit a bit disappointing. The game design I had in mind depends heavily on scrolling and there aren't the MOBs or card slots to spare for those tricks. It will either have to be crude scrolling for this game or a redesign of the core gameplay to something that scrolls between full screens, as with Legend of Zelda.

[catsfolly]

Ah, I see. That makes sense, albeit a bit disappointing. The game design I had in mind depends heavily on scrolling and there aren't the MOBs or card slots to spare for those tricks. It will either have to be crude scrolling for this game or a redesign of the core gameplay to something that scrolls between full screens, as with Legend of Zelda.

Yeah, GroovyBee's Rescue on Terra 5 game concept just pops from one full screen to the next:

 

http://atariage.com/forums/topic/212868-pesky-scientists/?hl=rescue

[Cybearg]

What I had in mind won't work in the same way, unfortunately, as the game depends on the player reacting quickly to things that zip past, unless I rework the core gameplay to support static screens somehow...

[catsfolly]

What I had in mind won't work in the same way, unfortunately, as the game depends on the player reacting quickly to things that zip past, unless I rework the core gameplay to support static screens somehow...

"Tennis in Space" had scrolling, and things zipping past the player, and tennis!

 

Food for thought....

 

[+atari2600land]

Is there any way to use the keypad yet? No use has been in any INTV Basic game so far, I was just wondering if there was a reason why.

[Cybearg]

"Tennis in Space" had scrolling, and things zipping past the player, and tennis!

 

Food for thought....

 

arrow26.gif

Sort of. I have no idea how it was done. Clearly there's screen scrolling going on and the tennis court is a bunch of sprites, but how was the static board achieved? Or maybe there was no scrolling going on at that point and the background tiles were just playing a loop?

[catsfolly]

Is there any way to use the keypad yet? No use has been in any INTV Basic game so far, I was just wondering if there was a reason why.

Early versions of IntyBasic didn't have it. Now it is there.

 

From the manual.txt:

 

 

CONT2.KEY

Current pressed key (0-9 for numbers, 10-Clear, 11-Enter, 12-Not pressed)

Because movements can be taken as keys, it's suggested to wait for

CONT2.KEY to contain 12 before waiting for a key.

 

Note using the .KEY syntax will include extra code inside IntyBASIC.

also you should use WAIT for each .KEY reading because it's when

IntyBASIC process debouncing and decodes keys. Remember this uses

extra processor time.

 

[catsfolly]

Sort of. I have no idea how it was done. Clearly there's screen scrolling going on and the tennis court is a bunch of sprites, but how was the static board achieved? Or maybe there was no scrolling going on at that point and the background tiles were just playing a loop?

You've got the idea.

 

The flying tennis court uses all of the sprites.

 

The meteors and "energy globes" are moved by drawing them in Backtab, and scrolling the screen.

 

For the stars, I created a 16 bit by 16 bit bitmap using 4 gram cards, and tiled the screen with these cards.

 

The 4 gram cards are redrawn every interrupt to make it look like the screen is scrolling at a different rate than it really is,

and to add parallax (because I like parallax).

 

The meteors and energy globes fill up most of their backtab card area, so they kind of appear to be moving on top of the star field.

 

The more Intellivision games you look at, the more ideas you can get on how to do things on the system...

Edited September 27, 2014 by catsfolly

[+atari2600land]

Why doesn't room=cont2.key+1 work?

[+nanochess]

Why doesn't room=cont2.key+1 work?

 

It should work of course, just put a loop with WAIT and test for cont2.key to contain a value from 0 to 9.

 

Still I don't have reports from testing in real hardware, but I hope to test as soon as I've a LTO Flash cart.

[Cybearg]

Hmm... I've recently been experimenting with drawing the GUI and trying out screen scrolling, but after adding in screen scrolling and drawing the GUI, I suddenly have a significant slow-down on the emulator. I'm not sure if it's frames dropping due to too many cycles or some other oddity.

 

If things start to seem to go slow, is that an indication of running out of clocks? I don't even have any game logic in place, so now I worry that I'll be walking on thin ice to keep from killing the processor.

[catsfolly]

Hmm... I've recently been experimenting with drawing the GUI and trying out screen scrolling, but after adding in screen scrolling and drawing the GUI, I suddenly have a significant slow-down on the emulator. I'm not sure if it's frames dropping due to too many cycles or some other oddity.

 

If things start to seem to go slow, is that an indication of running out of clocks? I don't even have any game logic in place, so now I worry that I'll be walking on thin ice to keep from killing the processor.

Sounds like you are running out of time.

What kind of things are in your GUI? Are there parts of it that don't need to updated every frame?

 

For example, if you are displaying the score, then converting the score from a binary number to a decimal display can take a lot of cycles. If you can do this conversion only when the score changes, it can save a lot of time...

 

That's all I can think of, without more information...

[Cybearg]

For example, if you are displaying the score, then converting the score from a binary number to a decimal display can take a lot of cycles. If you can do this conversion only when the score changes, it can save a lot of time...

Yeah, I was doing this, multiplying and dividing by tens, hundreds, thousands, and ten thousands across a number of print statements for each frame.

 

The alternative, I guess, would be two 16-bit score values (since most scores are 6 digits long) to hold the value and then 6 8-bit score values to hold individual score digits to print?

[Cybearg]

I reworked things a little bit and I think I may have the resources to pull off the effect of replacing GUI cards each frame of scrolling so the GUI appears still. The problem is that I'm having trouble wrapping my head around how it would actually work.

 

I tried making versions of the cards that scrolled, but then I realized that's not sufficient, as you'd need 2 or 3 versions of every card to ensure that there was a starting card, a center card, and an ending card, but if one is replacing, say, the digits of the score, that means, at minimum 30 cards will be devoted just to holding GUI stuff and those 30 cards must be replaced each frame, which is impossible.

 

How could such an effect be pulled off, then?

[catsfolly]

I reworked things a little bit and I think I may have the resources to pull off the effect of replacing GUI cards each frame of scrolling so the GUI appears still. The problem is that I'm having trouble wrapping my head around how it would actually work.

 

I tried making versions of the cards that scrolled, but then I realized that's not sufficient, as you'd need 2 or 3 versions of every card to ensure that there was a starting card, a center card, and an ending card, but if one is replacing, say, the digits of the score, that means, at minimum 30 cards will be devoted just to holding GUI stuff and those 30 cards must be replaced each frame, which is impossible.

 

How could such an effect be pulled off, then?

30 cards?

If the score takes 6 digits, then for a side scrolling game, you would need 7 cards to display it in unshifted or shifted state.

(Do you really need to see the score all the time, though.?)

Edited September 28, 2014 by catsfolly