• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

Trapper Zoid

Members
  • Content count

    6017
  • Joined

  • Last visited

Community Reputation

1370 Excellent

About Trapper Zoid

  • Rank
    GDNet+
  1. OpenGL

    Thanks to both of you for your replies, that's just what I needed - a sanity check for myself that expecting 2048x2048 texture support is a reasonable requirement.
  2. What would be a sensible maximum texture size to expect on today's hardware, factoring in the whole range of graphics cards, integrated graphics and legacy systems that could be realistically be expected to be still in use?   I am playing around with some 2D prototypes and am currently making tile sheets to load into an OpenGL texture. I would like to be able to load as much as possible into a single texture, which currently isn't going to be a problem, however it would be nice to know for the future what I should peg as a limit for the maximum size for a tile sheet so I can plan the scope of the available tiles accordingly.
  3. [quote name='Amadeus H' timestamp='1345530575' post='4971731'] (2) Macs are similar to Linux with their console-y ways. Some programmers prefer this. It also comes with a great dev environment (XCode), but so does Windows. [/quote] This is the main reason why I use a Mac for my main work computer. It's my favourite OS for getting stuff done, it runs all the programming and graphics tools I need, and it has Unix under the hood.
  4. 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.
  5. 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.
  6. Something like this was my dream goal back when I first joined GameDev.net, and I'd like to do something with it again some day. I made a monster post sometime in the first year I was here listing all the research I had done on the topic. It's several years out of date now but might be worth digging up. Edit:Ths appears to be it: [url="http://www.gamedev.net/topic/332564-automated-storytelling-and-interactive-plot-in-games/"]http://www.gamedev.n...-plot-in-games/[/url] Unfortunately the move to the new forum format appears to have really screwed up the formatting in my first post. From what I remember, nearly every attempt combines the sorts of approaches that I think from your post you've probably considered:[list] [*]represent characters with a bunch of attibute labels and characteristic variables which determines which actions they take from the set provided from them (i.e. Bob is a Knight, aggresiveness = 60%, chivalry = 70%, etc.) [*]logic-based planning towards goals for the set of actions available (wants to achieve goal X, so find a chain of A -> B -> ... -> X that meets that goal). This can be done on the character level (Bob wants goal X) or the meta-story level (story needs a dramatic pinch point at the 2/3 mark) [*]template based story patterns along the line of (hopefully more sensible) Mad Libs: (<ANTAGONIST> takes <VALUED ITEM/PERSON> from <PROTAGONIST> leading to recovery/rescue attempt). [/list] The problem with all of these is that they all tend to result in very mechanical and formulaic story events that are obviously machine generated. It takes a lot of care and clever artistry to pick exactly the right attributes, symbols, rules and templates to work for each story. I don't think there isn't going to be a universal approach - every designer will need to handcraft their own based on what type of game and stories they want to tell. But it's certainly achievable. I don't see any reason why you couldn't, for example, build a RTS or flight/space sim that builds the next mission from templates using the variables from the end state of the previous mission, building to a campaign arc shaped on the actions of the player. An RPG is slightly more complex in my mind, but could still be roughly equivalent.
  7. 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.
  8. 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.
  9. Wow, it's a Kickstarter straight out of the 80s. I'm slightly disappointed Chris Crawford was in front of a giant LCD screen instead of something like an Apple II. I'm not sure what I think. Mostly I'm confused as to why he's aiming for $150K.
  10. 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?
  11. 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.
  12. 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.
  13. 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.
  14. Thanks!
  15. 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.