TROGDOR

Hey Cybergoth, This is the first time I've logged in in about 9 months. After a long hiatus (no thanks to America's Army and Runescape for eating most of my coding time for the past year), I've decided to continue work on this game. I had made decent progress on this game before I shelved it. I already have my plane, the enemy plane, AA fire, and inertial bombs working, and some sound fx. I'll post a preview demo soon. I blew off the 2005 mini comp, but this is a good time to focus work on this game for the 2006 comp. Hopefully you'll be seeing more of me in the next few weeks.

Thanks for your help Thomas. Most of the trouble has been cleared up. I burned these 3 extra cycles with a WSYNC at the start of the loop. This has cleared up most of the sprite distortions. However, there is still a point on the screen where the sprites are rolling 1 scanline. I'm not sure what would cause that, since I've got VDEL enabled for both sprites, and it shouldn't be able to roll with that WSYNC in there. My understanding of VDEL is that it only needs to be enabled once. If you store a sprite value in the buffer, it should take affect at the beginning of the next scanline, correct? Or does it take effect exactly 76 cycles (i.e. one scanline) later? The display is similar regardless of whether I set the VDELs to 0 or 1. The only difference is that the VDEL enabled pushes my sprites down one scanline. Thomas, can you recommend a solution to prevent this problem, and can you clarify the behavior of VDEL as defined in the stella guide? Do I really have to squeeze all my graphics writes into the horizontal blank? Nice catch. I think there is a typo in the ATARI 2600 ADVANCED PROGRAMMING GUIDE. It says to use LDX #ENAM1+1 if you want to set up the stack trick for just the two missiles. That should just say LDX #ENAM1. Following the logic in the guide, I used LDX #ENABL+1, since I wanted to include the BALL. I also found another typo. In the illegal opcode section, it says: Decrement and Compare: Decrements the memory location and compares it to the accumulator. DCP Opcode:$C3 M <- (M)-1, (A-M) -> NZC (Ind,X) 2/8 I assume the 2/8 means 2 bytes, 8 cycles. But shouldn't this command be 5 cycles? If it is 8 cycles, you're not saving cycles, because DEC (zeropage) = 5 cycles, and CMP (zeropage) = 3 cycles. I'm including V0.04 below, with a demo of 6 planes flying in formation. There is a screenshot, and a zip with the bin and source. Thanks again, TROGDOR tbom_v004.zip

