jrok

Well right now I'm just using the playercolors player1colors option in the standard kernel, and using 30hz flicker for player1 to draw the two enemies. gameloop fspeed = fspeed + 1 if fspeed=6 then gameFrame=gameFrame + 1 : fspeed=0 if gameFrame = 8 then gameFrame = 0 temp1 = fspeed & 1 updateHero player0x=x : player0y=y gosub Hero updateObs gosub AssignObs if temp1 then updateSprite2 updateSprite1 temp1 = gameFrame & 3 gosub Sprite1 goto DrawFrame updateSprite2 gosub Sprite2 DrawFrame drawscreen goto gameloop So in the above, I set up a framerate (fspeed) that cycles at an interval of 6, and a flicker rate (gameFrame) that cycles at an interval of 8 and then use temp1 to determine whether the current loop is even or odd to update the approriate sprite. In the "Hero", "Sprite1" and "Sprite2" subroutines, I do all of the marlarkey to update their x, y, collisions, etc, and also include some animation subroutines for each. For example Hero if...goto HeroStand if...goto HeroKneel if...goto HeroLoop Sprite1 if...goto MutantLoop if...goto TentacleLoop if...goto OffScreen Then I made all of my sprites right now have 8 frames of animation, whether the shape was actually "animating" or not. HeroLoop temp3 = gameFrame on temp3 goto Hero0 Hero1 Hero2 Hero3 Hero4 Hero5 Hero6 Hero7 MutantLoop temp2 = gameFrame on temp2 goto Mutant0 Mutant1 Mutant2 Mutant3 Mutant4 Mutant5 Mutant6 Mutant7 TentacleLoop temp2 = gameFrame on temp2 goto Tentacle0 Tentacle1 Tentacle2 Tentacle3 Tentacle4 Tentacle5 Tentacle6 Tentacle7 OffScreen temp2 = gameFrame on temp2 goto OffScreen0 OffScreen0 OffScreen0 OffScreen0 OffScreen0 OffScreen0 OffScreen0 OffScreen0 There are probably be better, cleaner ways to do this, but I found this has worked pretty good for me so far. At first I experimented with the bB multisprite kernel for awhile, but it seemed a little limited for what I wanted to do both visually and in terms of gameplay (though I think it would be great for a fast and furious two-player game). Eventually I'll be flickering player0 as well, and probably do away with player colors and flicker a multicolor player sprite and up to one multicolor enemy or item, then use player1 to flicker two monotone enemies/items. The good news is that right now when I have the phospor turned up at 70 or above in x26 or Stella, there's absolutely no flicker at all, which is pretty neat to look at.

Thanks man! LOL, I think there was actually a green one AND a purple one.

if a > 64 then if a < 240 then a = 240 Genius! You solved it with a single line! You know, I was trying to do the something similar (cap the downward accelaration ), but I was trying to do it with an && operation, which thanks to your fix I now realize I've been grossly overusing. I also think I'm not quite "getting" negative numbers. In the above line, would 240 mean -24? Anyway thanks again. This really helped a lot.

Thanks for the great fixed-point physics example, Michael. My problem is, I need to register my sprite's collision against whole integer values that I'm pulling out of a data array. So far I feel like I've been banging my head against a wall trying to figure it out. I attached an example of a modified script that tests whether the player's y intersects with one of three shapeflags using your momentum method. Jumping around this playfield gives various results. Sometimes, everything's fine, while other times the sprite falls straight through the floor. I assume this is becuase if the jumper's downward accelaration ever exceeds "1" it will likely skip the y value of the ground. Or is it becuase of the way fixed-point numbers compare to whole numbers? I've tried a number of remedies, but so far no dice. I hope this post makes some sort of sense, and that you can help out. Cheers, Jarod. jumping_var.bas jumping_var.bas.bin

Thanks man! Yeah, I tried to go for a sort of double-meaning thing there. "Armageddon Complex" is the name of the station, but I think it would also work as the mental neurosis of the game's main villain, General Gog, who has a nasty habit of blowing up planets.

Thanks, man!

Thanks!

Yeah that's a good point. I think 1 pixel is to slow, and 2 pixels is a little too fast. I think eventually I'll have to uses fractional speeds for everything here (which would be nice because then I could do friction too). Aha! No I missed that one somehow. It looks like a bit of reading, so I'll probably tuck into it tonight after work. Thanks very much for the tip... this would make my life much, much simpler! What I'm also really in the market for is a good bB bankswitching tutorial... right now I'm cramming the entire game (sans title screen and sprite graphics) into a single bank. I'm working on slimming down the current demo code, but it it seems that even at its most optimized it's going to need about 3000 bytes to run, which doesn't leave much room for things like collisions, enemy behaviors, player inventory, etc. But of course, when I try to dump some functions into another bank, the program compiles into some insane Dada-esque nightmare. Do you know of any good bankswitch threads?

