jrok

I have no trouble with your BIN. The colors look correct. But, when I recompile your BAS file with DASM, I get the same error as yuppicide (rainbow effect).

Yeah, I liked that too. The thing is, I tried it that way at first, but it didn't look as good to me in without the multicolor shades of green. Heh I never thought about it that way, but I guess they are a little grating. Besides which, I doubt I would want to step on something like that if I had never seen it before. I'll try going back to a simple platform, and maybe save the headache-inducing thingee for something else, like an electrical fire. Yeah, me too. One thing I'm thinking of doing to get it back is having joy0 control player1. Then I could flicker a multicolor hero and one multicolor monster/item per screen. It would just mean that a lot of monsters and items would have to be monocolor, but I might be able to live with that. Thanks for the feedback, man.

I have a new update to this. I'll post more about the changes on my blog, since they are fairly radical, but here's an overview: Abandoned my "persistant monsters" dream (for now). It had it working okay, but implementing it in a fun game just started to seem daunting. Monsters stay in their assigned rooms now. Adandoned "playercolors." Not only do I know I'll want that darn missile back, but defining 16 colors for nearly every sprite was a real ROM hog. The hero's new look is a sleek white spacesuit, which I'll probably add some details to at a later date. I am only using multicolor with player1 sprites now. Added a room-to-room teleportation pad. I worked pretty hard on this sprite, so I hope its effective. I also added a psychdelic color effect for when you are teleporting, which I hope to improve upon later. You activate it by standing on it and press the fire button. Revised player movement and collisions. I'm at the phase in design now where I'm really thinking hard about how to make the gameplay innovative and fun. I'm going to ditch "jumping" for a jetpack (move joystick up) with limited fuel. I also added the ability to "climb" walls by running into them, rather than just having them stop you. My thoughts are that, when combined with a gun and a jetpack, there could be opportunities for some real slam-bang monster fights. Thanks for all the help and well wishes so far. I'm really excited about finishing this project! Jarod. Armageddon_Complex_teleport_and_climb.bin

You know, this demo brings to mind a question about scanline that's been haunting me lately. When I ran this demo in emulators while tracing scanlines, I noticed that whatever routine draws the random map causing the scanlines to leap suddenly, then return to 262 after the map has been drawn. I'm experiencing the same thing in my own project, when moving between screens. A couple of questions for anyone who can answer them: 1) Is this a problem - That is to say, if nothing in particular is going on your screen when the scanlines fluctuate, would it still cause problems on cartridge? For instance, I have a playfield drawing routine that operates when the player exits the left or right side of the screen. The frame that he exits on runs a DrawRoom subroutine that generates 340 scanlines, and the frame directly before the new pf appears generates only 16 scanlines. Then everything goes back to the constant 262. 2) If it IS a huge problem on cartridge, is there a way to minimize it (short of abandoning the subroutine, of course)? Thanks, Jarod.

I noticed there seems to be some sort of problem with using fixed point math and batari bankswitching. When you include either bankswitch.inc (or the supercharger version), DASM fails on the following for fixed-point subtractions: Sub44from88 0000 ???? (R ) bs_mask 0000 ???? (R ) ...and the following for fixed-point additions: Add44fto88 0000 ???? (R ) bs_mask 0000 ???? (R ) Does anyone know what these errors mean, and if there is any way around them? Thanks, Jarod. jumping_bs.bas

This is cool! It seems just random enough, with each maze being unique but navigatable. One thing that might be cool to add would be to use pfpixel to make an exit appear in a random postipn somewhere along one of the four external walls. Maybe when you pass though it, it could connect you to a new maze... just a thought. In general, this could be the basis for a really cool pacman-type game. Ms. Pacman used to bother me because I'd be doing much of the same pattern repitition every screen, so even a subtly random element like rearranged portions of the maze could really keep someone on their toes.

