Bad Panda Bear

Is Crazy Balloon compatible with non-modified Superchargers? I just played this using a Supercharger and a NTSC light atari six switch console. I had many problems with the screen going crazy whenever there was a collision or the balloon popped. Usually this was the same effect one would see when the cartridge is removed from the console. At one point it actually reset me to the Supercharger loading screen, making me think maybe it was hitting the Supercharger's hot spots.

...and the first thing I did with those controls was to ignore the project for nearly a year. Man I suck. I blame KOTOR. And Civ 2. But I've finally managed to arrange things so that I can start working on this again. Who out there is still interested? Are any of the other volunteers still out there and willing to give this a try? Anyway, my next step is to try to get a smaller test program running to try to figure out the problem I had when the ships got close to the screen edges.

I always liked Sabatoge, where the paratroopers came from the sky to sabatoge your gun. There's nothing quite like shooting a paratrooper's paracute off, causing him to fall to the ground in a bloody mess that kills other paratroopers already on the ground. Of course, now that I've read Band of Brothers I feel guilty about that.

Sorry for posting late, but my gift arrived over the holiday break while I was visiting my parents. Unfortunately the Grinch also left me a kitchen full of ants over the holiday. Many thanks Secret Santa! You picked exactly the item I was hoping you would.

Ok, I'll join in.

I feel like I need some sort of official acceptance speech like "Ladies and Gentlemen of AtariAge, I humbly accept this honor..." But seriously, I always thought of you as providing guidance rather than telling me what to do. But you're right, by the sheer amount of time I've invested in this projected it seems that I have practically taken control of it anyway. So it makes sense that you'd want to make that official. That being said, this started out as a low pressure environment for newbies to participate in developing a game, and I'd like that idea to continue. Tom seems to still be on board, and was it Galaga_Freak who was doing the intro? Whoever it was you are still welcome to contribute if you wish. And there are still some jobs free for anyone else who wishes to join. Cybergoth, are you still willing to work on the networking code mentioned earlier in this thread? The game isn't really ready for it yet but I think it's a cool idea that I'd be willing to attempt to tackle if you don't want to. For the near future though, I think I need a little break from FireOne. I've been thinking about entering the Minigame competition, and I need to clean my apartment and organize my Atari 2600 collection. Plus I've been purchasing expensive modern games and not playing them. Which makes me a saaaaad panda. Yes, that seems to be the Achiles heel of this technique. As a trade off it may be neccessary to not scroll the ships onto the screen but instead to have them appear in full. But I hope that can be avoided. I had originally wanted to keep the full 160 pixels of horizontal position, but this may be another trade off that has to be made. But regardless of this the multi-NUSIZ sprites force me to keep the early HMOVE because I needed the -15 move to the left to center the quad-sized lines underneath the single and double sized line. Yes. I blanked out the other sprites and commented out their movement so that I could test scrolling of the player 0 sprites without interference. But the code is still there, and is still being used for the submarine which is a 16 bit sprite now.

