Jump to content

Search the Community

Showing results for tags '2600 Game Development'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Atari Systems
    • Atari General
    • Atari 2600
    • Atari 5200
    • Atari 7800
    • Atari Lynx
    • Atari Jaguar
    • Atari VCS
    • Dedicated Systems
    • Atari 8-Bit Computers
    • Atari ST/TT/Falcon Computers
  • Classic Consoles
  • Classic Computing
  • Modern Consoles
  • Gaming General
  • Marketplace
  • Community
  • Community
  • Game Programming
  • Site
  • PC Gaming
  • The Club of Clubs's Discussion
  • I Hate Sauron's Topics
  • 1088 XEL/XLD Owners and Builders's Topics
  • Atari BBS Gurus's Community Chat
  • Atari BBS Gurus's BBS Callers
  • Atari BBS Gurus's BBS SysOps
  • Atari BBS Gurus's Resources
  • Atari Lynx Programmer Club's CC65
  • Atari Lynx Programmer Club's ASM
  • Atari Lynx Programmer Club's Lynx Programming
  • Atari Lynx Programmer Club's Music/Sound
  • Atari Lynx Programmer Club's Graphics
  • The Official AtariAge Shitpost Club's Shitty meme repository
  • The Official AtariAge Shitpost Club's Read this before you enter too deep
  • Arcade Gaming's Discussion
  • Tesla's Vehicles
  • Tesla's Solar
  • Tesla's PowerWall
  • Tesla's General
  • Harmony/Melody's CDFJ
  • Harmony/Melody's DPC+
  • Harmony/Melody's BUS
  • Harmony/Melody's General
  • ZeroPage Homebrew's Discussion
  • Furry Club's Chat/RP
  • PSPMinis.com's General PSP Minis Discussion and Questions
  • PSPMinis.com's Reviews
  • Atari Lynx 30th Birthday's 30th Birthday Programming Competition Games
  • 3D Printing Club's Chat
  • Drivers' Club's Members' Vehicles
  • Drivers' Club's Drives & Events
  • Drivers' Club's Wrenching
  • Drivers' Club's Found in the Wild
  • Drivers' Club's General Discussion
  • Dirtarians's General Discussion
  • Dirtarians's Members' Rigs
  • Dirtarians's Trail Runs & Reports
  • Dirtarians's Wrenching
  • The Green Herb's Discussions
  • Robin Gravel's new blog's My blog
  • Robin Gravel's new blog's Games released
  • Atari Video Club's Harmony Games
  • Atari Video Club's The Atari Gamer
  • Atari Video Club's Video Game Summit
  • Atari Video Club's Discsuuions
  • Star Wars - The Original Trilogy's Star Wars Talk
  • PlusCart User's Bug reports
  • PlusCart User's Discussion
  • DMGD Club's Incoming!
  • DASM's General
  • AtariVox's Topics
  • Gran Turismo's Gran Turismo
  • Gran Turismo's Misc.
  • Gran Turismo's Announcements
  • The Food Club's Food
  • The Food Club's Drinks
  • The Food Club's Read me first!
  • The (Not So) Official Arcade Archives Club's Rules (READ FIRST)
  • The (Not So) Official Arcade Archives Club's Feedback
  • The (Not So) Official Arcade Archives Club's Rumor Mill
  • The (Not So) Official Arcade Archives Club's Coming Soon
  • The (Not So) Official Arcade Archives Club's General Talk
  • The (Not So) Official Arcade Archives Club's High Score Arena
  • Adelaide South Australia Atari Chat's General Chat & Welcome
  • Adelaide South Australia Atari Chat's Meets
  • Adelaide South Australia Atari Chat's Trades & Swaps
  • KC-ACE Reboot's KC-ACE Reboot Forum
  • The Official Lost Gaming Club's Lost Gaming
  • The Official Lost Gaming Club's Undumped Games
  • The Official Lost Gaming Club's Tip Of My Tounge
  • The Official Lost Gaming Club's Lost Gaming Vault
  • The Official Lost Gaming Club's Club Info
  • GIMP Users's Discussion

Blogs

There are no results to display.

There are no results to display.

Calendars

  • AtariAge Calendar
  • The Club of Clubs's Events
  • Atari BBS Gurus's Calendar

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website


Facebook


Twitter


Instagram


YouTube


eBay


GitHub


Custom Status


Location


Interests


Currently Playing


Playing Next

