Jump to content
IGNORED

Baby Steps


Opry99er

Recommended Posts

I have been programming in BASIC for quite a while and have put out 5 games for the TI-99, a sixth is very close to completion. I understand variable manipulation, loops, user input, and various other things that are universal.

 

The things that are unique to the Intellivision and IntyBASIC are graphics and sound application, etc.

 

In the HELLO WORLD thread I started, I have a program that displays something onscreen, takes cardinal direction user input, and allows the player to score. The score changes color when it flips over 999.

 

This program was made using the TI BASIC conventions (with which I am intimately familiar) almost exclusively, so the languages are not all that dissimilar. :D

 

The implementation of SPRITEs, the definition of custom graphics (GRAM in this case) and the commands to put the graphics onscreen are primarily where I am missing the boat.

 

 

Tarzilla, I will take some time and break down the Inty-B source, try to teach myself what you did there. To be honest, I hadn't really looked at your source much with the intent of manipulating it. That is a very good idea and I appreciate the exhaustive comments. Your intent with this contribution is now understood. :)

 

@GroovyBee, you have had quite a bit going on. I do not believe anyone is faulting you for the tutorials not being released yet. :)

Link to comment
Share on other sites

I continue to fail at doing anything... :lol:

 

Even when I do a direct copy and paste from an example given by a contributor here, I cannot compile and run the program.

 

The following is the example code:

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

I get the following errors on INTYBUILD:

 

Error: required '=' for assignment in line 20

Warning: Invalid extra characters in line 20

Warning: variable #BACKTAB assigned but never read

 

IntyBASIC compilation failed

Program build aborted

 

 

Can't get the #BACKTAB to work for me, and I'm not PRECISELY sure what it does.....

 

 

There is no mention at all of BACKTAB in the IntyBASIC manual, and the Inty-B program does not use it. The only iteration of BACKTAB in the Inty-B example is the text that is displayed onscreen that mentions BACKTAB.

 

constants.bas has BACKTAB as equaling $0200 (which I understand is the starting memory location for the background table)

 

 

****EDIT****

 

Here's what I had to do to make this work (for those reading this thread in the future)

 

 

REM Include useful predefined constants
INCLUDE "constants.bas"
CLS
DEFINE DEF00, 1, my_tile
FOR I = 0 to 4
WAIT
PRINT AT SCREENPOS(0, I) COLOR FG_RED, "\256"
NEXT I
here: GOTO here
my_tile: BITMAP ".#.#...#"
BITMAP "#####.#."
BITMAP "..###.##"
BITMAP "#..#...."
BITMAP "##..#.##"
BITMAP "#.#..###"
BITMAP "#..#.#.."
BITMAP ".......#"
I used PRINT AT SCREENPOS and stipulated the GRAM card by the \ convention. It now displays fine. Is this a reasonable solution?
Will my PRINTed cards show up in BACKTAB for future comparisons?
Edited by Opry99er
  • Like 1
Link to comment
Share on other sites

Mmmm.... Will be working some more tonight. I.....have......a plan. ;)

 

 

This screen is just for kicks. I am going to try and port a game of mine from the TI... Just need to decide which one to do first. :D

 

They will run much faster in Inty and will look just as good. :)

  • Like 1
Link to comment
Share on other sites

Good stuff. :) I hope to finally start messing around with a little Inty programming soon but I'm a noob as well. Step by step tutorials would be very helpful whenever they are released.

 

Did you ever think about doing any ColecoVision programming? Since you're a TI99/4a guy and all.. ;)

Speaking of 99/4a's, I need to pull mine out and see if it still works..

  • Like 1
Link to comment
Share on other sites

I really have no love for the Coleco... Although it DOES share a VDP with my TI. Never had one, though, and don't ever really want one. ;)

 

I do love my TI dearly and the Intv holds a special place in my memories.

 

I will produce games for both...

 

Coleco though... I just never had one, so I do not have an emotional connection.

 

 

I think I have decided which game I will port first. :D

  • Like 2
Link to comment
Share on other sites

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

 