EDT: This game has changed completely since I first started working on it, so I've ammended my first post accordingly. "Armageddon Complex" is a sci-fi action-adventure set on a massive space station that has been taken over by a marauding band of alien terrorists. The aliens are trying to gain access to the station's "Inifinity Collider" - a doomsday device deployed by the Earth's governments as the ultimate peacekeeper. You are humanity's last hope. You must locate and activate the station's auto-destruct system and, if possible escape before the Complex explodes. Along the way, you may also accomplish additional objective that will increase your final ranking. HUD: At the bottom of the screen, the score area displays your current inventory and shield strength. You can hold up to three items in your inventory at a time, and can have a maximum of up to three shields. CONTROLS (Adenturing Mode): Left Joystick - Move hero in 8 directions Left Fire Button - Activate a computer terminal or Aim/Use the active item in your inventory, as follows: Laser Sword - While holding the button down, tap the Left Joystick left or right to slash in that direction. Gun - Move the Left Joystick in one of 8 directions to aim the gun that way. Release the Fire Button to shoot. Bomb - If you can find this, you can blow holes in interior walls. RightJoystick - Tap left or right to change your active Inventory item. CONTROLS (Puzzling Mode): Left Joystick - Move move cursor in four directions Left Fire Button - Press a colored button (or submit the code by selecting the Enter key at the bottom of the monitor. ENEMIES & OBSTACLES (only two at the moment): Killer Robot: Garden variety evil robot. They turn up randomly in rooms that you enter, and can be dispatched with a single shot or a swing of your sword. Mutant X: This is a persistent character that will serve much of the function that the Dragons did in Adventure, relentlessly pursuing you around the complex. You can mangle him with a sword strike or a bullet, but after a few seconds he will re-constitute himself and continue hunting you down. Computer Terminal: A security computer linked in to the Armageddon Complex security network. Can be used to disable Force Fields or trigger other events. Force Field: A barrier which must be disabled by entering the proper code in a computer terminal. Cheers, Jarod. Latest Version: Armageddon_Complex_v2.bas.bin

I see if I can check it out this evening before I head out of town. Michael Quick update: I decided to abandon pfheights & colors in my game, but something interesting happened. I ran into some trouble with the standard bankswitch.inc, since turning it on seemed to mess up my pf drawing routines. Out of curiousity, I included your bankswitch supercharger file instead of the standard. It wouldn't compile at first, but then I altered it to point to the standard 2600basic.h file (instead of 2600basic_SC.h). Not only did the program compile, but it somehow fixed the drawing functions that bankswitch.inc were screwing up! I tried ding the same thing with your sample file, ("test_pfcolors_with_pfheights_SC.bas"), but it failed on the following: RAMplayfieldcolorandheight 0000 ???? (R ) pfrow5height 0000 ???? (R ) pfrow4height 0000 ???? (R ) pfrow3height 0000 ???? (R ) pfrow2height 0000 ???? (R ) pfrow1color 0000 ???? (R ) Sorry if that's not very helpful, but I thought I'd report it just in case. Hope your trip went well. J

Hi Michael, I was trying to implement your pfcolors/heights method in a game I'm designing. I know this thread hasn't been active for awhile, but when I copied over your includes to bB and tested your attached sample file, my DASM compiler fails, reporting the following errors: 2600basic_SC.h (68): error: EQU: Value mismatch. old value: $00a4 new value: $00a6 2600basic_SC.h (69): error: EQU: Value mismatch. old value: $00a5 new value: $00a7 2600basic_SC.h (70): error: EQU: Value mismatch. old value: $00a6 new value: $00aa 2600basic_SC.h (71): error: EQU: Value mismatch. old value: $00a7 new value: $00ab 2600basic_SC.h (72): error: EQU: Value mismatch. old value: $00a8 new value: $00ae ... I'm using batari Basic 1.0 and DASM V2.20.07... maybe something changed in either one between then and now?

This is great! It answered so many of my questions... even if it posed a few new ones. Maybe instead of a Powerpoint, I might try to code a small screen position demo, that uses the score objects to track position. It seems like such a fine point, but as I've been experimenting with different techniques, the calculation seems like it would be useful for all kinds of games (whereas simply detecting pf collisions didn't seem very helpful at all). Thanks again the explanation, Michael. J

Thanks!