Hi all, I've just spent several days shoveling though the MiniDig and various posts about skipDraw, and found the incredibly helpful ATARI 2600 ADVANCED PROGRAMMING GUIDE. The result is I've pieced together my first major kernel. It allows for 2 animated sprites, the ball, and both missiles all on the same scanline. It uses exactly 76 cycles each pass, so it has no WSYNC. It's squeezed so tight it doesn't even have a NOP. I loaded it into my emu, and it worked! Sorta. There's some artifacts I can't figure out. This kernel is for the game "The Battle of Midway". You'll find detailed specs for this game in this forum discussion. The bottom of the screen displays a battleship, and the water. It isn't part of the main kernel, because I know there's no way I could do asymetric background graphics and all 5 MOBs in one scanline. The upper 75% of the screen uses the main kernel. Right now it just has a demo of the GRP0 plane HMOVEing across the screen from left to right. The sprite graphics are updated every 4 seconds to rotate the plane in all 8 directions. Here are the 3 problems I'm seeing: 1. The HMP0 setting isn't working the way I'd expect. I loaded #%00010000 into HMP0, expecting it to move my sprite one pixel for each movement (with one move every 16 frames). Instead it moves it 2 pixels. What's stranger is it moves it 2 pixels no matter what value I load into HMP0 I've checked for the obvious stuff: The HMOVE is right after a WSYNC, and there is only one HMOVE in all the code, and it's not in a loop. (Well, it technically is in a loop, but only once every 16 frames.) 2. The graphics in GPR0 are getting slightly garbled as the sprite moves across the screen. This problem I do understand, but I'm not sure how to fix. My original intention was to use VDELP0 to delay the plane 1 scanline, thinking that would free me up from the 23 cycle limit in horizontal blank, so I could calculate the GRP0 and GRP1 sprites and then display them the next line. But, VDEL appears to delay the display exactly one scanline, so the distorted graphics still appear regardless of whether I enable VDEL. Can anyone suggest a way around this? Is what I'm trying to do even possilbe? To reassure myself, I went back and played some Combat. They're able to do 2 sprites, 2 missiles, and symmetric background on one scanline. But, looking closer, I see that they've got half vertical resolution. I want to keep the full vertical resolution unless it's absolutely necessary to chop it. I took another look at JoustPong, and I see that it is also using 50% vertical resolution, so my hopes are fading fast. So it looks like I may be stuck with: Scanline 1: Calculate everything. Scanline 2: write out all the graphics based on those calculations using VDEL, so they'll start displaying on the next scanline 1. Do all 5 MOB's still have to be written in the first 23 cycles of the second scanline? I'm confused about VDEL. Is it a one time write, or do I have to strobe it every time I want the buffer to pass though? 3. The colors between Z26 and PCAE are very different! Yeah, I know, don't use PCAE. Thanks for any help on this. I'm including the kernel code below, and below that a zip file with the bin and full code. TROGDOR ;------------------------------------------------------------ ;The Kernel! The bowels of the beast! LDA #0 ;Careful! Set to 0 for 3 cycle load below. STA Temp1 TSX ;Careful! Need to initialize stack hack here. STX Temp2 ;Preserve the stack in Temp2. LDX #ENABL+1 TXS LDX #150 ;Initialize the scanline count down. JMP KernalStart ;FIXME! There's wasted ROM space here. align 256 SkipPlane0Draw LDA Temp1 ;3 Careful! Temp1 must contain 0. BEQ ContinuePlane0Draw ;3 SkipPlane1Draw LDA Temp1 ;3 Careful! Temp1 must contain 0. BEQ ContinuePlane1Draw ;3 KernalStart STA WSYNC NextLine0 CPX BombY ;3 PHP ;4 sets ENABL CPX Plane1BulletY ;3 PHP ;4 sets ENAM1 CPX Plane0BulletY ;3 PHP ;4 sets ENAM0, Total 21 TXA ;2 A now holds scanline. SEC ;2 SBC Plane0Y ;3 ADC #PlaneHeight ;2 BCC SkipPlane0Draw ;2 or 3 TAY ;2 LDA (Plane0GfxLo),Y ;5 ContinuePlane0Draw STA GRP0 ;3, Total 21 TXA ;2 A now holds scanline. SEC ;2 SBC Plane1Y ;3 ADC #PlaneHeight ;2 BCC SkipPlane1Draw ;2 or 3 TAY ;2 LDA (Plane1GfxLo),Y ;5 ContinuePlane1Draw STA GRP1 ;3, Total 21 TXA ;2 Reset the stack. LDX #ENABL+1 ;2 TXS ;2 TAX ;2 DEX ;2 BNE NextLine0 ;2 or 3, Total 13 ;Total: 21 + 21 + 21 + 13 = 76 LDX Temp2 ;Restore the stack from the stack hack. TXS tbom_v003.zip

I'm glad you're enjoying the game, criminal unbeliever. I think it is. Complex strategy games require text, something the Atari usually doesn't have. The only 3 games that I can think of that have more than just a few lines of text are the infamous Stellar Trak, Dragon Stomper, and the homebrew Dark Mage. That was one of my motivations for writing this game. The Atari can support a decent RTS, but noone's ever done it. Stellar Trak is a great strategy game, but it isn't real-time. I'm also partial to strategy games because they have a much higher replayability than most action games. Level 64 is tough enough that it beats me about 1 in 4 games, even though I know exactly what the AI is thinking. So I still play it a lot. TROGDOR