You know, I wasn't having trouble until I started to incorporate bankswitching. I had myriad problems trying to use batari's included bankswitching routine, but then I tried using SeaGtGruff's superchipheader_SC.asm and most of the problems disapeared. The only trouble that remains is that I get compiler errors when I try to use negative fixed-point variables and bankswitching, but I'm not smart enough to know what's going on there. I shelved it for now to hopefully figure it out at a later date. That's the main reason I haven't posted much of my bB source yet. I just know it's just sloppy work, and its probably due to years of grinding out fast and dirty projects with IDEs like Flash, where your code can be a total pig-sty and still compile. Actually, one of the reasons I decided to take up this hobby is to force myself to be a more efficient programmer and hopefully develop better work habits... but so far I'm still a bloody hack.

Well, I'm a total newbie but the way I've been approaching Atari design so far is to start out with all the bells and whistles (32kSC bankswitched) see how much memory is actually being used to do the most important things I want the game to do, and then pare back on the code and the number of banks used. So far I've been keeping all my routines in 4 banks and haven't even come close to filling them up yet, so I'm hoping I will end up with a 16K game.

Heheh, yup that was a bug. Thanks, man, I think I squashed it now. I also added a few new things, including a Spaceship (for escaping the game, eventually). Check it out. Armageddon_Complex_a0_8.bin

It's a cool game,. My only thought while playing it was that it handles a little slow. I suppose for the playfield collision you could statically define them in a data array using pfhline and pfvline to draw them, then select which one to use before play begins. Another interesting feature might be to add some button functionality. For instance, what if a button press drew a temporary wake of playfield pixels, that could be used to block/angle shots (like the tron cycle's wake, expect disapearing after a few loops?) With the players so small and the handling so slow, it's hard to home-in on the puck, so this might lend an extra element of surprise and stategy to the game. Plus, if you have a mode select before play begins, I suppose you could turn that feature on and off.

Nope. If it is outputting at 262 scanlines, every frame needs to be 262. The swag he's talking about is although 262 is your baseline, some games output at 264 or something else close. But every frame needs to be the same or you'll get jitters or rolls. Sorry about the newbie questions, but I'm a newbie I think I understand now. I went fishing for games that scanned over 262, and I noticed that "This Planet Sucks" weighed in at a constant 282 per frame. Out of curiousity, when you have frames that surpass 262, is there a standard method to even out the time? For instance, say I pared down my routines so that the maximum number scanlines in any given frame is 273. Would I (could I / should I) add garbage to the other frames until they also have 273 scanlines?

Thanks again for your help with this. I revised my code somewhat to try to get scanlines under control, and I just wanted to make sure I understood what you meant by "constant." I spread my code across three frames. Now, when I do a frame-by-frame trace in Stella, I get the following results: Frame1: 262 Frame2: 276 Frame3: 273 (...) It runs fine in Stella and z26 defaults, but the variance is less than 5% and it varies at a the same rate throughout the program. Is this what you mean by constant? Or do you mean that does every frame needs to have the exact same number of scanlines to prevent rolling (i.e. every frame has 276)? Cheers, Jarod.

Thanks, Nukey. I was just staring at my code a second ago and thinking the same thing (about breaking it across several frames.) What I'm doing now definitely isn't very elegant.

Thanks, Thomas. This is extremely helpful, and it makes a lot of sense too. The funny thing is, I now know my suspicions about those "for-next" loops were correct. When I disable them all together, I maintain a constant 262 scan, and when I limit their iterations, the variance isn't nearly as large, which is probably why that 2_loop version worked okay in Stella. Of course, that means I'll have to figure out a new way of testing those conditions, but it's incredibly helpful to know what sort of results to look for. Cheers, Jarod.

