Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store
Warnings about File Attachments - Please Read!

RevEng

Members
 View Profile  See their activity

  • Posts

    7,607

  • Joined

  • Last visited

  • Days Won

    12

 Content Type 

Blog Entries posted by RevEng

  1. RevEng
    For a few months now I've been toiling behind the scenes on a port of batari basic for the 7800. Today I'm going public and showing off a little bit of what I've accomplished. Since a picture is worth a thousand words...
     

    adventurer.bas
    adventurer.bas.bin
    adventurer.bas.a78
     
    ...the source code for that quick and dirty demo is decidedly not a thousand words. It's 68 lines of pure 7800basic code, and 12 of those are simple commands to import png images.
     
    There are already a bunch of useful features...
    import of png graphics to any one of the 7800's mode formats, with the ability to reorder color indexes during the import.
    plot sprites, values, and characters/tiles.
    simple joystick polling, for both one and two button joysticks.
    32k and 48k formats are currently available. SuperGame formats to come.
    switch between 7800's various display modes.
    pick from a zone height of 8 or 16.
    ...in addition to all of the great features that 7800basic receives from its batari Basic heritage. A special thanks goes to batari, who gave his approval and encouragement for using the excellent bB code base.
     
    There are still features to add, testing to do, and docs to write before 7800basic is ready for public beta, but it's in the home stretch now.
     
    [edit]update #2 posted.
  2. RevEng
    stella's voice
     
    The 2600 isn't widely hailed for it's luxurious sound.
     
    The TIA chip, which is responsible for the sound of the 2600 as well as the video, was designed with fairly minimal audio capabilities. On it's own it has the ability to make fairly simple tones, rumbles, and white noise type sounds.
     
    Similar to how you need to "race the beam" to draw anything useful with a 2600, you also need to "ride the speaker" to add interesting audio texture to your sound effects, changing the frequency and volume content as the sound plays.
     
    Further complicating the business of making interesting sounds is the fact that there are only a handful of frequencies to pick from in TIA's upper range, stemming from TIA's base-frequency-divider design. If you want a high pitched sound that shifts around, the transitions just aren't going to sound smooth.
     
    One of the biggest hurdles to sound-coding on the 2600 surprisingly comes from wetware limitations, not hardware inadequacies. Our brains treat a sound more or less as a whole unit, rather than a collection of individual frequencies. Even when playing back a sound over and over, most people will have difficulty naming more than basic changes in the fundamental frequency, and even then they can do so only over a relatively large timescale.
     
    In this sense, it's more intuitive for us to race the beam than it is to ride the speaker.
     
    samples
     
    One solution to this problem is playing back a sound sample. That way the coder remains blissfully unaware of the frequency content, but still can reproduce the sound.
     
    The problem with sample playback is it needs to happen frequently and continuously. On the 2600 that translates to a complicated kernel design (or one that blanks while playing) and eats up valuable rom space.
     
    I set out to investigate an alternative approach to sound reproduction by writing an FFT to TIA sound converter. The converter would generate lower-rate samples that would contain TIA frequency information. The plan was for this to be a kind of middle-ground between simple sound generation and expensive sample playback.
     
     
    the converter
     
    FFT stands for Fast Fourier Transform. Without going over a bunch of theory, it's a way of picking out what frequencies are present in a length of data, and what strengths they're present at.
     
    So the converter opens the WAV file and performs a sliding window FFT on it - in other words, it figures out the frequencies are present in each 1/60th of a second chunk.
     
    Then it looks at which frequency is loudest in each chunk, and finds a nearest TIA frequency match.
     
    There are a few things that are wrong with this approach overall.
     
    First, it completely ignores the fact that a sound is made up of more than one frequency. This makes the implementation easier, but limits the kind of sounds we can accurately represent.
     
    Second, it uses square wave TIA frequencies to represent the sine waves in the FFT, which potentially changes the character of the sound a bit.
     
    Third, it completely ignores the phase of the frequencies. Phase differences between related frequencies tend to provide a lot of texture to sounds.
     
    But since my design goal wasn't to perfectly reproduce the sound, I figured it would be worth trying to see what kind of results I would get.
     
     
    sound results
     
    I've attached a zipfile below that contains 2600 binaries, batari Basic files, and the original WAV files. The 2600 binaries play the sounds on startup, and then play again if you press the fire button on the joystick.
     
    The pacman-eats-a-ghost sample is pretty close to what I was hoping for as a result. Comparing the TIA sound playback in stella to the original WAV shows the converter nicely simplified the sound. It's not the same sound, but it's close in character.
     
    Pacman-dies is interesting because it highlights TIA's weakness in the upper range.
     
    The original sound sample starts off at a higher pitch, and our simplified tonal sample doesn't do a great job of representing it until the sound gets a fair bit lower, near the end of the sample.
     
    Haha is a short sample of a laugh. The original sample had fundamental frequencies below the range of my FFT routine, so it picked up on upper harmonics. Because of that the result isn't accurate, but has a neat texture that would make a neat sound effect for an underwater animal or weird space alien. [edit - a low pass filter, as suggested by batari allowed the routine to find the lower fundamental!]
     
    Dkintro is a sample of the Donkey Kong level intro tune. I didn't plan to use the converter as a tool for whole songs, but I think the result here shows that a specialized FFT-to-TIA-song-data converter might be feasible.
     
    what next?
     
    With a fair bit of extra code the converter should be able to compare FFT results with FFT data representing TIA's various possible outputs, instead of trying to match fundamental frequencies. This would allow the converter to better represent more complex sounds and noise.
     
    It's a work in progress at this point, but if nothing else comes of it, hopefully I've inspired other 2600 coders to consider the texture of the sounds in their own creations.
     
    FFT_to_TIA_results_2011.05.25.zip
     
    [edit - low pass filtered laugh result added]
     
    SFX-haha-lowpass.bin
  3. RevEng
    Daniel Everett, a linguist who studied the Piraha - a small tribe of hunter-gatherers in Brazil - reported that while the Piraha know of food preservation techniques, they don't actually preserve any food for their own use. Instead, tribe members immediately share and consume their catch with the rest of the tribe, as a sort of gift economy. Preserved food isn't needed because at any one time, one of the tribe is sharing their bounty.
     
    As one of them explained, "I store meat in the belly of my brother".
     
    You're probably wondering what the heck all of this has to do with 7800basic. I've been recently reminded that our retro development community has a similar economy of good will. Instead of hoarding some new technique or tool, developers openly share their discovery. Help received is paid forward in the forums. Those that can't code, test builds, create art, and offer advice.
     
    7800basic hasn't been released yet, but already I've been receiving help. batari gifted his source code to the project. Eric Ball loaned me his irreplaceable CC2 so I could test 7800basic on real hardware. Bruce Tomlin gifted his sign7800 program. CPUWIZ assisted with bankswitching questions.
     
    None of these guys benefit directly from 7800basic being created, but they've openly shared what they can to make it a reality.
     
    I can't help but reflect on how cool it is to be a part of this tribe.
     
    --
     
    The title of the entry says "update", so I guess I should give a quick update on 7800basic progress.
     
    This week I finished the first pass of documentation, added a built-in (optional) pause-button handler, and wrote the bankswitch code.
     
    The elephant in the room that I've been ignoring until now is graphical ROM layout. I'm using DMA holes to avoid having to pad graphics with a bunch of zero bytes. This works great, but any time there are two or more graphic blocks in a ROM it makes it tricky to fill the hole between them in a useful and easy way. (keep the jokes clean, folks)
     
    My first pass at a solution for using this space will probably be to take any "alphadata" character display data and throw it into any holes. This is low-hanging fruit because it can easily be measured before the resulting assembly code is sent to dasm, so I don't have to worry about overflowing the hole. The downside is, unless your game has a ton of character data the holes probably won't be 100% used.
     
    I'm kicking around some ideas that would allow the basic coder to stick routines and regular data in holes, but none of them are likely to make it into the code before the beta release.
     
    Which is a nice segue for the next bit of info. At the current rate of progress the beta release should be ready in weeks, not months, and I'm already looking forward to seeing what you guys do with it.
  4. RevEng
    Between working on 7800basic, recent MESS updates, and a few side projects, I've been also working on a 7800basic game thats an update to the old classic, Crossfire.
     
    In its current state its a bit rough, with programmer graphics, preliminary sound effects, and just a few essential stats on a plain scoreboard. On the plus side its playable, the difficulty does ramp up, and there's Crossfire fun to be had.
     

    salvo2085.bas.a78
    salvo2085.bas.bin
     
    The project is eventually supposed to be a re-imagining of Crossfire, as if Williams had riffed on the concept. I have the basic implementation of hyperspace/shield/smart-bomb pick-up items, though they need more glitz. Given time I'll add humanoids to save, and a few more wrinkles. (which I'll keep close to my chest for now. )
  5. RevEng
    the ascent
     
    Mountain climbing is an activity that can be done many ways.
     
    Mountaineers may employ sherpas to assist, or they can choose to climb only with other mountaineers. They may set up base camps at which they have large amounts of supplies, or they may simply climb steadily, carrying a meager stock of supplies that must last the whole trip.
     
    The list of optional equipment a mountaineer may employ is also pretty long - supplemental oxygen, crampons, ice axes, tents, high-tech thermal body suits, etc.
     
    Sometimes mountaineers and enthusiasts complain that other mountaineers are cheating due to the techniques they employ or the equipment choices they make. They feel the climb should be equally hard for all, and those who employ special gear to lighten the task are cheaters, not worthy of sharing the title of mountaineer.
     
    In this respect Atari 2600 programming is like Mountain Climbing.
     
    mount fuji
     
    The modern 2600 game coder has a lot of choices to make. There are well over a dozen different cartridge configurations to choose from, most with additional ROM via bankswitching, some with additional RAM, and yet others with additional processing like the Activision DPC boards or Melody boards with DPC+.
     
    Coders even have a choice of coding in pure assembly language, or batari Basic.
     
    And it doesn't end there.
     
    Both bB and assembly coders must choose between using Other People's Code, or writing their own. OPC for bB coders means using built-in libraries and kernels. OPC for assembly coders means using key routines that have been passed from hand to hand, posted on mailing lists and forums.
     
    And for those that choose to write their own code, rather than using OPC, can use undocumented 6507 instructions that weren't widely used historically, or work only with the official instructions. Similarly, they can use techniques that have been learned and documented in the era of the 2600 homebrew, or keep their techniques strictly to those documented in the Stella programming documentation.
     
    With all these choices, it's not a surprise that someone, somewhere, regularly declares that using one technique or another is a cheat. And, to use the analogy, often the person making the complaint isn't even climbing up the mountain with just his own two hands.
     
     
    where's the top of your mountain?
     
    If you're a 2600 game coder and your primary goal isn't "make a great game", then I'm respectfully going to suggest you should consider coding demos instead. Coding demos can prove your technical chops just as well as coding a game, without foisting yet another poor-to-average game on the 2600 library.
     
    If you want to have a secondary goal of constraining your choices, then by all means go for it! Just don't cry foul when someone else doesn't share your secondary goal. Why should they?
     
    Some of us just want to get to the top and enjoy the view.
  6. RevEng
    answer me these questions three...
     
    I mentioned in my first WIP article that I have three criteria for evaluating a game idea.
    Is my concept really technically feasible?
    Is it interesting?
    Is it fun?

    These are sometimes tough to answer without a prototype, so I'll often throw one together to evaluate these points.
     
    While it may seem like insanity to code up something I may well throw away on a system as tough to program for as the 2600, I generally work in batari Basic, so it takes very little time. In a lot of ways, bB is like a RAD environment for the 2600.
     
    a math war, in space...
     
    Ever since I was a little kid I was fascinated by the gravity simulation in Spacewar!, and I always felt the 2600 version went light on the physics, so I thought I'd code up a version that was a bit more accurate.*
     
    Gravity follows an inverse-square law. So if your ship moves out 2 times as far from the sun the force of gravity should drop to 1/4 of the previous amount...
     

     
    Since the 6502 isn't particularly good at calculating the required math for this on the fly, I needed to use a lookup table. Using the fact that the table is symmetrical in nature, I was able to give it a decent range of coordinates while still being able to squeeze it into a single 4k bank.
     
    After that, it was a cinch to add the code for basic gameplay.
     
    cywar...
     

    cywar.bas.bin
     
    I think from a simulation point of view, cywar succeeded. Its relatively easy to put yourself in a circular or elliptical orbit around the sun, and depending on your initial velocity the orbit can be very stable. (or you can watch it slowly decay)
     
    A few things to note:
    There are more rotational positions for the ship than in Asteroids or Spacewar 2600, providing finer control over the thrusting and shooting.
    The ship's velocity is added to the initial missile velocity.
    Flipping the difficulty switches to A makes gravity act on the missiles.
    Hitting the select switch toggles between regular and inverse gravity.

    For me this prototype provided a "yes" answer to the first two questions. For the question of fun, the answer isn't all that strong. For me it's a bit fun... kind of like Combat with less variety. Or unsurprisingly, like Spacewar 2600 with a better gravity simulation.
     
    I think the gravity mechanic might be more fun as part of a multi-screen space adventure, rather than just a straight Spacewar! knockoff. Maybe something like "journey to the planets" for the A8, with a touch of space combat like Star Trek 2600, with some planet combat like jrok's "redshirts".
     
    Get yourself to a planet of interest, set yourself up in a stable orbit, and beam the crew down for their away mission! It's an idea that's shelf-worthy anyway.
     
    -Mike
     
    -----------------------------------------
     
    * - It should be mentioned that this is by no means a slam on spacewar for the 2600. It's a 2k rom, and does an admirable job of faking gravity given those constraints.
  7. RevEng
    The 7800basic 0.1 beta is now public.
     
    It's possible to create games with 7800basic, but it's by no means finished. I figured I'd share some of the features I have planned, in no particular order...
    some mechanism to fill those pesky DMA holes that I mentioned in the last blog entry. This isn't a particularly sexy feature, but not wasting 2k/4k of space between graphics areas is important.
    adapt the nice hex2bcd conversion routine that omegamatrix wrote
    a plot command for drawing fuel gauges, energy bars, etc.
    SaveKey/AtariVox save support
    AtariVox voice support
    HSC support
    Pokey support
    the ability to specify zones in different graphics modes
    formal scrolling support
    I'm sure someone has suggestions to add. Feel free to post them here, or in the 7800basic thread. I'd love to hear them!
     
    But before tackling the feature list, for a short moment I'm just going to stand and enjoy the scenery. By which I mean continuing work on the 7800basic game I started.
  8. RevEng
    News...
     
    If you don't want to read the wall of text here, there's really there's just one update here: PAC-MAN-RED has kindly signed on for working on the graphics for Salvo 2085. The visuals in the final version should be top notch!
     
    I thought I'd also take this opportunity to share some behind-the-scenes stuff, for those of you that like reading about development details.
     
     
    ...Fireworks...
     
    While the current Salvo 2085 graphics are a mix of modified arcade sprites and programmer graphics, I am particularly proud of the explosion effects.
     
    When I started the game, I knew I wanted to do particle based explosions. I searched for software to do this, but I couldn't find anything that would generate simple low-res particle effects. I could have gone with full blown 3D animation software and tried to generate something that would convert down to low-res 2D, but I didn't want to put a whole lot of work into that and take the chance that the conversion results would be disappointing.
     
    So in the end I wrote my own quick and dirty C program to simulate particle explosions. It models the initial velocity, air resistance, and gravity. The easiest way to get the particle effects into 7800basic was through its built-in PNG graphics import, so the simulation outputs each frame as a PNG image.
     
    The nice part of having my own explosion simulation is being able to tweak parameters to suit the graphics restrictions - height, width, # animation frame - rather than sticking with real life parameters.
     
    For the enemy explosion I dialed in the parameters to provide an energetic and wide explosion, and coded the simulation so the particles disappear when they hit the floor. I also tweaked it so the floor is a slight curve, rather than a straight line, as it looks more natural.
     

     
    For the player explosion, I wanted to do something a bit different. I made it a bit less energetic to provide a fall-apart effect, and the particles also playfully bounce a few times when they hit the floor. (just what the heck is he made out of? )
     

     
    I was impressed that I could get two fairly distinctive looking effects from small tweaks to the same simulation, and glad I took the time to code up my own routine.
     
     
    ...and Dog Food
     
    I know how to code in assembly, and I have an M.O. of working on games that are a heavy mix of bB and assembly [1,2]. I usually do it that way so I can choose the optimum balance of rapid development and flexibility.
     
    I'm not doing that for Salvo 2085. I am determined to code it entirely 7800basic, because it's a matter of eating my own dog food, and proving that good things can be done in the language.
     
    That isn't to say I'll compromise game quality. If there's some feature that needs to be added to the language to make the game better, I'll do it. Already I'm seeing that I need to add an easier import for tall graphics, to help with title screen banners. (which could also be used for less efficient, but easy-to-move massive sprites.)
     
    So while I'm diverting my time away from 7800basic development with this game project, 7800basic will be receiving dividends from the work.
  9. RevEng
    checking sprite and tile "collisions"
     
    The 7800 has 2 types of display objects, sprites and character/tile graphics. Usually a game's display is made up of tiles for the background, and sprites for the moving objects.
     
    As a game designer, at some point you'll probably want to check which tile(s) your game sprites are moving over, or about to move over. Maybe you need to check if pac-man is eating a dot, or if the adventure hero is going to hit a barrier.
     
    Checking tiles underneath a sprite is slightly complicated by the fact that tile graphics use a different positioning resolution than sprite graphics do.
     

    tile/characters coordinates overlaid on a 160x192 screen.
     
    We can check which tile is under any single point on our sprite by taking the sprite coordinates and dividing the X and Y coordinates by X and Y conversion factors. The exact conversion factors you use will depend on the tile resolution you're using.
     
    Lets take the example of a full screen of 320A tiles with a zoneheight of 8. The tile resolution for this format is 40x24.
     
    The sprite positioning resolution is always 160x192, in all modes on the 7800, even the 320 ones. If we divide our max sprite resolution (160x192) by our max tile resolution (in this case, 40x24) we'll have the conversion factor.
     
    In our example with 40x24 tiles, the conversion factor is 4x8. (160/40=4, 192/24=8 ). To convert any sprite coordinate to a tile coordinate, we'll divide the sprite X by 4, and the sprite Y by 8.
     
    Now that we've converted the sprite coordinate to a character coordinate, looking up the character underneath that coordinate is a snap, with peekchar...
     

    lookupchar=peekchar(mapdata,tilex,tiley,40,24)
     
    The value returned will be the character index - literally the location that tile within the graphics block. If you're unsure which value you need to check for, you can always display the value returned by peekchar using the plotvalue command.
     
    which points should you check?
     
    If the sprites in your game are always aligned with your characters - if the sprites never overlap any tiles - then you can use any coordinate underneath the sprite. The one you use to plot the sprite is probably handy.
     
    But most games have smoothly moving sprites, which can overlap multiple tiles in both X and Y. While checking every point underneath the sprite isn't computationally feasible, in these cases you'll probably want to consider more than one point when checking for movement collision.
     
    To do a check to see if a sprite can move upwards without interference from character barriers, it's typical to check 2 points above the player - one at the top-left position of the sprite, and another at the top-right position - and see if both contain character #'s you have designated as "walkable". If so, then the player is allowed to walk upwards.
     

     
    For other directions you'd check another 2 points. For example, when moving left, you'd check 2 points just left of your sprite, one at the top-left corner of the sprite, and another at the bottom-left corner.
     

     
    Keep in mind that this isn't a recipe that you can adapt to every game. Other games will need to check other sprite points, as game mechanics require - the pac-man code checks the sprite point near the center of the pac-man sprite, to see if he's eaten a dot tile. Similarly, you'll need to decide which parts of your own sprites need to interact with the tiles.
  10. RevEng
    "Time it was, and what a time it was, it was
    A time of innocence, a time of confidences
    Long ago, it must be, I have a photograph
    Preserve your memories; they're all that's left you"
    -P. Simon
     
    new code, old system...
     
    For the last few years I've been writing code for the Atari 2600 in my free hours.
     
    It's been said that the toughest game system to program for is the 2600, so it's only natural that at a 2600 coder weighs exactly why he's jumping through hoops with boots on.
     
    People are drawn to program old systems for dozens of reasons. Some are revisiting their childhood wishes, some do it for the challenge, some enjoy the resistance of the medium, and some do it for the groupies.
     
    A big part of the draw for me is that its my way of remembering times gone by, without the tedium of playing the same old song over and over again; I riff on older memories to make them new again. As an added bonus, my work can create homebrew games that allow other people to make their old memories new again too!
     
    But not every bit of code that gets created is turned into a homebrew. For me, the first step in the development process is often to start with a prototype, mainly because I have some gaming dynamic or code technique that I want to test out.
     
    So I work at it. And work at it. And work at it, until one day I finally have something to look at and try out. Then comes the contemplation.
     
    Is my concept really technically feasible? Is it interesting? Is it fun?
     
    If the answer to any of these is no, I shelve the code and move on, a little sadder, a little wiser.
     
    I thought I'd kick off this new blog by taking one of these works down from the shelf and sharing it with you.
     
     
    apocalypse then...
     

     
    This one was to be called z-tactics, short for zombie tactics. It was my first assembly project, and it was an ambitious one.
     
    The idea in this game is that you're the head of a tactical unit that's trying to control a zombie outbreak. Everything is seen from a high map level - the deep purple is the zombie infection, the green is territory with life, the light purple are barriers, and the black is territory that was overrun by zombies but is now barren.
     
    Also on the playfield would be different power houses, which you'd select to activate that ability. One power house would give you the ability to build barriers. Another would give you "radiation", which you'd use to burn the life off a square which would create a kind of barrier, though there would be a small chance the radiation would cause a mutation and cause a zombie outbreak on that square. I also had the idea of a nuke house, which would level a big patch of ground.
     
    When used, each of the powers would deplete, and you'd have to wait for it to replenish, which would take more or less time depending on power. But if the square with a power house was overrun with zombies, you'd lose that power.
     
    I stopped working on z-tactics for a few reasons.
     
    The prototype and concept was technically feasible and interesting, but I wasn't convinced it would be fun. For me, "interesting" can be a source of "fun", but I realize for a lot of other people it isn't.
     
    I also realized that the majority of the 2600 fanbase want an action experience, and really aren't interested in semi-complex strategic games.
     
    Here's the binary, in case anyone is interested. It's not playable, but you can move the cursor around, and watch the green patches turn purple and the purple patches turn black.
     
    ztactics.bin
     
     
    what comes after z?
     
    It can be depressing to waste coding effort, but I don't feel too bad about shelving it now. A lot of the code and knowledge from z-tactics turned up in new efforts, like 21 Blue and the bB Titlescreen Kernel.
     
    Code is funny like that. Just like old game systems and nostalgic memories, it also wants to renew itself over and over again.
     
    -Mike
  11. RevEng
    One of the easiest ways to create phrases for AtariVox is to use the PhraseALator utility. PhraseALator is provided free of charge by the folks who create the SpeakJet chip in the AtariVox, Magnevation.
     
    Using a TTL level serial port, you can connect your AtariVox to your PC and pull it's strings from a nice point-and-click interface.
     
    You can use Phrasealator to lookup words in a dictionary and play them back, or you can use it to compose your own words; single-clicking on any of the phoneme buttons will preview the sound of the phoneme, and double-clicking on the button will add the phoneme to the current phrase.
     
    PhraseALator is a closed source program for Windows, and my main platform is Ubuntu, so I decided to create a similar program that could run under Unix type OSes. Speakalator uses GTK for the GUI and standard C Unix libraries, so it should be quite portable.
     

     
    As a bonus, batari kindly allowed me to incorporate code from his word to phoneme utility, so speakalator can make a best guess at words that aren't in the provided PhraseALator.dic dictionary.
     
    A Linux x86_64 binary is included, otherwise you'll need to build from source.
     
    The program expects the included speakalator.glade and PhraseALator.dic files to be in the current working directory when it runs. In the present version there isn't a config file, so the serial settings aren't saved from session to session.
     
    speakalator-0.1.tar.gz
  12. RevEng
    One of my back-burner projects is a spiritual sequel to M.U.L.E, for the 2600. So far I just have a planet kernel, species+color choice kernel, and the beginnings of a theme. The game will be developed at my usual glacial pace, so I figured I'd share the theme, as it could be appreciated on its own...
     
    irata_music.bin
     
    When working on it I diverged from my typical process a bit. Usually I compose in Rosegarden and then convert from MIDI to assembly data with TIA values obtained from webtune2600. This time I transposed the song and re-converted a few times until the off-tune notes were pushed to less obvious parts of the song. (ie. not related to the major third, harmonic fifth, etc.)
     
    It turned out pretty well, I think!
  13. RevEng
    For a while my time has been occupied with work and 7800basic updates, but in recently days I've managed to squeeze in some Salvo updates.
     
    Gameplay additions include:
    Humanoids to save. The enemies shots don't kill the humanoids, but if the enemies touch the humanoid it will die. By running over the humanoid he'll follow you for the rest of the level, so you can steer him to safety.
    Presently there's no penalty for losing all your humanoids (other than points) but I have more plans here.
    challenging stages at the end of two levels. Shooting all of the enemies in a challenge stage will earn you a free man. I'll be refining the later patterns, but most people probably won't see those.

    salvo.bas.a78
    salvo.bas.bin
     
    Despite the game's Crossfire heritage, I think you'll find it's already starting to take on its own unique flavor.
     
    Enjoy!
  14. RevEng
    One of my back-burner projects, was a 2600 version of M.U.L.E. It was just an inkling of an idea, and I even toyed with the idea of a different sort of game in the same universe.
     
    I've posted about it before, but reworking the M.U.L.E theme for TIA was a hoot. I'm particularly proud of the section in the middle, where the original tune does a series of upward key changes. I managed to replicate the same same rising feeling without the problematic key changes, by laying down a series of ascending notes underneath the non-key-changed melody.
     
    mulemusic.bin
     
    I'm a big fan of TIA music that's in-tune, without needing to do the Pitfall II trick. TIA sounds great if you throw the right notes at her. The mule music was written before I came up with the idea of Perceptual Tuning, but I managed to keep it in tune by shifting the key until I found one that worked. Nowadays I'd just start off in A3. And while I'm at it I'd likely use a more advanced note priority systems, so I could cram more TIA goodness into the tune, like I did with the T:ME Salvo theme. That said, the TIA M.U.L.E theme was an instrumental experience that led to the Salvo theme, so there's no regrets.
     
    I wanted to add some visual interest to the music player, so I took the standard colorbars, and tweaked them a bit. I'm actually taking one upward set of colorbars, and one downward set of colorbars, and I'm ORing them together.
     

     
    The result is interesting, I think. A bit hypnotic, with a backdrop of yellow patterns, that give way to splashes of color that soon disappear back to yellow. On the other hand, the patterns cycle after 256 frames, so I might have done better to move the two source colorbars a different rates, so they have a a longer period. 
     
    Colorbars on the 7800 are pretty much the same as on the 2600 - you change the color register and hit WSYNC. You can see that my interest in tweaking the traditional colorbars continued into my 7800 work, when you look at the Salvo titlescreen logo. Here chroma and luma are manipulated separately, with the colorbars getting shaded as a result.
     

     
    I think there's some interesting ground to be covered in coming up with alternate colorbar styles. Nobody is excited to see plain old colorbars anymore, so why not amp them up a bit?
     
    Back to M.U.L.E, there's the M.U.L.E experimental "planet kernel" I came up with. I think I managed a reasonable approximation of the M.U.L.E planet elements here...
     

     
    muleplanet.bin
     
    ...the plot "ownership" boxes has to be substituted with ownership bars, and the number of plots is reduced from the computer versions, but I think it's still essentially M.U.L.E.
     
    I hope my M.U.L.E music and planet kernel gives you a taste of what could been, in an alternate timeline where EA decided to support the 2600. On the down side, we'd have a dozen Madden 2600 games to contend with.
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2023 AtariAge

×
×
  • Create New...