|
I'm a freelance 2d artist; My portfolio can be seen here.
Feel free to contact me if you have any questions.
|
| Friday, December 21, 2007 |
  MiniMap, Inter-object communication, Saving Maps | 
Posted - 12/21/2007 8:10:18 PM | MiniMap
As the title suggests, I got the minimap to work (more) properly. The minimap viewport rectangle is a bit off still, but at least it gives you a general impression of which part of the map you're looking at.
Instead of doing one pixel per tile I just made a map of very small tiles, like this:  (isn't that cute?), and palette-shifted them to match the given terraintype. This would be tedious to render every frame, of course, so when a tile is changed it just gets drawn over individually -- there's no overlapping in the minimap like there is on the gamemap, so I can get away with it. (Which leads me to thinking that it'd be a good idea to draw Terrain/TerrainQuads and TerrainEffects to a single layer that's updated on-demand rather than every frame because I could totally get away with it!)
Oh, here's the screenshot:
Easy. Only an order of magnitude more difficult than I first thought it was going to be, which is quite good in the business of coding. I hear. Of course, to get an image element in the GUI to update based on changes in a random class without doing a bunch of stupid hacking was the real problem, which brings us to ...
Inter-object Communication
I modified GUI ImageElements and TextElements to accept a class that I'm calling "DynamicVariable" which can be defined in a GUI definition text file. So take the minimap as an example: It's given a target + varname, eg. "isomap","minimap", then it creates a link to a DynamicVariableCache in the class identified by the Relay as "isomap" and it updates from the variable labled "minimap" in said cache. Got that? Point is, it's more robust than before. A DynamicVariable will try to establish a link each update until it works, so order of creation is not an issue. (Now I just have to make sure that it can handle its link being broken and re-established with a different instance of the same object, though the situation has not come up in which this takes place.)
The GUI is coming together. I think I need to be able to minimize and move the minimap and do some other options on it ...
Saving/Loading Maps
Yeah, this was what I planned to be the next step today except I kinda balked at the prospect. I don't think that I have ever written files with Python before I wrote a little test this afternoon, so it's .. interesting and surprisingly easy -- when it's simple. And my maps are not. Marcel gave me some good advice on how to approach the problem (thanks!), so I think that I know where to start now.
Un(?)fortunately it really makes me want to refactor my isomap and isotile code now that I see what a mess they are in trying to sort how how to write them to file. Consider that all TODO. ... then once I've got THOSE working, I can start on gameplay ... or polish up the GUI more.. and then .. And so on with the putting off gameplay coding. Honestly, it's not my fault that I want everything working, it simply must. I swear, something will be happening by the end of January.
Speaking of January, I'm going to try to pick up some more graphic/design 'clients' then -- Need something to replace your programmer art with - at reasonable rates? Drop me a line!
Holiday non-schedule
I won't be doing MWF updates next week, possibly not until after the new year, 'cause ... you know, holidays! Let me just say "Have a Happy Fun Time" to everyone reading this.
'Til next time!
| |
| Wednesday, December 19, 2007 |
| GUI refactoring, GUI design. | |
Posted - 12/19/2007 8:29:37 PM | Refactoring goes on. I seriously spent most of today just getting everything to work that was broken by redesign of code.
Shots of GUI redesign
I need to code a random world generator so that I don't have to make a Potemkin Landscape every time I need a screenshot.
Start Menu Design
First let me tell you why the second one really irritates my sense of good design.
The background is a light image (a crop of a digital painting that I don't think I'm going to finish), but the game title foreground element is a window with a black background which punches right back through and 'reads' as farther 'back' than the actual background painting. Solution: Find a darker painting for the background and make a title banner with less 'depth'. Also the gold circle bits are starting to irritate me.
The button panel isn't so bad, and it's showing off the "dither transparency" which I'm going to start using for a number of UI panels to give a more open feeling while retaining the old-school colorkey effect -- and speed. But because this is the start screen, those buttons really should be unique graphics rather than generated generics, and this is going to require that I add support for unique button image states. Shouldn't be too bad.
Game-view Design
There really isn't much here because there isn't any gameplay. The hammer icon leads to Edit mode, the menu goes to the main menu, and the skull exits the game. I quite like those little trim graphics, they remind me of bismuth crystals, which have always fascinated me.
My goal is to have GUI elements that are as non-invasive as possible while retaining atmosphere through the use of little 'frills' like I've shown. And as a rule for my gui, if a panel isn't being used, it shouldn't be visible -- but it should always be clear or intuitive how to make a panel visible...
Sundry Items...
The minimap is going to be fairly difficult, now that I think it through. The only way one-pixel-per-tile is going to work is if it is drawn rotated 45 degrees. This breaks the cardinal rule of there being an intuitive connection between the orientation of the mainmap and minimap. What a pain!
And before anyone asks, the Editor view looks essentially the same as before. I added some dither-transparency panels to it but was having some issues with rendering text over them, so it'll require a little investigation.
Here's a fun thing: I'm going to generate different sizes of animated flags using a major and minor color and flag pattern for each polity. To get a rippling-in-the-wind effect per-pixel shadow masks will be drawn over the colorshifted 8bit template, then an alpha mask can be drawn back over it all. See here:
  
Then it could look something like this in-game:
(The little soldiers were drawn specifically for the fake screenshot and are not used anywhere in the game. Same for the rather rough selection marquee which uses the major/minor colors.)
The smaller flags imply that troops of vassal polities are in the army. Or something. Anyway it shows that political hierarchies will operate in the game. But how about political partnerships? Hmm.
| |
| Monday, December 17, 2007 |
| Design Doc, GUI Refactoring, Rendering Issues | |
Posted - 12/17/2007 10:57:04 PM | No screen shots today. Too bad.
Design Doc
My good friend, the doctor known as Brian, might help out with some art. I've know him for years and years so it's OK if I screw him over. It was at this point that I discovered that Brian could not, in fact, read my mind. For him to know what kind of art to make for the game I'd have to write down some kind of ... thorough description, "documentation", if you will, of the setting and gameplay. Madness.
So here's the current design manifesto. Read at your own peril, it's very much in progress.
Refactoring the GUI
I was iterating over all the buttons in a panel and checking if a mouseclick hit any of them in two different places. How ridiculously typical.
I've heavily revised all the workings of the GUI, Panel, and Panel Element classes. They're still a bit broken and I'm getting tired, so no screen shot of my new and improved ultra-slim GUI, but they're so beautiful and robust that I could make an interface out of a text file filled with noise. No, actually I seriously couldn't, but they're a lot better than they were.
Doing this brings up many new ideas that I should have in my GUI -- like what I'm thinking of calling a dynamicString class to put in place of regular strings in text elements or buttons that will update itself based on a call to some object somewhere else, for example a dynamicString could attach itself to a mouse position, then the mouse position would be displayed in real-time. Or something. The problem inherent in objects communicating with random other objects brings me to my next point...
Inter-object Communication
After discussing how Java's Swing handles buttons with Laura, I'm thinking of re-doing my relay class and adding a couple utility classes that can be used to set up connections between objects. Currently when a trigger is passed through the Relay it looks up the target by matching a string to a key in the Relay's dict. I thought, why does this need to be done every time? After the first successful 'connection' is made between trigger and target through the Relay, they could form a direct reference! (Of course some buttons will only ever be called once, like the 'quit' button, but for everything else I think this makes sense.)
The best part is, I don't have to intialize everything in a certain order like I think Java does. I just have to make sure that objects remove themselves from the Relay when they are deleted, which means I have to find out how the hell to add to built-in class functions -- I saw David O. do something in one of our Python/OpenGL projects where he had texture objects delete themselves from the OpenGL texture cache when they were themselves deleted; I just gotta do something like that.
Rendering
I've been having second thoughts to my rendering process.
I know that I've been hyping dirty rects for the past week and I do have my Video class set up to use them, I just have to figure out how to get everything that is rendered to pass their dirty rects back up to Video -- and how to do this only when necessary. It's a matter of planning, really.
And then I was thinking of how I render tiles: I currently render all the 'layers' in a tile from references to generic images as I iterate through, so like: blit Tile1 terrain, Tile1 terrainfringequads, Tile1 terraineffects, Tile1 isofeatures, Tile1 otherFX, shift over 128 pixels, blit Tile2 terrain, etc.
Could I not render every tiles bottom layer over the whole gamescreen, then every tiles next layer over the gamescreen, and so forth? Would this be much more costly? (A bit, probably.) Would I gain some kind of flexibility I wouldn't have otherwise? ... I recall an option in Civ where you'd tell it to show only underlying terrain. This may allow images to be drawn past the bounds of their tile without having (more) weird overlap artifacts.
And even further, I was talking to Laura about how I handle tiles, and she was saying why not render each tiles own little surface and store it in the tile (and only do this for currently visible tiles, of course), then call those on demand. This way I wouldn't have to re-render the whole stack of images every time -- I'd only have to re-render a stack of images in a tile where something changed. This would take more memory or something but may cut down on processing time -- I just have no idea if it'd be worth it.
I suppose I could implement all the different rendering methods and see empirically which has the best framerate, but that'd be a lot of work.
Does anyone know what's the best way to do this?
| |
| Friday, December 14, 2007 |
| Main Menu, Refactoring, Game Design | |
Posted - 12/14/2007 6:56:58 PM | Main Menu
Just so I'd have something to show, I finally put a little effort into the main/start menu:
Baroque, no?
I'd like to do a few epic fantasy paintings to act as the real background for that screen with a random one chosen on each load.
Refactoring And Such
I've given Input and Game a once-over. I spent a moment on IsoMap so that the game view is now drawn over the entire sweep of the 800x600 screen and all the GUI junk will be redone to be a bit less clunky. Maybe I'll even do some panelstyles that have dither transparency.
Now I embark upon sorting out the GUI classes with a few possible side-trips into Util. Once I'm done with this the entire GUI system should be a hell of a lot more robust; that is, easier to make layouts and easier to make those layouts dynamic, interactive with the game itself (as well as the player, to say the least).
Game Design
My post regarding "Command Points" (or whatever) can be found here, though it isn't getting as much immediate attention as I hoped. I'm sure it'll pick up.
(And maybe I could have been more controversial and said something like "If you were to make an innovation vs. time graph of the Civilization series it could be described as an exponential decay curve!". By which I mean that the new Civ. game looks like it's continuing with the increasing focus on discrete combat units and the animations thereof and rather less on everything else, much less on the interactions between complex social and economic systems or what have you. In other words, I don't think I'll buy this one.)
Ahem. So anyway I did talk it over with Marcel a bit today and got some interesting ideas with regard to CPs, social classes, and diplomacy that got me to actually start writing the game-play design doc. This is good.
The Big Mystery
I think it'd be funny to have a big part of the gameplay / game-setting be totally secret. Like the shareware/demo version will have about half the regular content and none of the Big Mystery -- to find out the Big Mystery you have to play the actual game and get totally blown away by it, like you think the game is about one thing and then it pulls a huge shift on you out of nowhere that you weren't expecting. Introducing a gameplay element that is so totally unexpected would be magic.
And hilarious. To me.
So I will.
Now I've just got to keep my trap shut about The Secret Of Monkey Island.
| |
| Wednesday, December 12, 2007 |
| Terrain Effects, Digital Painting, and that Dread | |
Posted - 12/12/2007 7:17:51 PM | Terrain Effects
Here's the shot:
See the little rocks and patches of dirt? Yep. Actually, "Terrain Effects" are almost exactly like IsoFeatures except that their size is always the same as tiles and they're drawn under IsoFeatures.
It shouldn't be too much trouble to make a generic class for both IsoFeatures and TerrainEffects, then take that code and make a generic Quad (sub-tile) for each, so that IsoFeatures and TerrainEffects can be built up from Quads just like Terrain fringe is.
... and maybe I'll re-do how Terrain fringe is handled ...
Digital Painting
I was bored and felt a hankering to do some digital painting, so on a lark I answered ryguyrocks' call for concept art. He asked for an alien/machine sort of thing, so I worked far too hard (like 6-7 hours) and made this:
I'm never going to work that hard for free again -- If I can help it. Unless it's a totally awesome idea.. but I should shut up.
Look out Craig Mullins, I'm gonna catch up to you someday!
But honestly, I feel incredible about how far I've come with digital painting in only the last few months. I used to look at work by Craig Mullins and could never understand how it could ever be done. I'd get depressed by how good he was and how I could never do what he does. But now I see how I could do what he does... with a hell of a lot more practice! Heh.
Now I just need someone to commission me to do some concept art for actual payment.
That Dread Horizon
I was feeling a real coding "high" on Monday, but now I realize that I'm on the brink of having to implement a whole huge area of the engine that I've never done before -- gameplay. The possibilities are enormous and I'm going to have to make a lot of decisions about how the game is going to work while advancing on, if you will, that Dread Horizon of the Eldritch Unknown.
I know, it seems so easy when you're just sitting around BSing about your idea for the Coolest Game Ever, but it's completely different when you start seriously planning implementation. Like how do I deal with the 'map knowledge' of many computer-'players' (I won't call them AI) running on asymmetric political and economic levels? I can't store and update a boolean "map" of who knows about what for every single CP if there are 120 of them, nor do I want the CPs to just outright "cheat" and see the whole map -- I'm looking at you, Galactic Civilizations! And like every game ever, for that matter.
I'm going to have to do a lot of planning and documentation, I think.
And I should totally make a game called "Mechapocalypse".
| |
| Monday, December 10, 2007 |
| Minimap, Isofeatures, Animation, Refactoring | |
Posted - 12/10/2007 12:27:04 PM | Minimap
This seriously took like 2 minutes to code in because I had already set minimap colors for all of the terrain types. It was just a matter of drawing these colors, per-tile-in-row per-row-in-matrix to a surface, then drawing that surface to a random corner of the screen. (It'll eventually have its own little window, I assure you, and it's got a spot in the lower-left corner with its name on it.)
Here's the good stuff:
Isofeatures
As hyped, I got 'em working, including animation, which I had actually coded about a week ago but never really implemented:
Pretend that those gray wheels are spinning in circles.
And no, IsoFeatures don't appear on the minimap yet, I neglected to assign them colors.
Basically there are a series of flags that may be bools or may be values and the isofeature behaves appropriately based on these. I bet that mixing types like that really makes some coders cringe, but "It totally works!" he said.
Animation
Just for fun, here's my animation class code so you can see how it works.
class Animation:
'' an animation based on a given tilesheet and framerate ''
def __init__(self,sheetName,msPerFrame=ANIMATIONFRAMERATE,randomFrame=False,linearFlag=True):
self.lenFrames = imagecache.getSheetLen(sheetName)
if randomFrame:
self.currentFrame = random.randint(0,self.lenFrames-1)
else:
self.currentFrame = 0
self.linearFlag = linearFlag
self.sheetName = sheetName
self.delta = 0
self.msPerFrame = msPerFrame
def getSurf(self):
'' return surface which corresponds to current frame ''
return imagecache.getX(self.sheetName,self.currentFrame)
def update(self):
'' update data : timer ''
self.delta += timer.delta
if self.delta >= self.msPerFrame:
self.delta -= self.msPerFrame
self.advanceFrame()
def advanceFrame(self):
'' go to the next animation frame ''
relay.trigger('isomap','redraw',True)
self.currentFrame += 1
if self.currentFrame >= self.lenFrames:
self.currentFrame = 0
This whole class gets placed into an IsoFeature replacing a animation=False bool if it is to be animated, then if isofeature.animation, the image is fetched through the animation class rather than through more conventional means in the isofeature's getSurf function (which higher level classes use to get its image to render).
What I really need to do if I ever want to run in greater than 800x600 is implement "dirty rects", which is a lot less naughty than it sounds.
Refactoring
I cleaned up the entire Borderstyle handling section in GUI. The rest of GUI and GUI's Panel and Elements is the place that could really use refactoring, but it is pretty intimidating. Ugh, so could IsoMap and IsoTile, the quad rendering crap especially. Let's see, what else did I clean up: Input, ImageCache (a little), added the ability to read bools to my file reader functions. I've got that "coder high", like I've suddenly realized many things that were just a bit difficult before. It's nice hitting these, and I like to think that I actually have reached a new level of understanding.
Just for fun I'm going to compare old code with new code.
The old:
class BorderStyleSurf:
def __init__(self,surface):
'' build style from given sruface''
baseDim = surface.get_width() / 5
brects = listFromFile('res/borderstylerects.txt')
def makeMulRect(rect,mul):
'' multiply every dimension in a 4-unit list by mul and make it into rect ''
return pygame.Rect(rect[0] * mul, rect[1] * mul, rect[2] * mul, rect[3] * mul)
self.topleft = surface.subsurface( makeMulRect(brects[0],baseDim) )
self.topright = surface.subsurface( makeMulRect(brects[1],baseDim) )
self.botleft = surface.subsurface( makeMulRect(brects[2],baseDim) )
self.botright = surface.subsurface( makeMulRect(brects[3],baseDim) )
self.top = surface.subsurface( makeMulRect(brects[4],baseDim) )
self.bot = surface.subsurface( makeMulRect(brects[5],baseDim) )
self.left = surface.subsurface( makeMulRect(brects[6],baseDim) )
self.right = surface.subsurface( makeMulRect(brects[7],baseDim) )
self.center = surface.subsurface( makeMulRect(brects[8],baseDim) )
self.baseDim = baseDim
And the new:
class BorderStyle:
def __init__(self,surface):
'' build style parts from given surface''
baseDim = surface.get_width() / 5
self.parts = {}
brects = listFromFile(os.path.join(RESPATH,GUISTYLEPATH,'borderstylerects.txt'))
bnames = listFromFile(os.path.join(RESPATH,GUISTYLEPATH,'borderstylepartnames.txt'))
def makeMulRect(rect,mul):
'' multiply every dimension in a 4-unit list by mul and make it into rect ''
return pygame.Rect(rect[0] * mul, rect[1] * mul, rect[2] * mul, rect[3] * mul)
for n, bname in enumerate(bnames):
self.parts[bname] = surface.subsurface( makeMulRect(brects[n],baseDim) )
self.baseDim = baseDim
def getSurf(self,partname):
'' return requested part ''
return self.parts[partname]
Much cleaner, and I'm being so good about filepaths. Still a bit ridiculous in parts, but it's quite improved I think.
Wow is that "dict of parts" comment ever redundant. I'll remove it immediately.
What's Next?
- More cheesy placeholder graphics
- TerrainEffects, and possibly Entities
- Minimap in its place
- Refactoring!!!
| |
| Refactoring, Consulting | |
Posted - 12/7/2007 5:11:25 PM | No screen shot today, nor much to say really. Been busy working for other people and figuring out how to manage my time. Switching states between projects actually does take a bit of momentum out of a run.
Trivia About My Code!
Interesting fact: I've got around 2200 lines of code going so far. The largest files are the GUI at 630 lines and the IsoMap/IsoTile code at 492 lines. The shortest is my Main class (Woo, OO!) at 30 lines (and half of that is imports). That sounds about right.
Refactoring
So what the heck, instead of "advancing" the code I'm refactoring it all to remove as many deprecations as possible, make file handling more robust, remove large commented-out forks, and make it more pleasant and efficient to work with. In the end, everyone will be happier for it.
The inspiration for this was a bit of a breakthrough with how to handle the many and conflicting needs of my tile subobjects (terrain,features,effects,entities), and how stupidly I was handling a lot of other things in comparison. I won't expand upon the tile stuff until I can show it in operation.
After seeing what my partner is doing at work, I think that I should add tabs to my panels. And I'm glad that I'm not making web interfaces for huge databases.
Art/Design Consulting
Jeez, I'm doing a lot more GUI design than I expected. This may be because GUIs may be the strongest point in my portfolio and GUI work has been the majority of what I've been doing on this journal. So I'm doing more GUIs. Am I damned to do GUIs for the rest of my days? Not that I mind, really; It beats animation.
What I'd really like to do is some grandiose digital paintings of sprawling science-fictional scenes. Maybe I'll just do one for myself.
Doing other people's art gives me less time to do my own, obviously. It looks like I'm going to actually have to start using placeholder graphics rather than "placeholder" graphics which look close to what I want my final graphics to look like that I spend hours perfecting. *cough*. I should just get over it and use sub-par graphics. Oh, but I do hate tainting my pretty engine with ugly graphics.
| |
| Wednesday, December 5, 2007 |
| GUI & Editor | |
Posted - 12/5/2007 4:50:03 PM | Editor functionality
Here's the shot:
I've added a number of "palette" panels to the editor in addition to the terrain palette. Multiple palettes creates the necessity for a palette chooser, so as you can see I added one of those too. I haven't quite pushed the number of terrain buttons past the bottom of the palette to properly test it, so I'll have to make some other terrains. (But I said this last week, I recall. I'll try not to repeat myself.)
I've made the editor "brush" technically able to "paint" things besides just terrain to the map, but I haven't tested these additional abilities because there's nothing else to paint with. I need to populate all of my other tile-objects and -effects and entity palettes with content! Lots more work presents itself, as ever. More on these in a bit.
GUI functionality
So now the GUI actually has the ability to remove panels from itself -- I never used it before except when purging all the panels at the same time. The ability to individually eliminate panels is needed to replace the editor's palette panel for when different palette panel is chosen. And so much more, of course.
I'm still having trouble getting the sliderbar's slider to slide. I can detect when the mouse is clicked on the slider and when it is dragged on the slider bar, but somehow the sliderstate which is explicitly set to "True" when the sliderbar is clicked comes up as "False" when the mousedrag function checks to see if it should be calling the slider -- and even if I remove this check, the graphic isn't moved. It's probably just a bunch of stupid errors and awkward manipulation of Pygame's rects/surfaces. I'm going to take a deep breath, stand back, and rebuild the whole mess after drawing a plan on paper of how it should work.
These sliderbar things span more of the interface than one expects at first. Try grabbing the 'thumb' on the side here and moving your mouse elsewhere on the screen outside of the sliderbar proper: It still slides as long as your mousebutton is held down. Madness! Not that it is difficult to do, just that I have to track one more thing higher up in the GUI than I want to.
Tile objects and effects
So how about those new palette panels in the editor? Well, they lay out the basic 'types' of objects and effects that can be applied-to/stored-in tiles. As you can see from previous screenshots, terrain more or less works (from a graphical standpoint, at least, there is almost no data being handled yet).
I did hack in IsoFeatures the other day, but I pulled that back out and need to think carefully about how to implement them (it'll take the sketched-out-on-paper design scheme, for sure). One problem lies in how graphics for IsoFeatures are handled: Some have one named graphic, some take a random graphic from a named sheet, some take a particular graphic from a named sheet, some will have to animate from a named sheet, and some will have to choose a particular graphic for themselves based on if neighboring tiles have certain types stored in them. Ugh. And the same pretty much goes for TerrainFX and Entities too.
I'll just have to be very systematic about it. On the upside, I'll be quite happy when this is all done and dealt with.
Good coding practices
I'm making an effort to use descriptive variable names. It's making my life much easier as code is far more clear when I'm not shuffling variables named "i", "a", "p", "i2", "aa", "aaa", and so on (I wasn't that bad during this project ever, but I have been in earlier projects). Even if it takes marginally more time at the moment, it really pays off to be descriptive in the long run.
Along the lines of being a lazy coder, I've been handling file paths as straight strings in Windows style. No longer! From now on I'm going to use the proper os.path.join function, and at some point I'm going to have to clean up a lot of old file handling code. Ugh again.
Art + design consulting
It looks like I'm doing art/graphic design consulting for two projects. This is really cool, and I feel like I am actually competent at this through some incredible force of osmosis that took hold in the last four years.
I wonder what that could have been.
| |
| Terrain fringe ordering + not getting things done | |
Posted - 12/3/2007 7:57:47 PM | Not getting things done
First: Being the one without a job, I've been recruited to care for my sister-in-law who is recovering from a tonsillectomy. I didn't get much work done today and probably won't for the first half of this week.
Second: I'm trying to make some small bucks as well as build my portfolio so I'm looking into doing "consulting" on Gamedev for amateur game developers in need of art. I set up the beginning of a game art portfolio and I'll get around to offering my skills once I figure out how much work this first offer is going to be. More on this as it happens. My game may go a little slower for it, but my artistic and coding energies draw from somewhat separate reservoirs so I don't think it'll be a problem.
Re-doing terrain fringe quad generation
I did accomplish a little today. As I pointed out in a previous post, there were small graphics errors cropping up in the terrain fringe transition quads (say that four times fast). I commented out all of the terrain fringe quad generation code in which a tile queries its neighbors terrain type per quad in itself to find out what graphics to use and then rewrote it all. I was a bit disappointed that it turned out much the same as before, though I did fix a bunch of things that could be described as cheap hacks, which I suppose is the whole point of cleaning up code.
Long story short, the problem ended up being in the section where I ordered terrain types by the arbitrary 'height' value. I had tried implementing a so-called "cocktail sort", which is like a double-ended bubble sort. In retrospect I should have tested it, but I didn't, so I replaced it with a cheesy bubble sort which really ought to be enough to sort lists that average maybe 3 or 4 elements. Problem solved, the terrain looks good now. And I redid how shorelines are drawn, they're much less hacky now.
I started back on scrollbars for sliders but got called upon to be waiter/nurse. Check back Wednesday, we'll see if I can get much done.
| |
|
| S | M | T | W | T | F | S | | | | | | | 1 | 2 | | 4 | | 6 | | 8 | 9 | | 11 | | 13 | | 15 | 16 | | 18 | | 20 | | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | | | | | | |
OPTIONS
Track this Journal
ARCHIVES
October, 2009
July, 2009
June, 2009
May, 2009
April, 2009
March, 2009
January, 2009
December, 2008
November, 2008
October, 2008
September, 2008
August, 2008
July, 2008
June, 2008
May, 2008
April, 2008
March, 2008
February, 2008
January, 2008
December, 2007
November, 2007
|