Nope. Most likely the screen will roll on actual hardware. Emulators are mainly written to emulate correctly written software. How they react on bugs, unless explicity implemented, is unpredictable. Hmm... Well that's sort of helpful to know, but I suppose this brings me back to original nature of my question. After all, viewing the program on z26 doesn't show any obivous "bugs." So what I'm really asking is, does a baseline metric exist that programmers use to debug for cartridge? I mean, if emulators can't simulate true VCS performance via settings, is there a generally accepted list of benchmarks or guidelines on what to look for that may work in emulation but will be buggy on cartridge? For instance, when I see wide trace variance in scanlines, what trace values I should aiming for (i.e 262)? Do benchmarks exist for framerate variance as well? Hope that makes sense. Thanks, Jarod.

Both binaries display a rapidly varying number of scanlines. Try z26 with option -n and see what I mean. Yes, I noticed that too. But if z26 doesn't seem to have a problem with that, does that mean that the actual VCS hardware won't either?

Thanks so much for your speedy response, stephena. I've attached two binaries to help illustrate the issue, and see if you can reproduce it on your end. I'm pretty new to emu's so I'm not exactly sure whether what I'm seeing is an emulation bug or not. Basically, the rate of the game at which the graphics update seems to jump, almost as if the framerate itself is changing while the game is in progress. In other words the code still crunches correctly, but the rate at which the screen refreshes isn't constant the way it is in Z26 defaults. The only reason I mentioned my for loops is that when I recompile with a lesser number of my for loops, Stella seems to handle the code fine no matter what the graphics transport mode is. Here's what I'm seeing on my end with these two binaries and Stella defaults: Armageddon_Complex_5_loops.bin - Entire graphics display shudders - The refresh rate jumps every two seconds, almost like a "hiccup" effect (sorry for the bad analogy, but I'm not sure how else to describe it) Armageddon_Complex_2_loops.bin - No shuddering - Constant screen refresh rate. When I use Open GL on the "5_loops" version refresh rate is constant, but the display still shudders. Again, none of these problems occur on Stella when I shorten the total number of for loops per drawscreen. Default Z26 didn't seem to have any of these issues, no matter how many loops I included. System Specs: - Windows XP Pro - Pentium D 2.80GHz - 2.0G RAM - RADEON X1300 Series graphics adapter Thanks again for for taking the time to respond. I guess since I was seeing a definite difference in the way Stella and Z26 were handling the same code, I wanted to know which would be better suited to debug for EPROM, but in no way was I suggesting that Stella was inferior to Z26 in emulation. If anything, I assumed the issue was with my code, and wanted to figure out which standard to optimize towards. Please let me know if I've left out any info that might be helpful. Jarod. Armageddon_Complex_5_loops.bin Armageddon_Complex_2_loops.bin

I'm curious which emulator is more accurate to physical cartridge performance? Both have a variety of settings that seem to "fix" certain performance issues but is there a particular platform and/or settings that reliably emulates the physical system? The reason I ask is because I'd like to someday put a game on cartridge, and I've already run into some major performance differences in a game I'm working on. In particular, I'm using three for-next loops to test for collisions with a game map. Each for-next loop runs five iterations per game loop, with the first five on one side of the drawscreen and the other ten on the other side. Default z26 settings run this code silky smooth with no performance problems, but Stella's defaults chew on it like burnt steak. But if I switch Stella's settings from "Software" to "Open GL" or limit the number of for loops from 5 to 2 it's fine. Unfotunately, limiting the number of for-loops is too, well, "limiting" and I don't trust Open GL's hardware accuracy. If anyone has any insight into the most accurate form of emulation, or even a good metric to test hardware accuracy I'd be much obliged. Thanks in advance. Jarod.

Aha! Thanks. So the includes are the same, then. I've been trying to figure out a possible bug with bankswitching and fixed-point math. It seems like when you try to do subtraction of fixed point variables with bankswitching on, the assembly fails on: "--- Unresolved Symbol List Sub44from88 0000 ???? (R )" Is this a known issue? Thanks for your help. Jarod

I just realized that the version of the "bankswitch.inc" include that shipped with batari 1.0 is this: ; this file is screwed, I accidentally deleted the comments. Restore with version in .99b zip file. 2600basicheader.asm bB.asm std_kernel.asm startup.asm pf_drawing.asm pf_scrolling.asm std_routines.asm std_overscan.asm bB2.asm score_graphics.asm banksw.asm 2600basicfooter.asm Does anyone have this version of the correct file? I sniffed around the web, but cannot find it. Any help would be much appreciated. Thanks, Jarod.

No problem. The cool thing is, with the phospor turned on full steam, there's no visible flicker at all. And even in the 70's range, the flicker is barely detectable. I'm already curious how this effect looks on an old-school TV tube... unfortunately I don't have an EPROM burner (or an old school TV). The thing is, if you limit this loop to update only three sprites (like I'm doing in AC with a condition that tests whether or not all four sprites are present in a room) one of them actually won't be flickering at all. You just have to alter the loop to skip updating one of the sprites: gameloop fspeed = fspeed + 1 if fspeed=6 then gameFrame=gameFrame + 1 : fspeed=0 if gameFrame = 8 then gameFrame = 0 temp1 = fspeed & 1 if temp1 && myVariable=someValue then updateSprite4 if temp1 && myVariable<someValue then DrawFrame updateSprite2 temp1 = fspeed & 3 gosub Sprite2 goto DrawFrame updateSprite4 gosub Sprite4 DrawFrame drawscreen updateSprite3 gosub Sprite3 updateSprite1 gosub Sprite1 goto gameloop

I thought I'd post an example of the way I am flickering and animating my four sprites in "Armageddon Complex." I suppose these strategies could have been broken into two separate demos, but I think that together they might be useful in visualizing Atari gameloops in general. First we select some kernel options. In this example, sharp-looking sprites are more important than missiles. set kernel_options playercolors player1colors pfcolors set smartbranching on We define some coordinate variables for our four noble sprites, as well as two additional variables to measure the framerate and the currentframe. dim sprite1X = a dim sprite1Y = b dim sprite2X = d dim sprite2Y = e dim sprite3X = g dim sprite3Y = h dim sprite4X = j dim sprite4Y = k dim gameFrame = m dim fspeed = n Next, initialize the game and give our sprites some starting positions. playfield: ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ end COLUBK = $E0 sprite1X=30 sprite1Y=48 sprite2X=60 sprite2Y=48 sprite3X=90 sprite3Y=48 sprite4X=120 sprite4Y=48 Our gameloop is responsible for doing three main things. Count its own iteration (fspeed) Keep track of which frame all the sprites are in (gameFrame) Determine whether the current loop is an even or odd number Inside the loop, fspeed tells the sprites to advance one frame every six gameloops. It also keeps track of which sprites player0 and player1 should draw. In this example, player0 draws sprites 1 & 4, and player1 draws sprites 2 & 3, and the subroutines that update them are balanced on either side of the drawscreen. gameloop fspeed = fspeed + 1 if fspeed=6 then gameFrame=gameFrame + 1 : fspeed=0 if gameFrame = 8 then gameFrame = 0 temp1 = fspeed & 1 if temp1 then updateSprite4 updateSprite2 temp1 = fspeed & 3 gosub Sprite2 goto DrawFrame updateSprite4 gosub Sprite4 DrawFrame drawscreen updateSprite3 gosub Sprite3 updateSprite1 gosub Sprite1 goto gameloop The subroutines themselves don't do much in this sample, except to repostion the player sprites to the appropriate xy value, and instuct it to go to its animation routine. Sprite1 player0x=sprite1X : player0y=sprite1Y : goto Sprite1Frames return Sprite2 player1x=sprite2X : player1y=sprite2Y : goto Sprite2Frames return Sprite3 player1x=sprite3X : player1y=sprite3Y : goto Sprite3Frames return Sprite4 player0x=sprite4X : player0y=sprite4Y : goto Sprite4Frames return Finally, we animate the sprites by looking at the current value of gameFrame. Since gameFrame caps at 8, our sprites have a ceiling of 8 possible shapes in their animation. Of course, they don't have to have 8 different frames. And probably shouldn't, if you want to create the illusion that they are moving at different rates. Sprite1Frames on gameFrame goto Shape1_1 Shape1_2 Shape1_3 Shape1_4 Shape1_4 Shape1_4 Shape1_3 Shape1_2 Sprite2Frames on gameFrame goto Shape2_1 Shape2_2 Shape2_3 Shape2_4 Shape2_1 Shape2_4 Shape2_3 Shape2_2 Sprite3Frames on gameFrame goto Shape3_1 Shape3_2 Shape3_3 Shape3_1 Shape3_2 Shape3_3 Shape3_1 Shape3_1 Sprite4Frames on gameFrame goto Shape4_1 Shape4_2 Shape4_3 Shape4_4 Shape4_5 Shape4_6 Shape4_7 Shape4_8 rem After this, you can draw all your purty graphics... That's it! The attached source has some additional comments in it. I'm pretty new to batari programming, so I'm sure there are many other and better ways to do these sort of things. But I thought that maybe this general method might be useful for a few folks out there. Cheers, Jarod 4_multicolor_sprite_flicker.bas 4_multicolor_sprite_flicker.bas.bin

Okay, I have a heavily revised build. I go into a bit more depth about the changes on my blog, but here's the basic rundown: Flickering four sprites at 30hz (no visible flicker with phospor in Stella or x26) Generalized room drawing function to build objects from the data set no matter what order they are written in (which is key for building my level editor, as well as saving tons of ROM) Limited the max number of room objects to 5 (whilst fishing for extra variables, of course! Included semi-natural gravity and a "Jump" function for joyfire0, thanks to more awesome help from the amazing Mr. SeaGtGruff. Monsters now recognized floors and walls, turning around if they bump a wall or reach the edge of a platform. I took the teleporters out of this build so I could focus more on streamling my map drawing and flickering 4 sprites. I optimized my code extensively, and this build moves much, much faster/smoother than my original newbie effort. However, I only have 33 bytes left in my game bank and I maxed out all my supercharger variables on this build, so for the next build I will definitely have to use extensive bit operations and *some* sort of bankswitching. EDT: Whoops, wrong BIN. New one attached. Armageddon_Complex_flicker4.bas.bin

No problem. I plan on posting my BAS file for this as soon as I can get the next build done. As I was telling someone else it moves really slowly in the currently posted build because of the way I was testing collisions. It's much "peppier" with the way I'm doing things now, and a lot more flexible in terms of how the map data is structured. I also included gravity and a jump for the next build, so if I can get the map functions solid it might be the beginning of a halfway decent platform-game engine.

Thanks Piggles! I'm working hard at a new version of this. When I reviewed my code I realized I was doing some things in a pretty boneheaded way. In the next build everything will move much faster, and I've implented gravity and a jump function for the hero. In total, I am trying to have a maximum of 6 objects per room (platforms, walls, doors or transporters) drawn out of my data array. Also some transporter pads will (hopefully) not just take him up and down, but also sideways and room-to-room. The problem I'm trying to solve right now was that in the original, I was serializing the playfield objects individually, instead of doing them on the fly with one function (that's also what was making everything update soooo sloooooowwww). As soon as I get that solved, I'll probably add a shoot function for the hero (using the ball). At that point, I'll likely be all out of ROM in my main game bank, and will need to learn bank-switching to proceed with development. By the end, I hope to have the hero do the following: - Draw and holster his laser pistol (to switch between jumping and shooting) - Select items from an inventory screen and use them (keys, shields, gadgets, etc) - Tuck and roll to dodge things while on the move - Interact with non-enemy sprites and background objects when he stands on their active x,y position. - Die! It's a lot to jam in, but I guess the whole thrust of my experiment is, once I get my map array working the way I want, to write a little level editor in some other language to see if I can make designing this sort of game simpler.