I've been silent about FireOne for the past several weeks, but not because I haven't been working on it. What happened is that I decided to try a simple little experiment that ended up being very complicated. As a consequence, this message is very long, and I apologize in advance for that. My goal was to make the sprites look better, and I thought that using a variable NUSIZx value for each scanline might allow more detail at the top while keeping the bottom portions large (important for battleships and carriers because they are supposed to be large). In implementing this I came across a series of problems that required me to do more and more complicated stuff to get things to work. Problem #1: There wasn't enough time in the horizontal blank to do two NUSIZx stores and two GRPx stores, along with the alternating missile enabling code. I solved this by setting VDELP1. This allowed me to set GRP1 on the scanline before. Problem #2: When you change NUSIZ, the sprite graphics were not aligned with the earlier portions of the sprite. To fix this, I had to set HMPx and do an HMOVE to align the bottom portion of the sprite. Problem #3: Doing an HMOVE on every scanline of the sprite ruined the left edge of the display. I considered just using a smaller screen, but decided to be ambitious and try the early HMOVE trick (See the Games that do bad things to HMOVE thread on the stella list). By doing an HMOVE at cycle 73 instead of after a WSYNC, I got rid of the HMOVE blank. Problem #4: I wanted the flexibility to choose different sizes at different points for the two player sprites. To do this I changed from using a spritePointer that points at each sprite, to using an 8 bit pointer from an assumed SpriteData table. Then in another 256 byte page in ROM called SizeData I have tables that control the HMPx and NUSIZx values to set for each scanline. The offset for each sprite is the same in SizeData and SpriteData, so I could use the same 8 bit pointer passed into DisplayMainStripe. The format I use has the HMPx data in the high nibble and the NUSIZx value in the low nibble. Here's an example from the first row (on the horizon) battleship sprite: ;; Row1BattleShip .byte %11011101 .byte %10000000 .byte %10000000 .byte %10000000 .byte %10000000 The sprite is still inverted, so the first few bytes have 0 movement (%1000 since HMOVE is being done at cycle 73), and single sized sprite data. On the last line, to make the sprite look longer, I used double sized sprite data. This requires a movement of 5 pixels of the left (%1101 in the high nibble) for the botton scanline to line up where I want it to. Also note that since bit 4 of the NUSIZx values aren't used by the TIA, I am using a 1 in this to indicate the end of the sprite. This saved me a few cycles in the display routine. It also means that I don't need to invert the sprites any more, but I haven't felt like changing that yet. Problem #5: When horizontally positioning the sprites, they line up differently because of the various HMOVEs done when drawing the sprites. So a sprite at position 0 may be mostly off the screen if the lower scanlines are moved to the left relative to the higher scanlines. To solve this I added another ROM table, called ShipTypeData, that has offsets for each sprite just as in SpriteData and SizeData. Right now ShipTypeData just has a horizontal offset that is applied to each sprite's X coordinate before horizontally positioning the ship (This is done in the VBLANK portion of the code right now). Eventually it could also store stuff like how fast a ship goes, and how many hits it can take before it sinks. But it is very inefficient in ROM usage because in order to use same offsets as SpriteData, the closer ships use many more bytes than the distant ships, even though they don't need to in ShipTypeData. I think this needs to be done differently in the future. Problem #6: Duplicating the sprites between the bottom two rows, and the top two rows didn't give the right pseudo-3D effect that the original game did. To fix this I made a version of each sprite for each of the four rows ships appear on. This of course requires much more ROM space. If the sprites are to fit into 256 bytes of memory, then I calculate that the game can only support four ship types, plus a blank sprite, an arrow sprite, and the submarine sprites. (I also ended up making the sprites a bit taller, so I had to remove the top sky slice). Problem #7: This is the one I haven't solved. When I position the ships towards the right hand side of the screen, the sprites go wacky. Now on my 2600jr I don't see this, so it might be an emulation problem. But my 2600jr looks like crap on my big screen anyway, so it's hard to see if there are any other problems with the code. Since I'm doing tricky things to HMOVE and NUSIZ, I really need to test this on my other 2600 console types (I have several) before I start blaming z26. Phew. For those of you brave enough to have read this far, I have the following question: Are the new sprites (see first screen shot below) good enough to warrant all this complexity and added ROM space? I kind of like them but I'm not very artistic and don't trust my judgement in this. fireone_src_and_bin.zip

What's the image quality like with you 2600 on you HDTV? With my 50" DLP (connected through RF) it looks kinda blurry and all of the interference is exagerated because of the way the image is strecthed to fill all the pixels.

