Fort Apocalypse

Have been using Crimson Editor and it works pretty well. We could develop plugins for a more recent editor/IDE like Eclipse, but that is probably overkill as editing sprites and playfields by hand is not hard. Although there is something to be said for being able to draw freehand and/or easily make animations. Being able to import images in and convert them to playfields/etc. would be cool. And Composing music would also be a great thing to make easier through some plugin. Also think it might be cool if Fred were to decide that it would make sense to open source batari Basic (even if he still reserved rights to sell licenses which could definitely still happen - I don't know what the legal ramifications are to allowing open-source development of a product that you want to retain sole rights to ownership are, but I assume it is possible at least in some sense). But I feel lucky just that he is letting us use it for free now. It is pretty cool to be able to write 2600 games easily/quickly.

Scoring works in this version. Also window blinks before target appears (giving you some sense that you have time to shoot it). There are 2 strategies I've learned so far: * Impatient - just keep using button to move quickly and shoot as quickly as you can (this is tough) * Patient - wait on a side of the building for the target to appear (this may be best strategy in later levels) Seems like something is missing though. It is an addictive game until about 5 or 6 levels into it. Maybe I'm just not making it hard enough fast enough? Maybe a single target is too easy? Maybe it needs an enemy other than time? deltaforcesniper0.3.bas deltaforcesniper0.3.bas.bin

screenshots

Fully functioning game. Very loosely based on the description of the 1st Special Forces Operational Detachment - Delta (a.k.a. Delta Force) snipers as described at the bottom of p.116 of Inside Delta Force by Eric L. Haney (great book, btw). Move the target off the screen to view the four sides of the building that you are sniping (white=front, red=building's left or sniper's right, black=back, green=building's right or sniper's left). You must quickly find the target (randomly placed on one of the sides) and shoot it, which is not easy. If you don't shoot the target in time, the target moves and your life meter decrements (this symbolizes the amount of time you have to terminate the target). If you shoot 2 targets you get to level 2, 4 for level 4, etc. Targets move more quickly in later levels. You also can move and then press the button to move quickly (unless your target is locked on, and then the fire button is only for firing). It is a difficult game. Let me know what you think. Thanks to Michael for the randomization code!

Awesome! Thanks Michael, and thanks batari! Wish I had more time this afternoon to finish this game... Got to get set for tonight.

When I run this, all the black dots should turn red because of the randomization, but they don't. Have tried seeding the randomizer with other random numbers, but that doesn't help. Any ideas on how to get random dots to fill in all of the black dots here? Note that there is one randomized number I'm not yet using, but will. Note that if you turn: m = (room * 2) - 1 : n = (floor * 2) - 1 : pfpixel m n on into m = (room * 2) - 1 : n = (floor * 2) - 1 : pfpixel m n flip That is still only setting that subset of pixels even though it would seem as if it should set all of the black windows red. Thanks! deltaforcesniper0.1.bas deltaforcesniper0.1.bas.bin

Unfortunately the compiler is getting stuck in an infinite loop in the latest version of my code, so I'm stuck. Can anyone see what I'm doing wrong that might cause it to do this? waterskier1.4.bas

The following code appears to put the compiler (the latest version at least) into an infinite loop. Be warned that killing Crimson Editor won't kill the process (have to manually kill it, and it isn't obvious which one it is). compilerinfiniteloop.bas