Yeah, the separate X and Y magnification are quite a bit different from what the TMS9918A VDP offer. The VDP basically offers 4 sizes:

  • 8x8 with no magnification
  • 8x8 with magnification (each pixel doubled horizontally and vertically to cover a 16x16 space)
  • 16x16 with no magnification (comprised of four separate characters)
  • 16x16 with magnification (each pixel doubled horiz and vert to cover a 32x32 space)

On the STIC, you have way more options. You have:

  • Two base resolutions: 8x8 (one character) and 8x16 (two characters)
  • Two horizontal magnifications: 1x and 2x
  • Four vertical magnifications: 0.5x, 1x, 2x, 4x
  • Optional horizontal and vertical flipping

 

As for the stic.txt that comes with jzIntv, while it's reasonably complete, it's definitely fairly dense. At one point I had hoped to expand it out to something more approachable on the Wiki, but that never happened. Some of the docs are there ( http://wiki.intellivision.us/index.php?title=STIC), but you can see I drew up a lot of artwork for STIC documentation that never got text to go with it. ( http://wiki.intellivision.us/index.php?title=Special:UnusedFiles ) There are diagrams there that demonstrate the X/Y magnification modes, MOB priority, the MOB field vs. the BACKTAB field (for hardware scrolling) and so on.

 

 

On a separate note: As a fellow TI-99/4A person, have you acquired an F18A yet? Santa brought me a couple, but I haven't installed them yet. (Still moving from TX to CA.)

Link to comment
Share on other sites

Although a 2015 Contest entrant, I still consider myself in "baby steps" mode. Hence, justification for my question here. :)

 

I'd like to know about the limits of GRAM.

 

I have learned late in the game (of the contest) that you can only define 16 at a time, per WAIT. I did manage more onscreen with DOUBLEY enabled, but it seriously stifled my love of animating sprites and further onscreen variety.

 

I've read about a 64 max in total, or "cards", that you can use as needed throughout the game. But I read elsewhere that you can also have many, many, more drawn out in your program (as long as you respect limits.)

 

Can someone give a rundown on this? And how does this relate to the backtab, and other such details?

Link to comment
Share on other sites

You only have access to GRAM for a certain amount of time during the VBLANK period. In that time you have to program the cards you want. Even with an assembly language game you can't program all 64 card definitions in the available time and still keep the display on. If you want more animated GRAM cards you have to do it in batches (once per game frame) and organise your data too.

Link to comment
Share on other sites

Yup. Certainly limited.

 

Just for fun, I stuffed some 200-300 tiles in my program. It compiled and ran just fine with IntyBASIC and jzIntv, of course, my program keeping them at 16 max/frame.

 

However, when I tried to define anything beyond SPR63 (past the 0-63 allowed), IntyBASIC read it as a variable like any other. Of course, you didn't include it in the "constants.bas" file for that very reason - it simply doesn't exist with Intellivision.

 

Of course, good judgement calls on which you use is a given, but is there any way around the 0-63 limit? Or is this simply a case of "it is what it is"?

Link to comment
Share on other sites

Yup. Certainly limited.

 

Just for fun, I stuffed some 200-300 tiles in my program. It compiled and ran just fine with IntyBASIC and jzIntv, of course, my program keeping them at 16 max/frame.

 

However, when I tried to define anything beyond SPR63 (past the 0-63 allowed), IntyBASIC read it as a variable like any other. Of course, you didn't include it in the "constants.bas" file for that very reason - it simply doesn't exist with Intellivision.

 

Of course, good judgement calls on which you use is a given, but is there any way around the 0-63 limit? Or is this simply a case of "it is what it is"?

 

Think of it this way. You have an area that is 64 slots. You can only stick 16 user defined cards in at once, then you have to issue a WAIT.

Now put the next 16 in and WAIT

Now put the rest in and WAIT.

 

From this point on you can PRINT or SPRITE any of these 64 cards onto the screen.

 

If you don't like a card, change it and up to 16 of it's contiguous neighbours with DEFINE and issue a WAIT.

There is also a DEFINE ALTERNATE command but let us walk first before running.

 

Great news, any currently displayed characters or sprites will automatically change if they are referenced on the screen for the cards DEFINEd.

 

