Jump to content
IGNORED

IntyBASIC compiler v0.7 (now with IntyColor)


Recommended Posts

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

Link to comment
Share on other sites

  • 2 months later...
  • 4 weeks later...

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 by Cybearg
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

 

post-14916-0-50365200-1411777851_thumb.gif

 

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

 

post-14916-0-96017200-1411786071.gif

Link to comment
Share on other sites

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

 

Food for thought....

 

attachicon.gifarrow26.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?

Link to comment
Share on other sites

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.

 

  • Like 1
Link to comment
Share on other sites

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 by catsfolly
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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