Fort Apocalypse

Player 3 disappears when using multisprite kernel and you move it too far to the right horizontally. If you move it to the left, it is no problem. Wierd! Attached is bin that shows this bug in Stella. (Who knows- maybe it is a stella problem?) Leave paddle emulator off (so paddles all = 0) and try the following (this is not a working game - for now it is just a demo of the strange behavior). I actually get it while in both (r/l) paddle mode (but for some reason no paddles work for me still). Also, flickering seems to be bad even though the players aren't on the same vertical scan line. If you have an answer for that too, it would be much appreciated! ultindy500_0.1.basultindy500_0.1.bin

That's an excellent point, and the command line option is good to know. This was a much requested feature a few years ago. Since I didn't personally develop ROMs with Stella, the thought never occurred to me to be able to change properties dynamically. To get around this, some people were even ingenious enough to create a script that recalculated the new ROM MD5 and rewrite a new stella.pro file, just to get the ROM to recognize the previous properties. I can see that being a PITA. I'd like to think I've learned my lesson on that one, since damn near everything in Stella is now configurable from both the commandline and UI Thanks, Michael and Stephen! Will give it a try!

Thanks, Michael. I was hoping there was some cool trick to limit the flicker, but that's just me wishful thinking! It's not a big deal, really. I just wanted to be able to start all of the cars off on a vertical line (actually 4 cars, a flag, and the pitstop are all on the same scanline, but the pitstop (player 1) does not flicker and the rest flicker badly). I'll start use imaginary horizontal start/finish lines instead of vertical ones.

Why not ask atariage if they will just add size to the list of attributes in the rarity guide?

Would be great! Just posted a topic to AA web guys linking back to this topic.

It would be really cool to have an AtariAge wiki we could post info about 2600 programming (especially in batari basic) into, along with homebrew games, etc. See discussion by Batari, Michael, etc. at bottom of first page of this topic for more thoughts on this.

I know this is mentioned as a problem, but is there any trick I can use in bB to limit flicker when I have 5 sprites (using multisprite) in the same vertical scanline?

