jrok

Has anyone come up with an Atari-friendly way to calculate (or, simulate) arctangents for use in bullet angles, steering and the like? I assume that you'd have to build the function from scratch, but I can't imagine that the math would arrive on time. Would it be a better to write some sort of pseudo-radian function to determine the angle of a bullet, where the bullet has 16 or so angles to choose from? Thanks, Jarod.

New Update: I've been toying around with my alternate level style and decided to post some progress. When you reach the third level, instead of seeing the emperor's face and the two gladiators, your gladiator appears in the center of the screen. When you press the button to start, you are chased around by two monsters. There's no real gameplay to speak of for this level-style yet, and if you press the fire button after a few seconds have passed, you will automatically move on to the next deathmatch. The only thing that's partially done for this level is the movement behaviors for the two monsters. I'm still sort of trying to figure out how I want to shake things up with this level. I'm leaning towards a lock'n'chase sort of gameplay, where you are stripped of your laser gun and have to defeat the monsters through some other means, like leading them into traps. If I'm able to work this out, I think that a monster level will occur every 3 or 4 matches, with swifter/smarter monsters and deadlier playfield hazards. Cheers, Jarod. Circus_Galacticus_m12_d15_y08.bas.bin

Hey, thanks!!! Jarod

I think it can be done with bB's multisprite kernel: player0: pac(batari)man player1-2: four ghosts (w/ 30 hz flicker) player3-5: 18 pellets (w/30hz flicker and NUSIZx) missile3-5:18 pellets (w/30hz flicker and NUSIZx) Cheers, Jarod.

Thank you for the detailed explanation. I have a couple of of questions. I'm a little confused about what's going on behind the scenes, here. When we compile a program that contains a macro, does the the compiler tally the total number of calls and write them into ROM? I assume one shouldn't do even do this, but how would the compiler handle a macro in a looping or iterative statement, such as: dim my_var = a macro my_macro missile0x = {1} end myLoop my_var = my_var + 1 callmacro my_macro my_var goto myLoop Also, I'm a little confused by the use of "{#}" in the below definitions and calls. What happens when the program executes "callmacro backgroundcolor {2}." Once again, thanks for making all this a little easier to digest. Cheers, Jarod.

I totally agree. In fact, I think I wrote something similar about Demon Attack and its ingenius use of color in my AA blog. Since the A2600 graphics capabilities are so spartan, I think use of color becomes incredibly important. And in Demon Attack, not only was the use of color aesthetically pleasing, but it served the gameplay mechanics as a sort of visual cue for progress. As you progressed through the game, you didn't have to "count levels"; it was like your eye would almost subliminally track colors and shapes that your brain would use to gauge your performance. For that reason, I still believe that Demon Attack was graphically superior to most RGB-raster arcade shooters of that day, including some of my all-time favorites like "Galaga." Great point! Jarod.

Well, sir, that almost sounds like a challenge! Thanks for the frank answer! Although I'm still unclear if it's considered taboo to post a bB game to the In Development section. Cheers, Jarod Kitchen

This all sounds pretty great! Where can we find this new build? Thanks, Jarod

I'm very new to this hobby, so I've spent a lot of time recently browsing old forum threads and trying to learn a little more about the dynamics of homebrew community, particularly when it comes to batari Basic programming. When I first got the itch to start programming for the 2600, I started by reading alienbill's website and trying to get my feet wet in Assembly. It was a little daunting, so when I started reading up on the bB compiler's capabilities, it sounded like a lot of fun as well as a way to prototype and to gradually teach myself ASM by studying the output. Its also been really helpful to read the kernel memory maps and to examine and customize some of the batari kernels and mini-kernels. I doubt I'll be programming anything remotely fun or even functional in pure ASM anytime soon, but bB has been a great beginner's tool for me to at least grasp the fundamentals of the TIA. That said, programming in bB has been really fun for me, and I've noticed a lot of bB games that folks here are developing that seem quite good. At the very least, it seems that many people are putting a good deal of thought and work into these games. And in general, everyone in the A2600 programming threads seems to be supportive of the notion bB could attract fresh blood to the community and the system. But over the last couple of days I've come across a couple of threads that seem to sort of disparage or in some way stigmatize Atari games that are written in bBasic. They aren't nasty or anything, and I absolutely understand the reasoning behind these opinions, given that simple love for the console is very different from loving the challange of programming for the 6502. That said, I decided to get into this hobby to have fun and talk about Atari games, not to be made fun of for having a smaller brain and/or not knowing the rules... I have a wife for that . So when I saw AA's list of games in development, I was curious whether or not it would be considered presumptuous or "bad manners" or something for those of us working on bB games to post there, even if it was one we were very serious about completing. Despite the number of titles people are working on, the list seems quite small, and - at least, from the descriptions and screenshots - it doesn't appear that any of them are being composed in bB (although, I suppose its possible they might have been prototyped in it). Does the community at large - programmers and collectors and fans - make a firm class distinction between ASM and bB games? Honestly, It's not that I have a fragile ego or anything, but I hate being "that guy" at the party who just doesn't "get it," and who everybody laughs at behind his back (like I said, already got a wife... ) Cheers, Jarod.

