Fort Apocalypse

Something else that would be nice is an example of how to handle sprite2-5 collision detection when using multisprite kernel. This is how I just did it, but it would be nice if someone could post what they think to be the best solution: findclosestp0 closestitemnum = 0 templowdistance = 255 tempitemx = shovelx : tempitemy = shovely : tempitemroom = shovelroom : gosub gettempdistp0 if !p0inventory{0} && tempdistance < templowdistance then templowdistance = tempdistance : closestitemnum = 1 tempitemx = gunx : tempitemy = guny : tempitemroom = gunroom : gosub gettempdistp0 if !p0inventory{1} && tempdistance < templowdistance then templowdistance = tempdistance : closestitemnum = 2 return gettempdistp0 if tempplayerx > tempitemx then tempdistance = tempdistance + (p0x - tempitemx) else tempdistance = tempdistance + (tempitemx - p0x) if tempplayery > tempitemy then tempdistance = tempdistance + (p0y - tempitemy) else tempdistance = tempdistance + (tempitemy - p0y) if tempitemroom <> proom then tempdistance = 255 return

Thanks. I wonder if no paddles with the multisprite kernel will change with the next update. That would be great! Curtis said it wouldn't be possible to hack it with the current multisprite kernel in this post. But if the multisprite kernel could be changed somehow to allow it, it would be awesome.

