Cybearg

Yes, I get it to compile as well if I define it as const COL_NTSC = 1 and then include the colors.h, but it doesn't seem to allow me to use any of the COL_XX definitions for anything. If I try to define something, it claims it doesn't know what COL_40 means. EDIT: Ah-ha! If I include colors.h like this: const COL_NTSC = 1 asm include colors.h end ... THEN it works and I can use the COL_XX definitions all I like. It just doesn't work if I include directly into bB, probably because then it's trying to read that ASM code in BASIC. Thanks for the awesome include, Omega!

It doesn't seem to compile for me. I tried including colors.h right in the bB file, then right after 2600header in an includes file, but regardless of where I put it, bB had a problem with the COL_NTSC = 1 line. It doesn't recognize the COL_XX colors, either.

That would be a problem. While it may work great for a larger game with space to spare, I'm tweaking my compilation, which consists of a ton of 4k games that are down to 0-20 bytes for each 4k bank. I'll have to go with Omega's style on this one, I think.

Well, another option would be to use the Color/BW switch to select your region so it could work on both. Just make that a universal thing, but I'm not sure how you could switch that during run-time without putting every color in a variable.

Is there a way to either: 1. Have a cartridge detect whether it is on a PAL or NTSC device and adjust its colors accordingly (but retain 60Hz), i.e. so that the reds for NTSC become an appropriate PAL red equivalent automatically? or... 2. In bB, program the cartridge to automatically replace the colors it contains based on whether you're exporting to PAL or NTSC (so I don't have to have a separate PAL and NTSC version of every project)?

Looks fantastic! Amazing what can be done when you know Assembly.

Thanks for the suggestion! I'll see if I can do that.

I expected there may be some confusion on these. It's not as self-evident as I would have liked. With Fix-it Felix, the indicators on the bottom-left of the screen shows which of the windows are broken on the row you are standing on. Move left/right to the gaps indicated (the indicator will turn red when you are standing in front of a broken window) and press joystick fire to repair it. With Flipside, you are competing with your fellow prisoner for the reward tokens, which regularly appear and disappear at various points in each level. The first to gain four pellets wins the round and receives bonus points. In single player, the game continues until all you lives are gone. In multiplayer, the game continues for a number of rounds, then the highest score wins.

There are older, separate versions of some of these games available in other threads: here and here, but those are older versions with fewer features. I don't have any plans to release the games as individual 4k ROMs.

It has a single player mode. Set your right difficulty switch to amateur and reset. And Heartbreak wouldn't have been possible if not for you, so, sincerely, thank you. If there is enough interest, they may well end up on cart as the compilation. The hardest thing is finding label artists. If anyone knows someone, please let me know.

I haven't been around lately. DID PR get a C&D? I thought it was still for sale. I think that the game concept looks excellent and very doable, and I'm pretty certain that the souls/level meter could be done the way you describe in your concept without too much trouble. Getting the numbers on the TOP of the screen may be more difficult--I'd have to talk to some people. I'd be willing to help with programming as well, if you need it.

Feel free to post any questions on how to play the games, since I didn't write up any kind of manual yet. I'm surprised there haven't been any yet.

It seems that Google has very generously celebrated Piñata's release with an interactive doodle on their home page. Good on you, Google.

I decided to release a compilation of the games that I've made in my half-year or so of working on Atari 2600 goodness. It includes updated versions of my four original games, as well as a fifth, new game. It should be 100% compatible with emulators and cartridges like the Harmony. Enjoy! Current version: 1.1.2 pinata_1_1_2_ntsc.bin pinata_1_1_2_pal60.bin Some of Piñata's features include: Five games, including arcade, action, and adventure: Heartbreak, Ping, Joyride, Fix-It Felix Sr., and Flipside. Hard modes for each game, set with left difficulty switch. Multiplayer modes for Joyride and Flipside, set with right difficulty switch. Driving controller support for Heartbreak. Full AtariVox save support for all games. Support for resetting high scores (hold reset and press joystick fire while on the title menu). Colorful game selection and credits screens. Ability to exit to title screen from games without toggling power switch (flip select and reset at the same time). Thanks to everyone at AtariAge who helped me out! For detailed credits, check the credits screen. manual_finaldraft.pdfpinata_105_ntsc.bin pinata_105_pal60.bin

