Baby Steps

[Opry99er]

This thread will be a series of questions concerning IntyBASIC...basics....... ahem...

 

 

I know some of this is covered in various other threads and in various text files associated with the SDK package, but as a brand new IntyBASIC programmer, I thought a simple thread covering some super simple necessities might be in order.

 

I will start with displaying a background.

 

In order to display a simple background, one must define a card or a set of cards, then put them onscreen using some kind of display command.

 

In another BASIC, this can be accomplished using the following code:

 

CALL CLEAR !clears screen

CALL CHAR(96,"51FA3B90CBA79401") !defines char96

CALL HCHAR(5,5,96,7) !draws the image at screen position (5,5) and repeats it horizontally 7 times

 

 

 

I know things are different in IntyBASIC, and I am excited to know how this would translate.

 

Please show the easiest way to accomplish the same thing in IntyBASIC.

 

 

(Once background generation is covered in full, we will discuss another simple basic standard)

 

 

 

Thank you for your help, and I look forward to learning from you guys.

Edited December 30, 2015 by Opry99er

[intvnut]

I recognize that BASIC, fellow TI-99/4A programmer!

 

CALL CLEAR => CLS

CALL CHAR => BITMAP / DEFINE

CALL HCHAR => PRINT AT, or a FOR loop. No direct replacement for HCHAR/VCHAR

 

For example, something like this roughly replicates your program:

.

         CLS
         DEFINE 0, 1, my_tile
         FOR I = 0 to 4
            #BACKTAB[5*20 + 5 + I] = $807   ! GRAM tile 0 in white
         NEXT I
here:    GOTO here

my_tile: BITMAP ".#.#...#"
         BITMAP "#####.#."
         BITMAP "..###.##"
         BITMAP "#..#...."
         BITMAP "##..#.##"
         BITMAP "#.#..###"
         BITMAP "#..#.#.."
         BITMAP ".......#"

.

Attention other IntyBASIC users, if there's something I've missed, please pipe up.

 

One thing you might have noticed: I referred to "GRAM tile #0". The Intellivision has two tile sets, the GROM and the GRAM. GROM is fixed, and GRAM is user programmable. There are 256 GROM tiles, and 64 GRAM tiles. You can think of them as two separate tile spaces as IntyBASIC does (and as the comment above suggests). Or, you can think of them as one large tile space where 0..255 are fixed, and 256..319 are programmable. Either way, you can't redefine the default character set like you can on the TI-99/4A.

 

As for the magic value $807... That's best explained by looking at the diagram here: http://wiki.intellivision.us/index.php?title=STIC#Color_Stack_Mode

 

 

 

Bits 0..2 and bit 12 combine to form the color number for the character, while bits 3..11 pick which card to display. $807 picks GRAM tile #0, and displays it in white.

[GroovyBee]

Personally, I'd recommend using constants.bas to avoid magic numbers

 

         INCLUDE "constants.bas"

         CLS
         DEFINE DEF00, 1, my_tile
         FOR I = 0 to 4
            #BACKTAB[SCREENPOS(5 + I,5)] = FG_WHITE + BG00
         NEXT I
here:    GOTO here

my_tile: BITMAP ".#.#...#"
         BITMAP "#####.#."
         BITMAP "..###.##"
         BITMAP "#..#...."
         BITMAP "##..#.##"
         BITMAP "#.#..###"
         BITMAP "#..#.#.."
         BITMAP ".......#"

[PuzZLeR]

Great thread - keep it going! We all stand to learn from following here.

 

Personally, I'd recommend using constants.bas to avoid magic numbers

 

Unless I'm talking out of my elbow here, I would think this is the same mindset as a C++ programmer avoiding "system calls", especially when migrating the program to other platforms. But the "system" here is only really one - the Intellivision.

 

Sure. It's simpler to use the constant, and less likely of error. But it's only a substitution really for the magic numbers.

 