Having trouble getting paddle emulation to work... (all paddles read as 0- can't even get first paddle to work). The "argument" line in crimson editor for running stella.exe I have set to: -bc Paddles -paddle 0 -grabmouse 0 -showinfo 1 -p0speed 20 $(FilePath).bin Does that look right for mouse emulation? Has anyone gotten paddle emulation via mouse to work when starting stella.exe from crimson editor, and if so could you post your argument line from crimson editor tools -> preferences -> tools -> user tools? Am I going to have to buy a stelladaptor and paddles to get this to work?

It would be really helpful if bB had a convention to address 4 bits (or even 2) as a number. While you can still accomplish the same with a lot of bitwise logic, it seems like it might be faster to develop if you could address 4 or 2 bits in a var at once as if it were a short and really short int. Not sure what the convention would look like to address these vars though, and I'd bet it would be extremely hard to implement.

Lately I've been thinking this is the new Atari plan for spring 2008.

Any suggestions? I'm not sure where else to go with it other than maybe trying to reuse player0 and player1 sprites for even more sprites (but that might be too busy), changing the behavior of player0/1 sprites... at a creative loss and I know it is no where as good as it should be. I don't know how to reuse player0/1 sprites as actual player sprites without getting really crazy with collision detection (like did player0 collide with player0... huh?)

This might be a good candidate for using multisprite kernel also. That way you could have up to 5 bananas falling at once and maybe add some things that you have to avoid. Eat fruit, avoid candy. Or maybe it could be Atkin's where you avoid carbs.

Check out what I did in Insane Painter. It defintely is not the optimal way to determine playfield collision with a ball/missile, but it seemed to work. Note there is some really funky stuff going on in it (not that is it complicated, just a little convoluted). Specifically some funkiness is that once the missile1 comes on the screen the ball reacts to the missile collisions which was not originally intentional, but it added some chaos to it that I think made it a little more fun. If you forgive it not having any dim statements of note you might be able to reuse the pfread parts of it. Note also that the offset/division to determine pfread and pfpixel locations is not perfect, but was close enough for me. Here is some sample code from it for collision (I think batari or michael or somebody came up with the original divide by 4 / divide by 8 thing to find the playfield x,y location, but they had an offset that it didn't seem like was needed for a small ball- it was probably for a player sprite): doball if d < r then d = r : f{0}=1 if d > 145 then d = 145 : f{0}=0 if e < r then e = r : f{1}=1 if e > 91 then e = 91 : f{1}=0 if f{0} then d = d + r else d = d - r if f{1} then e = e + r else e = e - r if collision(ball,playfield) then m = d : n = e : gosub ballcl ... ballcl if m > 16 then m = m - 17 m = m / 4 n = n / 8 if m < 31 then m = m + 1 if f{0} && pfread(m,n) then f{0}=!f{0} : pfpixel m n off if m > 1 then m = m - 2 if !f{0} && pfread(m,n) then f{0}=!f{0} : pfpixel m n off m = m + 1 if n < 10 then n = n + 1 if f{1} && pfread(m,n) then f{1}=!f{1} : pfpixel m n off if n > 1 then n = n - 2 if !f{1} && pfread(m,n) then f{1}=!f{1} : pfpixel m n off n = n + 1 rem for t = 1 to 3 : pfpixel m n flip : drawscreen : next pfpixel m n off rem this sets the a var I was looking at to do a sound s = 17 ... return ... in the gameloop... rem sound for the collision if s > 0 then s = s - 1 : AUDV0 = s : AUDC0 = s : AUDF0 = s : AUDV1 = s : AUDC1 = s : AUDF1 = s

Great game! There is a way to check for higher score. Look at Random Terrain's Batari reference. Specifically copying the relavant part of that doc: I think I did pretty well for the first try on easy level: (my sad reflexes couldn't get me any higher)

I'd say post it. If you are worried you could include a BSD-style license in the top to keep people from taking it and making a professional product out of it- but I seriously doubt we have to worry about that here. The community would shun anyone who did something crappy like stealing a game and selling it, I would guess. I was thinking recently though of a few ideas: * A sourceforge project called "Atari 2600 Batari Basic Games" (or similar) that could contain a lot of different games. If you guys aren't familiar with subversion source control it is way easy to use (much better than cvs) and sourceforge now supports it. For example to get the code the very first time you use: svn co (url of your project) to update your code you do: svn up to commit (save version) of your code you use: svn commit and there are GUI's like TortoiseSVN (I think that is the name) among others that make it simple to use from windows explorer/filesystem like interface. * Someone like atariage hosting a wiki for batari basic tips and tricks. The forum is way cool, but it is a pain to find stuff on. While I like the scavenger hunt aspect to finding info, a wiki may be better. MediaWiki is free so would be a good choice and it is versioned, so even if someone messes it up, you can bring the old version back.

This thread is way cool. Can't wait to try the game! This kernel looks like it would be great for doing some sort of strategy/simulation game also, or board games (chess/checkers/chinese checkers/maybe even mancala!). I'm probably getting way ahead of myself.

Curtwatch: kind of like Baywatch, but without Pam or the Hoff

4 player paddle racing game (a little similar to Indy 500). 4k. Works much better now! Playable, but still mostly testing the steering and driving as proof of concept, so if you have paddles let me know how it drives. Michael designed the pit stop (now I just need to implement a need for it). Curtis did the 4 player colored lap counter. Thanks to Michael, Batari, Curtis, Lord Mike, and everyone else for the advice. Notes: * I don't have paddles, and playing it in Stella is difficult. I have a feeling the steering part still needs work. Maybe if you have paddles you tell me whether the steering is too rough and maybe even suggest what is wrong and how I could fix that. * You can move the cars around in any of 16 directions using the paddle buttons as accelerators. * The player icons are now tied to direction * Has sound for all four engines * Has lap count and working lap detection * Has fuel gauges (lines to left and right of playfield). When fuel runs out, car is slower. * Direction works better than previously * Real Indy car sprites (thanks to batari) See below for latest version (0.8 ) ultindy500_0.8.bas.bin ultindy500_0.8.bas

Sorry to see that the last post is two years ago. A 4 player Indy 500 would be great. Wonder if it could be done with 4 paddles instead by just changing the way that the controls work a little. Hmm... this would be easy in bB with multisprite kernel. Maybe I'll do it!

Really cool game! I really like the cave designs, the player design, some of the enemies are scary looking (like the cobra) and others are hilarious looking! (I mean that as a compliment- it's fun!) I kind of get the feeling that the character is delusional (maybe he hit his head during the cave-in?), because it reminds me a lot of the pink elephants part of the movie Dumbo when some of the enemies appear. Some ideas (if you can still fit them in): * Would be nice if there weren't so many pink enemies (maybe throw in some other colors?) * Would be nice if the enemies were more colored in (so they don't look like ghosts) * Would be nice to have multiple enemies per screen * Would be nice to throw in a pit or two that you have to walk around or you fall into (and die?) with some E.T.-like falling animation would be nice * The flashing walls rooms might look nicer (maybe) if they were a slightly changing colors of off red to make it look like lava or really hot rock somehow. The flashing just makes it look too spacey to me. Super cool stuff! Haven't found the cool parts yet!

If you're interested, this is the game I was working on: Insane Painter. Some say it is a cross between Breakout and Surround. I never played Surround though. I spent many a night on it, and the code still looks like crap. But it was fun!

When it makes the awful noise it usually means it didn't compile correctly. I'm no expert, but for the time I have been programming bB so far, I'd recommend Crimson Editor. I don't like the way it handles block selections of code, but other than that, it is pretty good to just be able to ctrl+1 (compile) and ctrl+2 (run). If you follow the instructions on the Batari site, it will get you up and running in no time. Don't worry about the stuff you would miss from 2600ide like the sprite editor and so forth. There are online versions of that with much more functionality. (See this) The main things to remember when starting development are: * Read this and refer to it often * Make sure you pop as many times as you need to within a subroutine before calling goto from it (two levels deep = pop : pop * All lines MUST be indented one space EXCEPT tags (or line numbers) and the "end" after defining a playfield/sprite. * Do what you can to not address things that have range maximums < 255 (for example, sound TIA registers, pfread, pfpixel, ...) * When the page above refers to a hex with an "x" in it it doesn't mean you should use an "x" (a copy and paste error I made which had wierd results and still compiled) * Lots of stuff compiles that maybe shouldn't (it is very relaxed), and you won't get nice error stacktraces (ha!) * If there is no goto or return at the end of some code you are executing it will just keep running to the next stuff and even off the page! (and into the beyond!) (another obvious thing that I missed at one point) * Be prepared for some pretty crazy stuff * Don't if within an if if the first if has bit conditionals, and be careful with elses in ifs after ifs (it is an else for the first if not the second one I think) * You CAN reuse code and subroutines... be inventive! For example if there was a subroutine I wanted to work on x,y and also e,f I would reference m and n in the subroutine and then assign before the gosub like m=x : n=y : gosub sharedsubname for the first scenario and m=e : n=f : gosub sharedsubname for the second scenario. There are also temp variables (see the link above for details). * Unless you are dividing by a power of 2, you must put include div_mul.asm at the top of the code somewhere * set kernel_options no_blank_lines gets rid of the blank lines in the playfield, but uses missile0 to do it * (when using const pfscore=1) pfscorecolor overrides playfield color * Even if it scares you a little, use bits and remember binary. It is your friend. * There are only 26 variables (?) a-z (not counting temp vars) I think (check the doc above, but that is all I use) * By default you only have 4k. It ain't a lot and you can use more, but it is more fun to try to work within it * If you get past the frustration, it is a heck of a lot of fun to try to develop within the boundaries of the system, even just in bB! Also stuff I learned about posting games to a thread: * Under manage current attachments click the X next to a file you upload to delete it so you can put another one in the same post, then you can always keep the latest version in the top post of the thread. * I started saving the file with a version number in the filename, that way people know it is updated. * It won't let you attach an asm file for some reason * Use F12 to take screenshots in Stella and then post the pngs to your thread Good luck and have fun!

Ping... anything from the rumor mill on what is going on at Atari? Curt I know that you aren't allowed to say anything... but would be nice just to know you exist and still have a job.

Hey, Hoping someone might have a suggestion. I am working on a game, Insane Painter, in which the ball is being used, missile0 is being used to get rid of playfield empty lines, missile1 is being used (like a ball), and player0 and player1 sprites are being used as enemies. So since the game was about "painting" the playfield, I was just flickering part of the playfield to indicate the two "good guy" players, but I'd like to use player sprites in place of them if possible to do this and still retain the two "bad guy" player sprites that appear later in the game. Restrictions: * I don't think I can use the multisprite kernel because the playfield can't be mirrored in this game. * I think collision detection will need to be separate for each "good guy" player, and will need collision detection to know when each of the two "good guy" players has been hit by ball, missile1, or either of the two enemies (which are currently player0 and player1). Any ideas for how I might be able to utilize sprites for both good guy players and bad guy sprites and still be able to handle collisions between the two? Thanks!

With thanks to Batari and SeaGtGruff I got past the subroutine bugs and it seems pretty stable, and pretty fun (at least to me). Please try it out and let me know what you think! Thanks! insane_painter_0.8.basinsane_painter_0.8.bas.bin