Yep, the USS Yorktown will be in there. Thanks for the positive feedback guys. I've got some ambitious plans for this game. I'll have to see if they can actually be implemented on an Atari. There's a whole lotta blue sky there. That's going to get filled up with Japanese Zeros and anti-aircraft flak (aka Dangerous Black Squares.) The main jist of the game is an action flying/bombing game. Here are some planned features for the game: - You will be flying an SBD Dauntless scout-bomber. - You can drop bombs on the ship, which will cause visible damage to the ship. - Each bomb will knock out one pixel of the ship. The pixels of the ship will be stored in RAM. - If you can bomb enough times in the same place to knock a hole all the way to the water, the ship will sink. - The plane will be armed with a machine gun that will shoot in the direction the plane is flying. - The plane can fly in 16 directions, represented by 8 different sprites (included below). - Both your plane and the bombs you drop will have 16-bit inertia, velocity, acceleration, and gravity effects. - Japanese Zeros will be flying around trying to shoot you down. - Colliding with a Zero will crash your plane. - Zeros will either take off from the ship in the case of the aircraft carrier, or they will come down from the top of the screen in the case of the battleship. - Flying too low to the ship means instant death by AA fire. (Saves me the trouble of drawing the ship, the bomb, and the plane on the same scanline. ) - Both your plane and the Zeros will wrap from one side of the screen to the other. - The game will have vertical scrolling, but probably not horizontal scrolling. That would require too much RAM for single bit rolling (12 rows X 6 bytes = 72 bytes. Too much.) Unless somebody out there has a super-efficient single bit horizontal scrolling routine that I'm unaware of. I wonder if I could replicate two quad-sized sprites. Hmmmm.... - The ships will have 2 or 3 anti-aircraft cannons (drawn as sprites) that can be bombed. - There may be a tactical target on the ship that will sink it instantly if hit. (Ammunition storage.) This target will be under the towers, to encourage you to bomb the towers. - You will get bonus points for bombing the 3 18-inch cannons on the battleship. - Your plane will have a fuel gauge. When fuel runs out, you will crash. - Your plane will have a gun overheat indicator, so you can't fire constantly. If the guns overheat, they will be inoporative until they cool down. - Your plane is weighed down by all its bombs. If you fly at a sharp upward angle, your plane will slow down, and could stall out. (Anyone remember Triple Action Biplanes for the Intellevision? :wink:) - The plane controls are left and right to rotate, press down to bomb, fire button to fire guns. Or I may make the controls up and down to rotate, left and right to speed up or slow down, tap button to fire guns, hold down button to bomb. - Anti aircraft fire will fly straight upward until it reaches the targeted altitude, and then explode into a cloud of flak, which will fade from black to gray for 4 seconds. - Zeros will occasionally attack in a formation of 3 planes, with a klaxon alert. - There may be multiple stages to the game (not sure yet): - Stage 1, defend your aircraft carrier from incoming Japanese bombers. You will control 2 50cal anti-aircraft cannons which will operate similar to the anit-aircraft cannons on the Japanese ships. Pressing the joystick left or right will control which of the 2 cannons fire. The flak detonation height will either be controlled by a target that is moved up or down, or by how long you hold down the button. The button technique sounds like more fun. When you shoot down all the enemy bombers, the stage is done. If both your guns are bombed, you lose a life and get 2 new cannons. If your ship takes too much damage and gets sunk, it's game over. AA fire can knock out enemy bombs aimed at the AA cannons. - Stage 2, defend your aircraft carrier from incoming Japanese bombers. This time you control an F4F-3 Wildcat fighter. Similar to stage 1, except you need to shoot down the enemy bombers with your plane. The plane flies similar to the SBD, but it will handle better, and there's no bombs. AA guns on the ship will fire automatically to assist you, and you can't be damaged by the flak clouds. (On harder levels, I may make your plane susceptible to friendly AA fire.) If your plane is shot down, you lose a life. If the ship is sunk, game over, man. - Stage 3, Attack the Japanese ship with an SBD, as described above. - Stage 4, Land on your aircraft carrier. If you crash, you lose a life. There will be some congratulatory special effect here if you land successfully. Starts over to stage 1, but harder. (More Zeros, more AA fire, etc.) - If I go with an 8K game, I will add a tactical element to the game, and the obligatory 12 character text display. The tactical portion would be real-time rather than turn based. There will be an overhead map of Midway Island and the ocean. You deploy your fleets, and launch planes to scout for and then attack enemy ships. All battles are resolved by playing the corresponding stages above. This would also include a battle where you defend Midway Island itself, with a plane or AA cannons, if Midway gets attacked. A 12 to 16 K version of the game might include: - 1st-person submarine battles - Destroyer battles, hunting submarines with depth charges. - Battleship battles (entering cannon trajectories to hit a moving target.) - maybe even let you play the Japanese side. I've got a lotta coding to do. The SBD/F4F-3/Zero graphics are done, included below. I'm happy with how the horizontal and vertical planes came out, but the diagonals look kinda crappy. The light gray pixels will be strobed to simulate the propeller. The plane graphics are based on the photos from the Naval Historical Center website, which is also where I got the ship photos. TROGDOR