I'm not sure about the ramp getting smaller (but it is doable, just may not look good?). You can see what the speed difference would look like in the current version by trying the different levels. I think level 4 (3 if 0-based) is a little too fast. I'm thinking slalom would be easier to do with increasing speed with since then it could become a matter of how quickly you could turn back and forth. Maybe I should add slalom. Think so? If so when should the skier jump and when should the skier slalom? (Maybe thats what the select switch would let you pick (jump or slalom?) or would it alternate throughout the game? Thanks for all of the ideas!

Try hitting select on the latest version above and letting me know what you think of color on the other levels. Will do my best to make it look like you like it. I want to do this also. Maybe I should reuse player0 sprite for boat and skier so I can avoid flicker. Have you tried level 3? What if I kept level 3 difficulty of it and made you have to pick up 2 skis and then the boat would pick you up? I just can't get rid of the shark screen unfortunately. Emotionally attached. I'll be glad to hear about way to improve it though, including ways to get points. I thought before it might be good to be able to whack the shark with a ski after you pick one up? I definitely want to increase difficulty as game goes on. I'm not sure the best way to do that though since there is no sense of level completion. Maybe I could add a life bar on right that could be the distance to home/marina. Thanks for the feedback, and I'm glad you like it!

Added an "avoid the jetski" minigame (is somewhat random whether you get that or shark) and basic boat and jetski sound (no other sounds yet), although sound needs suggestions/work. waterskier1.3.bas waterskier1.3.bas.bin

this version has a boat that picks you up. you have to grab the handle without getting run over by the boat. changed colors a little. waterskier1.2.bas waterskier1.2.bas.bin

First version with fixed compiler and attempt at bad sunset colors (help needed if you have ideas!). Thanks for the link! waterskier1.1.bas waterskier1.1.bas.bin

Aha! Impaler found that kernel fix that batari posted a few months ago here. Looks like we all should be using this... http://www.atariage.com/forums/index.php?s...t&p=1314595

I've attached a .zip file containing the updated std_kernel.asm and std_kernel_SC.asm files. Michael That's awesome. Thanks, Michael! It would be great if there could either be an official pinned patch thread where people could link to topics that included patches to the kernels (so patch and discussion would be contained in other threads) and it would be great if the best of the patches could be hosted on the batari basic site with links to the atariage forum threads that discuss the patches. Same with minikernels, etc. I'm having trouble at the moment finding the fix for pfcolors that Maus said was here in the forum somewhere so I thought it might be good to mention this here.

Do you have the link to that topic? Am having trouble.. tried finding it in search, paging through bugs, and in bugs thread with no luck. TIA

Faster gameplay depending on level. Dot become "ski" that you have to pick up for points or jump for points. waterskier1.0.bas waterskier1.0.bas.bin

Here you go... old school colors (except for top which I need to figure out) and ramp. waterskier0.6.bas waterskier0.6.bas.bin

screenshots...

bug in after 3 dies fixed (wasn't calling return enough). life counter used when hit enemy (which makes it a little too hard to fall for now). Shark minigame added (try to fall to see it- if you survive you ski again). waterskier0.5.bas waterskier0.5.bas.bin

Has colors now, but kind of looks bad because I need to figure out how to get around the pfcolors bug that doesn't set colors correctly. If anyone knows how to fool it via asm or some other fix, please let me know. The levels are different now since I'm limiting playfield colors for time being. waterskier0.4.bas waterskier0.4.bas.bin

Link to the easter egg Michael found about shakescreen since it has a code sample for how to shake the screen.

In addition to examples, there is a great reference here that batari wrote and Random Terrain maintains: http://www.randomterrain.com/atari-2600-me...c-commands.html

Man! Just looked at that code and I'm really intrigued about how the sprites were shared by pointing player0 and 1 at same memory locations. I'd have to stare at it for much longer before really getting it though. Would be nice if there were something baked into bB that allowed for p0 and p1 to easily share player definitions, but it is pretty cool that you can do all of this stuff. As for the Combat DX game itself, minus all of the many, many playfields available, it could benefit (maybe) from use of the 2 player score and life counters, and add something to the select menu to allow you to choose desert/arctic. But I also like Michael's split screen idea. Also, would be cool to have 2 tanks per player like Armor Ambush (pull back on joystick to change player).

Try the setup for Crimson Editor. I think most of us are using that. It may no longer be actively supported, but it works well, and things like the sprite editor, playfield editor that are in 2600ide, etc. are available via online resources listed here: http://www.randomterrain.com/atari-2600-me...c-commands.html