how does this program know "smiling_face" is a SPRITE 0

[8bitwidgets.com]

and NOW i see what it the score for 27 should be:

 

PRINT AT 27 COLOR 2,<.2>score1    ' left score

 

that .2 inside the <> somehow moves the score further to the right so it is symmetrical.. 

 

 

[carlsson]

This is explained in the manual.txt (and probably in Oscar's books as well):

 

  PRINT <>expr          ' Simple number

  PRINT <const>expr     ' Right-aligned with zeroes to 'const' size.
  PRINT <.const>expr    ' Right-aligned with spaces to 'const' size.

 

[+DZ-Jay]

9 hours ago, Caleb Garner said:

ok here goes!    I figured out the color thing..  so it's in the sprite (which makes sense) but i don't really understand this well..  but i know more in the book will explain it so i'll be patient..  i haven't explored the sprite stuff but i understand somehow you can add parameters together and the total will give the desired result..  that will take some rote practice to feel that one out.  

 

    SPRITE 0, $0708 + x1, $0208 + y1, $0800 + 5 * 8 + 2    ' the 2 is (bad) red and 3 is the light green.  
    SPRITE 1, $0708 + x2, $0208 + y2, $0800 + 5 * 8 + 3

 

    PRINT AT 27 COLOR 2,<>score1                    ' left score 
    PRINT AT 31 COLOR 3,<>score2                    ' right score

 

 

 

The Movable Object Blocks (MOBs) are described by various attributes assigned to STIC registers.  (The STIC is the Standard Television Interface Chip, i.e., the Intellivision's video chip.)

 

These registers are 16-bit wide, but the bits are grouped into fields that describe a specific attribute, very similar to the way the BACKTAB word reserves some bits for the picture index, the foreground and background colors, etc.

 

Each MOB is governed by 4 registers, called X, Y, A, and C, which stand for "X position," "Y position," "Attributes," and "Collisions," respectively.  Their individual layout -- that is the bit-fields reserved in each -- depend on their individual needs.

 

Below is a description of the layout of each register:

 

X Register:

 

Y Register:

 

A Register:

 

 C Register: 

 

In IntyBASIC, you define a MOB with the SPRITE command, which takes as arguments the MOB number, and the composed values for its X, Y, and A registers, respectively.  (The C Register is handled separately and directly by the language through the various collision variables.)

 

So, you see, it is not that you add together a bunch of numbers.  What you are doing is setting up individual values within each field in a register.

 

As shown in the illustration above, the MOB color is governed by the lower three bits of the A Register, which define the primary color (lower 8 colors), and the 12th bit, which specifies pastel color (the upper 8 colors). These four bits together afford a numeric value from zero to 15, which happens to be the range available in the Intellivision's color palette.

 

Therefore, if you want to set the sprite color to red (color #2), you need to set those four bits to "2," or "0010" in binary.  That is, the lower three bits must be set to binary "010," and the 12th bit to zero.

 

One thing to consider is that, when you call the SPRITE command, it does not update the existing MOB registers, but replaces them wholesale with the new values you give it.  So, if you want to set the color of a MOB, you must set the entire A Register at once, not just the color.  That means you need to encode in the new register value, the following attributes:

• The background priority flag;
• The picture card index;
• The flag that states whether the picture is in GRAM or GROM;
• And the four bits for its color.

 

Any field that is not set, defaults to zero.  For example, not setting the color, implies color #0, or black.
 

One simple way to encode all these values together is to define constants for them, and shift the values into their respective target positions -- then take all those aligned values and add them together.  This is how the book does it.

 

Take for example the code you posted:

SPRITE 0, $0708 + x1, $0208 + y1, $0800 + 5 * 8 + 2

 

That statement sets all three registers for MOB #0.  Let us focus on the A Register for a moment, which is the last argument:

$0800 + 5 * 8 + 2

That expression evaluates to a numeric value which encodes in it the various fields of the A Register.  Let us break it down:

$0800 + 5 * 8 + 2

0000010000101010
    cgpppppppccc

c: color = 2
g: GRAM flag = On
p: picture = 5

• 5 * 8:  Indicates picture card index #5.  Because the picture index starts three bits from the right, we must shift the number three bits left.  This is the same as multiplying it by 2³, or 8.
• $0800:  This is a magic constant that serves to indicate that the card is in GRAM.  It sets the 11th bit on.
• 2:  This is a color from the lower 8 primary set.  Because the color is in the primary set, it only takes three bits, so we don't have to worry about the 12th bit, and just leave it as zero.

 

The book uses a lot of magic numbers like that $0800 value for the GRAM flag, and sometimes assumes their meaning without explaining them, so it is always good to ask where these values come from.

 

Personally, I recommend you explore the "constants.bas" library file that comes with IntyBASIC, which defines symbolic constants for a lot of those commonly used values.  This makes your code much more legible.  For example the above A Register value could be expressed like this:

SPR05 + CS_RED

That means "GRAM card index #5 for sprites," and "foreground color red."  The constants themselves pre-shift and compute the values as necessary.  Similar constants handle the background priority (BEHIND, which means lower priority, or "behind the background"), and the bit-fields in the other registers.

 

It is just good practice to use constants instead of magic numbers.  It makes the code easier to read, easier to troubleshoot, and also easier to modify in the future.

I hope this helps.  For more information on the register layout, see the document "STIC.txt," or the Intellivision Wiki.

 

    dZ.

 

Edited September 3, 2021 by DZ-Jay

[+DZ-Jay]

On 9/1/2021 at 9:10 PM, Caleb Garner said:

I'm definitely not a sponge.. i have to beat this stuff into my head and probably ask things more than once sometimes..  

 

I don't envy what you must be figuring out with enemy movement.. i know i'm going to have my work cut out for me for I, Killbot and Road Defender.  

 

17 hours ago, Mik's Arcade said:

yeah, the problem is we have all the ideas, but lack the programming chops to back it up.  Plus, we are working with limitations as well.  My first game was way too complicated for me to try.  I need to keep it simple and make a few basic games before i get into the more creative projects.  baby steps...haha.  I go through ebbs and flows. I need to do consistent work. I'll go a over a week without doing anything and then carve out only a couple of hours on a weekend.  I can't do those marathon coding sessions like I did back in my high school days.

 

good luck!

 

Do not get discouraged -- there's plenty of people in here that can help.

 

When I joined the Intellivision programming community, back in 2008, my goal was to make a Pac-Man conversion for the Intellivision -- which had been a dream of mine for a while.  Back in those ancient days, when dinosaurs roamed the memory banks, there was no IntyBASIC and very little in the way of tutorials.  There were some very helpful people, but they were very few, and although they provided lots of guidance and hand-holding, we still had to do everything in Assembly Language, from scratch, barefooted, uphill, through the snow! 

 

Yet, with the help of those few veterans, and the encouragement of the larger community, I persevered and ... er ... never actually managed to complete my Pac-Man game. (cue sad trombone)

 

However, my efforts toward that goal eventually lead to an original concept, released successfully as Christmas Carol vs. The Ghost Of Christmas Presents, which turned out to be a bigger accomplishment for me.  That's me -- slow learner, lazy-ass procrastinator extraordinaire, not accustomed to dealing with low-level details, stupid with hardware, and dumb with maths.

 

It was the combination of the guidance, help, and encouragement -- mixed in with a bit of tenacity and perseverance on my part -- that drove that success.

 

One key lesson I would like to share with you is that -- as alluded to before -- the final game was not my first game.  Nor the second.  The final release of Christmas Carol was a bigger, better, and more sophisticated version of the earlier rendition that spawned from my Pac-Man effort.  First there was the unfinished Pac-Man; second was the conversion of that first one into a simple, one-maze version of Christmas Carol; and third, that simple game eventually grew into the final epic game.  It took a few iterations and many years, and on each I gained more experience and mastery over the platform, which drove me to improve the work.

 

This is the typical way that software is developed -- and I am willing to bet that it applies equally to anybody here who came to game programming with no prior experience:  You start with a plan, but you really do not know how to do it or what it will take to get it done.  You hack at it as best you can, and eventually it takes shape -- and by the time you learn your way through the complexities of the platform and the intricacies of the target application, you've gained enough experience to actually know what to do now.  So, you either scrap that project and start anew, or you evolve it and reshape it -- either way, it is no longer what you started with.

 

As the venerable Fred Brooks said in his Mythical Man Month:  Plan to throw one away -- you will anyway.  Wise words written in the 1970s which are as prescient now as they were back then.

 

All that I am trying to say is that the path to your great masterpiece is there in front of you.  It is long and difficult, but it is wide open for you to take.  Just accept that you may not realize your ultimate vision on your first attempt, and perhaps not even on your second or third attempts -- and that is fine -- make peace with that notion and focus on the fact that you can realize it.  You just have to start on your way, and take one step at a time.  You don't have to start small (I didn't), although that helps -- just start and see where it goes.

 

And who knows -- perhaps you'll encounter a detour along the way and come up with something even bigger and better and truly your own, and end up in a completely different destination.

 

Anyway, best of luck, Godspeed, and march on.

 

     -dZ.

Edited September 3, 2021 by DZ-Jay
Edited for dramatic effect (LOL!)

[Mik's Arcade]

i really need to get back to programming again.  I want to finish the game I was working on, it's the closest I've come so far.

 

 

when it's done, I want to share it with the group and have them help me work on graphics. I'm terrible at layering sprites in order to get decent looking characters on screen.

[8bitwidgets.com]

On 9/3/2021 at 7:50 PM, Mik's Arcade said:

them help me work on graphics

While I'm not an artist, I love pixel art and making it.  if I could be of help, count me in to help.  Same with Music.. VERY new to intellivision music but i'm very experienced with midi / computer music..  i got the twinkle twinkle song to work so that's encouraged me..  

 

On 9/3/2021 at 4:04 AM, carlsson said:

explained in the manual.txt

i've copied it over to my project folder and will review it.

 

On 9/3/2021 at 6:41 AM, DZ-Jay said:

Below is a description of the layout of each register:

Wow this is really well laid out and I know I'll be getting very familiar with it in time. I read through it and I kinda get it.  so with this example (left padde from "game of ball".  For my own understanding while I know you tackled A and C really well, I want to start with X and systematically move to Y then A then C.. 

 

    SPRITE 0, $0708 + x1, $0208 + y1, $0800 + 5 * 8 + 2

 

breaking it down like this:

 

$0708 is the magic number and by me saying + x1 means really to just say move to this sprite to the value of x on the X axis (a variable defined earlier as x1 = 23) the 8 is really just 00 through 15 as possible numbers..  thus the 8 in the above code is to enable collision? 

 

at this time I don't understand what the $07 means..   and the 08 collision value is an assumption.. 

 

BUT what do I do if I want to enable collision and i want to double the width which is the 10th slot?  and then maybe something comes up where i need the paddle to become invisible as some kind of penalty / power move by the opponent which is 9..   

 

I'm going to stop there for my understanding tonight..  if I can understand how to work with X fully the others will very likely make more sense.. A and C deal with more a lot of awesome possibilities but feels like a rabbit hole i don't want to go down just yet (questions leading to more questions and getting overwhelmed) but what's nice is you've already defined a bunch of stuff I can come back too! 

 

On 9/3/2021 at 6:41 AM, DZ-Jay said:

explore the "constants.bas"

I peeked at it but it was a lot if information.. good stuff!     greek still but it looks like it would be a great reference! 

 

On 9/3/2021 at 6:41 AM, DZ-Jay said:

I hope this helps.

absolutely!  a lot but it's ALL information I'm going to need to master and have every intention of doing so!   I have the stic.txt in my project folder for reference as well.  

 

On 9/3/2021 at 7:38 AM, DZ-Jay said:

Do not get discouraged

I am not in the least and it is certainly due to all the great input you've shared here and the other gurus here! 

 

On 9/3/2021 at 7:38 AM, DZ-Jay said:

Christmas Carol vs. The Ghost Of Christmas Presents

holy crap that's an awesome game.  i just watched a youtube review.. love all the cutscenes and such.  much better than a pacman remake!     and as for the rest, i totally agree and will keep at it.  thank you so much for your amazing insight and support for a complete stranger!  

I just ordered a pack of 10 replacement flex circuits for my intellivision controllers.. also likely to mod a couple of spare intellivision 1 controllers to have rs232 ports so i can use them with my sears intellivision or maybe even if i come across a decent priced intellivision II that might not have controllers or in fact comes with intellivision II controllers.. lol..  

 

I'm working on the ball part of the "game of ball" tonight.  it's already throwing new mysteries at me..  but i'm ready for it!  

Edited September 4, 2021 by Caleb Garner

[+DZ-Jay]

1 hour ago, Caleb Garner said:

While I'm not an artist, I love pixel art and making it.  if I could be of help, count me in to help.  Same with Music.. VERY new to intellivision music but i'm very experienced with midi / computer music..  i got the twinkle twinkle song to work so that's encouraged me..  

 

Send me a PM, let's talk.  I have an Intellivision music tracker that needs some music.  If you can compose music, I can help you track it for IntyBASIC.

 

Quote

i've copied it over to my project folder and will review it.

 

Wow this is really well laid out and I know I'll be getting very familiar with it in time.

I can't take credit for the images.  Those were made by @intvnut for the Intellivision Wiki, which is where I took them from.

 

@intvnut, a.k.a. as Joe Zbiciak, is an all-around Intellivision guru.  He wrote the assembler and emulator, lots of tutorial, and produced the LTO Flash!, among other things.

 

A lot of us owe him a great deal for getting us started programming for the Intellivision.  He is one of those very few veterans I mentioned before, who help me.  In fact, it was always mostly him.

 

He seems to be very busy with real life lately, so he doesn't post too much, but when he is, he is always eager to lend a hand.

 

Quote

I read through it and I kinda get it.  so with this example (left padde from "game of ball".  For my own understanding while I know you tackled A and C really well, I want to start with X and systematically move to Y then A then C.. 

 

    SPRITE 0, $0708 + x1, $0208 + y1, $0800 + 5 * 8 + 2

 

breaking it down like this:

 

$0708 is the magic number and by me saying + x1 means really to just say move to this sprite to the value of x on the X axis (a variable defined earlier as x1 = 23) the 8 is really just 00 through 15 as possible numbers..  thus the 8 in the above code is to enable collision? 

 

$0708 represents binary "011100001000".  So, if we map that to the layout mentioned above, we get:

 15  14  13  12  11  10   9   8   7   6   5   4   3   2   1   0
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
                      ^   ^   ^  \_____________________________/
                      |   |   |                 |
                      |   |   |                 `-------------> X position
                      |   |   `-------------------------------> Interaction
                      |   `-----------------------------------> Visible
                      `---------------------------------------> X Size

 

It means that the sprite is magnified in the X coordinate (i.e., every horizontal pixel will be double the size), it is visible (i.e., the sprite is shown when on the screen); and it interacts with other objects or the border (i.e., collisions will be detected for it).

 

It also means that whatever position is in "x1," that it will be added eight (%00001000, or $08); essentially shifting the actual coordinates 8 pixels to the right.  This is probably because the coordinate system for MOBs starts 8 pixels to the left as the coordinate system for the background scene, in order to allow for smooth sprite transitions.

 

Quote

at this time I don't understand what the $07 means..   and the 08 collision value is an assumption.. 

There is no collision information in the SPRITE statement.  It is composed like this:

SPRITE <number>, <x register>, <y register>, <a register>

As I mentioned in my last message, you shouldn't have to worry about the C Register at all (really), because it is handled by IntyBASIC for you, and exposed through a different interface.

 

 

Quote

BUT what do I do if I want to enable collision and i want to double the width which is the 10th slot?  and then maybe something comes up where i need the paddle to become invisible as some kind of penalty / power move by the opponent which is 9..   

 

According to the values you posted above, collisions (8th bit, "Interaction") are already enabled, and the 10th bit ("X Size") is already set for magnification.

 

The sprite is currently visible (9th bit, "Visible"), so if you want it invisible, you'll have to invoke the SPRITE statement again with an X Register value that does not set that bit.  If you consider using the "constants.bas" file as recommended before, it'll be a lot easier.  Your original statement may look something like this:

SPRITE 0, HIT + VISIBLE + ZOOMX2 + 8 + x1, ZOOMY4 + 8 + y1, GRAM + (5 * 8) + 2

 

Then, if you want to make the sprite invisible, you just don't add the "VISIBLE" term to the X Register argument.

 

If you are not using the "constants.bas" file, you then need to work out with a calculator the correct value of all the bits you want together.

 

 

Quote

I'm going to stop there for my understanding tonight..  if I can understand how to work with X fully the others will very likely make more sense.. A and C deal with more a lot of awesome possibilities but feels like a rabbit hole i don't want to go down just yet (questions leading to more questions and getting overwhelmed) but what's nice is you've already defined a bunch of stuff I can come back too! 

The A Register describes attributes for the sprite, including the picture and color, so it is necessary.  The C Register provides the results of collisions, but as stated before, it is handled by IntyBASIC and exposed in a different interface.

 

The reason for this is because IntyBASIC tries to read the C Register as early as possible because there is a limited window of time that the CPU has access to the STIC registers, and collisions are something you probably need to incorporate in your logic within the current frame.  Therefore, the IntyBASIC runtime environment reads the register and stores its values in variables that are accessible to your program.

 

See the IntyBASIC manual or the book for additional details on this.

 

Quote

I peeked at it but it was a lot if information.. good stuff!     greek still but it looks like it would be a great reference! 

 

The "constants.bas" file is organized by subject area, so all sprite constants are grouped together, all FG/BG mode constants are grouped together, etc.  If you have any questions, just ask!

 

I strongly recommend you get acquainted with it.  Include it in all your programs, and every time you need to set a magic number, see if it is already defined as a constant.  If you do not know what the magic number means, just ask -- we can help you break it down as necessary (as I did above).

 

Quote

holy crap that's an awesome game.  i just watched a youtube review.. love all the cutscenes and such.  much better than a pacman remake!     and as for the rest, i totally agree and will keep at it.  thank you so much for your amazing insight and support for a complete stranger!  

 

Thanks!  I am just paying it forward.  When I say I had a lot of help from the veterans, I mean I had a lot of help from the veterans. (Isn't this community awesome?!)

 

It is hard for me to overstate how much I took from their fount of experience, because I was as bewildered and lost as you are.  A few years later, I am just glad I have a bit of their experience to help others as well.  Perhaps someday, it'll be you helping others.

 

 

 

Quote

I'm working on the ball part of the "game of ball" tonight.  it's already throwing new mysteries at me..  but i'm ready for it!  

Good luck!  Ask if you need help!

 

     -dZ.

Edited September 5, 2021 by DZ-Jay

[8bitwidgets.com]

33 minutes ago, DZ-Jay said:

Send me a PM, let's talk.

awesome will do!  I'm super interested in how to do polyphony songs (twinkle was only 1 channel) and how to get things like noise to be percussive AND of course gorgeous sound design like Night Stalker.. seriously.. HOW THE HELL did they get some of those sounds..  that "player shot" sound is absolutely signature..  how three sine waves could make this almost water like sound..  genius. 

 

33 minutes ago, DZ-Jay said:

$0708 represents binary

Oooooooooooo OK crystal clear now!  I definitely can work with that!  

 

 

33 minutes ago, DZ-Jay said:

worry about the C

awesome thank you @nanochess

 

Edited September 5, 2021 by Caleb Garner

[8bitwidgets.com]

39 minutes ago, DZ-Jay said:

I strongly recommend you get acquainted with it.

Indeed I will!  

 

40 minutes ago, DZ-Jay said:

Isn't this community awesome?!

learning how true this is every day

 

 

Now onto sound..  but i gotta be honest yea this pong example is going to take some serious reflection before i move on to the next project..  there's a lot to unpack in there, but i am excited to understand it because I know it's going to be a super important thing to understand.. i've just been spoiled by newer engines that do physics for me!  

 

 

 

[Cmdr Orange]

On 8/29/2021 at 9:01 AM, Caleb Garner said:

    ' Example 1
  

    CLS ' Clears the screen
    DEFINE 5,1,smiling_face ' Define card 5 as a smiling face

    C = 0

 

main_loop:
    #backtab(c) = $807 + 5 * 8 ' Place it on the screen
    wait ' wait for a frame
    wait ' wait for a frame
    wait ' wait for a frame
    wait ' wait for a frame
    wait ' wait for a frame
    #backtab(c) = 0           ' remove it from the screen
    c = c + 1           ' Increase value of the C by 1
    IF c = 240 THEN c = 0        ' If c equals 240 then make it zero
    GOTO main_loop

 

smiling_face:
    BITMAP "..XXXX.."
    BITMAP ".X....X."
    BITMAP "x.x..x.x"
    BITMAP "x......x"
    BITMAP "x.x..x.x"
    BITMAP "x..xx..x"
    BITMAP ".x....x."
    BITMAP "..xxxx.."

 

Hello everyone, I'm new here. I just got Oscar's book yesterday, and I downloaded the most recent files to get started. I figured I'd ask my question in this thread since it already talks about the same code.

 

I'm trying to get "3.1 Our first IntyBASIC program" to work. I have typed in exactly what is in the book, which is the same as what Chopper Commander wrote. See quote.

 

After saving the file and running it through INTYbuild, I get this error message.

 

Error: variable 'C' not defined previously in line 25
2 used 8-bit variables of 228 available
0 used 16-bit variables of 47 available
Compilation finished
IntyBASIC compilation failed.
Program build aborted.

 

Line 25 in my code is...
C = 0

 

the 0 is a zero, I'm using Notepad++ and I have the Freebasic language selected and numbers show up in teal and default text show up in black.

I've tried changing the c value to 1 in line 25
C = 1

Still get the same error message.

 

Can someone help? Also, please dumb it down for me, I haven't coded since 1993. I took one semester of GWBasic in high school. Gonna take a bit of time to fully up to speed.

[+DZ-Jay]

45 minutes ago, Cmdr Orange said:

Hello everyone, I'm new here. I just got Oscar's book yesterday, and I downloaded the most recent files to get started. I figured I'd ask my question in this thread since it already talks about the same code.

 

I'm trying to get "3.1 Our first IntyBASIC program" to work. I have typed in exactly what is in the book, which is the same as what Chopper Commander wrote. See quote.

 

After saving the file and running it through INTYbuild, I get this error message.

 

Error: variable 'C' not defined previously in line 25
2 used 8-bit variables of 228 available
0 used 16-bit variables of 47 available
Compilation finished
IntyBASIC compilation failed.
Program build aborted.

 

Line 25 in my code is...
C = 0

 

the 0 is a zero, I'm using Notepad++ and I have the Freebasic language selected and numbers show up in teal and default text show up in black.

I've tried changing the c value to 1 in line 25
C = 1

Still get the same error message.

 

Can someone help? Also, please dumb it down for me, I haven't coded since 1993. I took one semester of GWBasic in high school. Gonna take a bit of time to fully up to speed.

If you are using the IntyBASIC SDK and created a new project using "INTYNEW," then the problem is that the generated template includes the directive "OPTION EXPLICIT," which requires you to declare all variables prior to using them.

 

This is good programming practice in general, which is why the SDK includes that by default.  However, it may not be very useful when using it on other people's programs which may not follow such advice.

 

To resolve it, you can either:

• Add "Dim C" at the beginning of your program (preferable); but you'll probably will have to do this again when adding additional code pieces from the book which may also use new variables.
• Comment or remove the line "OPTION EXPLICIT" at the top of your program.

    -dZ.

[Cmdr Orange]

Thanks dZ,
worked like a charm.

Now time to hit the book.

[8bitwidgets.com]

Keep at it!  Something that DZ-Jay has helped me understand in the book is that the book is right, but it doesn't explain why things are done how they are.  So just go with the flow and hopefully click for you.  If they don't someone will definitely do their best to explain things!