Hi All, With the MiniComp all wrapped up, I'm taking a break from Master of Arcturus to start a new 2600 development project, The Battle of Midway. I'm pretty sure you can't copyright historical events. I'm going to try to squeeze this game into 4K, but if it won't fit, I may expand out to 8K. Here are a couple teaser screenshots from version 0.02. The ships only use 36 bytes of ROM each. I'll post more details about the game as development continues. TROGDOR

We need a blog of just the facts regarding Infogrames. No opinions, just verified facts about what has occurred. I've started this as a separate thread, because the "So what happened" thread is mostly opinions, and is getting too long to read from start to finish. Here's all I know about Infogrames actions at this point: - 4 Homebrew games were removed from the Atari age store. The games were: Castle Crisis Mondo Pong JoustPong Double Breakout - Several reproductions based on Atari titles (such as Saboteur), and most of the hacks based on games from Atari were also removed from the store. - A few buttons were removed from the Atariage website. - atarilabs.com got a C&D three years ago. They had to surrender their logo and web domain to Infogrames. - Dan Iacovelli got some grief from Infogrames regarding fest issues on cafepress.com. - sku_u's wife got a threatening email for using pixellated graphics in the banner promoting their gaming night. It did not contain any Atari logos. Infogrames was unhappy over the use of a Berzerk robot and the Adventure yellow block. The source for these facts is the "So what happened?" thread. The unanswered questions are: - What is the specific list of reproductions that were removed? - What is the specific list of hacks that were removed? - Can Al offer a description of the buttons that were removed, so we can get some understanding as to why they were removed? - Is Al allowed to discuss the terms/justifications of the removals? If not, is Al at least allowed to state that he is not allowed to discuss the terms/justifications of the removals? - Dan Iacovelli, can you provide more details about your incident? Did you get a C&D letter, and can you post it? - sku_u, can you post the C&D letter you got? How was the incident resolved? Regarding atarilabs.com: The atarilabs.com site is still there, so the above fact is wrong. The atarilabs homepage has a tiny text message that says "Atarilabs is not affiliated with Infogrames in any way. Their lawyers don't send us nasty letters either. They are actually very polite." Here is a link to the original atarilabs.com letter from Infogrames. It really isn't a C&D letter, because it doesn't contain any threats from Infogrames. http://atarilabs.com/senta.htm There is a link on that page to see Lawrence Wright's reply. To Infogrames credit, it is reasonably polite, and does grant the site permission to use Atari logos for non-commercial purposes. The problem that us homebrewers are going to face is that selling cartriges is inherently commercial, and that's probably why we're a target. atarilabs.com never lost their site, and did not have to surrender their domain name. Here's the last news article I found on the subject, from the link: http://www.gamelord.org/archives/april2002.htm This is exactly why we need to get our facts straight. Based on this information, I was too hasty in my judgement of Infogrames. If you have an opinion about Infogrames, please post it in the "So what happened?" thread. I want to keep this thread short, so people can figure out what's really going on without having to filter through hundreds of posts. If you have new factual info, or a clarification of a fact, please post it here. Thanks in advance for any info, TROGDOR