A few I learned that weren't on: http://www.randomterrain.com/atari-2600-me...c-commands.html for bB 1.0 were: Paddles: * there is no way to use paddles with multisprite kernel (according to Curtis it isn't even hackable with the current kernel) * to check paddle button 0, use: if joy0right ... * to check paddle button 1, use: if joy0left ... * to check paddle button 2, use: if joy1right ... * to check paddle button 3, use: if joy1left ... Hacks: I was shown by Michael that you can get 12 rows of vertical resolution in the playfield with the regular kernel by doing the following immediately after defining the playfield: pfscroll upup : pfscroll upup However, the caveats are (1) I'm not sure that it continues to work if you mess with pfscroll some more and (2) if you redefine the playfield (even if you are just setting it again to what it is currently) you should NOT call pfscroll up : pfscroll up, otherwise every other time the playfield AND score will be shifted up a bit. To get around this, I was told (and just tested this) that you can just do pfscroll up : pfscroll up once after the first playfield definition, and then set a bit and check it whenever you redefine the playfield so that you won't call pfscroll up : pfscroll up for subsequent playfield redefinitions. Example: (be sure to define some variable up top, for example I've called it "myvariable")

Ok, here are the ideas I've had so far that I'm going to try to implement. Let me know what you think or if you have other ideas: Items: * Shovel - can dig away playfield in some (brown dirt) rooms * Gun - shoot enemies in the direction you are moving * Magic item - not sure they purpose of this yet but will involve sound and flashing background maybe. Maybe it opens up portal to void? Inventory control: * Press button quickly to use item * Hold button to drop item * Can exchange item with another item just by touching other item * Second player can take your item Rooms: * Open rooms * Mazes * Dirt room you have to dig through * Void - completely empty rooms where there may be lots of monsters and scary background sound Non-inventory items: * Transporter/entry point to void (both players must touch in 2 player game) * Doors that aren't always open * Painful flashing walls Monsters: * Regular Adventure dragon * Room filled with baby dragons * Floating eye * Big dragon * Big floating eye Goal: * Retrieve something besides a chalice? * Return home? That's all I've thought of so far. No idea yet how much will be doable.

Woohoo! I figured out how to handle two different items. There are now a shovel and a gun in two separate rooms. You can hold them, switch them around by grabbing the one you aren't holding. Did this by checking proximity to player1 among other things. Man that was fun! 2padv0.2.bas.bin2padv0.2.bas

And yet another version that has the ball as the second player for now. The crappy AI is there just to show you how the second player could interact. Unfortunately you can't resize the ball's height in multisprite kernel, and I can't use one of the other player sprites without losing easy collision detection. It might be fun playing the dot though. Could fit through tight spaces but you just move slower (to give it a handicap). 2padv0.1.2.bas2padv0.1.2.bas.bin

Here is a one player version that shows how I'm thinking an object can be carried simply. It doesn't work as smoothly as Adventure does it though. 2padv0.1.1.bas2padv0.1.1.bas.bin

2 player adventure game in bB. Now playable by 2 players, and you can win! Return the cross to the dark blue castle, but don't get trapped or killed by a dragon or flying eye! Find the wand to teleport or the wand to shoot dragons and eyes. Suggestions are all welcome! (Especially those that can help me reduce the code size- trying to keep under 4k). 2padv0.5.bas2padv0.5.bas.bin

Good idea! I think I'll do that. I was thinking at first maybe pfscroll upup had to do with the other playfield collision detection bugs but it didn't.

You might also want to add a title screen and sounds/music. Also you could use Curtis's minikernel for multiple scores and allow a two player game. And some dice transitions might be nice (maybe you could use pfscroll, pfvline, pfhline, and/or pfpixel to do transitions like having the dice scraped from the table or having them evaporate.

Curtis, Can you look at the following code and tell me why playercolors can be set in the racetrack screen but not the main title screen? Thanks! ultindy500_0.3b.bas ultindy500_0.3b.bas.bin ultindy500_0.3b.asm.txt

Still having problems with scorecolors and collision detection though.

(double posted)

That is correct. When I remove that code the problem doesn't happen anymore, but since it is a hack to reduce the vertical resolution of the playfield, I also can't use as much of the playfield as I could before. I reduced the playfield by one block after removing that pfscroll business and it works. Thanks!

Ok this is really wierd. If you move a car over the finish line enough to win (it is not that hard to do after you get the hang of it) you will win, and if you hit reset, the screen (including player scores) moves up by almost one playfield row. If you do it again, it resets back to the way it was. Wierd! Also playerscores for some reason can't have color set on them in the title loop as it doesn't appear to take for some reason. Not sure why. And of course there is the issue I said before about one player always thinking it is colliding with the playfield when it isn't and another player never recognizing it hit the playfield, even though the other two players detect collisions with playfield fine and there is really no difference in the code. It must be some strange timing issue I guess? At least I have an "interesting" title screen now... ultindy500_0.3b.basultindy500_0.3b.bas.bin ultindy500_0.3b.bas.asm.txt

Can anyone tell me why collision detection between player and playfield is not working correctly? For 2 of the players it works. The other 2 one never detects it and the other seems like it always thinks it is colliding even if it isn't. ultindy500_0.3a.bas.binultindy500_0.3a.bas

0.3a has commented, clearer code (thanks for the suggestion, Mike!) playfield collision not working correctly for 2 of the players. let me know if you can figure out why ultindy500_0.3a.basultindy500_0.3a.bas.bin

Thanks, Walter! I know there is a lot left to do. Please let me know if you have any ideas.

That was built off of my latest "snapshot" build version locally. I haven't released it because there weren't any significant changes from 0.8 (yet). If you have idea for how this could be a better game, let me know. I might even try to go down the road of player sprites, but is just going to be a pain since I can't use collision detection easily if I'm reusing player0 and player1 sprites.

That's because of this

Mike, Thanks for the suggestions! I'll definitely make sure I go back and add in some more dims and comments like you said. Let me know how you'd like the driving action to change (if you think it should react faster, etc.) and it would be totally awesome if you could try it out with real paddles and let me know (unless you just did- in that case I want to know every detail!).

That sucks. I'm assuming it is tied up in some legal issue. Edit: I just now found the thread where the Boulder Dash stuff is discussed here: Boulder Dash for the 2600. This is totally ridiculous, but at the same time I think it is super cool that this game has lived on.

Here's your problem Did you mean to set a there the 4 statements? From looking at the code I think you mean to set c.

It would be nice. I'm getting more careful now about the mouse so it isn't as bad. I wish I had 2 stella adaptors and 2 sets of paddles. I know what to ask my kids to get me for Christmas. Or should I just ask for a real 2600 with set of games and 2 sets of paddles, and a croc cart/etc.?

I fixed the problem. I was doing some messed up stuff in player definition. I was afraid that my code sucked. Now I know. I had started to add comments in the code, but then the code got so long, and it was easier for me to read it when it was short. If I didn't have to use temp variables for everything (if I had more vars) it might be easier to read. I should also just use dim to alias the temps to make it more straightforward, but I'd be afraid I or someone else might think that those vars actually store something that isn't temporary. Please let me know how I can better write it to make more sense.