Jump to content
IGNORED

[IntyBASIC] More advanced tutorials - suggestions


GroovyBee

Recommended Posts

The beginners tutorial series I mentioned here is still being worked on (slowly) but I've had a few PMs since the programming contest closed, suggesting some more advanced topics e.g.

  • Sub pixel movement
  • Collisions with BACKTAB obstacles e.g. walls and collectable items
  • High score league table
  • Handling scores larger than 65535

Are there any other suggestions for advanced IntyBASIC topics that developers would like to see covered?

  • Like 2
Link to comment
Share on other sites

  • Handling scores larger than 65535

 

As for this one. I use an array of bytes to hold a digit of the score.

 

drawscore:procedure

if flag1=1 then print at 7,$800+320+(sc(0)* 8)+6

if flag2=1 then print at 8,$800+320+(sc(1)* 8)+6

if flag3=1 then print at 9,$800+320+(sc(2)* 8)+6

if flag4=1 then print at 10,$800+320+(sc(3)* 8)+6

if flag5=1 then print at 11,$800+320+(sc(4)* 8)+6

print at 12,$800+320+(sc(5)* 8)+6

 

return

end

 

Is what I used to draw the score in Mad Bomber. I use another routine to add the score like:

 

AddScore:procedure

sc(5)=sc(5)+pointvalue

if sc(5)>=10 then sc(4)=sc(4)+1:sc(5)=sc(5)-10:flag5=1

if sc(4)>=10 then sc(3)=sc(3)+1:sc(4)=sc(4)-10:flag4=1

if sc(3)>=10 then sc(2)=sc(2)+1:sc(3)=sc(3)-10:flag3=1:SL2=66:SPointer2=0:lives=lives+1:gosub loadlives

if sc(2)>=10 then sc(1)=sc(1)+1:sc(2)=sc(2)-10:flag2=1:wait:define 6,1,ohface

if sc(1)>=10 then sc(0)=sc(0)+1:sc(1)=sc(1)-10:flag1=1

if sc(0)>=10 then sc(1)=sc(1)-10

return

end

 

The flags are used to tell the drawscore to draw that digit. So I don't have 000000 because original Kaboom don't have 000000. So it'll just show 0. I used the same thing for my Colecovision projects for PONG, Spunky's Supercar and Adventure of a Witch. Another method is use a single byte to draw 2 digit.

 

I use

y=variable/10

x=variable%10

 

Then use those 2 temp variable to draw the digit I need. If the variable score1 is over 100, then add 1 to the next variable score 2 holding the next 2 digit and then subtract the variable score by 100.

 

Sub-pixel movement, nanochess provided a solution to a thread and I'm using that for Mad Bomber. I would do, cheating subpixel movement, is to have the object move 1 pixel every 2 or 4 frames.

 

That all I have for now.

Edited by Kiwi
  • Like 2
Link to comment
Share on other sites

Perhaps "Advanced" is a relative term, but anyway...

True!

 

How to get the "standard" Intellivision start-up screen to show up.

Thats not possible in IntyBASIC because the RAM is cleared before your program is called. You can fake it, and there is an example of doing just that in the SDK.

 

Examples of the different screen modes (and therefore how/why to select one vs the other).

This will be covered in the beginners series.

Link to comment
Share on other sites

Again, "advanced" is indeed relative I say too. :)

 

Are there any other suggestions for advanced IntyBASIC topics that developers would like to see covered?

 

Here's a few, if I may? :)

 

1) Sound effects. Unless there's a link I missed, we are sorely missing here. Maybe a bit more in-depth discussion and/or examples on the channels, frequencies, volumes, envelopes would be great. Also, how to properly loop, combine, or, especially, "close" the sound.

 

I'm also thinking of starting a sound effect request/share thread. Of course, it would make the thread better with info on the above to link to.

 

2) Maybe a bit more on GROM/GRAM, color stack and FGBG. Some beginners may be confused as to which 64, etc, but so could advanced.

 