I do enjoy manipulating them. Is there are a particular other reason to avoid them?

[GroovyBee]

Sure. It's simpler to use the constant, and less likely of error. But it's only a substitution really for the magic numbers.

 

I do enjoy manipulating them. Is there are a particular other reason to avoid them?

It makes things far more readable. Once you've got several projects under your belt not having to think about what the numbers mean in the context you used them in, always helps. You can just get on with solving the problems unique to your game.

[+DZ-Jay]

It makes things far more readable. Once you've got several projects under your belt not having to think about what the numbers mean in the context you used them in, always helps. You can just get on with solving the problems unique to your game.

 

 

Just make sure to use meaningful constants. I am not joking when I say I've seen things like this:

Const FORTY_TWO = 42

Only for the factor to require change in a future release, and instead of re-factoring the entire codebase, they just change the value. So you get something stupid like this:

Const FORTY_TWO = 45  ; Fixed bug #12334

 

It would have been infinitely better for the programmer to have used a name that describes what the value is, like say:

Const CUBE_HEIGHT = 42

Edited December 30, 2015 by DZ-Jay

[GroovyBee]

Thats not as bad as the code I saw in a project years ago that was lines and lines of

 

value=89+1+3-6+9+2-10.....

 

for one value!

[PuzZLeR]

It makes things far more readable. Once you've got several projects under your belt not having to think about what the numbers mean in the context you used them in, always helps. You can just get on with solving the problems unique to your game.

This is true when looking at code that is not your own. Actually, when I was first learning IntyBASIC (which is not too long ago actually) I used to think of them as "those funny numbers". What are they? This was a tough baby step for me.

 

Thats not as bad as the code I saw in a project years ago that was lines and lines of

 

value=89+1+3-6+9+2-10.....

 

for one value!

Uh oh. I've done stuff like this in my code.

 

That's because the 89 was a coordinate, the 1 was a size, the 3 was a delta, etc. whereas value=88 wouldn't be as clear. Baby steps.

 

Also, I probably would have added it wrong anyway most of the time.

[GroovyBee]

This is true when looking at code that is not your own. Actually, when I was first learning IntyBASIC (which is not too long ago actually) I used to think of them as "those funny numbers". What are they? This was a tough baby step for me.

It also helps in your own code too. If you work on things in your spare time and put a project down and then pick it up weeks or months later then if its a jumble of numbers its harder to get back into. If its meaningful constant names the "relearning" task is easier in my opinion.

 

Uh oh. I've done stuff like this in my code.

The shame!

[Opry99er]

Thank you guys very much for the information. I will put it to good use, I promise. For good... Not for evil....

[GroovyBee]

Thank you guys very much for the information. I will put it to good use, I promise. For good... Not for evil....

 

As with topics in the main Inty forum, things can wander all over the place here too.

[Opry99er]

Next tidbit:

 

Now that we have our little "wall" in place, let's put something on the screen to interact with it!

 

 

In 'the other BASIC':

 

CALL SPRITE(#1,96,16,100,100)

 

 

This puts a character (ASCII code 96) on screen as a SPRITE (or MOB). It is labeled as SPRITE #1, and it is colored white (color code 16). It is using the same character definition (96) as the wall graphic (for now)

 

It is placed at location 100,100-- which is 100 pixels down, 100 pixels across.

 

 

Our happy little MOB will be moving and interacting soon, but for now, let's just get him onscreen.

[GroovyBee]

Screen coordinate of 100,100 are not possible on the Inty. So adapting slightly :-

SPRITE 0,8+100+HIT+VISIBLE,50+ZOOMY2,((96-32)*+SPR_WHITE

So thats :-

 

- Sprite 0 with the highest priority in display order.

- 8+100 means 100 on screen in X, sprite collision enabled (HIT) and you can see it (VISIBLE)

- 8+50 means 50 on screen in Y, with a magnification of 2 in Y (ZOOMY2 - each of its pixels is the same size as a BACKTAB pixel)

- 96 is your ASCII code "-32" because the Inty GROM starts with a space (ASCII code 32), "*8" to move the card index into the correct field, SPR_WHITE making it white.

[Opry99er]

Hmm... That is interesting...

 

So the screen is 160 pixels wide by 96 tall.

 

The input fields, then are:

 

1) Number (0-7)

2) X location (+

3) Collision status