Infogrames is brilliant. If they keep this up, they'll remove all unsanctioned references to Atari from the internet. Infogrames understands the catastrophic consequenses of free advertising from fans. Here's my 2 cents. (well, more like a buck fifty.) 1. The number one priority is getting this story up on slashdot. They will print this. They love controversy, especially when it's the Man sticking it to the little guy. If you don't think we can do anything, check this out this story: http://yro.slashdot.org/article.pl?sid=04/...92&tid=1&tid=17 It gives new meaning to the slashdot effect. The summary of the story is that an author, with help from Penguin Publishing and some lawyers, was harassing a small company to steal their domain name, katie.com. The backlash from the slashdot story was so intense, Penguin Publishing backed down and instead renamed their book. We are only a couple hundred geeks. But slashdot is hundreds of thousands of geeks, who will be sympathetic to our cause. And they are huge video game consumers. That will be a nasty PR hit to Infogrames, and they will at least have second thoughts about attacking fan sites. 2. Do not buy Infogrames games. And far more importantly, let Infogrames know you are not buying their games, and why. Boycotts don't mean squat if you don't let the company know why you're boycotting them. Send them emails. Send them snail mail. And best of all, call them. The phone call costs them time, and they can't ignore a phone call. Don't scream at them. The more sensible you are in your message, the more impact it will make. If you sound like just an average consumer, they will be much more concerned than if you give the impression of being a fanatical hobbyist. My guess is that they've written off the homebrew community as hackers and pirates, rather than seeing us as loyal fans, or they wouldn't be doing this. I like games, and I may still want to play Infogrames games. But I won't buy them new, and I won't buy them when they are first released. I will buy them 1 year after release, used, so Infogrames makes no money off my purchase. 3. We need to stick together. We will have differing opinions on what is the best way to handle this threat. It's fine to discuss these different opinions, but respect the opinions of your fellow Atari aficionados. We don't have to agree, but starting flame wars in this forum will just divide the community. 4. As for insulting Infogrames, I say insult away. It's just more bad PR for them. And PR is all a soulless corporation is going to listen too, because it affects the sacred Bottom Line. 5. Do not ditch all your Atari gear. Remember, Infogrames is not Atari. 6. Someone needs to keep a blog of all questionable Infogrames actions, especially C&D orders like the one mentioned previously. We need to keep track of dates, who was involved, and the verbatum text of the order / request. The blog probably shouldn't be on AtariAge, as it would make this site a target for retaliation. I also recommend seeing the movie "The Corporation". It's a great documentary that's in a small number of movie theaters right now. It talks about how corporations operate in a disembodied moral vacuum, and it certainly applies to this situation. There are some scary things in that movie, and they talk about stuff that's a lot more serious than Atari carts. Check your local listings. http://www.thecorporation.com As for JoustPong, the short term solution is "Flying Paddles". I'm pretty sure the word Flying, and the word Paddles are not trademarked. But who knows, I could be wrong. I think people may understand now why I loved the name "War of the Worlds" so much as a game title. It's one of the very few science fiction titles in the world that is in the public domain. I suppose we could just go on a 75 year coding hiatus. By then, all the copyrights on all these games will have expired, (if Congress doesn't extend the copyright laws yet again,) and we can start our own Atari(no longer tm) nursing home. There are farther reaching implications: - Will www.atariage.com have to surrender their domain name to Infogrames? - Will www.homestarrunner.com have to remove it's "Atari themed" menu because it has a graphically accurate depiction of the Adventure dragon and chalice? - Will Paul have to remove all his classic game tributes from his up coming Homestar RPG? - Is an 8x8 pixel character from a game considered owned IP? For example, can I never reuse the pixelated image of an Atari Space Invader, or a ship that happens to use the same pixels as a plane in Combat? - Is the yellow square from Adventure considered IP? - Are all fan sites an implied violation of copyright? I can understand the protection of trademarks and logos. But when it becomes so fanatical that these companies attack fan sites and call pixels IP, it becomes ludicrous. And intellectually dangerous. In closing, here's a friendly reminder from Corporate America: - StanJr, please remove your avatar. It is a violation of the Spiderman trademark, owned by Marvel Comics. - kisrael, please remove your avatar. It is a violation of the Joust and Pong trademarks. - moycon, please remove your avatar and burn all your Deli Invader carts. They contain a photoshopped alteration of a copyrighted Space Invaders illustration. - Everyone using the Boycott Infogrames avatar, you must delete that image. It is unauthorized use of the Atari logo. - inextremis staple, please remove your avatar. Eagle Scout is a trademark of the Boy Scouts of America. - TROGDOR, you can keep your avatar, because the guys at homestarrunner.com aren't assholes. TROGDOR :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad: :mad:

