|
| audio |
| develop |
| documentation |
| download |
| faq |
| metaserver |
| news |
| screenshots |
|
|
| [ www.salpwars.com / doc / journal ] |
Latest Version: 0.44a (12,973 lines) |
Salp Wars
Development Journal of Mr Plat
September 10 2001
- Added more support for teamed items and preventing auto-repositioning on a item-item collission.
- Stripped out OpenGL code (sorry :-)). Maybe another time. :)
September 9 2001
Since few people seem interested until a beta is available, I'll be keeping the update list as terse as possible. Only significant changes shall be noted.
- Added low-level support for the saving of joystick/keyboard mappings. Axis controls and multiple joysticks not supported [yet?]. keyboard.ini and joystick.ini (in /prefs/) are not meant to be human-edited, but can be If You Know What You're Doing. If you muck it up, delete either file and re-run Salp Wars. They will be auto-created if missing.
- Added level-file support for platforms (very cool):
# PLATFORM <sequenceID> PLATFORM tiles/LiftHorizontal96/1 # PLATFORM_CONTROLPOINT <mapcode> <xOffset> <yOffset> PLATFORM_CONTROLPOINT 01 16 16 PLATFORM_CONTROLPOINT 02 16 0
July 16th and more
Okay, so I've been slacking in the journal department. I figure I'm the only one who reads this anyway, and I forgive myself for not keeping it up to date. Truth be told, though, I've been more involved with the game lately than I'd been earlier. The engine's looking spiffy (at a slow rate, but there's a lot of groundwork being laid in the process, and this should speed up development later). And by the time you're reading this, the new site should be up and kickin'.
Chris [Kraft] was kind enough to let the SW site be hosted on his fizko.net box. I hope the DSL line it runs on doesn't die in the near future. If I knew the company providing it, I'd recommend them to you :-). However, since I don't, I'm just going to stop drop and roll. Or is that duck and cover?
Anyway, future news will probably be directed toward our mailing list and website instead of this journal. It's nice to see that the game has gotten farther than a simple map viewer :-). Resourceful gents might even find neat ways to download semi-recent Win32 binary builds.
July 7th/8 2001
I've been working on the ItemPlatform class now. So far, the game can create a platform where, when a player jumps on it, he is moved along with it. In the process, I've come across a few other "problems" that scared me. Many of these were fixed or at least temporarily avoided :). Only time will tell whether it's working "properly" or not -- I need to throw more/different objects into the game before this becomes apparent.
At any case, it's still pretty cool. You can specify control points that the platform moves between, and it will cycle through that list.
It may be best for me to take another break with regard to these new Item subclasses. I'm thinking that maybe I should go back to animation land and properly animate a main character. The only problem with this notion is that I need a main character to fill the PlayerStomper spot. And I'm not sure what they should look like. Nothing against you, Starry, but you're kind of weak as a main character :-).
Pizza is salty...but ohh so good.
July 6 2001
Mike Wiering (the Tile Studio guy) sent out a mass-mailing recently to let us know that Tile Studio 2.0 is ready for consumption. You may want to hold onto your old copy "just in case" -- I haven't played with the new version as of this writing but plan to. For a list of changes and download information, check out his site at http://www.cs.kun.nl/is/ts/. I'll be updating our main page's links accordingly.
Fruit snacks are neato, but I think the sharks can easily beat up the dinosaurs.
June 30 2001
Holy time warp, Batman!
I spent some time today with the item-item collission code, and am happy to say that the preliminary collission code seems to be in place. It's not as efficient as it could be (I could use some linked structures to narrow some of the searching) -- but this won't be important to me until we get a lot more objects running through the game at the same time.
Life is bouncy. More to do :).
June 7th/8 2001
I've been wanting to clean up some of the code before heading into item-item collission detection, so today I tightened up some of the code by adding a bunch of 'const's where applicable. In doing this, the compiler caught a weird logical error that I otherwise probably wouldn't have caught for a while. Hooray! On the other hand, I feel dizzy - I've never seen so many consts in the same place before in my life!
Game::Item also has _height and _width properties, separate from [though still defaulting to] its Tile::Sequence's width/height values. The Tile::Sequence* passed to the constructor can be 0, too.
Jay and I talked for about 4-5 hours about various game ideas, and in this time we also went over the TileStudio interface. He seems to have a much better grasp of what he can do with the editor, and hopefully he's comfortable enough to start putting together "real" tiles.
I like granola bars.
May 31 2001
Welp, my three weeks of breaktime are over, and the groundwork for the game has been laid. There is still a lot to do, but this work has made me much more comfortable with the timeline for the project.
Soon I have to pack up and head out of Oshkosh for muh homeland, and I'm not sure how the 'net connection will be there. I'll be working as well. Between these two things, don't expect updates to be nearly as frequent as they've been in the past three weeks - but I'll still be working on the code locally. Hopefully those folks playing with tile art will continue to do so - they're looking very promising.
The last bit of work I did today was in making the controls more mario-esque and hopefully more playable/realistic because of it. I'm not sure if I've succeeded in this, though, and the only way to really find out would be to do a playtest of it.
Plater!
May 30 2001
Brian's convinced me to use namespaces with these libraries so as to ease some potential pain in the future. I went ahead with the conversion, and have things in order once more. I'm kind of scared to try compiling it again in Win32 though.
Oh, and I began the PlayerStomper class, the first player class that will be coded into the game (for Lil Stomper, of course). I've added some better hooks as far as key controls are concerned, but this will have to be improved at some point to support preference files and allow the user to specify which key does which function.
Overall a fairly productive day, but nothing impressive to show off. No problem.
May 28th/29 2001
Hey there, it's been a while. Okay, so I've been easily distracted lately and my UT stats clearly show that I've been addicted to it. Now let's see what I got done that might make up for this...
I played around in the map editor and added a bricky castle (without door) and various floating platforms to the Runway map. It will be a while before it turns into something credible, and it's still quite gaudy.
I tried adding OpenGL support to the app, and was only half-successful. I'm not quite sure why yet, either. Sometimes the tiles don't show up using their proper color key, and I was only able to get the framerate up to about half the fps I get without OpenGL. Needless to say, I don't plan on throwing GL support on for a while, if at all. But I'll need to if/when I want to add super special effects. At any case, the code for it is still in the app, and turning it off/on is as easily as changing a bool value.
I compiled another Win32 binary for those making maps. It should let you get a better idea of how your maps fit into the big picture. Contact me if you want this new version.
GameDev.net seems to be a great place to frequent. I read a few more articles about physics recently, and planned out some of the MapCode/GameItem support. I'm not quite sure what the best thing to do next is, but I'm awfully tempted to work on the GamePlayer and give him Mario-like motion (gameplay and animation). But the more I think of doing this, the more I'm tempted to integrate SockMan. And the more I'm tempted to integrate SockMan, the more I'm tempted to port SockMan to use SDL_net. But I don't want to port it yet. It be boring :). And my break period is nearly over.
PIC: Bricky Castle (It still looks fake and gaudy, but it'll have to do.)
May 27 2001
I read a bit more about collission detection, game design, and code optimization techniques. I also ordered some free cds from BMG Music Service. This batch should contain Marilyn Manson's "Holy Wood" (which sounds like a desperate rehash of his older material lyrically, but we'll see), Live's "Distance To Here" (so I can hear the dolphins cry), a Carpenters tribute album to replace my super-used, super-scratched-up copy, and Radiohead's "Kid A" for the trippy part of me. Someone's gotta pay for their drug habits, ya know?
Just for kicks, I ran a memory leak tester against my program and found 0 leaks (and a smiley face in the leak report - how cute)! I also ran it against gprof, and inlined a few functions that got called heavily. Not sure if it improed the program much, but I feel better about the funcs =). Isn't that what counts?
May 26 2001
I tried using two different tricks to try to get a faster map rendering time, and kept one. The first move, a keeper, was to change the screen depth to be an optimal one, and make the bitmap depth match the screen's. Spiffo. By doing this, the proggie starts at around 255 fps instead of 130, nearly doubling the initial drawing speed. The second trick was to predraw the map onto a huge bitmap, and then copy that pre-tiled map instead of drawing it tile-for-tile each frame. For some reason it seems to still be slowing things down (and taking up about 15 megs of ram =)), so I'm not employing the trick for now. Code's still there though, and definitely an improvement. Less than 5 megs of RAM used. I'd be interested to see how the new code ran on Herman or Bran's computer.
After a bit of thought about the engine, I figured out a way to raise the framerate even higher (see screenshot). This is something you'll have to see to believe.
Sailor/Koala/Mira sent me a preview of a map she's working on, and I must say I'm excited to see the finished product. Since I didn't want to switch platforms to view it, I finally dared to use "wine" to run TileStudio. And it worked! Though I must say the gui tools have a pretty dark background to them :). It's the second screenshot of the day!
It's a laid-back day full of Smashing Pumpkins, Pilots of the Stone Temple variety, and Heads of radio. I called jay and recooped most of the notes that I lost in the Mysterious Notebook Disappearance of 2001. Just trying to get a better idea what actual gameplay will look like, and what sort of functionality needs to be added to the game to make it work.
PIC: Drastically Increased Framerate (And I almost had to buy a new monitor! Phew, that was close!)
PIC: Mira's Map, viewed in WINE (Don't look at me, I didn't choose the black GUI stuff. Hope I can change that =))
May 25 2001
I fixed some bugs regarding map bounds (yippy) which should make bounds checking both more accurate, less generous to the player, and more efficient! I'd like to try adding diagonal bounds support today, but I don't have a map that uses them yet, and I'm not currently in Windows to make one. What was I thinking yesterday? :-)
I want something chocolatey. With coconuts.
The quote of the day is Sartre's "hell is other people", courtesy of Brian.
Nothing productive visually or codewise today either. I've been trying to get a better idea of what kind of objects will be in the game and the best way to generalize items (for cpu/network/memory efficiency). Called Jeff, called Jay, checked out a few gamedev.net articles, and listened to Chelsea in Orbit. I am at one with the world (next: the universe)!
PIC: My new desktop! (I installed the Acqua theme today. It looks purdy. And stolen. )
May 24 2001
I wrote and got a prompt reply from the TileStudio developer Mike Wiering. It's good to hear that (1) TS is Freeware, (2) A new version of it is in progress, and (3) He's a nice guy. I would've been happy with any one of those 3. :)
I'm pretty happy about yesterday's .lev support, and I'm not quite sure where to go with mapcode support yet. It sounds like I have to make another format to specify various [non-logical] game objects that would be referenced with mapcodes. This would allow a lot more reuse in the long run. Isn't reuse what everybody likes?
The rest of the day was mostly spent either testing/tweaking the game for Win32, or avoiding development entirely.
The result? I've put the various dlls (SDL, and icky MS stuff) necessary for its execution in one directory. Herman and Bran tested it on their boxes and it ran on both (though Herman needed a reboot before it would work). The sad news? On a P3 700, it "only" renders 60-80fps. (For reference, most SNES games are somewhere between 50 and 60fps).
Since nobody else has any maps ready yet, I started making my own. It's fairly ugly and fairly bare, but I may have to run with it.
Oh yeah, this journal now has a closing </table> tag so that Netscapers (and those who resent improperly-formatted html) can view it. I don't want to push people to use IE more than I have to :-). Thanks Mike.
May 23 2001
I wanted to check joystick suppport after today's reboot, and - oh no - /dev/input/js0 didn't exist! After a root "modprobe input" and/or "modprobe joydev", all was good. Phew! Now I just have to figure out how to have the system automatically do this whenever it starts up.
I fixed some scrolling issues and added ScrollX/ScrollY support into the tsd file. You'll want to download the latest .tsd from the main Salp Wars page when you're ready to export your map(s).
The Salp Wars site is slightly bulkier with a few new developer links. And who could forget the obligatory title graphic that tells absolutely nothing about the game?
And as if I haven't done enough Work That Few Will Appreciate lately, I've made the various objects a bit sexier and implemented rudimentary .lev file support. One might notice that it currently doesn't support XML. My current justification for this is that if I use XML data files, I can always do it later. Though I've been trying to stick to super-cross-platform libraries, I don't want to mess with more libraries than I have to. Xerces looks like a good candidate for XML parsing; I just don't want to mess with it.
And finally we have rudimentary level (.lev) file support! Woohoo! Now I have to pretend I'm done with the boring work (then realize shortly that I still have to add mapcode support... eeeeewwww!) When do I get to code the fun stuff, mommy?
PIC: Retro-Starry. (See, there's no color or patterned background redraw.. trippy! Don't let the FPS readout scare you either; I've been purposely keeping it down around 30fps lately - the game only uses 2% of the cpu! Woo!)
PIC: Retro-Starry Part 2. (Can you tell which part of the background is being redrawn? :-))
May 22 2001
More meetings, forms, and encapsulation lie ahead for me today. Hooray.
GameItem now uses acceleration as well, so in-game movement is much spiffier, and simulates the SMB feel a lot better (that is, if you stop moving, your character gradually slows to a halt.. and similar effects when you change directions). Jumping is tons better because of this, though because of the way jumping is set up right now, Starry floats instead of jumping. :-) But what else do you expect from a star, really?
I spoke with Dr. Briscoe (the UW-Oshkosh prof who I'll be consulting with during the Fall semester) about the project timeline/etc and under his suggestion, I'm going to simply wait until the Fall before I define what part of the game the practicum entails. This should save me from some potential grading trauma. The fact remains, though, that Salp Wars *will* have a playable release by the end of this year.
In an unimpressive turn of events, nothing significant was achieved today. I spent a bit of my time re-installing Mandrake 8, and re-configuring some of the apps/drivers on it. UT still has to be resolved before I can go entertain myself again =).
I *DID* get SDL (in linux) to recognize my Gravis GamePad Pro joystick, though doing so was a bit of a kludge. I noticed that I could read the joystick info by doing a "more /dev/input/js0". But although /dev/js0 existed, nothing became of it. So I rm'd /dev/js0 and symlink'd this to /dev/input/js0 (i.e. "ln /dev/input/js0 -s /dev/js0"). Happily, I can now play around with the joystick in the game, and I've added very crude code to play with Starry through the gamepad. I'm not comfortable with this kludge in the long run, though for development purposes it ought to do just fine!
May 21 2001
Unsatisfied with the character being at a constant position on the screen, I added X-threshold values to the camera positioning (currently padding 1/3 of the screen). This makes the game a little more credible (as it compares to other sidescrollers). The y-values dont use thresholding yet, but it's only a copy-and-paste away if the gameplay deems it necessary.
Today I'm taking a little break from collission detection and work more on the GameState object as well as level(/player?) definition files.
I was playing Unreal Tournament today (okay, so it's a common event) and thought about how it's tricky to organize a good team attack in the game. When you're attacking, there's no time to stop and type text to the other players (unless you like turning into ground meat), and when you're playing, the messages tend to scroll too fast to read on a well-populated server. Still, teams playing CTF (capture the flag) really need to organize themselves in order to win. For example, on the Facing Worlds (aka Face) map, some players ought to be defending the base, others should be sniping from the tower, others should be clearing midpoints between the two bases, others should be constantly raiding the other team's base (not just for the flag), and still OTHERS should be taking the opposing team's flag back to base. Obviously there should be defense tactics too, and the team should support whoever has the flag. Anyway, since you never know what kind of players you'll get on your team, it'd be nice for someone to be able to lead the team in order to point out weak points in the team's formation. Unfortunately this is not always possible for reasons I mentioned in the beginning of this rant. Though the audio hot keys provided with UT go a long way in this regard (eg: "Take their flag!" "Defend the base!" "Get our flag back!"), it'd be nice to have an in-game list of various critical points on the map (e.g. top of base tower, base flag floor, bridge, redeemer room, and similar locations in other teams' base) and the count of players [from your team] in that location. This way players could simply look at the number of players in a given location, and if it's 0 or 1, hopefully head over there to fill the position. This may come in handy for CTF maps in Salp Wars, but we'll see. It's also probably important to note that I'm trying hard to make the game playable via a SNES-like gamepad (eg: Gravis Gamepad Pro), and here it would be especially difficult to do any typing. The good news is that the keyboard/mouse would be free for another in-room player to use additional controls (perhaps a mouse click would fire in the direction of the mouseclick, for a better-aimed bullet). The second player could pick up the communications board too. However, for single players, it may be good to use a single button to send audio cues, where the audio cues are configurable by the player and are activated by a series of button presses. For example, if I pressed the audio cue button on my gamepad once (and after some delay), my character might yell "Take their flag". If I hit it twice, it might yell "Defend the base!", and so on. This would allow decent communication, quickly, and without costing us an array of buttons (as SNES controllers only have 1 axis, and 6 other buttons to work with). This is all feasible, but obviously a ways off yet.
The engine currently runs at around 120fps on my box. Considering that I'm using an 800mhz P3, this is unacceptable in the long run, but I haven't put forth much an effort to optimize the code yet either.
Today I did a bit of work with the GameState, and started designing the .lev and .mc file formats, but it wasn't exactly what I'd call productive. A lot of it stems from the chicken-and-the-egg problem.
A lot of this work was just a matter of encapsulation - I'm trying to move some of the code from my main salp.cxx file into the various objects, and it's taking a while. Super-boring, but necessary. And I have to be cautious so that it's done in a way that allows decent networking to be added later.
May 20 2001
Today is the day of map bounds detection! But first, let me quickly appreciate Wal Mart's sparkling peach soda. I don't know why it's labelled as "limited edition" ("take the raspberry away, not the peach"), but it's definitely worth checking out. The Oshkosh Wal-Mart currently has it selling at 25 cents per liter bottle (50 cents in Manitowoc), so not only is it yummy but it's extremely cheap. I have about 12 liters left. Woo!
After a bit of work and many watermelon chunks, simple bounds detection has been added. Its accuracy depends on tiles' movement being relatively slow. In other words, as long as a tile isn't jumping diagonally, at half of a screen per frame, life is good. And even if it wasn't completely accurate, would anyone notice anyway? The bounds detection does *not* support diagonal bounds yet; only up/down/left/right (though this is primarily what should make up the game).
GameItems are now drawn properly on the map. I also added some simple camera positioning (which also snaps to the map) so that the character is centered on the screen, and even added some simple (but cool) parallax scrolling support. The scrolling background(s) can repeat their patterns vertically, horizontally, or both.
I think the screen resolution is officially planned to be 320x240. Small eh? It looks OK in full-screen view. What's annoying, though, is that in linux the closest resolution my box currently recognizes is 640x480, so in "full screen" mode the game only takes up 1/4 of the screen. But it's centered. In Windows, however, it fills the screen as you'd expect. I figure that if I mess around in Mandrake, I can get it to do the same with my box in linux.
Oh, and today let me introduce Starry, the tiny test character. Since I need an original character for dev purposes and no others currently exist, I've elected to draw Starry. Just to clarify here, he is *not* meant to be a main character in the final game. I'm sure Jay can make much cooler-looking (and larger) characters.
Oh, and the gaming controls are a bit nicer too, since I can move starry around. It's just simple sliding (+ cheap gravity), but it works. Things like jumping and inter-object collissions need to be addressed yet.
Now for some more watermelon...
PIC: Starry takes in the view. (Note how he's resting on the platform, and also notice the newly stolen, repeated, [parallax'd] background (sorry, no animation in the png :-)))
May 18th/19 2001
I was planning on meeting with Jay about the TileStudio developments on the 18th but the meeting was a no-go. Hopefully he take some initiative to check out the app soon. It's important to me that graphic development works alongside the engine development. I don't want the graphics to be added as an afterthought.
I also did some reading about Dead Reckoning (in the context of network simulations) and other tile-related stuff whose topics I don't remember offhand. Not much progress on the engine these two days, but my parents donated a big ol' seedless watermelon (YumYum brand) to my development efforts. Thanks :-).
Oh, I *did* "finish" another (2-minute) song meant for the game. I place "finish" in quotes because it's not the greatest song I've ever written. So if you already think my songs are crap, this one is worse. :)
May 17 2001
It scrolls! It scrolls! There is room for optimization in the drawMap() code, but what's important at the moment is that scrolling works.
I updated the map file format to use a few less variables, and updated the TileStudio template to reflect these changes. I re-exported my test tileset as well as their demo Charlie* tilesets, and these maps are readable by the game engine as well now. Sweet! For some reason, the larger maps don't act appropriately if the x=0 of the map is to the right of x=0 on the screen, it doesn't show up at all. This works fine with other maps, and it works fine for any values of y, so I'm not entirely worried about it. Right now, I don't see any logical scenerio where the X=0 of the map would be to the right of the X=0 of the screen.
The Mayfield Four are a pretty cool band. I got their "Fallout" album early in the year during my yearly wrapped-$1-cd shoppin' spree at a local used cd store. I'm ashamed that I hadn't seriously listened to the cd until recently.
I also downloaded and installed the various SDL files (the DLL and development files) in Windows and managed to compile the engine in VC++ 6 with little effort. Hopefully it'll be just as easy when networking support arrives (right?) :-). Lucky for me, there's a lot of work to do before networking hooks are thrown in. This is perhaps the only time that I consider myself lucky to have tons of work to do.
Fixed aforementioned scrolling issues, and a few more that popped up when I changed the screen resolution to weirder values.
*.cc -> *.cxx for easier VC++ compilation. Hopefully VC++ won't heavily affect the look of this project.
Brian says that processors like 'int's more than shorts/chars. Hrmph.
GameItem has a few more functions for TileSequence support, and TileSequence got bulked up a bit as well. The next step would be to work on basic tile (player) movement and map bounds checking.
PIC: Stolen Charlie map, scrolled. (Hey, it was a demo file - but look how nicely it loads.)
May 16 2001
Seeing that some of this development was getting off-track, I took a bit of a step back and went at the code from a different approach.
I worked with TileStudio some more and created a TS Code Generation Format for my engine. Then, I added code to the engine that would parse these files (both the bmp and the tset files that it currently creates).
The old object names have been scrapped for the time being. GameEntity has been changed to TileSet, and two new classes - TileMap and TileSequence - have been added to the mix.
The TileSequence object/parsing hasn't been tested for logical errors yet; I'm trying to concentrate on TileMap first. Next up: scrolling in drawMap();
PIC: A dirty map. (A quick and dirty map I made to test the .tset and .bmp file parsing)
May 15 2001
I've added a function that converts a bitmap to a bitmap of twice the length, with the second set having been flipped horizontally. This should make life a little easier for character tile design. If not, it's not a big deal either, since it would be fairly easy to snarf out of here.
I checked TileStudio and noticed that there *are* functions to flip images, so perhaps this flippage won't be necessary. Time will tell. Either way, it was a good little exercise in using SDL.
What has me sort of worried is that there doesn't seem to be any support for doing these image manipulations directly in SDL, so if I ever need to rotate the images, they would all have to be separate frames or I'd have to calculate them myself, or texture-map them in OpenGL. I'm not looking forward to it, but at least I'm not writing an overhead space game or something (eg: asteroids) where this would be a key element of the engine.
May 14 2001
I looked closer at SDL (http://www.libsdl.org/) and it seems much more suited for this project. As an added bonus, I should be able to add OpenGL stuff later (on top of the blitted bitmaps) if I dare, so it should be a win-win situation.
SDL is cross-platform, so Linux/Windows should be all but guaranteed, and MacOS compilation has great possibilities as well. There's also a note in the FAQ which mentions a cross-platform networking library. Pretty sweet. But I probably wont be looking at this for a while =).
Thanks to the various tutorials and fairly straight-forward design of the SDL, I was able to make pretty decent headway on the game engine. the GameItem and GameEntity classes are still babies, and the UI code is largely reminiscent of the tutorials, but this should evolve nicely with time.
Right now I have a stolen duck animating himself in the corner of the black screen. What's kind of a bummer is that he only faces left. Obviously it'd be silly to require Jay to draw characters facing both left and right (not at the same time ;-)), so I must find The Right Way to horizontally flip these images before (or when) they're blit'd.
PIC: A duck in the void. (notice how transparencies are used -- the bitmap really has an icky green color around the duck, but only the (black) background color is seen here).
May 13th and Earlier
Began spec sheet, and clarified various requirements with instructors. Convinced Jay to head the artistic efforts on the game's graphics. Seeked out various tile editors to sample what was out there. TileStudio was a clear winner from the selection, but there are some features (eg: copy/move rects of pixels) that it clearly lacked.
I became more familiar with TileStudio's interface and played various games that were created with a combo of both TS and Clean. I plan to use TS to speed up development of the game content.
Also wrote "Rush Hour", a faster mp3 ala Contra, I thought. Brian thinks it sounds more like an airplane game (ala Gradius). At any case, it is clear that I can mimic the low-tech sounds that eminated from the NES/SNES.
I've been looking at various gamedev.net tutorials regarding various parts of game creation (Game Programming Genesis, tile engines, music design, collission detect, etc) to get a better feel for what I'm getting myself into.
There was one article that particularly scared me -- it talked about how to use OpenGL to write a tile engine. The article suggested I texture map various quads. But when we're talking 32x32 tiles (or smaller) and a 640x480 screen, that's a lot of quads. I'd like people to be able to play it w/o hardware acceleration, so instead of even attempting this, I decided to move on.