Concerning the persistent world thing, I recently was working on a game where the player could move to another room based on a 5 byte array (to create an 8 by 5 map). When the player tries to move to another screen, it checks the array to see if the next bit up/down/left/right is true or false and allow movement based on that. Maybe I misunderstood the problem.

How do other systems like Coleco or NES do it? I assume it doesn't literally define all bounding boxes that the player could hit, right?

No pfread? Then how can one do decent collision detection?

That depends. Technically, you can do more with Assembly, but batariBasic makes things easy enough that clever programmers can figure out ways to make it seem like more is being done. Some things simply can't be done with batariBasic alone, while those who program in Assembly can make some amazing magic happen. Anyway, even if the games were programmed in BASIC and then converted to Assembly, converting it back to BASIC would be extremely difficult because there's no direct 1-to-1 correlation BASIC to Assembly. There are often many ways to achieve the same result in both BASIC and Assembly, so it would be a cryptographer's nightmare to figure out exactly what equivalent BASIC code was being demonstrated in Assembly without going through piece by piece, documenting every line of code, then laboriously breaking it up and interpreting it by hand.

Here you go! Again, I can tweak colors and stuff if you want any changes. By the way, I love the cute little astronaut character. His character design is brilliant and I really like how his jetpack works. Very neat! Moon.zip Moon.bas.bin

Here you go. Just drop the titlescreen folder into the same directory as the Moon.bas file. titlescreen.zip

Use temp card instead to save memory. You have 7 of them. Should be enough.

Oh, woops! Sorry! I'll post it when I get home. I thought something seemed missing from that file list.

I forget exactly how I cobbled together my combination of vbB, bB, and DASM, but I BELIEVE that I have that latest versions with fixes. Maybe someone with a better memory (read: bookmark history) than myself, such as Random Terrain, bogax, RevEng, or someone, can give you the start of the breadcrumb trail that is the long and complicated update history of bB/vbB For what it's worth, I have vbB build 1.0 (build 566) and bB version 1.01, though I know there are a bunch of obscure little fixes/changes that have been added beyond the official update numbers. Someone really should start a stickied topic that says exactly how to update to the latest version, and, ideally, keep that topic updated (on the first post) on how to keep updated.

This seems to work. Note that I had to make the game bankswitched 8k, because there just wasn't enough room remaining in your 4k game for a full title screen. I just tried an idea for the title screen, but I included what you need for the title screen editor if you want to change anything. Also, I noticed that your game jumped to 293 scanlines every time the player lets off joystick fire. It seems to be because of this line: if !joy0fire then player1x = 255 : player1y = 255 : player2x = 255 : player2y = 255 Likely because the x ends at 170-something and the y only goes up to 90-something, so 255 is an invalid coordinate and it must have taken a frame or two to reset the locations, causing the screen to roll. I changed that line to this: if !joy0fire then player1x = 0 : player1y = 0 : player2x = 0 : player2y = 0 And an earlier line setting all those locations to 255 to this: player1x = 0 : player1y = 0 player2x = 0 : player2y = 0 player3x = 0 : player3y = 0 player4x = 0 : player4y = 0 Everything seems to function the same, but now without any rolling, so far as I can see. Moon.bas.bin Moon.bas Moon_title.xml maingraphic_2.bmp

Very neat! Very clever use of your resources. A few things I noted as I played with two hands: 1. If you die to a big enemy like the big, brown tank, the enemy will shrink down to normal size in the death version. You'll need to reference NUSIZ1 in the end game loop so they keep their relative size. 2. I like the two-player cooperative aspect, though it'd be nice if player 2 shot an actual shot, rather than just lining up the cursor and pressing fire. Are you using the playfield ball? Maybe you could have that fire as a projectile. Whenever player 2 hits fire, if a projectile is not on the screen, it will home in to the location of missile 0 until it reaches it and disappears (unless it hits an enemy first). 3. There were a few times when the crosshair got lost because it went too far off-screen and got caught in the repeat cycle on the left or right or I just didn't know where it is. It's good that its location resets when the HUD is brought up, as that fixes that problem if it happens again, but maybe consider limiting the x and y locations of missile 0 so it can't get lost off-screen like that. Other than that and some sound, it seems like a fun cooperative game! Kudos on that. : D