Yep, you caught me. I added some fictional background to the Prologue in the manual, and at that point the War of the Worlds title didn't apply at all, so it became Master of Arcturus. It seems that every combination of has been used as a game title: Space War Space Battle Space Conquest Space Conflict Stellar War Stellar Battle Stellar Conquest Stellar Conflict Interstellar War Intersetllar Battle etc etc etc... but Master of Arcturus returns no Google hits, so it wins. I managed to get version 1.00 submitted on time. What do I win for being the last submission to MiniComp 2004? The Golden Procrastinator award? I suppose the trophy would be a golden wristwatch with a finger pointing at it. The latest version has the following enhancements: 1. Name changed to Master of Arcturus. 2. Slight random element added to combat. Every stardate, I randomly set or clear the carry bit on the subtraction. In a 13 round battle, this can make a substantial difference, to the point that an attacking fleet of 255 can defeat a defending star system even with the production add on. It does make combat more interesting. 3. The split screen display now has a pretty border. Unfortunately, the text display code causes those nasty black lines on the left side of the screen, so I had to remove the highlighting effect for destination and launch selection fields. 4. On reset, the previously selected level is preserved. Unless you select level 65. In that case, when you reset you'll see the level you actually played. 5. Nasty bug fix. There was a 1 in 64 chance that the game star data would get corrupted by the shifting star Fx during the title screen. In one particular instance, it was changing the player's homeworld to an Alien world, causing the game to end the moment it started! I need to hire more beta testers. I don't have the updated manual with me, so I can't post it yet. I'll post the updated game and manual tomorrow. In the meantime, here's a new screenshot. For the last 4 days, an old highschool drinking buddy has been in town, so it's been a rough weekend. Bar hopping and assembly coding are a dangerous mix. It's 3:00 AM in Arizona, and it's time to get some sleep. TROGDOR

Agreed. These aren't too hard to implement. I haven't seen the brightness problem on my Dell Axim PDA LCD display. Are you running NTSC or PAL mode? I have a personal peeve against strategy games with random elements in the combat. Did you every play a game of Risk against the computer and have 20 armies defending Australia, and watch the computer blast through them with his 5 armies because he got a series of lucky dice rolls? Grrrrrrrr. At the absolute most, I may add a random +1 bump on combat rating per stardate, and see how that affects the game. Regarding all the other suggestions for War of the Worlds, they are interesting, but remember this is a 4K ROM with only 128 bytes of RAM to spare. If I attach any new attributes to the ships, that's an extra 16 RAM bytes consumed, which is one eighth of my total RAM! (8 bytes for the ships on each world, plus 8 bytes for each of the fleet slots.) Here's what the current RAM usage looks like: 24 bytes for the indexed text display buffer 3 X 8 = 24 bytes for world data (X location, industry, ships, ownership) 3 X 8 = 24 bytes for fleet data (ships, destination, ETA) 12 bytes reserved for the stack (allows for 6 nested subroutines.) 4 bytes for the random number buffer ~24 more bytes for misc (GUI states, joystick states, temp vars, level, sound queue, etc.) 112 bytes consumed. So I've got about 16 bytes left. I've also got about 400 bytes of ROM left, if I optimize the code a bit more. Yep. The 4-digit stardate display uses 2 BCD bytes. But, using BCD will only allow 99 ships in one byte. I could expand it to 2 bytes, which would take the ship limit all the way up to 9999 , but that has far reaching consequences on system resources. First, it would eat the remaining 16 bytes of RAM in the worlds and fleets datastructures. Then it would complicate the numerous calculations done on the ships, requiring multibyte addition and subtraction with carry. Consider the combat rating calculation for a fleet. It's easy to divide by four in binary. Just LSR LSR. In BCD, it would require dozens of lines of code and hundreds of cycles to divide by four. It would be relatively easy to divide by 5, though. X4 bit shift the high byte into the low byte, and you've divided by 10. Then, multibyte add the number to itself, and you've got a divide by 5. But still a lot more complicated than just 2 LSRs. I think the game would be more amusing if I could horde up 5000 ships into one fleet, so I'll look into this for a possible v2.0. But it won't happen by Sunday. The current code has a very fast BCD converter. It uses looped subtraction to figure out the 100s digit, and then a table lookup to convert 0-99 binary to 0-99 BCD. Granted, the lookup table burns 100 bytes of ROM, but it runs in 6 cycles. :wink: No, not really. I played dozens of games of Spaceward Ho! back in the early 90's. But I wasn't thinking about that game when I wrote War of the Worlds. There are many similar strategic 3X (eXplore, eXpand, eXterminate) games out there: Reach for the Stars Spaceward Ho! Master of Orion but all these games are turn based. War of the Worlds is real time. There were at least a couple old games for the Macintosh that predated Spaceward Ho! that were similar to my game. They were very simple, with just industry and ship counts, and they were played in real time. But it's been so long that I don't remember their names. My primary inspiration for this game was an online multiplayer game called Intergalactics. I'm not sure if the game servers are still running, but the game was very fun and addictive. TROGDOR