You can have 64 defined and active at a time. You can have lots of BITMAP statements up to 42K words worth in your code, but you can only have 64 defined into the GRAM area are once.

 

It will take 3 DEFINE statements, each followed by a WAIT to change a set of 64 possible.

 

This is good if your are changing whole screens at once like title screens or intermissions.

 

For lots of animated characters you would set aside a certain card number for the character and just DEFINE that card every couple of frames, point to a different BITMAP data statement to get a set a different frame of data.

 

You could have a character that has hundreds of unique frames of animation but you only need the current one DEFINEd to the card slot at any given time.

Link to comment
Share on other sites

Thanks! :)

 

Well, even with "only" 64 cards, you can still do some pretty stuff, at least background-wise, and you can still define alot of variety in sprites and animation, with careful management of your program. I was kind of hoping to get away with some laziness on the "management" part, but, I guess, "it is what it is".

Link to comment
Share on other sites

When programming for classic architectures, careful pre-planning and indexed data structures are absolutely critical if you plan on 'pushing the limits.'

 

I always try to start with as structured a format as I can, even if I don't need it... It helps legibility at LEAST.

 

I will post the code for my Spaghetti Western game soon... It is probably not as elegant as some programs out there, but you will see clean and clear structure with room to expand. :)

 

BTW, I have not tried your game yet!!! (a few others from the contest I have not tried either... I need to quit slacking!

  • Like 1
Link to comment
Share on other sites

When programming for classic architectures, careful pre-planning and indexed data structures are absolutely critical if you plan on 'pushing the limits.

True. Clever programming has historically pushed many limits in the past. Looks like we'll have to carry the tradition here too. :)

 

I will post the code for my Spaghetti Western game soon... It is probably not as elegant as some programs out there, but you will see clean and clear structure with room to expand. :)

 

BTW, I have not tried your game yet!!! (a few others from the contest I have not tried either... I need to quit slacking!

 

And I too will be posting my Source very soon if it helps. (Seeing if I can clear a bug in the meantime.)

 

My game is only a WIP as I only really started this thing a few weeks ago, so don't expect much. However, although I'm not saying it's in any way the best game, I will say that my goal for the contest, and when I finish it later, is to make it as action packed as possible!

  • Like 1
Link to comment
Share on other sites

Yup. Certainly limited.

 

Just for fun, I stuffed some 200-300 tiles in my program. It compiled and ran just fine with IntyBASIC and jzIntv, of course, my program keeping them at 16 max/frame.

 

However, when I tried to define anything beyond SPR63 (past the 0-63 allowed), IntyBASIC read it as a variable like any other. Of course, you didn't include it in the "constants.bas" file for that very reason - it simply doesn't exist with Intellivision.

 

Of course, good judgement calls on which you use is a given, but is there any way around the 0-63 limit? Or is this simply a case of "it is what it is"?

 

Just to be sure, the 16 cards at a time is a limitation of IntyBASIC. Well, kind of. That is as many cards as IntyBASIC is able to copy in a single VBLANK. However, the machine has some additional capabilities that can be exploited under some conditions.

 

For instance, by not enabling the display during VBLANK, you can have unrestrained access to the GRAM/STIC bus for as long as you keep the display disabled. The screen will just be blank, displaying the same colour as the border, and you can copy as much as you like to the GRAM without problems. This is commonly done during game or level initialization, when clearing the screen for a few frames fits as a natural transition.

 

IntyBASIC automatically enables active display on every VBLANK interrupt, curtailing your ability to do the above.

 

-dZ.

Link to comment
Share on other sites

Thanks! :)

 

Well, even with "only" 64 cards, you can still do some pretty stuff, at least background-wise, and you can still define alot of variety in sprites and animation, with careful management of your program. I was kind of hoping to get away with some laziness on the "management" part, but, I guess, "it is what it is".

 

Also keep in mind that, like Tarzilla said, you can change those 64 cards whenever you like. I use this to great effect in animating sprites and background elements in my game by just "cycling" the GRAM cards assigned to MOBs and other objects. Moreover, there is nothing that says you must define your play-field in GRAM only once; it is typical to swap GRAM tile sets on different screens and levels to get new backgrounds.

 

-dZ.

Edited by DZ-Jay
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...