Sorry if I'm having is a RTFM moment, but I was just curious about the relationship between "playfield" pixel position versus "sprite" positions. It seems as though pfpixels are roughly 4.5 times the width of sprite pixels - but not exactly 4.5, since odd numbered pfpixels will produce fractional results. I'm working on simulating sprite / playfield collisions based on datasets right now, and am realizing it would be much easier if I could just translate sprite position to pfpixel position on the fly (or, vice-versa). I'm just curious if anyone has experimented with such a technique on one of their games. Thanks in advance. J

More or less. Keep in mind you don't have to define everything then check everything. You could define temp6 (the r * 15 one) then define temp5, do a check, redefine temp5, do a check, redefine temp5, do a check, etc. If you're going to do the exact same check, but on different array elements you probably want to break the check part off into a separate routine (making it as generic as possible) that you call after setting your temp vars. Thanks! I really appreciate your help here, and will absolutely try this method. I think I've been spoiled for years by other languages where I'd be able to do something as simple as 'array = [room][value]', and at the same time pull a zillion variables out of my ass. I really do enjoy the challenge of this language. After all, if Da Vinci had photoshop and an HD camera, we would have never gotten the Mona Lisa, right?

Thanks. This seems like another great idea. The only thing I'm worried about is using the temp variables, since I need several of them in each function. One of my main design goals is to register whether the player's x and y positions overlap a certain area on the screen that represent game objects. (i.e. using coordinates to simulate the player "colliding" with an elevator -like in my example- or a door, a wall, a laser cannon, etc). So at the very least I assume I would need no less than four variables to define the x and y shape. Do you mean that I would define the temp vars inside the function, like this? data array 10, 40, 5, 20 [i] // a square shape that is 30 pixels wide and 15 pixels tall.[/i] gameloop (...) gosub SomeLabel (...) goto gameloop SomeLabel function someFunction temp1 = r * 15 temp2 = temp1 + 0 [i]// the left edge of the shape[/i] temp3 = temp1 + 1 [i]// the right edge of the shape[/i] temp4 = temp1 + 2 [i]// the bottom edge of the shape [/i] temp5 = temp1 + 3 [i]// the top edge of the shape[/i] if x<array[temp2] || x>array[temp3] then playerCollision= 0 if y>array[temp4] || y<array[temp5] then playerCollision = 0 if x>=array[temp2] && x<=array[temp3] && y<=array[temp4] && y>=array[temp5] then playerCollision = 1 end return Would that be the general idea? Thanks again for your insights. P.S. - Dungeon is great Atari game

Thanks, man! I'm only flickering three sprites right now, but I know I'll eventually have to flicker at least four (and possibly as many as six!) to get the kind of gameplay I want. I haven't got there yet, but I might wind up having to dump pfcolors under the bus to get back my precious missile0... hopefully that won't happen.

Thanks Nukey. Those are both really interesting ideas. So if I understand you correctly, I would end up with 15 data sets (at least, given the example I posted), each of which would have a length equal to the total number of rooms I wanted to draw? If so, that's a pretty great idea.. it also means I might want to write my "level editor" first, so i don't pull my hair out trying to remember which value goes where. LOL. Man, I don't even know regular Basic, so you are way, way way ahead of me. Thanks again for the great ideas. Cheers, J