3) Sprites. Better explanation on resetting sprites, etc. Also, routines on how to add more than 8 MOBs. Yes, you'd have to introduce "flicker", but it may help in some games. (Maybe add to "constants.bas" with this?)

 

4) Pausing a game.

 

I have a couple more in my head, but this should be enough for now.

 

  • Handling scores larger than 65535

 

Here's an added tip, as I did for my game - just artificially print something like "00" after the score. It does not extend the value of 655535, but if your game scores in the 10s/100s/1000s, etc as a common denominator it would help save bits. (This, I guess, is for the newbie as I believe the advanced have already figured this one out).

 

 

  • Like 1
Link to comment
Share on other sites

1) Sound effects. Unless there's a link I missed, we are sorely missing here. Maybe a bit more in-depth discussion and/or examples on the channels, frequencies, volumes, envelopes would be great. Also, how to properly loop, combine, or, especially, "close" the sound.

I think this is a very game specific topic. Although having an asynchronous sound handler might be interesting.

 

I'm also thinking of starting a sound effect request/share thread. Of course, it would make the thread better with info on the above to link to.

Good idea!

 

2) Maybe a bit more on GROM/GRAM, color stack and FGBG. Some beginners may be confused as to which 64, etc, but so could advanced.

This will be covered in the beginners series.

 

3) Sprites. Better explanation on resetting sprites, etc. Also, routines on how to add more than 8 MOBs. Yes, you'd have to introduce "flicker", but it may help in some games. (Maybe add to "constants.bas" with this?)

Sprite multiplexing isn't often used in Mattel games. It also brings its own set of headaches like bounding box collisions etc.

 

4) Pausing a game.

Probably a beginners topic.

  • Like 1
Link to comment
Share on other sites

Hi GroovyBee, thanks for responding.

 

I do have a question if I may about sprites (to you, or anyone else reading). It's easy to add an extra color into a sprite by including an extra sprite into it, which even a beginner can do. As per advanced, is there a way however to do this without using that extra sprite?

  • Like 1
Link to comment
Share on other sites

Hi GroovyBee, thanks for responding.

 

No worries. I'm just looking for "input" as Johnny 5 would say.

 

I do have a question if I may about sprites (to you, or anyone else reading). It's easy to add an extra color into a sprite by including an extra sprite into it, which even a beginner can do. As per advanced, is there a way however to do this without using that extra sprite?

 

If your wannabe 2 colour "enemy" has restricted motion e.g. moves only left/right or up/down you can reprogram 2 GRAM cards on the fly and put them in BACKTAB and then overlay a sprite on top. If its free roaming then you are better off using 2 sprites.

  • Like 1
Link to comment
Share on other sites

There are much more efficient ways of handling BCD arithmetic on a processor that doesn't have BCD mode.

Definitely for sure. I'm still new at programming, and my mind tend to be simple. I can be very stubborn trying getting things to work right. It does what I wanted to now. So the score behavior match up to the Atari 2600 Kaboom score. Which is score that doesn't show 000000. It shows, " 0". The side effect, it took me hours to figure out how to do highscore comparsion using this method for the first time and limited of ROM space.

 

I kinda know that the score in RAM in Kaboom probably started off either 00 00 0A or AA AA A0, which the 0 or A points at the space graphic. They probably ror or rol 4 times or do a bitmask to get the 1st and 2nd digit of the variable to temporary variables to be processed by the 6 digit score routine. I don't have the Kaboom ROM to trace the code, but do have the commented score code.

  • Like 1
Link to comment
Share on other sites

A sound tutorial would be excellent. I don't agree that it's game-specific at all - it's no different than explaining how to program a MOB, or what screen modes do what, etc. Sure, the end result and your choices are highly influenced by the actual game itself, but the HOW and WHY you do certain things are more conceptual, often fairly universal - and not obvious to the beginning programmer.

 

Sound is one of those things I struggle with a fair bit, because it's very unintuitive compared to graphics. For most "sound effects" (ie: not ambient noise) you have to manually track the sound channels independently, flipping them on and off as desired, all the while modulating what you actually want. Anything beyond a simple "play this tone" requires at least some understanding of modulation, the noise/envelope generators, running timing loops and checking on them, etc. Graphics? Toss it up on the screen and move it around accordingly. Music? Type in notes as if you were transcribing sheet music - and effectively, press play. Sound is generally a lot more work, if you want anything decent.

 

