January 2nd, 2009
Went off and worked on geometric objects and celtic knots for a while; eventually gave up in dispair and returned to phantomnation. Once again, rewriting system structure from the ground up-- better timing loop, capable of handling typed input, hopefully have banished the sprite stuttering bug, started paying attention to the executable's called path so you can actualy run the thing by clicking the executable icon instead of having to run it from terminal, finally fixing animation problems, finally getting texture storage issues resolved (maybe one day I'll rewrite the terrible memory-leak check code with something that doesn't store all allocated memory locations as a linked list)... but once again, the game has constricted to a single white hex on the blue gradient background, optionally with text in various corners as I test out the new(-er) menu & font code. Font code now does proper wordwrapping (instead of cutting words in two if they fall against the right margin) but it's all still monospaced.
Recent stupid bug: when writing texture code, accidently (well, 'accidently') typed __alloc(sizeof(strlen(path+1)))
. promptly overwrote important information (presumably about the just-allocated memory) past the end of the allocated memory. went nuts trying to figure out what was causing memory corruption 'invalid next size' free() crashes. But now it all works properly! ...as far as I can tell.
To make myself feel less miserable about having worked on this thing for two years and still being at the 'pull everything out, rewrite from ground up' stage1, I decided to look back into the dim reaches of history, back when reptiles ruled the earth and i had just started learning how to program in C (specifically, two years ago when I also started working on phantomnation). Here is the amazing "game.c", the program with which the first screenshots in this gallery were taken from. Here are the two maps I wrote: map1 and map2. I think all you need to compile the program is the OpenGL & SDL development libraries. (and presumably you could even compile it in something other than Linux, since I don't think I was using any platform- or compilier-specific references.) Then, as you can see in the source, run it from terminal with the relative path of the map you want to load. What's really alarming is that some of that code, altered but not really that much, has been lurking in the maps.h header until this current rewrite, which I began by being aghast at the map system and determining that I really needed to make a storage system that will work well for stuff like pathfinding & overlapping (yes, overlapping is back) also, instead of working well at... storage and retrieval and being almost impossible to work out how to draw the tiles in the right order, much less get pathfinding between non-adjacent tiles working2.
later:
As mentioned briefly above, after ages of having the font-drawing code cut words in half if they happened to fall on the word boundry, I took it upon myself to rewrite it to do word-wrapping. And while I was at it, I figured I should go ahead and allow different text alignments, since I've also gotten annoyed with the status text that's supposed to be in the top-right corner actually being more like 'top-middlish'. And while I was writing the right-align text I realized that adding centering and justification3 were really just small tweaks on the basic left-aligned code. So I did so! And now you can see what I have wrought. Right there, on the right! with left, right, and justified text. the justified text being the lyrics to the song i am listening to right now; showing that a good song is usually not good poetry. Even when justified in a blackletter font... and now that I look at that screenshot closer, I see an improperly-justified line. sigh. (the line midway through, reading 'down. do you hear his knuckles on your ', which does not justify when it should. this is because of complexities regarding the way lines and newlines [specifically, the \n character] are dealt with. there should be a line break right after 'door?' on the following line, and since with word-wrapping you don't know you've hit the edge until you overshot, the newline was parsed on the line before it should be if the first word on a line ends with a \n. And since the last line in a block isn't justified... you have the above issue.) Suffice to say, I fixed it.
1 I always seem to make things harder for myself. If I had resigned myself to just, like, using terrible sprites both for textures and tile surfaces, having minor animation problems when you pause, not having full walking animations, having an ugly font and uglier font code (or [gasp] using a generic font and built-in font libraries)... well, I probably would have gotten much further than I have so far. My excuse is that I started this whole project so that I could learn how to program something non-trivial (although there are those, I suppose, who would say any game is a trivial program compared to gigantic tangles of corporate database code or whatever), so the point of this, to a degree, is not to produce a game but to engage in a process (that, apparently, will never complete) that increases my programming abilities. Nevertheless, I do always seem to pick the most advanced and complicated option whenever I have the ability to do so. see: overlapping tiles vs. flat maps; non-adjacent pathfinding vs. pathfinding of only adjacent tiles; triggering events while walking over them vs. triggering events only on walk end; the entire 'walking around on maps after the battle has completed' thing; a whole bunch of plot & game mechanics stuff i haven't even got far enough to program; etc. But only because I think the more complex-to-code things in the above list will either 1) make more sense from a player's standpoint or 2) make a more nuanced game, potentially. Complexity for complexity's sake isn't much fun. [↑]
2 the FFT-style jumping from peak to peak, across valleys that may be unreachable (or may not exist), as opposed to the usual 'every tile on the path between here and the goal must be adjacent to the previous and following tiles' mode. And of course, the latter is much easier. See above footnote. [↑]
3Though I think it physically hurt me to justify a monospaced font. But non-monospaced fonts (specifically the complex storage of letter heights and widths) are still beyond me. And really, a monospaced blackletter font is already a typographical abomination, so justifying it doesn't make it that much worse. [↑]
January 4th, 2009
There were some lingering issues with the text formatting. In a whole bunch of cases, the left- or right-aligned text would merrify run past the margin. Justifying the text would usually fix the problem, just by squishing spaces down. It ended up to be because when I was calculating the length of the words on the line vs. the amount of space for each line, I was calculating against just the right margin. So things would work fine provided the left margin was 0, with increasing amounts of overrunning the larger the left margin was. So then I fixed it by using the proper formula of rightMargin - leftMargin
. Hooray!
Next, i'll be working on map storage, again. Ideally building up all the way to event structures and proper highlighting and good pathfinding before i start on map generation and soforth. Then will come the redux of 'walking around on maps' + dialog (...i hope), then the actual battle structure. some day, i'll start on stuff like eq & status screens.
January 6th, 2009
the manual depth-sorting algorithm1 does not work as planned.
eventually i got it working in exactly the wrong order, then reversed the order that it draws the tiles.
the algorithm currently works right provided the camera rotation is a multiple of 60— i think. fairly certain there are other cases in which it doesn't work right. since the rudiments of map storage are complete, i'm going to get the rudiments of map input working, so i can start working on pathfinding & cursor support for overlapping tiles. also, unexpectedly but not really exceptionally so, skills i learned regarding complex 3d geometry for the aforementioned celtic-knot code turned out to be useful for phantomnation2!
1 i am writing my own depth-sorting algorithm because that's what'll fix the various clipping issues with billboarded sprites. also, probably some time in the future i might expand it to a general clipping-and-culling algorithm, so that there will not even be an attempt to draw tiles past the edge of the screen and tile joins not facing towards the camera. potentially also tiles that are totally covered by other tiles in the current view, but those are probably going to be so rare it wouldn't be computationally worth it. [↑]
2 since to do depth-sorting, one has to calculate (well, obviously) the distance of any object to the camera plane. that was the huge issue i was having with depth sorting— not only is it complicated geometry stuff, but you have to resort every time the camera angle changes. but thanks to me finally learning about qsort()
and bsearch()
as well as learning how to do things like, say, calculate the distance between a point and a line, the depth-sorting problem... isn't solved yet, but it's now something that it's possible for me to solve. [↑]
January 9th, 2009
Map input is proving to be more complex than anticipated. Or rather, more complex to add the proper integration/interpolation code I want to use (it is from that 'fix your timestep!' tutorial: even though phantomnation's physics could be termed 'minimal', nevertheless, better to start with a proper framework now [um, two years down the line] than wait until I actually need to do some complex physicas integration.) than I had anticipated, esp. since I am... likely unwisely using the integration/interpolation code to handle timed animations. We'll see how this goes.
January 18th, 2009
I thought about the animation issue and refered back to the 'fix your timestep' tutorial and realized, hey, none of the stuff I'm ever going to do in phantomnation is going to require real integration, as it is all basically linear or sine interpolation (well, and probably other curves once I get unit jumping and attacks and soforth working) and thus, I have no reason to even fix my timestep to begin with.
So I junked a whole lot of physics code and went back to a simple non-fixed timestep. And then I wrote out all the basic interaction stuff I wanted to get working in a better todo document. And then I coded some of that basic interaction stuff!
Animation timing finally works perfectly correctly— when the game is paused, animations do not progress. Animations are centralized and work kind of magically, in that all you have to do is say 'okay i want an animation from now until five seconds in the future and i want the value to be along a sine curve' and bam, the animation system will do that and you just have to refer to the final interpolation value in whatever calculations you're making (and remember to free the animation when it's done, although sometimes not even that). So that is a big relief, to finally have well-timed animations working, 'cause they're kind of vital for the game to look pretty because, as I have decided, I'm probably going to value shiny over playable for the time being1.
I hooked rotation, tilting, and zoom up to the new animation system, and noticed that the animations would only go in one direction— rotation would always to to the right, tilt would only tilt up (if you tried to tilt again it would reset to base tilt and tilt up again), and zoom would only zoom out... but more like zoom in (see left).
I tried flipping the sign of the zoom value, but that only lead to a familiar black border (see right). Which was odd, because I specifically have the backdrop calculate its position from the resolution, so it should always clamp the edges of the screen. But then I realized that hey, changing the resolution value doesn't magically alter the OpenGL ortho box; you still have to call glOrtho
with the new resolution values before it resizes the actual view. But since the backdrop & font/menu code always assumes the resolution matches the OpenGL reality, it stretched out even though the changes hadn't been applied.
(the uni-directional movement issues were actually due to two other, unrelated bugs that were boring to find & fix— for rotation, I messed up some bitwise arithmatic, and for zoom/tilt I wrote the wrong logic checks.)
Also, the manual depth-test certainly doesn't work right. At first I thought it might have been because the camera plane was never recalculated (which it wasn't), but then I called the recalc code at the proper junction and was faced with alarming stuttering tile placement during rotation animation, so now I am certain I have made a mistake somewhere along the line.
(later: my mistake was, in fact, that I had forgotten the degrees → radians conversion formula, so the line that was being depth-tested against didn't match with the line of the real camera. everything else was right. gg.)
1 I have resigned myself to struggling with this forever, so I figure I should at least make the game look very, I dunno, 'professional', even when it's unplayable, esp. when the 'professional' appearance requires complicated background code logic I don't yet understand. [↑]
April 20th, 2009
So, um. AND THEN, I DROPPED EVERYTHING AGAIN. Well, there are nuances in the timeline that the bug screenshots can't capture, 'cause I've been working on-and-off on a whole bunch of really low-level stuff, and there aren't many bugs at the level, partly 'cause it's so deterministic (and I've done what I'm trying to do a few times already with various levels of skill) and the bugs that do occur aren't visually appealing.
Not that these bugs are visually appealing, but they're at least visual. And they represent a massive improvement in my capacity to do things. Specifically, I got fed up regarding monospaced fonts and the larger, more looming monospaced sprite sheet problem. So after rewriting the memory allocators and the texture loaders and the animation system and untangling the inclusion hierarchy, I set myself up against the issue of SPRITE SHEETS.
Man, sprite sheets. Such a hassle, at least in part because attempting to look up how to write sprite sheet-loading code ends with pages of 'blah blah megaman blah blah terrible sprite art blah blah etc' results and very few programmer-oriented results. But then I stumbled upon an article which seemed a reasonable solution to my problems. And let me tell you, there's nothing like writing a state machine to show off your increased skills at... writing state machines? But the last one I wrote was back in the dark ages of phantomnation, for reading map data1, and this one is simpler and works better and is much easier to read. So yes, skills++. (for the curious, this is what my sprite sheets look like, with the caevat that the 'special' colours are user-specifiable, in the sheet itself. details of implementation are left to the viewer, 'cause if I didn't get help writing the state machine neither do you.)
So it's back to this, again. badly-wrapped text on a black screen. But all the letter size and baseline information was loaded automatically from the image file, and adding proper word-wrapping and alignment (again) is just another level of convolution, not some earth-shatteringly vexing problem. And the same sprite loading procedure can be used to load up actual character sprites, so thusly I am freed forever from the problems of loading up sprite data. Now I just have to draw the sprites. so many sprites. Also, to rewrite all of the menu code to... work, firstly, but also to deal properly with the new font code. Or, more usefully, to update the menu code so it can do things like inventory lists or complex things with pretty typography instead of just simple dialog boxes and menus. one step forward, two steps back.
(some more issues while writing up the alignment code)
[this was 'cause when drawing text right-aligned, you draw the letters from right to left and I hadn't realized that you want to offset the character by its width before drawing it, rather than afterwards, as you do for left alignment. do it afterwards with right alignment, and this happens: each letter is offset by the width of its neighbor, rather than by its own width. which doesn't matter if you're using a monospaced font, which is probably why I didn't run into this problem previously]
But now the printing code works almost perfectly (there's an amazing crashy exploity memory corruption/buffer overflow error for words 64 letters or longer, but that's easily fixable) and is a great deal simpler than the previous printing code which I wrote all of four months ago. yes indeed, skills++. BUT NOW TO CONTINUE REWRITING CODE. until, some day in the far future, I reach the point where I am covering new ground and run into something that requires I build up everything from scratch again.
1 It's in game.c (in map_readfile()
), so you can go and read it if you'd like. It's pretty horrific. [↑]
April 29th, 2009
This is what happens when you accidently draw text with the wrong texture. (I rewrote the font code to potentially be less CPU-intensive [I realized having it recalculate the word-wrapping EACH FRAME was... probably not a good idea] and forgot that the function that actually draws the letters [as opposed to the one which calculates the spacing and wrapping] doesn't do a texture bind)
June 11th, 2009
Stopped doing anything whatsoever for a while, (In my defense, well, progress this past year has been astounding, even including all the months of dead time— note the first post in gallery three, made just about a year ago.) but am now at least finishing up the text/menu system (um, finishing up this iteration of the text/menu system). I was confused because the menu index was stretched out by a few pixels, even though I was pretty sure my math was right. So I grabbed an older, more confusing formula from a previous version of the index code and ended up with this. My math was right, just I had forgotten I wasn't using a 16x16 pixel index image. Which is funny, 'cause the sprite sheet code? It knows how large all the sprites are; at no point did I actually need to type in THE INDEX IS 16 BY 16 PIXELS. But I did, 'cause I forgot. This is what going away from programming for months does!
(see also the 'new' sans font, which is still half-finished [hence all the missing capitals] and is gonna need to be redrawn sometime soon; it's too thin with too high contrast)
June 22nd, 2009
blah blah blah, stuff working right, blah blah blah, incorrectly formatted sprite sheet, blah blah gibberish.
June 28th, 2009
In which I have finally gotten around to getting things like scrolling, rotating, and zooming working in this iteration of phantomnation. After a whole bunch of debugging the new, never-before-used animation system, I start actually specifying animations to use. However, of course, I forget to alter the openGL frustum when zooming again, resulting in things going wrong.
but even after fixing that particular problem, the index drawing command is still... not quite right. The calculations it used for generating the four corners of the quad to draw were all wrong.
June 30th, 2009
So I finally get around to making the map system. Things are... less than optimal. There are a succession of weird crashy bugs that appear alarmingly non-deterministic-- I populate a list (for tiles, for use with doing my own depth-testing) with entries, send it to qsort, and some of the entries come back NULL. I populate the same list with entries, make sure it is actually populated, and send it to qsort. still NULL. comment out the call to qsort. but then it still crashes (due to NULL entries in the list that should not be NULL, of course) when I make a dialog box. Because take makes the list abruptly become NULL in some slots for no readily-apparent reason. (these screenshots were from when I NULL-checked the list which should never be NULL. After popping up and closing a dialog box, those three hexes disappeared mysteriously from the list that should not have been touched.)
Eventually I just comment out all the depth-sorting stuff and make drawMap() just draw tiles in whatever order, making sure to test for NULL beforehand. Okay, bug fixed! Or... deferred. So I go off to make sure there are no memory leaks. And there are! And due to some printf() statements in the freeMap function I can see that the memory not freed is a tile list. but... the printf call that prints the memory address happens right before the line that frees that exact same memory address?!
I'm going to stop coding now, and I'm not going to start again until the universe starts being deterministic again.
July 1st, 2009
<xax> but wow, the difference between *(void **)(l->items + l->itemSize * --l->cur) and *((void **)l->items+(l->itemSize * --l->cur)) is ALARMING
<xax> and by 'alarming' I mean 'crashy'
<cbee> the one on the right is the good code?
<xax> The first one is the one that works right
<cbee> ah
<xax> because the idea is l->items + l->itemSize * --l->cur makes a valid memory address that you want to deference
<xax> and the latter is actually 'deference l->items, then add l->itemSize * --l->cur to /that/ memory address' [ed: these are void ** we're talking about, so dereferencing them gives another memory address]
<xax> I'm just happy I figured out my 'non-deterministic' bug. Because I was passing the same pointer but getting different values when I dereferenced it! because the pointer math was doing different things! [ed: technically incorrect; i was passing the same information but doing different pointer arithmatic to dereference it]
<cbee> This means your tiles will show up correctly?
<xax> yes! It also means the game will stop crashing when you rotate the map around and tilt it up (or zoom out, or any other combo of two animations) at the same time
<cbee> Why would rotating crash it?
<xax> See, I'm using my own code to make automatically-extending arrays, because there's a lot of stuff that needs, well, array-type storage. and sometimes you need to resize them, and etc etc.
<xax> so I have these being used all over the place, most notably in map storage and in animation storage. And when an animation finishes, it's removed from the list of active animations
<xax> when there's only one animation, when it's removed the math involves a multiplication by 0 ('cause it's at offset 0), so even the wrong pointer math worked fine.
<xax> When there were /two/, one of them did the wrong math when it finished and was being removed. And that crashed the program
<xax> or rather, *(ITEM LIST + SIZE * 0) == (*ITEM LIST) + SIZE * 0
<xax> but *(ITEM LIST + SIZE * 1) != (*ITEM LIST) + SIZE * 1
(all quoted from IRC because I didn't want to type up the whole explanation again. LONG STORY SHORT: ALL THOSE WEIRD ERRORS ARE SUDDENLY EXPLICABLE. AND NOW FIXED.)
July 4th, 2009
Imagine there are a lot of screenshots here involving problems with cursors. Most of the cursor problems were animation-based and are now all stomped. Also, I tried to tackle the cursor/tile 'picking' interface code again, with much greater success. For the code-minded: you may compare the old and the new code by comparing the new to the old.
After the cursor location code came the cursor animation code, which was incredibly easy to get working with the new animation system. For a while, switching tiles while the cursor was autocorrecting height lead to problems, because I forgot to reset part of the animation timing, but soon enough that was resolved as well.
Now that the basic cursor code is completed, my next step should be to upgrade it to handle the various cases that appear with multiple tiles on one coordinate. To do this, I'm going to have to make a map that has the various complex tile interactions. Which means I'll probably work on map-creation code for a little while, then finish off all but the most complex cursor code1.
(there is a new issue regarding cursor drawing, though— since it's drawn last with depth-sorting off, the cursor is never occluded by tiles, even though it should be. oh well. I can fix that later.)
1 The function that resolves the height of any arbitrary point on a sloped tile. Since the hexagonal tiles have six corners with an additional seventh 'center' height value, the method that seems most intuitive to me is to calculate which triangular sector of the hexagon the point is in, then do a triangular interpolation with the three applicable height values. The problem: I have no clue how to do either of those steps. This same function would be used to draw units walking on tiles, and for doing collision-detection when walking off of sloped tiles. [↑]
July 5th, 2009
Some bad cursor-swapping between tiles on the same coordinate has been implemented. it defaults to... something like a random tile (well, not really), but switching to the next-highest tile (which loops over to the lowest) is allowed.
This brings up the old issue of cursor depth-testing— part of the reason I added the tile cursor now was because it was becoming extremely hard to figure out just which tile the cursor was over, since it's always drawn on top of every tile. As it turns out, even highlighting the tile the cursor is over doesn't help that much when the tile cursor is, again, always drawn on top. (see picture.)
So I guess the next step is to continue working on cursor multi-tile height resolution by way of getting the cursor(s) drawn in the right order. This is also important, because adding stuff into the map tile drawing order is totally vital for lots of things, most notably drawing units. So it'd perhaps be good to do that now, instead of waiting further to get that worked out.
July 11th, 2009
Since I still have no real map-creation functions, I have to manually set a lot of stuff. like the texture repeat value for join textures. Sometimes, I forget.
Also note: the skewed join alignment.
INCORRECT. Incidently, this is what phantomnation maps look like from below. There is a consistant vexing bug where the rotation, zoom, or tilt will flip out (the technical term) and lead to situations like this. It's not very reproducible— it keeps happening, but I can never trigger it when I want to.
What happens is... the map will tilt or zoom, than tilt or zoom again, in the same direction. In this case, the absolute bottom viewpoint. At which point, for reasons which still escape me, that particular control locks up and I can no longer tilt at all. Oh well. I'm sure I'll figure out why it's broken at some point.
Meanwhile, I'm gonna be working somewhat concurrently on battle and free movement. The new cursor (which is, um, so very placeholder) you might have noticed in the latest screenshots is the results of me generalizing the old drawUnit()
function to work with an arbitrary sprite sheet. This could be used with unit sprites to... draw unit sprites! So I gotta program a bunch of event stuff for switching around unit sprite offsets (for walk animations) as well as maybe even making a rudimentary unit struct. Then comes rewriting the timeline code to work in this latest incarnation, followed by maybe getting a little collision-detection going. Both of which require that I get the tile struct ->occupants list working right, so units standing on tiles will draw properly when there's more than one person on one tile (which happens: all the time for free movement; during walk animations over an occupied tile in battle).
So suffice to say, I've got a bunch of stuff to do. as always.
July 15th, 2009
You get points if you can figure out why this particular connectivity graph is incorrect. Hint: it has to do with the way overlapping tiles are handled.
Also, I showed the phantomnation code to a friend of mine, and his scorn at the completely pathetic way of compiling I was using (...the less you know about the way I was compiling before, the better) drove me to finally get around to making a Makefile for the probject. SO NOW THERE IS A MAKEFILE.
Also, I fixed the connectivity graph. Now it is only slightly terrible. Next up: I guess drawing units, maybe?
July 18th, 2009
Drawing units! Not that you can tell here, but the problem is that the unit does not rotate with the camera-- no matter what direction you look at the unit at, it'll still be facing away from the camera. Which is kind of creepy.
Once I solved that, another problem revealed itself: the initial flipping code for sprites flipped x AND y, so the sprite was drawn upside-down as well as backwards.
Even more annoying, because I haven't yet fixed it, is that the billboarding code is copied mostly-wholesale from an older version and thus does not respect sprite centering handles at all. This is a problem, because the sprites' handles are such that if they were working, they would has as their baseline the center of the tile they are standing on. Since they're /not/ working right, the sprites are all jumbled up and appear to be standing at the far edge of the tile, no matter how you rotate. Vexing. But ultimately fixable, even if 'fixable' means 'fixable if I rewrite the billboarding code to properly use vectors'.
July 19th, 2009
Okay. working on billboarding. Reading a tutorial on billboarding I had bookmarked gives me a 'oh, duh' moment.
And, as usual, my first attempts are bug-ridden and odd. First I flip the Y axis so everything draws upside down (again), then I mess with Z values to accidentally stretch out the billboarded sprites to infinity. All in all, not the best code I've ever written.
However, even after ironing out those particular defects of implementation, the code is still unusable due to a more fundamental issue: since (as it says in the article) the faux-billboarding I am using involves clearing the OpenGL modelview matrix, the sprites no longer draw where I want them to! The xyz coordinates given are based on the position on the existing modelview matrix, so when that is cleared they are drawn (nicely billboarded) in all the wrong locations. They don't even stick to one location; rotating the camera sends them skittering across the map due to changes in the cameraview matrix which aren't accounted for in the billboarding code.
This just will not do.
So, well, I kind of remember how matrices actually work— when any of those gl functions like glVertex3f()
are called, they really create a 1x3 (or 1x4?) matrix, which is multiplied by the modelview matrix, and the resulting 1xwhatever matrix is the transformed location of the point. So it follows that if I do those calculations myself to get that transformed point, then clear the modelview matrix, the sprites will all draw in their proper location billboarded properly and everything will be perfect forever.
Victory is mine! See also, a comparison between the old and the new billboarding code. The way in which the new billboarding code is better than the old billboarding code is very different than, say, the way in which the new map tile resolution code is better than the old map tile resolution code, in that the difference in lines of code (the old code is actually shorter!) isn't as important as just what those lines are doing.
so, huh. it might actually be time to draw out a tiny sprite sheet or two. which, i mean, i'm already doing. just... moreso. sigh. drawing is hard.
August 1st, 2009
Now that I have some config options working, I have to resist the urge to recompile every time I change it. So used to everything being hardcoded. Right now the only way to change options is by editing the config file by hand, and the only three options you can change are system font, screen size, and fullscreen-or-not. In addition, the config file syntax isn't documented anywhere outside the state machine that parses the config file. Also, the fallback options leave something to be desired-- I have no clue what'll happen if someone tries a resolution larger than their monitor resolution, or if fullscreen is attempted and fails, etc etc. Still, it's an improvement.
September 2nd, 2009
I decided to work on map generation, instead.
Well, really I decided to 1) work on the physics system 2) burn out after trying to thing of a way to store and reference all the physics info 3) work on an altogether-unrelated project. But then I decided to work on map generation.
First method: a random drunkard's walk. In this screenshot, I forgot to move the tile location from the base, so each tile was placed in a ring around 0,0.
Second method: a random drunkard's walk, with a minimum of overlap checking. A random direction is selected, and if there is a tile there then the tile position is popped back one tile and a new random direction is picked. The first time I tried this, I forgot the 'pick a new random direction' part, so if there was a collision it would blow the whole stack off by testing if the location it last placed a tile had a tile placed, then checking back another tile to do it all over again. This always happened, too-- if you look at the statistics, it's pretty much inevitible.
What I really need to do is... devise a map-generation algorithm which isn't just a random walk! Not sure what form that should take, though. obviously.