Hi everyone, Just to quickly introduce myself, I'm a 32 year old multimedia designer and retro graphics geek with fond memories of the Atari 2600. I'm a self-taught, halfway-decent programmer in wimpy languages like Java and Actionscipt, but I sort of skipped over the "Basic" portion of my education. I've been using bB for about a week now, and its definitely the stepping stone I need to work my way into assembly (thanks, Fred!) The game I'm working on is an adventure that requires screen-to-screen movement, with new rooms to be drawn by accessing segments of a data set, (which I imaginatively named 'gamemap'). In other languages this process is pretty simple to accomplish, but I'm running into a few problems in bB, since it doesn't seem like you can nest arrays. In my code, I have a sets of fifteen values that describe how to draw a room and objects inside it, including things like the span of lines to draw and arguments that are passed to certain interactive objects of the playfield for use in the gameloop. In my posted binary, my sample room object is a Teleporter activated by the button, that sends you up or down depending on which floor you are on. For example: data gamemap 137, 13, 85, 20, 12, 135, 138, 85, 20, 30, 31, 7, 2, 85, 45, //This is room 1 end drawElevator // This is drawing the elevator graphics in my program, and setting the animating portions to off if gamemap[4]=12 then pfvline gamemap[9] 0 11 : pfvline gamemap[10] 0 11 if gamemap[4]=12 then pfpixel gamemap[9] gamemap[11] off : pfpixel gamemap[10] gamemap[11] off if gamemap[4]=12 then pfpixel gamemap[9] gamemap[12] off : pfpixel gamemap[10] gamemap[12] off gameloop (...) updateBackgroundOb function tElevator if x<gamemap[5] || x>gamemap[6] then playerTouching = 0 : yAdj = 0 if y>gamemap[7] || y<gamemap[8] then playerTouching = 0 : yAdj = 0 if x>=gamemap[5] && x<=gamemap[6] && y<=gamemap[7] && y>=gamemap[8] then playerTouching = 12 : yAdj = 2 end if gamemap[4] = 12 then bgobj = tElevator : gosub Elevators (...) goto gameloop In the above example, the gameloop finds the values it needs for the elevators by pointing to static positions of the array. As you can see in my attached BIN, this all works like a charm for a single room. But for moving from room to room, what I really need is something like the following: const roomsize = 15 //The length of a segment that describes a single room roomvar=0 data gamemap 137, 13, 85, 20, 12, 135, 138, 85, 20, 30, 31, 7, 2, 85, 45, //This is room 1 137, 13, 85, 20, 12, 90, 94, 85, 20, 20, 21, 7, 2, 85, 45 //This is room 2 end gameloop curroom = roomsize * roomvar //The multiplier that points to the appropriate segment of gamemap (...) if x>rightside then roomvar=roomvar+1 : gosub newRoom updateBackgroundOb function tElevator if x<gamemap[5+curroom] || x>gamemap[6+curroom] then playerTouching = 0 : yAdj = 0 if y>gamemap[7]+curroom || y<gamemap[8+curroom] then playerTouching = 0 : yAdj = 0 if x>=gamemap[5+curroom] && x<=gamemap[6+curroom] && y<=gamemap[7+curroom] && y>=gamemap[8+curroom] then playerTouching = 12 : yAdj = 2 end if gamemap[4+curroom] = 12 then bgobj = tElevator : gosub Elevators (...) goto gameloop newRoom (...) drawElevator if gamemap[4+curroom]=12 then pfvline gamemap[9+curroom] 0 11 : pfvline gamemap[10+curroom] 0 11 if gamemap[4+curroom]=12 then pfpixel gamemap[9+curroom] gamemap[11+curroom] off : pfpixel gamemap[10+curroom] gamemap[11+curroom] off if gamemap[4+curroom]=12 then pfpixel gamemap[9+curroom] gamemap[12+curroom] off : pfpixel gamemap[10+curroom] gamemap[12+curroom] off return The idea is, when you exited the room you were in, the next room would be drawn by locating the next set of fifteen values, and all the methods and functions would access to that set. Basically I thought this would be a way of simulating multidimensional arrays, but I recieve errors on the expression gameMap[somevalue + curroom]. I know that bB arrays aren't writable, but does anyone know of a good sound way I can move a pointer around in my array? Thanks in advance for any help you can give me. As a side note, I'm really excited about writing my first Atari game, and if I can get my screen-to-screen movement to function, I plan to contribute to the community by writing a "level editor" in Java or Flash that would let authors quickly define playfield areas and their arguments, then output the proper bB code for insertion into projects. Cheers, Jarod "Mutant Armageddon" tech demo Instructions: Joystick left/right - moves character Joysick down - duck! Button - Use/activate elevator (when standing on it) EDT: The monsters in this demo are dumb as doorknobs right now, moving in a single direction. They will be plenty smart eventually, and if I can implement my screen-to-screen technique, their positions will be updated in new rooms based on where they last left the screen, simulating map "roaming". Mutant_Armageddon.bin

Hi everyone. I'm trying to program a player graphic that animates in 8 directional orientations using batariBasic and the multisprite kernel. The human player controls the player0 sprite, which uses odd and even frames to display two graphics, where one portion is the head and arms of a flying superhero and the other portion is his flowing red cape. The sprite is animated using temp1 to produce a value between 0 and 3 and jump to the correct frame of 4-frame animation. I am attempting to use long sprites in my animation routine to account for the 5 possible orientations of the sprite (REFPO is used for left, left-up and left-down sprites.) I've been trying to use player0pointerlo to display the correct directional frame during the animation routine. Basically, I made a var called playerDir that changes when the player moves the joystick, and then have tried: player0pointerlo = playerDir ... where playerDir is a integer of the first line of a graphic in the long sprite. But instead I've just been getting a garbage sprite where the cape should be, and I honestly have no clue what I'm doing wrong. I've posted my .BAS file with the above line commented out in the main loop, and when compiled it displays the correct sprite set. If there is anyone out there who has created a similar sprite and could help me figure out what I'm doing wrong, I'd greatly appreciate it. Thanks in advance! animated_8direction_sprite.bas