I'd love to have a more advanced SOUND command that allowed something like 'SOUND channel,tone,duration'. But with ability to do even more than just that, because that still doesn't give you very much by itself. Maybe including the noise/envelope in the same command.

  • Like 2
Link to comment
Share on other sites

Definitely for sure. I'm still new at programming, and my mind tend to be simple. I can be very stubborn trying getting things to work right. It does what I wanted to now. So the score behavior match up to the Atari 2600 Kaboom score. Which is score that doesn't show 000000. It shows, " 0".

 

I've no idea how Kaboom does it in the original code but luckily in 6502 you can do BCD maths. In the display code I'd draw the score right to left. If the current score byte is $00 draw two spaces and move to the next least significant byte of the score to display. If its less than $10 draw one space and then a digit (and jump to code that no longer checks for a leading zero), otherwise draw two digits (and jump to code that skips checking for leading zeros).

Link to comment
Share on other sites

A sound tutorial would be excellent. I don't agree that it's game-specific at all - it's no different than explaining how to program a MOB, or what screen modes do what, etc. Sure, the end result and your choices are highly influenced by the actual game itself, but the HOW and WHY you do certain things are more conceptual, often fairly universal - and not obvious to the beginning programmer.

 

The effects generated would be game specific. In my own assembly language games I have a data driven sound driver that allows 3 sound effects to be played at once. The game engine gets a "handle" to the channel thats been allocated to the effect so it can poll for sound completion (if required). That way, it doesn't need to know that its using a specific channel. Personally, I don't use the sound chip's envelope generator because there is only one and the envelopes available are quite limited in my opinion. I normally modulate the sound effect's volume myself. For some of the sound effects in Piggy Bank the sound data tables were copied into RAM and their tones adjusted on the fly (as they played) to save ROM space.

Link to comment
Share on other sites

Here's my informal list of useful "advancy" topics, in no particular order:

  • Sound effects
  • Fixed-point arithmetic
  • Software collision detection (i.e., bounding boxes)
  • Multi-MOB sprites (e.g., colour overlaying, large bosses)
  • GRAM cycling animations at fractional rates
  • Smooth background scrolling
  • Sub-pixel sprite movement
  • Object speed acceleration/deceleration with linear or wave damping
  • Using damping for extra-high-accuracy hand-controller input handling
  • Simple physics simulations:
    • Acceleration due to gravity (e.g., parabolic jumping, ballistics, etc.)
    • DYCP and other demo-y effects
    • Friction & momentum (e.g., slippery surfaces, movement in water, etc.)
    • Moving objects converging on a point
  • Like 4
Link to comment
Share on other sites

 

The effects generated would be game specific. In my own assembly language games I have a data driven sound driver that allows 3 sound effects to be played at once. The game engine gets a "handle" to the channel thats been allocated to the effect so it can poll for sound completion (if required). That way, it doesn't need to know that its using a specific channel. Personally, I don't use the sound chip's envelope generator because there is only one and the envelopes available are quite limited in my opinion. I normally modulate the sound effect's volume myself. For some of the sound effects in Piggy Bank the sound data tables were copied into RAM and their tones adjusted on the fly (as they played) to save ROM space.

 

I think a primer on how to generate interesting and fun sound effects would be very helpful. Many people (I recall being one myself) have a hard time translating an idea of a sound in their heads into its actual harmonic/noise components.

 

The tutorial could include a set of general-purpose sound effects that others could literally just copy+paste into their games as is or with minor modifications. For instance, police or fire sirens, various clicks and bleeps for "activating" in-game buttons and actuators, a raspberry buzzer, a thunder clap, a "whooshing" sound, etc.

 

People could not only use the sound effects, but learn how they were made in detail. A varied enough library would show them how to "reason" other sound effects on their own.

 

-dZ.

  • Like 2
