GroovyBee Posted February 12, 2016 Share Posted February 12, 2016 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? 2 Quote Link to comment Share on other sites More sharing options...
+5-11under Posted February 12, 2016 Share Posted February 12, 2016 Perhaps "Advanced" is a relative term, but anyway... How to get the "standard" Intellivision start-up screen to show up. Examples of the different screen modes (and therefore how/why to select one vs the other). 1 Quote Link to comment Share on other sites More sharing options...
Kiwi Posted February 12, 2016 Share Posted February 12, 2016 (edited) 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)* +6 if flag2=1 then print at 8,$800+320+(sc(1)* +6 if flag3=1 then print at 9,$800+320+(sc(2)* +6 if flag4=1 then print at 10,$800+320+(sc(3)* +6 if flag5=1 then print at 11,$800+320+(sc(4)* +6 print at 12,$800+320+(sc(5)* +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 February 12, 2016 by Kiwi 2 Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted February 12, 2016 Author Share Posted February 12, 2016 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. Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted February 12, 2016 Author Share Posted February 12, 2016 As for this one. I use an array of bytes to hold a digit of the score. Interesting! There are much more efficient ways of handling BCD arithmetic on a processor that doesn't have BCD mode. Quote Link to comment Share on other sites More sharing options...
PuzZLeR Posted February 12, 2016 Share Posted February 12, 2016 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). 1 Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted February 12, 2016 Author Share Posted February 12, 2016 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. 1 Quote Link to comment Share on other sites More sharing options...
PuzZLeR Posted February 12, 2016 Share Posted February 12, 2016 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? 1 Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted February 12, 2016 Author Share Posted February 12, 2016 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. 1 Quote Link to comment Share on other sites More sharing options...
+nanochess Posted February 12, 2016 Share Posted February 12, 2016 The unsigned 16-bits arithmetic comparisons support in the next version of IntyBASIC will simplify greatly the handling of scores larger than 65,535 4 Quote Link to comment Share on other sites More sharing options...
Kiwi Posted February 13, 2016 Share Posted February 13, 2016 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. 1 Quote Link to comment Share on other sites More sharing options...
freewheel Posted February 13, 2016 Share Posted February 13, 2016 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. 2 Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted February 13, 2016 Author Share Posted February 13, 2016 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). Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted February 13, 2016 Author Share Posted February 13, 2016 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. Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted February 13, 2016 Share Posted February 13, 2016 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 4 Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted February 13, 2016 Share Posted February 13, 2016 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. 2 Quote Link to comment Share on other sites More sharing options...
PuzZLeR Posted February 14, 2016 Share Posted February 14, 2016 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. 1 Quote Link to comment Share on other sites More sharing options...
Kiwi Posted February 14, 2016 Share Posted February 14, 2016 I do want to help with making advance tutorial since I do know most of the answers to the suggestion provided above. I can start making them tomorrow. 2 Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted February 14, 2016 Share Posted February 14, 2016 I do want to help with making advance tutorial since I do know most of the answers to the suggestion provided above. I can start making them tomorrow. That will be brilliant. Make it so!!! Thanks. Quote Link to comment Share on other sites More sharing options...
freewheel Posted February 15, 2016 Share Posted February 15, 2016 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. 1 Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted February 15, 2016 Share Posted February 15, 2016 (edited) 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 February 15, 2016 by DZ-Jay 1 Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted February 15, 2016 Author Share Posted February 15, 2016 I do want to help with making advance tutorial since I do know most of the answers to the suggestion provided above. I can start making them tomorrow. Feel free to start but I already have stuff that needs finishing off for sub-pixel movement and sprite/BACKTAB collisions. 1 Quote Link to comment Share on other sites More sharing options...
Kiwi Posted February 16, 2016 Share Posted February 16, 2016 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.) <- 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 6 Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted February 16, 2016 Author Share Posted February 16, 2016 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). Quote Link to comment Share on other sites More sharing options...
First Spear Posted February 17, 2016 Share Posted February 17, 2016 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] 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.