4) Visibility

5) Y location

6) Magnification factor

7) Character code

Color

 

Am I understanding this correctly?

[GroovyBee]

So the screen is 160 pixels wide by 96 tall.

Its 159 displayable pixels in X. the very last column is not displayed.

 

The input fields, then are:

More like this :-

1) Number (0-7)

2) "X location (+8 )" + "Magnification factor in X (ZOOMX2)" + "Collision enable (HIT)" + "Visibility (VISIBLE)"

3) "Y location (+8 )" + "Magnification factor in Y (ZOOMY2/ZOOMY4/ZOOMY8)" + "Double height mode (DOUBLEY)" + "Flip in X (FLIPX)" + "Flip in Y (FLIPY)"

4) "Character code" + "Foreground colour (SPR_xxx)" + "Priority (BEHIND)" + "GRAM flag (GRAM)"

 

Note: "Character code" + "GRAM flag(GRAM)" can be replaced with SPRnn if not generated algorithmically.

 

Am I understanding this correctly?

Have a look at the manual because all the commands are in there.

 

Edit: Added names from constants.bas in brackets and SPRnn details.

Edited December 31, 2015 by GroovyBee

[PuzZLeR]

Thank you guys very much for the information. I will put it to good use, I promise. For good... Not for evil....

 

NO! For evil! "Evil plans" with IntyBASIC was what I announced since my first post.

 

:-D

[Opry99er]

Its 159 displayable pixels in X. the very last column is not displayed.

 

 

More like this :-

1) Number (0-7)

2) "X location (+8 )" + "Magnification factor in X (ZOOMX2)" + "Collision enable (HIT)" + "Visibility (VISIBLE)"

3) "Y location (+8 )" + "Magnification factor in Y (ZOOMY2/ZOOMY4/ZOOMY8)" + "Double height mode (DOUBLEY)" + "Flip in X (FLIPX)" + "Flip in Y (FLIPY)"

4) "Character code" + "Foreground colour (SPR_xxx)" + "Priority (BEHIND)" + "GRAM flag (GRAM)"

 

Note: "Character code" + "GRAM flag(GRAM)" can be replaced with SPRnn if not generated algorithmically.

 

 

Have a look at the manual because all the commands are in there.

 

Edit: Added names from constants.bas in brackets and SPRnn details.

 

Aye, they be tharr....

 

This thread is more of a tutorial of sorts... Start at the beginning (display 'something' onscreen), then create a MOB, then make it move, then show how collissions are handled, etc.

 

And no disrespect AT ALL intended toward the contributors of the SDK, but I am having a little difficulty bouncing from STIC.txt to the manual to the tools page, etc.

 

It is my own inadequacies, not the fault of the developers.

[Opry99er]

Okay... Starting to come together in the ol' head here...

 

The ZOOMX and ZOOMY were a bit confusing at firsr, but you can 'stretch' your MOB in multiple directions... That is neat! I am used to a simple MANIFY factor which is either single or double magnified. This means that an 8x8 SPRITE becomes a 16x16 SPRITE -OR- a 16x16 SPRITE becomes a 32X32 SPRITE.

 

This is pretty unique.

 

I am getting an understanding for how the BACKground TABle is utilized as well. I like the idea of defining cards in bitmap 'drawings' as well. I am so used to HEX, however, that it is taking me some time to get used to the card definitions.

[+DZ-Jay]

Aye, they be tharr....

 

This thread is more of a tutorial of sorts... Start at the beginning (display 'something' onscreen), then create a MOB, then make it move, then show how collissions are handled, etc.

 