Link to comment
Share on other sites

Glad to see sound effect requests are making noise. :)

 

I do believe some general content can be demonstrated, which the user can tweak into their game later on.

 

Just dazzling sound effects alone can make a bland game much more exciting. Also, on the contrary, a great playing game can be seriously hampered by poor sound effects as well.

 

If your wannabe 2 colour "enemy" has restricted motion e.g. moves only left/right or up/down you can reprogram 2 GRAM cards on the fly and put them in BACKTAB and then overlay a sprite on top. If its free roaming then you are better off using 2 sprites.

 

Losing a precious 1/8 sprites sounds like a last resort for me, but will look into timing GRAM cards. I was also wondering (again asking GroovyBee or anyone else here) can you use any of the GROM cards as you would a GRAM card with your sprite’s graphics? Haven’t had success with this.

 

As well, I often wonder if there's anything beyond card 255 in GROM.

 

Software collision detection (i.e., bounding boxes)

 

I have yet to get the COL registers working, but I've liked this scheme better anyway as I see more flexibility in it. It should be expanded upon.

 

Friction & momentum (e.g., slippery surfaces, movement in water, etc.)

 

Yes, in context to the game if there's a winter, ice or underwater, mucky sewer, etc, level. Would love this.

 

The unsigned 16-bits arithmetic comparisons support in the next version of IntyBASIC will simplify greatly the handling of scores larger than 65,535 :)

 

Within the domain of good coding savvy we can certainly extend operations beyond this 16 bit limit. But, at the end of the day, I believe all we'd really need are a few optimized routines ready-made for constants.bas. Would love to see how this is done. :)

  • Like 1
Link to comment
Share on other sites

I was also wondering (again asking GroovyBee or anyone else here) can you use any of the GROM cards as you would a GRAM card with your sprite’s graphics? Haven’t had success with this.

 

As well, I often wonder if there's anything beyond card 255 in GROM.

 

 

Bit 11 controls GRAM vs GROM. The trick of adding 256 to your GRAM card, then multiplying by 8 (or however this is handled in constants.bas)? Just don't add the 256 and you're using GROM cards. Easy-peasy when it comes to SPRITE. BACKTAB cards requires you to use color stack mode of course, but for SPRITE you can use GROM cards just as easily as GRAM.

 

As for what's "beyond" card 255 - nothing. You have 8 bits to specify which card you want to use, which allows up to 256 possible cards (0-255 for GROM, but 2 bits are ignored for GRAM as you can only load 64 cards there). Depending on exactly how you specify your "beyond 255", you'll either just cycle back to card 0 again, or start mucking with higher bits (FG color, priority, you name it). It's not like an address space where if you go past 255, you get random data from somewhere.

  • Like 1
Link to comment
Share on other sites

I was also wondering (again asking GroovyBee or anyone else here) can you use any of the GROM cards as you would a GRAM card with your sprite’s graphics? Haven’t had success with this.

 

As well, I often wonder if there's anything beyond card 255 in GROM.

 

 

To answer your first question, yes, you can use GROM for MOBs just as you can use GRAM. This applies to the BACKTAB as well, which you already know. As freewheel suggested, the MOB's "Attribute" (A) register reserves nine bits (bits #3 to #11) for the graphics card to use; the first eight of which (bits #3 to #10) hold the card number, with the ninth bit (bit #11) serving as a flag of which memory to pull from: a set bit #11 means pull from GRAM, a clear bit means pull from GROM.

   A Register:    Address = $0010 + MOB #

      13   12   11   10    9    8    7    6    5    4    3    2    1    0
    +----+----+----+----+----+----+----+----+----+----+----+----+----+----+
    |PRIO| FG |GRAM|      GRAM/GROM Card # (0 to 255)      |   FG Color   |
    |    |bit3|GROM|     (bits 9, 10 ignored for GRAM)     |   Bits 0-2   |
    +----+----+----+----+----+----+----+----+----+----+----+----+----+----+