The reason in adding it was for this, not to completely and accurately emulate how a real system would look (although I'm not opposed to improving the emulation of it, if someone has suggestions). Well, that's okay. If I wanted complete and accurate emulation, I'd have to see a half empty can of Meister Brau sitting next to the TV antennae, and hear my grandad shouting "Again with the bleep-bloop-bleep-bloop?... turn that [email protected]&! off and go outside, already!" But honestly, the main reason I was asking was because I don't have the hardware to test my programs. That said, it might be kind of cool to have a Open GL raster mode that tried to mimic a CRT monitor in a side-by-side comparision... maybe by including an optional Open GL overlay that tries to simulate the old light sweep and shadow masking? Given that the world has pretty much got both feet in LED and plasma displays these days, being able to reproducing something close to the old CRT might add a nice nostalgic touch to the experience of playing some of our favorite old games on new sets. Cheers, Jarod.

When you say it seems to work best, do you mean it's seems to be the best "eyeball" approximation of what it would look like on a CRT, or that it provides the best looking display on an LCD? (or both??) Thanks again, Jarod.

These instructions are fine if you want to always use the phosphor effect with that particular ROM. But if you want to toggle it in real-time, you can use the 'Alt-p' key combo. This won't save the setting, but will dynamically switch between the modes while the game is still running. Thanks, stephana, I didn't know that. BTW, do you have any insight on any analog metric that the Phosphor setting is based on? I used to be somewhat well-versed in the way the Cathode Ray Tube works, but I'm fuzzing a little on the way that phosphors were categorized/characterized. I know it had something to do with transmission length, and that there was variance depending on the chroma signal and the type of shadow mask it was using, but my memory pretty much fades to black after that. Obviously there's no substitute for testing on a real CRT, but I couldn't find any documentation on this particular feature and I'm kind of curious. Thanks in advance, Jarod.

Thanks man, I will! Cheers, Jarod.

Thanks!!! There's still a couple more things I want to do and some polish I want to add before I would consider it complete. I'm about halfway done coding my alien wildlife "survival" stage, and I'd like to add in one more level type and a two player mode. I'm also trying (and, mostly, failing) to write a custom score kernel for the game, so I can have a H.U.D. that shows your score, the number of shields you have left and a timer clock for the survival stages. I also want to add a hires title screen and some music. At that point, I think I'd be confident enough to call it "done" and release the game and the source. As for putting the final game on cart, I would really like to try to do that. The main obstacle I think would be the cost per cart. The cartridge would need to contain eight swappable banks and a SARA chip, which might make it too expensive to make by myself. But if there's a way to do it, I definitely will. Cheers, Jarod

Good idea, but how about this. Just have NOTHING but the dude in the middle during the opening sequence.. have the two guys running around randomly shooting? That's a good idea. I think I might do that. And then when you click, maybe the playfield fades in. Thanks. I'm sure this is an incomplete explanation, but in my understanding of it the phosphor effect is supposed to mimic the way that light from the TV's scanning beam would linger in the material that coats the inside of the standard CRT TV screen, creating a sort of glowing effect. So the idea is, when the next beam comes, there's still a little light from the last beam left, which would have the visual effect of "blending" the two consecutive frames. From an Atari programming standpoint, I guess its mainly important for those of us who are only using a single display kernel and need to flicker things to get more of them on the same scanline. Computer LCD screens don't use light in this way, so Stella and Z26 have phospor settings that attempt to show how the game would look on a regular TV. When I tried running my program in Stella without phosphor turned on, I saw the strange color change effect you were talking about, but hopefully it won't look like that on a TV screen. If you want to try it with phosphor on you could follow the instructions & screenshots below. The only thing I'm not too sure about what the setting is actually measuring. The real "phospor effect" is analog, so when Stella sets phospor to "77" I assume that means that the frames are 77% blended, but I have no idea what that translates to in terms of actual old fashioned TV screens. Cheers, Jarod. Instructions: - Click once to highlight the game - Click Options - Click Game Properties - Click Display - Set Phosphor to "Yes"

Thanks so much for this. Out of curiousity, do you think this kernel could be adapted for a bankswitched or a Superchip game... or, maybe even both? Cheers, Jarod.

This is great! The game plays really well and has enough variation to stay interesting. I think the game is very good as is, but some people on here had some cool ideas. I think this is a pretty neat idea, since you don't have to draw an additional sprite for it. Maybe it could act as a sort of bonus multiplier when you catch it, or hand you a big chunk of time back. Then, you'd have moments in the game where the clock is ticking down, and you have to decide whether to go for the easy catches, or gamble on the rare fish for a big payoff. I like this idea too, since it would give you the chance to rack up big scores if you're quick and saavy, and still increase the challenge for more advanced players. One other idea I'll throw on top is, what if when the player presses the button at the moment he collides with a jellyfish, he can perform a double-jump, almost like he's hopping off the thing as he catches it. It might provide another level of "checkers-like" depth for savvy players, who could time and plan their jumps to get mult-fish bonuses. On the other hand, I think its damn fine work just as it is. Great job. Jarod.

Aha! That works pretty good! Z26 has a phospor setting too, but only captures the current frame, not the blend (unless I'm missing something). Thanks! Jarod.

I just realized I never made any screenshots for this game, so I did a few: It was a little tricky. Since I'm doing the game with 30hz flicker, I had to cut and paste elements of some alternating frames. If anyone knows a good way to take a 30hz snapshot with Z26, please let me know. Cheers, Jarod.

Thanks for the feedback. Yeah, it's because he's transparent, and part of the room is showing through. I don't much like it either, but if I don't flicker him, I'll run into trouble in other things I'm doing. Maybe the center portion of the room doesn't appear until he disappears? I'll try to figure something out. I'm not seeing that bug. Are you using Stella or Z26? If it's Stella, do you know if the phospor option is turned on or off? That's a bug for sure. I'll work on it. Cheers, Jarod.

Thanks!!! That make me feel pretty good because I really worked hard on the sprites and the animation in this game. Particularly tricky was getting the up and down animations to function well, since they had to display 16-frames within an 8-frame animation routine. Originally, I actually had 8-directional animations, including up-diagonal and down-diagonal loops, but it was just too much of a ROM-hog. I have a few more sprites planned, but their animations might not be as complex due to the same ROM constraints. Cheers, Jarod.

New Build: Eliminated external walls: After struggling to find the cycles for them, I decided to just eliminate them altogether. The TV screen makes a good enough border. Due to the limitations of the batari playfield, you won't be able to "shoot" in the extreme left and right portions of the screen, but I'll try to figure out some other gameplay element to explain that (Yars-style "safety zone"?, refuel point?) Expanded hittable areas: I still want there to be a bit of precision aiming in the game, but I expanded the hittable portions of both characters. Basically, you should be aiming either dead-center or at the head. Added "hit-points": The player must be hit three times to be killed. The enemies start out with a single hit point, but gain additional hit points as the game progresses, up to a maximum of six. Now that each player has two hittable regions, its conceivable I can make it so that head shots cause more damage than body-shots. "Evil Otto": If the match goes on long enough, the Emperor's face reappears in the center of the screen. Right now it's still a sort of placeholder test, but ultimately he'll shoot a few bullets at you when this happens. The time that needs to elapse before the Emperor appears decreases as you progress through the game. Revised sound: I've been tinkering with the sound effects a bit, particularly the laser beam effect. Revised some playfields: The idea is to make you work a little bit for good shooting angles in the beginning of matches. I'm definitely going to have to playtest this idea a lot. Ultimately, I'd like part of the challenge to include how quickly you can dispatch your foe, with bonus points earned for fast victories. Thanks for all the help and good wishes so far. Cheers, Jarod Circus_Galacticus_m12_d7_y08.bas.bin

Thanks!!! It's funny you said that about the sounds, because it's something I haven't been happy with and have been experimenting with in this next build. But now that you said that, I may go back to the original laser sound. That's a pretty great idea. I'm trying to figure out how that might work. It would be pretty easy to make it all grow back at once, but in order to have it grow back a bit at a time, I guess I would have to figure out some way to store the values of destroyed pixels, and I'm running low on variables as it is so I'm not sure how possible it is. I'll try though. I've revised the collision detection again to expand the hittable area, although you still have to aim fairly careful. The idea is to aim for the dead center of the sprite, or the sprites head. I'll explain more when I post my next build in a minute. Another great idea. I think I have enough room to include some hi-res screens. Music is another thing all together. Not only am I daunted by the amount of work involved, but I also know don't have the best musical ear around. Thanks for the advice, Jarod.

That's one of the things I need help on. For collisions, maybe you could track each character's playfield position, which you can do every game loop (or in the vblank) no matter which sprite is flickered. When the jellyfish's playfield x and y match Bob's playfield x and y, treat that as a collision. Cheers, Jarod.

I really like this game a lot, particularly the movement of the jellyfish. Also, not having Bob get stung seems in line with the light-hearted nature of the show (which, I admitedly don't know much about). One thought I had was what if, instead of getting stung and dying, Bob just gets stunned and loses time when he doesn't touch the jellyfish from below? Also, maybe you can work in some kind of a point bonus for catching more than one in the same jump? Great job so far! Jarod.