Wow, my very own sticky! Thanks for the positive feedback guys. It means a lot coming from the homebrew gurus. Also thanks for the Z26 advice. I may have to take drastic measures and actually read the Z26 manual. I passed the enhancement suggestions on to our QA department, and they gave it the green light. Attached below is version 0.47 of War of the Worlds. Here are the enhancements: 1. The game now consistently uses 262 scanlines for PAL compatibility. 2. The text display no longer shifts when displaying numbers greater than 99. This was because of a divide by 100 code branch. 3. All text display is now evenly separated by 8 scanlines. This applies to the World Status Display, and the Fleet Status Display. I'll clean up the Title Screen and Incoming Messages if time and ROM allows. 4. I removed lower and upper wrap-around on the ship launch selection. I'm keeping lower and upper wrapping on the Level selection, because I usually play level 64, and it's just 2 down taps away. :wink: 5. Pressing left on the joystick resets ship selection to zero. Pressing right on the joystick sets the ship selection to all ships. 6. The Manual has been updated to reflect the interface changes. I also added a section called "Performance Evaluation", which discusses scoring. I'm still working through some ideas on how to spiff up the borders and background of the Galactic World Display and Text Terminal. I didn't have much choice on the title. Paramount Pictures approached me 6 months ago, requesting development of a game called "War of the Worlds". They gave me a 7 figure advance to cover develoment costs. The game was not well received when I showed them the alpha release. They kept ranting on about something called an "Xbox", and threatening to pull my funding. Xbox? Is that an add-on module for the 2600? Seriously, I put a lot of thought into the title of the game. Before I wrote the first line of code for the game, the working title was set at "War of the Worlds." As for it having nothing to do with the original War of the Worlds, I disagree. It's an epic battle between two interplanetary civilizations, competing for total domination. I had considered other titles: Battle Beyond the Stars (This movie was so painful, it deserves it's own 2600 game.) Battle of the Planets Master of Arcturus (This was my second choice.) I was aware of the Defender hack out there, but I'm not impressed by graphics hacks. I felt that such a classic title deserved a more involved development effort. On a completely unrelated topic, has anyone seen a random alien message yet? There are several messages embedded in the game. TROGDOR war_of_the_worlds_v047.zip

Sure, I'll see what I can do on this. Is there a utility I can use to count scanlines, or am I stuck counting cycles? What's a good method for testing PAL compatability? Below I'm including a touched up screen shot of the game. The text is a composite of 2 screen shots, since it uses dual frames to display the 12 characters. TROGDOR

Hi all, I've just finished my first Atari 2600 development project, "Master of Arcturus" (previously "War of the Worlds"). I'll be submitting this game to the 2004 Minigame Comp, but first I'd like to get some feedback from the user community. Attached is a zip file containing the 4K bin, and a .pdf instruction manual. Please read the instruction manual before playing the game. The user interface for this game is more complicated than most Atari games, and if you don't read the manual, you'll have to climb the learning curve on your own. I tried to make the controls intuitive and easy to use. The manual still needs work, but there is enough info in there to understand the basics of the game. I have an Atari box with a Supercharger, but I can't find the power adapter. Let me know if you try it out on the original hardware. The ROM is Supercharger compatible. I'll post some screen shots soon. Happy Gaming, TROGDOR http://www.homestarrunner.com/sbemail58.html war_of_the_worlds_v046.zip

Hi Thomas, I find myself addicted to PCAE's interface. The debugger has been very helpful for catching many mistakes. Do any of the other emulators have a built in debug tool? As a noob to this forum, I'm not going to question your advice. But, until I find a comparable debug tool, I have to stick with PCAE. I haven't run into any other discrepancies so far. My goal is to have identical game play on all common emulators, with the 2600 hardware and an unmodified StarPath as the gold standard. I haven't tried the code on my Atari box yet. I was premature with my diagnosis. It turns out that I was disabling both VDELs at the start of the display kernal. ;Set up graphics for single sprite display, instead of text display. lda #0 sta COLUBK;set background to black sta NUSIZ0;single copy sprites, thin graphics. sta VDELP0;Turn off vertical delay. sta VDELP1 So I'm still not sure why 2 WSYNCs are needed. I just subscribed to the SourceForge stella-main list. TROGDOR

Thanks Cybergoth. A rookie mistake on my part. With VDEL enabled, my GRP resets are getting buffered, and the buffer passes through with the second WSYNC. I'm just surprised it didn't completely hose my star display, which is not expecting VDEL to be enabled. So the artifacts are actually the correct display, and it's PCAE that is technically displaying the image wrong by not showing the artifacts. TROGDOR

Hi All, I'm a long time reader, first time poster. I'm near completion of a 4K Atari 2600 game for the Minigame Competition. The game uses a split screen, with a star system display on the top half, and a text display on the bottom half. I'm seeing a problem while initalizing the text display, caused by the following simple code: sta WSYNC;Reset sync to posistion text sprites. lda #$00;Turn off the sprites so they don't display during sta GRP0;text initialization. sta GRP1 This code is meant to keep the 2 character sprites blank for the 6 scanlines I need to prepare the text section. My main development emulator is PCAE 2.6 for Winders. The text has always displayed fine on this emultator. However, when I run on any Stella-based emulator, the GRP settings are ignored until the text is displayed, causing GRP artifacts to display during the 6 initilization scan lines, as seen in the screenshot below. Normally, alien artifacts would be a good thing in a space game, but... I have tried several things to prevent the artifacts. The first thing I did was burn an extra scan line, with the sole intent of turing off the GRP sprites. This didn't help. I also tried moving the GRP reset to various horizontal positions during the scanline, using a series of NOPs. This also didn't help. I was able to fix the problem with an ugly hack. If I repeat the above code twice, the artifacts are removed. i.e., I WSYNC, then reset the GRPs, then WSYNC again, and again reset the GRPs. This wastes a scanline, and wastes 8 bytes of ROM. There are no HMOVES or other strange code anywhere near the execution of this reset code. All that happens before it is the looped display of the last star and cursor graphics in GRP0 and GRP1. I've checked for possible dumbness on my part, such as changing the the GRP values after this reset, but this isn't the cause, as evidenced by the fact that display looks fine in the PCAE emulator, and is fixed in Stella by the 2 pass GRP reset. I noted that the artifacts only appear on GRP1, not on GRP0. Otherwise, I'd see gray artifacts from the GRP0 star display, along with the red artifacts of the cursor display in GRP1. I also see these artifacts running Pocket VCS 1.0 under PocketPC 2003 on a Dell Axim PDA. My brother sees the artifacts running another Stella based emulator under Linux. And they appear in Z26 version 2.13 for DOS. The two screenshots below are from the same bin file, compiled from the same code. So my questions are: Is this a bug in the Stella source? Has anyone ran into this before? If yes, can you suggest a cleaner way around this issue? Are there any restrictions on when you can change the GRP contents? I didn't see anything in the documentation. I have one more unrelated question. As you've probably guessed from the screenshot, this game uses dual frame 12 character text display, similar to the text in the game Stellar Track. Is there a simple way to get a 2 frame screenshot from an emulator without having to Photoshop morph 2 images together? If anyone is curious about the game, it's a real-time space strategy simulation. I'll be posting a demo soon for feedback, prior to submitting it to the Minigame Comp. Thanks in advance for any help on this, TROGDOR "But Basketball is a peaceful planet!"