As freewheel also said, when the bit is set (GRAM), only the first 6 bits are read. I can attest to the fact that the last two bits are then ignored then. This means that attempting to use any GRAM card number above #63 will be the same as reading card #63. It also means that, if you are sure your MOB will use GRAM exclusively, you could use those two bits for your own storage. This may or may not be useful.

 

(Note that the same happens in the nine bits in the BACKTAB reserved for the graphics card. I leverage this quirk myself in Christmas Carol to use those extra two bits to encode the state of "candy" or "snowflakes" in a particular BACKTAB position.)

 

One other thing, if you explore the graphics cards available in GROM you'll notice that there aren't really 255 cards. The last 43 cards are actually not graphics at all: they are part of the EXEC code. The designers needed a few extra bytes in which to store the ROM overflow and chose the end of GROM. So in reality, there are only 213 GROM graphics and 43 noisy garbage cards. However, the latter could be useful for explosions and such, and in fact B-17 Bomber does just that for the flak.

 

As to what is beyond card #255 in GROM, well that's actually GRAM in there. Know what happens when you add one to 255? The ninth bit (bit #11) is set! In other words, 256 = GRAM bit set + Card #0. How 'bout that! :)

 

One last technical bit...

 

In actual, honest-to-goodness reality, that GROM/GRAM flag is not a flag at all. The nine bits (#3 to #11) form an offset in memory for the STIC to use to get the card. This makes even more sense if you consider that the nine bits are shifted three bits to the left, essentially multiplied by 8 (i.e., there are eight bytes on each card, so every eighth byte is a new card).

 

So, if the nine bits resolve to 240 (card #240 with GRAM flag clear), it actually means "1,920 + the beginning of graphics memory" (8 x 240 = 1,920). This lands somewhere in GROM.

 

Conversely, if the nine bits resolve to 260 (card #4 with GRAM flag set), it actually means "2,080 + the beginning of graphics memory" (8 x 260 = 2,080). This lands, as you may imagine, somewhere in GRAM.

 

-dZ.

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

Here's my informal list of useful "advancy" topics, in no particular order:

  • Sound effects
  • Multi-MOB sprites (e.g., colour overlaying, large bosses)
  • Simple physics simulations:
    • Acceleration due to gravity (e.g., parabolic jumping, ballistics, etc.)

 

 

post-24767-0-04196600-1455598005_thumb.gif <- animated GIF

 

The sample game will cover these topics. I have made a sound effect engine that take input from an array of data. It's the only procedure I put down to be on frame procedure statement, so it'll run at every interrupt. It uses 2 sound channel, it can be changed to be 1 channel so play simple will work.

 

Multi-MOB sprites, the main character have 8 different preset of poses. I transferred that idea from my games that uses a group of sprites to make up a multicolor character.

 

Simple Physics Simulation, I used a table to make the main character jump and make him jump and bounce when a barrel hit him.

 

It will also have a code how you can spawn up to 4 single sprite different object with different behavior. For example, when punching a barrel. It will turn the barrel object to explosion fairy dust animation object. Then when that animation finish, it moves the object to 0 and change the object ID to zero so the game can spawn a new object.

 

I do need a bit more time to go through my code and comment in it. Add new objects, score routines, and etc. I'll post it either tomorrow night or Wednesday afternoon.

PS It's good to not worry about semicolon when doing IntyBASIC game

  • Like 6
Link to comment
Share on other sites

The sample game will cover these topics.

Looks good. Mine take the approach of a text/image tutorial explaining the concepts with code that becomes more complex as the tutorial progresses. Its always good to have complete example games in the SDK (should you allow it to be published in there too).

Link to comment
Share on other sites

I have a similar idea for doing sounds, putting the words/instructions in DATA and playing them. In terms of optimization (at the risk of pre-optimization), I wonder if it is better from a storage or game-speed perspective to play an effect using 50 words from a DATA statement, or to have an n-line procedure that calculates the tones and plays them.

 

 

[snip]

The sample game will cover these topics. I have made a sound effect engine that take input from an array of data. It's the only procedure I put down to be on frame procedure statement, so it'll run at every interrupt. It uses 2 sou[snip]

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