Jump to content
  • Advertisement

Trapper Zoid

  • Content count

  • Joined

  • Last visited

Community Reputation

1370 Excellent

About Trapper Zoid

  • Rank

Personal Information

  • Interests
  1. Trapper Zoid

    Sound wave generator - quick update

    The OPL2 chip in Adlib cards used 18 oscillators, each representing a sine wave, and output at nearly 50kHz, so that's approaching a million trig calls a second. I'm not sure what the speed is of the trig function calls on today's hardware; I'll make a note to check. I don't think it would be a bottleneck if I did use a million trig function calls on today's hardware, but I'd like to compare it with lookup tables regardless to test whether there is a noticeable difference to how it sounds.
  2. Trapper Zoid

    Sound wave generator - quick update

    I tried implementing the sound wave generation looping through hard-coded samples rather than algorithmically, but I have issues with the current implementation. The basic approach is straightforward but it took a couple of days to debug and the result still doesn't sound right. Apart from the output sounding lower quality, it is clearly out of tune. Not sure what is going on there - whether it's a discretisation thing, something with converting floats or merely another bug. I decided to go with samples because it's very easy to add new wave forms. Create an array of floats for one wave period, plug it in, and you're done. AFAIK its the way sine waves were done in hardware due to how computationally expensive they are to calculate. Plus if I get around to adding normal non-looping sound files to this system it's done in the same way. My gut feeling is that it is better to go back to implementing the core of this system as if it was on a hardware chip - using simple hard-coded algorithms, different for each tone, based on bit registers with different purpose per waveform - and then add a layer on top of that to convert instructions like "channel 1, triangle wave, 440Hz, half volume" into the right register values. Eventually I want to play around with phase modulation, like what was used on the Yamaha chips used in Adlib sound cards or the Sega Genesis/Mega Drive, once I get my head around how the operators worked in hardware.
  3. Trapper Zoid

    Buzzer Trio

    While implementing the tone generators in software I figured there's little reason not to simulate the actual clock speed of the hardware, at least to begin with. It means doing about six times as many calculations, averaging out the half a dozen sound values to the single one at 44100Hz rate sent to PortAudio. But when we're talking about a few odd million calculations per second with today's processors it won't hurt to add in a few million more. I really doubt any CPU bottlenecks of the future will be in the audio subsystem. The three tone generators and noise generator are up and running. I'll need to play around more with the noise generator to learn how to properly use it, but the tone generators seem straightforward enough. I hand-coded in a short music demo to test how it sounds: Three Square Wave Moonlight Sonata (no voltage drop-off): (I'm going to have to find or figure out a good way to represent sound data as commands, as hard cording everything in a big ol' integer array isn't the best solution.) I've been playing around with simple ways of moving the sound beyond pure square waves to give the sound a bit of a more hardware generated sounding feel. So far all I've tried is a simple voltage drop-off, a method suggested in the Sega emulator page from the last entry. In hardware, the voltage when held will drift back towards zero. If you're using a float based internal representation for your sound data, it's pretty simple to mock that up by storing the output and multiplying by a fraction close to one (0.99...) every cycle. In terms of effect, the multiplier morphs the square waves more towards being sawtooth, affecting lower tones more than higher ones (they have longer wave periods so the voltage is held away longer). And it also dampens the overall volume too, more noticeable for the stronger values: Three Square Wave Moonlight Sonata (0.999 multiplier per cycle): Three Square Wave Moonlight Sonata (0.99 multiplier per cycle): Three Square Wave Moonlight Sonata (0.9 multiplier per cycle): I think I like the sound somwhere between three or four nines: it's close to the original but with some more interesting edge to it. But two nines has an interesting hardware sound too, and the crappy hardware sound of one nine is a nice effect.
  4. Trapper Zoid

    SN76489 - Partying like its 1984

    For my little retro-sounding software audio system, the sound chip I'm looking for inspiration is the Texas Instruments SN76489. It, its variants and various clones were used in a lot of hardware from the eighties, like the Sega Master System and the Game Gear, the ColecoVision, the BBC Micro and the IBM PCJr/Tandy 1000. I'm not trying to directly emulate the SN76489 as closely as possible, but it will help to start by looking at how this chip works so I can make something that sound appropriately "retro"-ish. The SN76489 features three mono square wave tone generators and one white noise/periodic noise generator with 4-bit (16) volume settings. I'm picking it as a starting point because it's one of the simpler sound chips in terms of operation yet can still make some nice tunes. Plus I grew up playing adventure games on a Tandy 1000 HX so I've got fond memories of those triple square wave tunes. Useful SN76489 links: Wikipedia page for Texas Instruments SN76489 (links to chip datasheet in footnotes) SMS Power page on the SN76489 with info for Sega emulator developers Sierra AGI specification for the sound system, including IBM PCjr The links go into the details, but I'll sum up the basics: The chip has eight internal setting registers which are set with byte sized commands to the input pins. The setting registers are: 3 x 10-bit frequency settings for the square wave channels 3-bit control mode for the noise channel ("periodic" or "white" noise with one of four speed settings) 4 x 4-bit attenuation (volume) registers for the four channels The chip gets a clock signal which it then turns into a internal clock. Different varieties of the chip allow different input clock frequencies - some allow up to 500kHz and divide by 2 for the internal clock, but the ones used in the consoles and computers appear to be the type that allow up to 4MHz and divide by 16. Either way ends up with an internal clock of up to 250kHz. But "up to" is the critical point - both the Sega and the Sierra links above say the standard operation was to tie the clock to the NTSC TV colour subcarrier frequency of 3.5795MHz, which gives an internal clock of 223.7kHz. The clock frequency directly affects the output frequencies so it will make a difference. Each square wave tone channel has a 10-bit counter and an output bit. They work by resetting their counter to the value in their 10-bit frequency setting register until they reach zero, where they flip their output bit and reset their counter again. The white noise generator uses a 15 or 16-bit linear feedback shift register, where the output is the bit that is shifted out the end and the input bit at the other end is determined by XORing two bits together (usually on the shift register). These are described in detail in the SMS Power page above if you want the details. It seems this is the part that varies the most between different chip designs, which might be important for anyone wants a characteristic noise generator for a specific system. Each of these four channels outputs 0 or 1, which is set at their volume attenuation levels and combined in a mixer to get the analog output. There are a lot of further subtleties that are better explained in the linked pages (especially the SMS Power one for Sega emulation), but the basics are fairly straightfoward: counters and shift registers. Thoughts: Something I'll have to design for is the difference in clock speeds between actual hardware and software (semi-)emulation. My software is (probably) going to output audio at 40-44kHz, rather than the internal clock speed of 220-250kHz. I'm going to have to think of a good way to get info from my program to the sound generation code. PortAudio's documentation says to avoid using mutexes in the callback function. I haven't done much tinkering with threads but I think as long as I keep the data transfer small and simple it will be fine, as the worst that could happen if the callback happens mid-data set is a brief sound spike. Going to have to think of a way of encoding this type of audio in a more human understandable way than raw register settings, but that can wait until after I get the basics done. I think the SN76489 was first used in 1979 or 1980 but it was used all throughout the 80s. I have to pick a year from somewhere in the decade. IBM PCJr and the Tandy 1000 came out in 1984, along with the garish 16 colour wonders of EGA - somewhere else I might be going.
  5. Trapper Zoid

    Things that go beep

    I've been looking deeper into the audio system of Allegro 5, looking to see if I can do some tone generation for some retro-sounding bleeps. It turns out that Allegro 5's audio system isn't the best for this kind of thing. Generating waveforms is simple enough. What I needed was a way to get my raw data from my own data structure to the OSes sound system. That's the sort thing a framework like Allegro 5 was designed to hide, not give easy access to. I also found the documentation on the audio system tends to gloss over the advanced features. There is a callback function for Allegro's mixer data structure, which is designed for post-processing but can be used to set the values directly. And it works - mostly. The problem I found is that there is no way to manually set the update rate that the callback function is called. For my system and the audio settings I was trying (mono 16bit int sound) the function was fixed at 2048 samples per call. At a playback rate of 44100Hz, that's roughly a twentieth of a second per call which is a noticeable amount of lag. As far as I can tell from sifting through Allegro's source code there isn't any function calls or config settings to alter that short of putting them in the library myself. Which seems more trouble than it's worth given I'll probably break everything trying to make Allegro do more than it's supposed to do. The better answer to me is to look for an audio library that is designed for this kind of thing. I'm trying out PortAudio. I haven't had much time with it yet, but so far I've got it running and outputing square wave beeps with a callback function running on my own set number of samples per call. 256 samples and the beeps sound instantaneous. Given that's all I need PortAudio to do, I'm happy. The downside with a low-level library like PortAudio is that is all it does, so if I want to extend this to working on wave files I'll need to write my own loaders. Right now, I'd like to see how far I can go with old-style tone generation. Additional: I've noticed these journals have tag functionality, which I'm currently not using. Is there a standard for how tags are used on GameDev.net?
  6. Trapper Zoid

    Initial thoughts on Allegro 5

    Having PhysicsFS already wrapped into Allegro is a time saver in itself. Plus the fonts work (I never got SDL_ttf to work under SDL 1.2). That said I probably would have gone with SDL 2.0 due to my familiarity with SDL 1.2 if it wasn't for their Mercurial repositories being down when I went to check it out. I'm kind of glad they were, because Allegro 5 looks slightly more my style.
  7. Trapper Zoid

    Initial thoughts on Allegro 5

    SDL has been in this weird limbo between 1.2 and 2.0 for years. SFML seems nice enough from what I've seen and I know there are loads of people on the forums who swear by it, but it's very much a C++ library.
  8. Trapper Zoid

    Initial thoughts on Allegro 5

    I've got a simple "try all the basics" program running using Allegro 5 - bouncing bitmap with sound effects, playing music with an on-screen FPS counter using the font system and outputting keystrokes to the debug console. Nearly everything seems to be working fine. The only thing I haven't got working is tracker music formats, but since I'm not sure if I need that I should be fine with Ogg Vorbis. Bitmap-wise I know Allegro can read PNG files and that's all I need. From my brief look at Allegro 5 so far it seems like it will do everything I want it do. It's quite straightforward and simple enough to integrate with whatever I wish to do. I'll need to try it out on something proper to get a better feel of it of course, but so far it feels nice enough. The only real hassle was getting all the libraries compiled and linked correctly, especially when I wanted to move from the standard defaults. Make sure there are separate debug and release libraries. Do you build for 32-bit only or also 64-bit, and maybe PowerPC if you're on a Mac? Do you go with dynamic linking, where you have to make sure you bundle all the libraries with your game and link them correctly, or static linking where you have to make sure the compiler links with the right libraries instead of defaulting to the dynamic ones. It wasn't particularly difficult, but it did involve heaps of retries and fiddling with settings to get it done right. I must of recompiled and reinstalled the Allegro libraries about fifty times. I'm going with static linking BTW, because I think I'm less likely to screw up including the right libraries at release time. I'm not sure about the 32-bit vs. 64-bit decision. I don't think it will make much difference to compile for both, but I also don't think it should make much difference for the sorts of 2D games I want to make to stick with 32-bit only. I had a check of all the games installed on the iMac I'm developing on and all the games appear to be 32-bit only (or older, PowerPC and/or 32-bit games; no 64-bit at all) so I assume there is some reason behind that.
  9. Trapper Zoid

    #define JOURNAL_VERSION 3.0

  10. Trapper Zoid

    #define JOURNAL_VERSION 3.0

    Hey all. The GameDev journal is out of mothballs once again, rebadged and back in circulation. I'm hoping to post more often here in the immediate future, keeping things informal and the posts short so I don't get distracted by blogging instead of ending my game development hiatus. It will be good to be lurking around the journals and forums. Right now I'm getting back into gamedev basics by playing around with Allegro 5 using my old friend C. I've only had a very preliminary look at Allegro 5 so far, but my overall impression is that it's a pretty sweet, simple framework for doing everything I would like the library do with a very straight-forward, C library way.
  11. Trapper Zoid

    I'm back, and ready to ActionScript

    Heh, a response makes me feel bad I disappeared again. I stalled for a bit on figuring out AS3 architecture and then my computer broke. I'm still here, but lurking until I have something worth posting. I'll have to make sure that's before the end of the month.
  12. Trapper Zoid

    ActionScript #1: Setup

    I've been struck with the dreaded lurgy, so I'm working somewhat sporadically. Still working through the basics. Setup I've got a new Windows 7 PC which hasn't had much set up on it, so the first thing to do is load up everything I need. Sounds straightforward, but it always turns out to be more hassle than you think. Version Control I probably won't need version control for the simple stuff I'll be working with in the first week or two, but if the point of the exercise is to rekindle decent game programming habits then it's best to start early. While I'm working solo on these projects, I'd like to be able to sync code between computers. I've got a Win PC and a Mac and I like to do things on both. Previously I've been using SVN on a single computer, so I tried to come up with a straight-forward way for two computers to share the repository. But everything I tried was ugly. So I've decided to try a distributed source control method instead and switched to Mercurial. I've only played around with tutorials so far but it looks like a much better approach for my work flow; it's a lot easier to set up repositories whenever and where-ever I like. Mercurial was very easy to set up on both Windows 7 and Mac OS X, so no problems here are all. It was surprisingly simple actually - version control usually has a lot of setup pains. I'm looking forward in seeing how Mercurial operates. flixel Next stop was to flixel's site. flixel is a great open source ActionScript library that I briefly looked at last year. My thoughts at the time was that the structure was eerily similar to my ideal simple game architecture that I'd been playing around with in C++, except in Actionscript. And the site is aimed for beginners, so it's got links to all the resources I need. For now, my exercise is to rekindle some basic game programming techniques, so I'm going to be working from scratch as a learning exercise. However flixel itself is a great resource for learning how to do things while I learn. And once I'm up to speed with ActionScript, I'll probably dump all my crappy learning code and switch to flixel. I haven't yet used or even looked at flixel's code, so no judgement calls yet - other than I really liked the look of it a year ago. Flex SDK Now for the actual development tools itself. Flex SDK is the free development kit from Adobe. Simply grab the latest copy and unzip. Pretty straightforward setup. FlashDevelop Next thing to install is FlashDevelop, the free open source IDE for ActionScript development for Windows. As well as the program itself, FlashDevelop says it requires Flex (already got), the .NET frameworks (already got previously) and the latest Java JRE. Despite saying it needs Flex as an external prerequisite, when installing FlashDevelop through the online install doohicky it downloaded another, slightly out of date version of Flex. Which is annoying when its about 200Mb on a slow crappy internet connection. Grrr. Oracle doesn't make it easy to install Java JRE. Their site is a mess, and their installer makes it a pain to change install directories (I had to manually make the directory structure myself). Nothing too major, but it's by far the most annoying install of all the stuff I've had to do so far. On to the code! And now, checking it all works! First gripe: FlashDevelop makes it hard to change the default editing font. The option is there, but it's under Syntax Colors for some reason. Annoying. Second gripe: The syntax checker crashes. Clearly I haven't set something up right. Looking into it, I think there's an issue with using the 64-bit version of Java JRE 6. So annoying. One uninstall, download and install of 32-bit Java JRE later (including going though many hoops to disable the Java Update Scheduler and replace it with my own scheduler: sorry Oracle, I don't want to constantly run your code merely to check for your monthly updates. And Oracle doesn't make it easy for you), and we're back in business. Grr. Third gripe: FlashDevelop has this weird autocomplete that doesn't seem to like the default Flash objects as options for import packages. I think it's aiming for a work flow where it automagically adds them as you include them in your code. Gripes aside, everything else was fairly plain sailing to get that first program running: Hello, Flash Player! Overall impressions thus far: Mercurial - looks promising! FlashDevelop - need to learn the kinks Java JRE - SO ANNOYING
  13. Trapper Zoid

    I'm back, and ready to ActionScript

    Thanks! I'm working out the kinks of this new-fangled journal system. Pretty snazzy compared to the old one from first impression. I still haven't figured out why I've got the Anonymous Silhouette avatar though. Edit: There we go!
  14. Trapper Zoid

    I'm back, and ready to ActionScript

    Hey everyone, I'm back! Looks like things have changed dramatically over in Journal Land. It's going to take a while to figure out the kinks with the new system. After (too long) a hiatus, I'm back at game development, looking to shake off the rust. My plan to reboot is to teach myself game development in ActionScript for the Flash Player. My impression is that Flash is a neat method of making small games or prototyping neat ideas and sticking them on the internet for all to see. There is also a bunch of great libraries now, like flixel and FlashPunk. What I'll be posting here is an informal journal of my progress as I work my way through ActionScript programming: what's neat, what's problematic, and what bone-headed mistakes I make along the way. Enjoy!
  15. Trapper Zoid


    This is the wrap up of my week long game dev experiment, cross-posted from my blog. The week is over, and technically I failed. Bummer. What I did get done was a tile-based prototype, shown above in the screen shot. It's an experiment for what a tile based puzzle game would be like if the tiles consisted of two colours, split at the diagonals. In the version above, the coloured sections get highlighted if there's a connection chain of four or more tiles long. Unfortunately, it's currently just a toy. I didn't think of a good way to make a game out of it. I was on my way to experimenting with a Tetris-like mechanic - matched tiles disappear, replaced with tiles above - but I ran out of time. I might continue working on this at some stage, but I'm doubtful. Coloured tile games don't excite me as a developer, mostly because I suspect every single gameplay combination has been done to death by now. I'm also not sure if it's worth posting the prototype: it's not fun, dead simple, Mac OS X only and spits log files into a subdirectory in your Library folder that you need to clean up after. Maybe next time. Part of the point of just having a week is that if I need to walk away, it doesn't feel like much of a waste. I'll need some time to evaluate what went right and wrong from this exercise, but I've got some ideas of how things went off the top of my head. First: I need to organise my time better. I just dove in, and while the time pressures helped me stay focused to begin with I went a bit all over the place with my focus. It would have helped to spend an hour or two at the beginning figuring out exactly what my objectives are, the best way to achieve them in the time available and pitfalls to avoid. With the haphazard approach I can get focused with deadlines, but I'm easily distracted by non-essential things. I also lost a lot of energy at the end which is part of the reason why I only got a prototype done. Second: prototyping in C is a pain. Having a better set of in-built functionality at my fingertips would give me a lot more flexibility. I wouldn't have to waste hours of work trying to think of a C friendly way to do the tile connection counting algorithm. Third: prototyping puzzle game ideas in a short period of time is hard. I suspect if I just did a simple action game I'd have got something finished in the time. It's easy to kludge together something amusing in the action game genre, but puzzle games live or die on their core mechanic. I don't know if this is inherent to the genre or just my lack of practice with the area. Fourth: if I'm not excited by the idea, then it's really hard to crunch development. I didn't exactly go "full out" in developing this one, a conscious decision to see whether it could be done with a sensible workload. But I confess it also meant I slacked off the pace in the last couple of days when minor issues reared their head and made completion all that more challenging. Maybe if I really loved the idea I might have sweated through the headaches (metaphorical and literal), the random Xcode crashes (grr) and the heat. But in the end, yesterday I effectively waved a white flag when it was clear I was out of time. I feel bad about that. So... where to from here? I might have not completed an actual game, but it was a good exercise. My feeling is I should repeat the process until I get good at it. There's one week between now and Christmas; that's plenty of time for another small game attempt. This time, I'd like to give Python a whirl as a comparison. I need a theme though. I'm happy for any suggestions, otherwise I'll take something at random in the next few hours.
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!