And no disrespect AT ALL intended toward the contributors of the SDK, but I am having a little difficulty bouncing from STIC.txt to the manual to the tools page, etc.

 

It is my own inadequacies, not the fault of the developers.

 

None taken.

 

You were not intended to bounce from the STIC.txt to the manual, to the tools page. The expectation was for you to read the tools page first, get acquainted with the SDK layout. Then use the manual as a reference while you explore the examples. The manual is highly technical, and we plan on addressing that in the future with more tutorials, but it is full of valuable information for every command.

 

Then there's the "STIC.txt," which is just there for hard-core users to use as reference. The idea is that if someone asks "how do I set X on the BACKTAB," we can say "take a look at STIC.txt which offers the layout of the BACKTAB word."

 

Ideally, what I would like is to have helper macros to abstract all of that, but we are still starting with the SDK, and it was important to just get the first version out. The next version is easier and more versatile, and it will continue evolving.

 

Opry99er, I will suggest one last thing. If you think it is important to have such a tutorial as this one (and I agree it is), why not compose it in a document and include it as part of the SDK?

 

By the way, that's what Tarzilla tried to accomplish with his "Inty-B Intro" tutorial. Have you taken a look at that one? The source should be very well commented as well.

 

-dZ.

[carlsson]

In case anyone benefits from one, why not start a Rosetta Stone with regards how to translate other BASIC dialects into IntyBASIC? I will probably not start one myself, but might contribute with what I know if someone else does.

[+Tarzilla]

I do find this thread a little strange, tutorials are usually written by people that are experts in the subject, not by people asking a question, attempting to answer the question themselves, then having several people give the correct answers. Comes off disjointed.

 

I think we are seeing a lot of people entering the area that aren't life long programmers (unlike DZ-Jay, Groovybee and others,) if you aren't, looking into the STIC.txt may not be the best thing. I would suggest looking into the sub folders that come with both the regular installs of IntyBASIC and/or the SDK. Intro.bas does try to show the basic features of the STIC with comments.

 

I have a second Inty-B tutorial in progress that features different features such as scrolling, but real life keeps delaying things.

[Opry99er]

Tarzilla,

 

Thank you for the Inty-B program. It is really an excellent example of the capabilities of the system. My son and I watched it a few times yesterday and he laughed each time Inty got the IntyBASIC logo out of the mailbox and put it on his head.

 

 

As far as 'disjointed' I can see your point. The issue, however, is that the tutorial series has been talked about for months and it takes quite a bit of time to put together a 'jointed' tutorial series and present it a piece at a time to newbs.

 

I started this thread to develop some usable tutorial material for those who might put it together (as DZ-Jay suggested) into one package.

 

I do believe it is important to have step by step tutorials... A "Teach Yourself IntyBASIC" package if you will.

 

I would absolutely LOVE to contribute in a positive fashion. I can take information, package it and make it shiny and put it into a document with code examples and screenshots... I need a better understanding of the language first, which is why I started the thread.

[carlsson]

"IntyBASIC for Dummies" anyone?

[+Tarzilla]

The Inty-B video is nice, but the actual code is nicer, and more importantly, the code was meant to be looked at and fiddled with so a newbie can see the cause and effect by changing things like the parameters of the SPRITE command. Take a copy of it and start changing things in it, it makes use of the Constants.bas file so all the magic hex numbers you see in the STIC are replaced with human understandable text.

[GroovyBee]

As far as 'disjointed' I can see your point. The issue, however, is that the tutorial series has been talked about for months and it takes quite a bit of time to put together a 'jointed' tutorial series and present it a piece at a time to newbs.

*raises hand* "My fault!" I have a few tutorials almost "in the bag" but they aren't pitched at the complete noob. I had meant to start the series during the contest but that idea didn't pan out. Hopefully, they'll start when the dust has settled on the programming contest.