Opry99er Posted December 31, 2015 Author Share Posted December 31, 2015 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. 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. Quote Link to comment Share on other sites More sharing options...
Opry99er Posted January 1, 2016 Author Share Posted January 1, 2016 (edited) I continue to fail at doing anything... 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 January 1, 2016 by Opry99er 1 Quote Link to comment Share on other sites More sharing options...
Opry99er Posted January 1, 2016 Author Share Posted January 1, 2016 2 Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted January 1, 2016 Share Posted January 1, 2016 This line :- #BACKTAB[SCREENPOS(5 + I,5)] = FG_WHITE + BG00 Should be this :- #BACKTAB(SCREENPOS(5 + I,5)) = FG_WHITE + BG00 Sorry about that! It compiles and works as expected after the changes. 1 Quote Link to comment Share on other sites More sharing options...
Opry99er Posted January 1, 2016 Author Share Posted January 1, 2016 Hey no problem! I have a MOB onscreen now, moving around with the disc. Next step is collision with the background. 2 Quote Link to comment Share on other sites More sharing options...
Opry99er Posted January 1, 2016 Author Share Posted January 1, 2016 Just playing around right now... Having fun! 3 Quote Link to comment Share on other sites More sharing options...
PuzZLeR Posted January 1, 2016 Share Posted January 1, 2016 No, it's not "a game", but you've got something that at least LOOKS like one. I remember, just a few weeks ago, when I've done something like this, it was an amazing day. Cheers! Quote Link to comment Share on other sites More sharing options...
Opry99er Posted January 2, 2016 Author Share Posted January 2, 2016 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. They will run much faster in Inty and will look just as good. 1 Quote Link to comment Share on other sites More sharing options...
SiLic0ne t0aD Posted January 2, 2016 Share Posted January 2, 2016 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.. 1 Quote Link to comment Share on other sites More sharing options...
Opry99er Posted January 2, 2016 Author Share Posted January 2, 2016 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. 2 Quote Link to comment Share on other sites More sharing options...
roadrunner Posted January 2, 2016 Share Posted January 2, 2016 I seen the title Baby Steps and thought this would be about the movie What About Bob?I'm Sailing!I'll leave now......... 1 Quote Link to comment Share on other sites More sharing options...
Opry99er Posted January 2, 2016 Author Share Posted January 2, 2016 Baby steps down the road.... DOCTOR!!!! LEO!!!! MARVIN!!!! 4 Quote Link to comment Share on other sites More sharing options...
intvnut Posted January 2, 2016 Share Posted January 2, 2016 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.) Quote Link to comment Share on other sites More sharing options...
Opry99er Posted January 2, 2016 Author Share Posted January 2, 2016 (edited) I do have an F18A. Thanks for the above post. Good info there. Check out my new "porting" thread on one of my TI games to IntyBASIC. Edited January 2, 2016 by Opry99er Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted January 2, 2016 Share Posted January 2, 2016 Just playing around right now... Having fun! Hmmm... that snowman needs a rounder belly! Quote Link to comment Share on other sites More sharing options...
Opry99er Posted January 2, 2016 Author Share Posted January 2, 2016 Yea, that did look quite a bit like a certain maze game we know, didn't it? 1 Quote Link to comment Share on other sites More sharing options...
PuzZLeR Posted January 3, 2016 Share Posted January 3, 2016 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? Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted January 3, 2016 Share Posted January 3, 2016 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. Quote Link to comment Share on other sites More sharing options...
PuzZLeR Posted January 3, 2016 Share Posted January 3, 2016 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"? Quote Link to comment Share on other sites More sharing options...
+Tarzilla Posted January 3, 2016 Share Posted January 3, 2016 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. Quote Link to comment Share on other sites More sharing options...
PuzZLeR Posted January 3, 2016 Share Posted January 3, 2016 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". Quote Link to comment Share on other sites More sharing options...
Opry99er Posted January 3, 2016 Author Share Posted January 3, 2016 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! 1 Quote Link to comment Share on other sites More sharing options...
PuzZLeR Posted January 3, 2016 Share Posted January 3, 2016 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! 1 Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted January 5, 2016 Share Posted January 5, 2016 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. Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted January 5, 2016 Share Posted January 5, 2016 (edited) 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 January 5, 2016 by DZ-Jay Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.