Found 54 results

  1. vdub_bobby

    2008 Plans

    THOUGHT I'D REVISIT this topic again this year. -I have two big 2600 projects that have been kicking around in my head for a while; I'd like to make some significant headway on one or the other this year. One is an RPG for the supercharger, the other is a 32K+ Street Fighter II-ish fighting game. -I'd like to possibly do something for the A800. Though I might be satisfied just porting Squish 'Em to the 5200; I'm about halfway there already. -Create a PAL60 version of Elevators Amiss. -Possibly write something for the GBA. I've been kicking this around for a while, but the graphics-requirements are so much higher that it's hard to pick a good project. I've been thinking about porting Elevators Amiss or Go Fish!
  2. vdub_bobby

    Squishy

    THINGS ARE MOVING ALONG, though my self-imposed deadlines are looming and looking more and more unrealistic the closer they get! Unsurprisingly. I'll keep plugging away, though, and we'll see what happens. The Latest! Big changes: -Scrolling now works, though the kernel isn't completely tightened up yet. -Randomly generating girders, monster colors and positions. -Moving monsters. -Player movement constrained. Now pressing up scrolls the screen, down does nothing. -Matching up things to the original: starting location of player is correct. Brick falls at correct speed (and speeds up to fall at same relative rate when you are climbing). Monsters "fade in" when they appear. Scroll stops at correct place. A few notes: -I have to scroll two lines at a time, rather than one. It looks a little chunky compared to the original, but I think I'll have to live with it. -Realized that the girder colors change during the game! They are hardcoded in the kernel now; have to see if I can change that. -I think the falling brick is ok. -_Fandal_ helpfully disassembled A800 Squish 'Em for me so I'm hoping to extract the sounds. I think the sound hardware is mostly the same, except with the BIG difference that the A800 has 8 bits of frequency resolution, compared to the 5 bits that the 2600 has. Are any of you experienced uncommented-asm readers able/willing to help me partially disassemble this? -Still have 48 free bytes of RAM! I don't want to count my chickens before they hatch and all that, but this just may be my first project where RAM wasn't an issue. Would be nice...
  3. vdub_bobby

    Back In The Game

    SO AFTER A LONGISH hiatus from 2600 coding I've begun to dive back in. This coincides with finishing the first new (to me) Zelda game I've played in about 4 years. Complete coincidence. So, a few days ago I got some of the rust off by writing a buzzer program. I'll probably get back to that and add some sounds a tweak up the controls a little for Murph74, but last night I returned to Go Fish! And boy has it been a while. I spent about two hours last night trying to, essentially, hack a six-digit score into the darn thing. Why, you ask? Well - to my surprise, and pleasure*, a few people are good enough at Go Fish! to max the score. A little while later, that same person contacted me with a request: He really enjoyed the game, but wanted a further challenge. He wanted to know, was there any way to add another digit to the score (making the max 99,999) or to make the score roll back to zero after surpassing 9,999. I responded, "Sure, but you'll have to wait until the new year" (this was in Nov/Dec last year) since I was in the middle of Christmas hustle and bustle as well as finishing up my part of Toyshop Trouble. Now, making those changes to Go Fish! requires overcoming some technical problems: 1. The reason the score maxes in the first place is because the high scores are saved to the AVox; if the scores rolled that wouldn't work properly as the highest scores wouldn't necessarily occupy the top spot in the high score list. So the simplest solution, allowing the score to roll, would be less than optimal. 2. Obviously, all current 4-digit display routines would have to be rewritten to use 6-digit display routines. This includes the game-play screen and the title screen. 3. RAM. Is tight. A six-digit score would require an extra byte to store the score, plus an extra byte for each saved high score. Plus extra bytes for the extra pointers necessary for the six-digit display routine. 4. ROM. All these changes will likely require ROM, which is limited. 5. A bunch of routines will have to be updated to handle a six-digit score rather than a four-digit score. My goal was/is the following: increase the score to six digits and decrease the high-score table to a single (six-digit) entry, which is saved to a different part of the EEPROM block assigned to Go Fish!. I started doing this last night and...wasn't very successful. My coding style of two years ago was a little different (read: sloppier) than it is now, that plus the fact that it is two years old made it difficult to follow at times. Also, I quickly ran into ROM-space issues, which required a bunch of code/data rearranging/optimizing. All in all it was rather frustrating and I didn't really get anything to work right. By the time I finished I was ready to give up and just remove the AVox EEPROM routines and make the score roll (i.e., the easy solution), but after talking it over with Rebecca a little I think I may give it another chance before giving up entirely. So we'll see. I really want to do this, but I don't want it to turn into a 40-hour, 3-month project that saps my will to live. *Pleasure because I wasn't entirely sure how possible it was to max the score, so I'm glad to find out that it is possible to "beat" the game. Also pleasure for the more obvious reason: that someone liked the game enough to get that good at it. P.S. Here is the binary, and screenshots, of the Atari Buzzer. AtariBuzzer20070202.bin
  4. OK, NOT THAT DIFFERENT. But I did free up seven bytes of RAM, which is pretty huge. I finally wrapped my mind around supercat's fractional-position replacement - it was a little tricky because, unlike his example (16 speeds between 0 and 2 lines per frame) I wanted 64 speeds between 1/2 and 2 lines per frame (LPF). I ended up going with 64 speeds between 1/2 and 2 1/2 LPF, using a counter which goes from 0 to 32 and a 128-byte table (i.e., thirty-two 32-bit entries). I realized about halfway through coding this that, since my counter tops out at a power of two, I could just use the frame counter (which is a byte of RAM that is decremented every frame, going from 255-0 continuously). So I ended up saving all seven bytes which were being used for fractional elevator position. So no apparent changes except that all the elevators except the slowest are a little bit faster: ElevRep20061109.bin
  5. vdub_bobby

    Back to life

    SO... I was thinking the other day: Say you want two completely independent, non-flickering sprites on the screen. What's the widest they can be (in pixels)? Using a variant of Zach's fancy 52-pixel technique, I figure you can get as wide as 10 pixels for each. Anyone think of a way to get wider?
  6. Guest

    Combat Redone

    FOLLOWING ON THE DISCUSSION in Manuel's blog, I thought I'd try to present and, possibly, collect some ideas for a possible re-written Combat game. Like Zach said, doing for Combat what Gunfight did for Outlaw.So, my initial list of desireable/possible features for a rewritten tank game:1- or 2-playersAsymmetrical terrain/mazeScrolling terrainMultiple projectilesMultiple vehicle types (beyond tanks & airplanes)PowerupsMultiple terrain types (walls, water, etc.)Any other thoughts or comments?EDIT: Add mines from Glenn's comment in Manuel's blog.EDIT II: Add more turning angles?
  7. Guest

    Reindeer Rescue bug found!

    AND, OF COURSE, it was my own buggy code all along. :roll:I have to run pretty quick, so I'll fill in the details later, but basically I committed the classic boneheaded ASM mistake: I forgot a '#' in front of a constant: lda GameFlags ora PLAYERCONTROL_BIT|SCROLLPF_BIT sta GameFlags Can't believe it. Well, mystery solved anyway.Will post fixed binary and source later. EDIT: Fixed source and binary attached. RR20060301.zip And a big thanks to Eckhard to sending me his modified version of z26 (that forced undefined bits high), seeing the problem in an emulator made it possible for me to track the problem down through the z26 log files, where I saw that the reason for the weird behavior was due to the game flags somehow becoming corrupted. It was a bit tedious, but it wasn't hard, ultimately, to track down exactly where they became corrupted; it was code that looked like this: lda bf ora CXP1FB sta bf Well, this will help me to be humble, anyway.
  8. Guest

    Now! With Scrolling! (Also, NWCGE)

    SO, VCSTROID development continues, somewhat slowly.Now the 1K master map is implemented, and you can scroll (to the right, only).Since I will be at NWCGE and plan on demoing this, er, demo (along with some other stuff), I thought I'd polish it up a bit, so I also added the Metroid tunes I was working on a month ago. Now a 32K binary, using the bankswitching scheme I outlined a post ago. Metroid20060224.bin Change tunes with SELECT.I've been thinking a bit more about this Metroid port and I realized a couple of days ago that my kernel doesn't really support displaying the lava. Not sure what to do about that...nor what to do about displaying doors. I could use sprites, but it would cause some serious flicker, especially in rooms like this: Oh, and, speaking of NWCGE, I will be there with games to sell and stuff to demo, along with David (djmips). I'll be there almost all day Saturday and he'll be there all weekend. So if you're in the neighborhood, stop by!EDIT: Here is the unfinished stuff I'll be bringing to the show to demo. NWCGEdemos.zip
  9. Guest

    GTD: IV

    GTD STANDS FOR Goofy Tech Demo, by the way. So I wasn't real satisfied with the way things looked yesterday; so I decided to give up using the sprites for the player's bullets, and use the missiles instead. This means no crazy weird shapes/colors for bullets, plus it also means no background starfield. But, you can actually see your bullets, which I think is a little bit more important. Plus I figure I can use sprites for special weapons that move slower and might be easier to see. So, changes: -Using M0 and M1 for player bullets, each flickered at 30 Hz (when necessary) for 4 bullets on screen at once. To my surprise, happily, four bullets, at the speed they are moving, is plenty to fill the screen. -Collisions between bullets and enemies are working, though sometimes bullets appear to pass through enemies. I think it is sometimes because I need to jigger the horizontal comparison between bullet and enemy and sometimes it is because the bullets are moving 4-pixels at a time and possibly jump right over enemies without ever hitting them. -Collisions between the player's ship and enemies are working; currently it just kills the enemies. -Sometimes the screen jumps a bit; I assume because the collision detection routine takes too long. ss.bin Screenshot:
  10. Guest

    Goofy Tech Demo

    HERE'S SOMETHING I've been working on...can't decide if I like it or not. r1k.bin Screenshot. Background color is different in screenshot. EDIT: New version attached. Has 24 sprites instead of the 16 previously. Also added more boundary checking and changed the movement routine. r1k.bin New screenshot. For some reason Stella hates this binary...??? Runs fine in z26 at a (95%) constant 262 scanlines, so I don't know what's up. I think it has something to do with the RIOT timer.EDIT II: New version attached, that works with Stella. Will eventually crash. Still 24 sprites (I think that's the limit of RAM) but some are different now. r1k.bin And screenshot:
  11. Guest

    Reindeer Rescue Final Recap

    YOU GOTTA MOVE ON at some point; this is the final recap. And not much of a recap, truthfully, but maybe the one with the most content. Anyhoo, here's the source and the ROMs. Enjoy!ReindeerRescueSourceAndRoms.zip
  12. Guest

    Step Two! There's so much we can do...

    ARKANOID 2600? Next up, my flier for an Arkanoid port to the 2600.Let's see...July 18 2005 looks like the latest source I have.Here's the latest, buggy, binary: It also has a thread in the homebrew forum.Here's a screenshot:Judging from the date on the latest source I have, I last worked on it January 21st of this year.Here's a screenshot:Status of this project:Preliminary, working kernel written, with 15x16 brick playfield, two larger balls, two (flickering) enemies, and a paddle-controlled, uh, paddle. :)Current version supports two kinds of bricks: breakable and unbreakable.I think I have a reasonable way to implement three kinds (unbreakable, breakable with two hits, and breakable with one hit), but it would require rewriting the kernel. And I'm not entirely sure it would work.Collision detection is buggy as hell.Second (and third) ball not moving.Ball-to-brick collision detection, besides not working, takes a LOOOOONG time. Implementing for three balls may not work because it takes so damn long.Needs a TON of work before it even has one playable level, let alone being an actual game. As an example, the (non-working) collision detection is hard-coded for only one level.Reason I stopped working on this:I needed to stop dinking around and focus on getting M-4 completed for the mid-August show.I didn't, and still don't, have a solution for the collision problem (specifically, how to do it faster).Pretty much everybody who commented on the project wanted:1. bigger balls :ponder:2. three balls :ponder: :ponder:3. bricks that took multiple hits to breakI got 1 and 2 mostly implemented, but not 3, though I have since figured out a way to do it that I think would work (involving a 256-byte table).Pros of this project:Judging by the response to the trial balloon I floated in the homebrew forum, lots of people would be very enthusiastic about it.I'm pretty sure I could get a kernel that had three large, breakout-style balls, three types of bricks, two enemies, the floating pills, and a paddle-controlled paddle.I like breakout-style games.Having a screen-designing contest would be very cool.Cons of this project:Having a bunch of people looking over my shoulder and comparing my work to the million other versions of the game might not be the most fun in the world. :)I like Arkanoid, but it isn't my favorite game in the world. And, I really *don't* like the enemies in it - a bunch of twirling geometric shapes? Boring!I like this project, but I just can't seem to muster up a lot of enthusiasm for it right now. Of all my tentative projects, it is and would be by far the most popular. So I dunno.
  13. vdub_bobby

    RPS

    NATHAN has probably given up all hope, but never fear! I am actually working on it, though veeeeeeeeerrrrrrrrrrrrryyyyyyyy slowly... Most of what little I've done so far is simple stuff to help me understand the code better. I did, however, get one of Nathan's new hand graphic sets in, and I cleaned up the scanline counts and some of the transitions where the screen would jitter or jump. And I changed the copyright date. Lot's still to do: ; To do: ; ; fix scanline count so it is an even number and consistent all the time: ; PARTIALLY DONE - scanline count is good on title screen (262) and select screen (262) and transition between them is solid. ; note: screen rolls if you hold down RESET!!! ; note: scanline count jumps when you press SELECT - FIXED! ; get new graphics from Nathan Strum in. ; PARTIALLY DONE. male_ graphics in, need to add code to support two (or more?) sets of hand graphics ; rewrite music to make smaller (in terms of both ROM and RAM) and add it in ; modify title screen to reflect ; additional contributions, ; possible fancy graphic from Nathan (?) ; DONE - new date ; Make game options visible from the beginning (?) ; make default options single-player, medium difficulty (question: Are there different difficulties?) ; make controls more intuitive? With more feedback? Add prompts (e.g., "Hold trigger to begin") ; more sound effects? ; allow start of new game with fire button ; make hand movement more natural not just linear up-down-up-down-etc. ; add game-over state and logic (currently, game never ends, win or lose) ; add some kind of "campaign" mode (?), complete with boss (?) (get feedback from Nathan about alternate boss hands, ; like robot, monster, or just bigger. Add code to unlock that is shown if you beat the game.) ; AtariVox/SaveKey support? rps.bin rps_source.zip
  14. vdub_bobby

    Squupdate Final

    WELL, THAT was a whirlwind! Finished up Squish 'Em with just days to spare. I posted the list of differences vs. the A8 version in the Squish 'Em thread, but I thought I'd recap here and try to collect my thoughts about my next project(s). First, Squish 'Em - this turned out waaaay better than I thought. It was easier than I hoped (and a lot of fun ) to disassemble the A8 source, which allowed me to get the timings to match exactly and the sounds to match very very closely. I still had to make some compromises but they all turned out to be minor ones, so I'm happy and pleased with the result. I'm also very happy that I was able to squeeze it into 4K. Wow - two games released this year. Busy busy. Though, once again, I took the summer mostly off, so I squeezed most of my coding into intense bursts in the spring and the fall. And I just remembered - I also modified Go Fish! to allow a 6-digit score. So, enough looking back - what's next? A couple of minor projects: -convert Elevators Amiss to PAL (or, likely, PAL60). -possibly convert Go Fish! to use Econobanking or whatever that cheap 8K banking scheme is called. A couple of big projects are also in the works: -I've been thinking about picking up the Supercharger RPG I was working on a year or two ago and trying to bang that into shape -I've also been toying with a big project for a while now, bugging Nathan for sprites, and writing kernels (on paper). I'll keep this one under wraps for just a bit longer - but I will say that the possible availability of a 64K cart has revived my interest... -Something for the A8? It's kind of a dream of mine to write an A8 game, but the difficulty is picking a project, of course. Anyway, if you've read this far, thanks for indulging a little navel-gazing and have a good Christmas!
  15. vdub_bobby

    AtariVox Editor

    SO IT'S been a while since I've posted anything...or coded anything. But I was inspired by...well, by something I can't talk about. Um. Anyway, I revived an idea that I kicked around almost two years ago and banged something out: 2kAVoxEditor20081209.bin I haven't tested it with an AtariVox myself - but Nathan did and it seems to work fine. What does it do? It's a way to quickly play with your AtariVox using your 2600. Add/edit/adjust sounds and control codes and then play 'em! Controls: Trigger switches between PLAY and EDIT modes. When in PLAY mode, up/down navigates the sound buffer. Right begins playing (i.e., sending codes to the AtariVox) immediately, from the cursor position. Left stops playing immediately*. When in EDIT mode, up/down changes the currently selected value. Left deletes the current value, right inserts a value at the current position. *Immediately is not entirely accurate - since the AtariVox has an internal buffer, the AVoxEditor will send 60 codes/second while playing; hitting left (to STOP) will only stop the sending of codes, but the AtariVox will continue speaking. So, for most code strings, it will send all codes to the AtariVox in less than a second, regardless of how long it takes to speak. A few other notes: switching to EDIT mode will stop the sending of codes. Hitting play will immediately begin sending codes from the cursor position. The buffer is 96 codes long. It might help to consult the SpeakJet manual for reference to what the codes are (see pages 15-16): speakjetusermanual.pdf Enjoy!
  16. SO. I had plans for 2006: Oh-fer! I rock! In more detail: I came up with an idea and did maybe 15-25% of the programming. Got a little bogged down with the SC's/2600's limitations and didn't really have time last summer for much programming. I am thinking about picking this up again, but other projects have a higher priority. Started a bunch of stuff but didn't really come close to finishing anything. Made a big push to get the Elevators+Maid game done by Christmas but my involvement with Toyshop Trouble pretty much sunk that idea. I did contribute to a couple games, though. Yeah. I still would like to develop something for the 800, but other than a lot of reading I didn't get anywhere with this. Again, my busy summer killed all chances of submitting something to the competition. Maybe in 2007! So...what the hell did I do? I'll quickly review partly to motivate me, partly to cheer myself up. Contributed to several homebrews. Did the most work for BlipFootball; wrote the kernel and music driver. Tommy did the music for that, by the way. Did the music for Four-Play; composed the tune (with help from Tommy) and wrote the driver for it. With Tommy, again, wrote music and driver for RPS homebrew. The music may not make it into the game and the game wasn't released, though. Also helped with Toyshop Trouble. Got maybe 50% done with the Elevators+Maid game. Wrote many demos: Metroid is probably my favorite, also several different music drivers, tried to develop an intelliflicker routine that used both sprites - which kinda worked, and a four-player shooter (using paddles). Started the NES High Score Club. Wasn't a lost year for sure, but didn't quite go the way I hoped a year ago. Shocking, I know.
  17. YOU, TOO, CAN MAKE your Atari talk! Nathan wanted a ROM that he could modify/play around with that would make the AtariVox speak, so I jumped at the chance to get coding again. Here it is: SpeechTester20070802.bin SpeechTesterSource.zip The ROM currently supports up to 4 different speech strings, though only one has anything in it right now: the "go fish" from the game of the same name. Switch between speech strings with SELECT, start/restart a speech string with the trigger, and reset everything with RESET. Hmmm. Just realized I should allow using the joystick to switch speech strings. Maybe I'll change that.
  18. AFTER MAKING BIG plans earlier this year I've done a whole lot of nothing so far. Hmmm...strike that. Looking back through my blog, I've done more than I thought. Mostly I just haven't managed to produce a game. I was going to use this blog entry as a data dump for everything I've half-assed over the last couple of months - and don't worry, I still will use it for that purpose! - but I think I will change gears and use it as a sort of retrospective of the year so far. Maybe help me get focused. So, if you follow the link above (don't bother), you'll see that these were my plans for the year: 1. Write something for the Supercharger contest. 2. Write a standard cart 2600 game 3. Port Go Fish! to the A800 4. Write something for the minigame compo I've sort-of made progress on a few of those things. I started work on an SC RPG for the contest but ran out of enthusiasm and time. If Glenn extends the contest deadline, I might pick this up again. Here's what I've got so far: SCRPG20060317.bin Basically, I took Andrew Davie's Boulderdash kernel concept and tried to shoehorn it into the SC. I got bogged down trying to figure out how to do the text. My start-of-the year ideas for a 2600 cart were 1. a paddle-controlled, four-player horizontally scrolling shooter, 2. a port of Metroid to the 2600, and 3. something else that would use the paddles. I don't remember what. To lay everything on the table, I suppose I could also pick up my Arkanoid demo and finish that and I could finish the PONG demo. I've also been working on (pencil and paper) a Street Fighter II-esque fighter for the 2600 - which would have an insanely complicated kernel. Most likely, and tying in with #4, Squish 'Em will be the next game I finish. As for porting Go Fish! to the A800 - I'd still like to do that, but I will probably try to port it to the GBA (!) first. In other news, I've done some music with Tommy. I haven't heard anything so I'm assuming that it ended up being too late, but Tommy and I wrote a title-screen tune for RPS, which I will unveil here: RODTVTheSong20060529.bin I think it turned out pretty well. I also am planning on writing (with Tommy) a tune for another game; hopefully this one won't be too late. So...plans for the rest of the year? Tune for other game, Squish 'Em, more SC stuff, and other stuff as I am inspired.
  19. Guest

    VCStroid?

    SO, FOR LACK of anything better to work on, I decided to see if I could actually get a kernel working for a VCS Metroid. The answer is yes. Right now it supports a partially asymmetric, striped playfield (PF1 & PF2), one non-flickered sprite, up to five (limited by RAM) intelliflickered sprites, M0 and M1. I'm kind of amazed that I got it working, actually. Some of the missile writes come at non-optimal times (around repositioning scanlines) but not too bad. Screenshot: Binary: Metroid20060208.bin
  20. Guest

    GTD: Number Three

    I KEEP TINKERING and tinkering with this two-sprite flicker engine. I'm not real enamored with it, but I'm having fun playing with it. I haven't drastically changed the kernel; despite my bold words, I haven't been able to make it work. But I was able to figure out a quick sorting method that does work with the flicker engine. It isn't perfect, but objects don't disappear and it is slightly better than a 1-sprite flicker engine. The sort returns results like this: For 3 objects: 123132123 For 4 objects: 1234134214231234etc. In all cases, the first two objects are shown, only. So the highest object is shown on all frames and the following objects are rotated, once per frame. It's a little more complicated than that, but that's the basic effect. And the sort is fairly fast, almost as fast as the flicker sort.The sorting algorithm is as follows: 1. Does this sprite have the same Y-value as the next sprite (in the list)? If so, swap them and move to the next sprite in the list, returning to 1. 2. Does the previous sprite overlap the the next sprite? If so, swap this sprite and the next sprite, move to the next sprite and return to 1. As Manuel noted, and I was expecting, processing all these sprites (flicker-sorting, moving, etc.) takes a *lot* of time. Too much time, actually. So I split things over two frames. The current 2FP (2-frame program ) goes a li'l something like this: Move Sprites Display Flickersort Display repeat. The next big step (BIG!) will be adding collision detection. A complete, brute force collision detection routine would take too long; impossibly long. To test each sprite (my engine supports 22 currently) against every other sprite to see if they overlap and have collided - ! Yeesh! What is that, 22! comparisons? Ouchie. I wasn't sure exactly how I was going to solve that problem, then it came to me: if I assume that the flickersort will have the sprites in rough order (if not now then perhaps soon, anyway!), then I can just test each sprite against the sprites that are near it in the list. And since I only need to test collisions between the player's ship and enemies and the player's bullets and enemies (but not bullet-to-bullet and not enemy-to-enemy), that will cut things down to a (hopefully) manageable level. So the final 2FP will look like this: Move Sprites Display Flickersort Check Collisions Display With other assorted game logic fit into the cracks. At least that's the hope.Anyway, here's the demo without collisions working: ss.bin (See below!)Hit SELECT to change weapons. Screenshot: EDIT: Got collisions working! Screen jumps rarely, I think. Flicker also becomes a bit intolerable, but that can probably be cleaned up somewhat by tweaking what happens when objects collide. ss.bin
  21. Guest

    2600 Music Helps

    BASED ON SOME COMMENTS I have received, especially in response to Reindeer Rescue, I thought I'd attach some of the stuff I use to help with 2600 tunes. First off, gotta give big props to my brother. He created these worksheets and has helped with almost all of the 2600 music I've done. Except for Reindeer Rescue, curiously. Tommy made this worksheet for me; based on P Slocum's music guide and E Stolberg's music chart. I find this much easier to use, plus it really shows what you have to work with: Second, here is an example of what Tommy creates for me; that I then translate into code: --hope you don't mind me sharing these with the world, T. The music driver I have written allows for note length between 32nd notes and half notes, and all 32nd-note steps in between. Each note has a volume (0-15), can be articulated (or not), and can be any frequency of any of 4 (predefined, hard coded) distortions. Also, a hi-hat plus two other percussion sounds can be laid over the top, though I just today cut the rhythm tracks out of the Metroid tunes since they are so rarely used and I ran out of ROM space. The tonal data is laid out in byte pairs like this: .byte %LLLLVVVV, %ADDFFFFF Where: LLLL = note length, 00 = 32nd note, %1111 = half note VVVV = note volume (0 - 15, written directly to AUDVx) A = articulate note (1 = yes, 0 = no) DD = distortion lookup number (0 - 3; generally, 0 = distortion 4 (square), 1 = distortion 12 (lead), 2 = distortion 6 (bass), and 3 = distortion 1 (saw)) FFFFF = frequency (0 - 31, written directly to AUDFx) I terminate with $FF - seems unlikely that I'll ever want to play a half note at full volume
  22. vdub_bobby

    Metroid Flashback

    GOING THROUGH the forum/blog archives and I realized that I don't think I ever posted the most recent version of my Metroid VIP (Vaporware In Progress). So anyway, here it is. Metroid20060303.bin I'm not sure how it is different from the last version I posted either here or in the forums, but this one has selectable songs (with SELECT) and decent scrolling - horizontal only, though. The main next tasks for this are the vertical scrolling and adding enemies to the map (so they scroll on the screen). Don't expect any work on this for a couple of months, though.
  23. Guest

    Genres

    I'M TRYING TO ROUGHLY sort the 2600 library into genres; for the purposes of seeing which genres really are underrepresented.It's a balancing act between defining the genres too narrowly and too broadly. Here's what I've got so far, with a few example games for each:1. Scrolling Platformers (Road Runner, Pitfall II)2. Non-Scrolling Platformers (Pitfall!, Xenophobe)3. 2D Non-Scrolling Shooters (Space Invaders, Galaxian)4. 2D Scrolling Shooters (Defender, River Raid, Thrust+)5. 3D (or first person) Shooters (Star Fire, Battlezone)6. Board Games (Othello, Chess)7. Breakout Clones (Breakout, Circus Atari)8. RPGs/Adventures (Adventure, DragonStomper)9. Frogger Clones (Frogger, Space Treat Deluxe)10. Maze Eaters (Pac-Man, Crystal Castles)11. Catchers (Kaboom!, Eggomania)12. Puzzles (Edtris, KLAX)13. Q*Bert Clones (Q*Bert, Frostbite)14. Car Racers (Enduro, Dragster)15. Sports (Tennis, Skiing)That's a big list (15 categories) but I think you lose something if you combine some of those - I could combine all 2D shooters into one category, but is Gravitar really similar to Galaxian?On the other hand, I could easily divide these up almost ad nauseum - separating 2D Scrolling Shooters into those with gravity (Thrust+, Gravitar) and those without (Defender, River Raid), etc. The sports games as well.More than 20 categories becomes unmanageable, I think. I guess the goal is the fewest helpful categories.Any comments? Come up with any games that don't fit anywhere in there?Here's my initial list of games that I'm not sure where to stick:TapperBump 'N' JumpStampedeMarble CrazeDark Mage (does it go in the RPGs/Adventures genre, or does it standalone in the Text Adventures category?)
  24. Guest

    Possible Wild Western Port using SC

    MANUEL got me thinking about a Wild Western port. At first I thought it was too simple of a game to need the Supercharger, but I'm reconsidering. Using strips of RAM to display sprites/particles would allow this kind of kernel: lda RAM,Y sta GRP0 lda RAM,Y sta GRP1 lda RAM,Y sta COLUP0 asl sta ENAM0 lda RAM,Y sta COLUP1 asl sta ENAM1 lda RAM,Y sta ENABL ;+45 Assuming that Y ranges from 0 to 160, that would require about 800 bytes of RAM. Using 45 cycles leaves about 25 for other displayed objects. Those other displayed objects are: 1. The train in the center, which AFAIK doesn't really move 2. The train tracks in the center, which do scroll vertically. 3. Obstacles (cactus, rocks, etc.) which also scroll vertically. If I draw those with the PF, making them symmetrical with a reflected PF, then I can do this... lda RAM,Y sta PF0 lda RAM,Y sta PF1 lda RAM,Y sta PF2 ;+21 Which takes up almost an entire scanline. But I'd probably update the particles every other line (or even every third/fourth), leaving plenty of time to reposition the sprites. Problems: 1. Drawing trains and obstacles with the playfield. Might get ugly. 2. Controls? The arcade uses a joystick, an 8-position rotary controller and two buttons. Possibilities: A) Use two controllers: Joystick in port 1, DC in port 2. Might work if you could operate the DC and its button with one hand. This might make a good 2-player variation, though. B) Shoot in direction you are moving or last moved. Not sure how to have him jump on the train, though. Don't really like A or B. Anybody else have any brilliant ideas?
  25. vdub_bobby

    Speaking of ideas

    I HAD AN UTTERLY RANDOM thought this morning, an idea for a game: What if you took Missile Command, flipped it upside down and put it under water? I.e., rather than protecting a city from missiles, you would be protecting a ship from torpedos/etc. You would drop depth charges (and...?). Has this ever been done?
×
×
  • Create New...