And the number is... 118 Oesii was the closest at 101, but the rules clearly stated that the contenst ended at 12:00 am AtariAge time, and his post was at 12:25 am. Sorry. That makes Mr. FoodMonster the winner at 150. PM me with your address by tommorrow night and I'll get the prize shipped out to you Tuesday morning. I'm going on a business trip this Wednessday until the 30th, so if I don't get your address by then you'll have to wait a bit longer. I'm rather surprised at the low number. It leaves me wondering just how long I've been collecting empty 12 pack boxes. One of these days I should throw them away or something. I scare me.

My understanding is that burn in varies based on what type of TV you have. DLPs and LCDs are not very susceptible. Plasmas, CRTs, and Rear Projections (except LCD and DLP rear projection) are. Here are some FAQs I found that have more information: AVS Forum thread on burn in Another AVS forum thread HDTVArcade FAQ

Tommorrow marks my 29th and last official birthday. (Next year I shall deny any knowledge of this "birthday" concept). To celebrate I should probably throw a party at which I would receive lots of presents. Oh wait...that would involve interacting with other carbon based life forms...nevermind. Instead I'm going to give away a present. One NTSC Arcadia Supercharger, pictured below. This unit has been tested and cleaned with rubbing alcohol. (Although I couldn't get all the dust out of the corners). All you have to do is guess how many 12 ounce pop cans are strewn about my apartment. To help you make an educated guess I will give you the following hints. Hint # 1: Pictured below are the 12 packs that 99% of the cans came from. Hint # 2: I last cleaned my apartment of cans 3 to 4 months ago. I probably didn't clean up the corresponding 12 pack boxes however. Hint # 3: I average about 1.5 12 packs a week Hint # 4: Every work day I take a can into work, which usually doesn't make it back to the apartment. The person with the closest guess wins. I will ship anywhere my local US postal service will let me. If there is a tie the first guess wins. The contest will end Monday June 21st at 12:00 am AtariAge time. This gives me the whole weekend to get off my butt and find those cans.

In a way both those statements are right. What BNE does is to branch when the Z flag is set to 0. Usually this happens when the result of an instruction is not zero. For CPY, the cpu flags are set the same as if a subtraction occurred. So if YPosFromBot does not equal Y, the result of subtracting the two will not be 0, so CPY sets the Z flag to 0. This triggers the branch. Alternatively code like this would also branch when YPosFromBot is not equal to Y: TYA ; Transfer Y to A SEC ; Set carry so it does not interfere with subtraction SBC YPosFromBot ; Subtract YPosFromBot from A BNE SkipActiveMissile In this case, if Y does not equal YPosFromBot the result of the SBC is non-zero. The Z flag will be set to 0 so the branch will be taken. Hope this helps.

It appears to be just the ships, I've attached two pictures of the TV screen. One is before play starts with only one row of ships. And the other is after I've reached 1000pts and all the torpedoes have turned to refueling cannisters.

I've been seeing something strange when playing seawolf with a supercharger. When I play the binary in z26 it seems fine, there 3 rows of ships to shoot at and refueling starts with one refueling container at 1000 pts. When I convert to a WAV and play on supercharger, I get only one row of ships. I invariably die once before reaching 1000 pts, and when I do reach 1000 pts I start to see multiple refueling containers, that never go away. It's as if the mines start turning into refueling containers. This makes the game rather easy at that point. This was on a NTSC Vader and an NTSC sears heavy sixer. But when I play the binary on a CC2, it works like it does in z26. So I started to think that I was doing something stupid, like using an old version of the binary to make the WAV file with. But I re-converted and double checked and I still had the same problem. I also tried changing the volume I use when playing the WAV but it didn't help. So has anyone else seen this?

Well I drew them, so of course they're ugly. But I do think using more rows of ships is a good idea, so I did a quick version of this (see screen shot below). My main concern was that the pseudo 3D effect of the game would be ruined. So I made the sprite for the horizon version of the tanker a scanline shorter to make it look more distant than the ships on the second row. For the foreground ships, I don't think it matters too much because they're closer and therefore should show less of a size difference due to distance. So what do you all thinK?