I'm still around, and I'm still working on BASeBlock, I assure you! The standard landing page hasn't seen as much care as it really should, mostly due to connection problems as well as having to manually ftp files back and forth. In any case, Here are some images of BASeBlock taken with it's screenshot feature. I basically just tore these out of the screenshots folder it uses. Either way the screenshot feature is a lot easier than having to alt-Printscreen and crop it with photoshop or another image editor: First, the platforming component.

The platforming component has been rather greatly expanded since I took that screenshot; it now has powerups that can come from blocks, and a few enemies. I also tweaked the sidebar, as can be seen. the white weird kaleidoscope version was a tad out of place. I made a few further revisions to the sidebar status layout as well, as can be seen in this image, which demonstrates one of the more recent changes I made (as in, today) to the "normal" Block. The sidebar doesn't have the appropriate items to show the new layout, but the energy bar is closer to the HP bar and fits in the upper "box" area; the second box, shown below, shows the current powerups. I was going to perform some further tweaks, such as showing them larger (and thus more recognizable). I was also considering the possibility of dealing with mouse events within the status bar separately from those in the game area, to allow for things like tooltips or messages when mousing over powerups, or something.

Some other more recent changes include fixing a bug/issue whereby the eyeguy slows everything down immensely, which was the result of the eyeguy forcing every block to redraw, which could be untimely if there are lots of image blocks with large images, and whatnot (or really any semi-complex drawing code). The same "bug" is in the boxdestructor. I believe I fixed them; they were indiscriminately forcing all the blocks to redraw when the intention was to only do so when they destroyed a block.

The former image also shows a new enemy I added, the spinner guy, which spins and shoots bullets. the bullets are deadly to other spinnerguy's or to eyeguys, as well, and also to gamecharacters; gamecharacter being currently represented by a Mario 3 set of sprites, but I intend on changing it to something more appropriate (and that isn't copyright, mostly) before I release it. Don't hold your breath for something awesome though since I am terrible and character design. I fixed quite a number of bugs in highscore display, which now also shows asterisks next to the name that was just submitted in the list; the value editor (used for cheats as well as the high score entry) now supports character editing via a cursor. As seen in the screenshot there is a new "orb" item; the idea is that these will provide health, score, and energy in small amounts. I intend on making them a lot smaller than in the image, and there are still some things to work out, like where the heck they are going to come from (perhaps every block broken could spawn a small amount of them, and the paddle needs to catch them (like powerups) to gain a teensy bit of health or extra points). The primary reason I haven't "packaged" this version up for release is because that is a massive pain; and I always have "half-finished" features- "just after I finish this one thing" type stuff. Hopefully I can have a new version in a week or so, unexpected circumstances notwithstanding. I'm also going to remove the limitations on the unregistered version, and make it so there really is no reason- yet- to register. primarily because I want to purchase a proper license for BASS.NET and BASS first, to avoid any complications later on.

2.1.1.0 changelog:

fixed DWM check on XP. (was crashing when trying to callinto dwmapi.dll, not surprisingly) *fixed missing System.Drawing.HTML Exception when showing editor window *tweaked editor tooltip so that it doesn't cover the point where the mouse is.

2.2.0.0 changelog:

2.1.1.0 changelog:

fixed DWM check on XP. (was crashing when trying to callinto dwmapi.dll, not surprisingly) *fixed missing System.Drawing.HTML Exception when showing editor window *tweaked editor tooltip so that it doesn't cover the point where the mouse is.

2.1.0.0 changelog:

• *Bullets now check periodically to make sure the block the are "attached" to still exists. (prevents the "floating machine gun bullets" bug).
• *Splitter ball powerup now works properly with the sticky paddle power up. (if the paddle has it the splitter forces it to release all the balls it holds).
• *fixed CrazyBlock so it isn't mysteriously invisible for no reason. (Serialization issue, it was being saved as it's superclass type (BallBehaviourBlock<CrazyBallBehaviour>). Happens to the best of us.
• *Changed vomitblock to actually make sense rather than inexplicably cause a crapload of ridiculously large explosions.
• *fixed the crazyblock. so it actually displays.
• *fixed terminator (gun) powerup to enable the machine gun" higher level modes.
• *changed grow and shrink sound effects
• *the Magnet powerup now recharges the energy of the paddle as well.
• *changed sticky and terminator overlay images
• *attempted fix XP issue where some items drawn are flickery. Solution was to check the OS/composition options and use a different paint routine. the XP/non-composited version composites the image itself by passing in a bitmap buffer to the "normal" paint routine, and then painting that. I say "attempted" because I've not had the chance to test it.
• +FrustratorBlock now lives up to it's name.
• +pressing shift with the "Sticky" behaviour will release all the balls stuck to the paddle.
• +Clicking during the level score countdown will skip it
• +added a new splash screen image
• +added JavaScriptBlock, which at the moment is pretty much useless. (Uses JINT interpreter)
• +Added Extra life powerup, when I realized there was no way to get extra lives. at all. Very rare, though. (maybe I could add something like coins to collect?)
• +added "brickstest" levelset, which demonstrates theming.
• +made eyeguys less of a death sentence when they are spawned. (they shoot less often now). (around 4 times less frequently)
• +made the enemy spawning "powerup" stop putting eyeguys underneath the paddle. That was annoying.
• +when eyeguys die they now use the "explosion" effect, which was added LONG after I originally implemented Eyeguys...
• +added Block replacer filter to editor.

BASeBlock 2.0 finally released!

EDIT: The Program seems to be problematic for everybody but me. I want it to work. I've spent the last three days, without sleep (not even joking) fixing all the niggly issues with the game that have cropped up, and now I can't reproduce a lot of the issues. I updated the version online to 2.0.1 (also reduced the size of the installer by a nice sum) which will write crashlogs. Finally, BASeBlock 2.0 is upon us! It can be found on the Downloads page.

This program also marks my first attempt to "go commercial" at least partly. this is described in the summary on the download page. Basically, BASeBlock is shareware. Buy it, I send you a registration key, and it unlocks some protected behaviour. For now the only locked function is that you cannot save files in the editor. Just getting the bloody thing uploaded was a tale in and of itself, but that's another story.

BASeBlock Version 2.0 is coming close to release; It should be out by the end of this week. Only a few minor issues remain; High scores are working perfectly now, and I've added a bunch of new block types since I had a huge brainstorm of ideas. The "terminator" power now has a goofy projectile and machine gun stages, and a new "laser spin ball" powerup which makes the ball randomly shoot weak lasers around. I'm hoping to refactor some of the core "engine" code to make it easier to maintain and extend. (The gameproc() routine is far too long and I need to pare it down). Speaking of which, I really need to split up block.cs and cGameObject.cs into separate files. cGameObject.cs has almost all the GameObjects, which includes all the powerups, enemies, etc.

On the topic of BASeBlock, I should point out my latest blog posting ; BASeBlock will still be open source, but it will also cost money to enable the editor's save function. If the two seemingly disparate goals interfere (being Open Source and being paid for, specifically) I may end up sacrificing the former in favour of the latter, at least until a balance is found. I'm not 100% sure just yet how much it will cost but I was thinking around the 5$ mark.

Sales

1. A Name
2. A Organization
3. The Product they want to purchase

Today's bit of "news" was a tad long and general to have as a news entry. it can be found here. Basically, the best summary is that I am trying to expand into the work of freelance work, something I probably should have done long ago but didn't really know how to start. This will serve me on several fronts I feel:

• Experience

  The obvious one here is that I will gain experience. I would do that anyway, but this will "force" me to explore technologies more thoroughly; in the case of this application, I've learned even more about WPF, ADO.NET, and MySQL.

• Professionalism

  This site doesn't exactly reek of professionalism, but whatever the site may seem like at a glance, I take my freelance development VERY seriously. Perhaps even too seriously. I feel that a persons work in the field reflects upon them. And I work tirelessly to make sure that I create software that I can still be proud of years down the line, and that customers can use to fulfill a variety of needs. So far, my projects have been "hobby" projects. BASeBlock, for example, I feel is very cool, but I only kind of work on it and add stuff I "feel like adding"; so I might not always fully explore some avenues. As a freelance professional, I have specifications that need to be followed, and it pushes me to learn many new technologies, and develop skills in those technologies I might be familiar with but otherwise try to avoid. I've found, over the last few days working on this project that despite my misgivings about using new technologies I have because I might mess up or get in "over my head" I've yet to encounter any hurdles that can't be solved with the mindset that they aren't obstacles to be overcome, but rather challenges to be faced. New Levels to complete, to stretch the very sinews of my abilities to bursting point until they stretch beyond what they were capable of before. It's all about self-improvement in a personal level, and the fact that I can deliver excellent, High-Quality software at the same time just makes sure that everybody wins.

• Financially

  It's no secret. At the moment I am unemployed, mostly through my own actions; there is no reason for me to be working in retail food chains. I'm sick of assisting highly-paid Database administrators and IT specialists with their problems on-line with my experience and know-how while I try to scratch by on jobs that are basically the equivalent of burger-flipping. It's time for a change. It's time for me to use that knowledge to help people, companies, and others in a professional capacity that serves to keep me afloat. That's all I want. I don't want to be rich- I just want to make a living doing what I love, and I don't think anybody can blame me for it :).

Entirely unlike everything and anything I've posted as "news"; I gave Linux Mint 12 a shot yesterday. This was prompted primarily because I found a broken PS3 and ripped out the hard drive (80GB, btw) and found it to be your standard notebook SATA hard drive. so I plonked it into my laptop (keeping the 250GB that is normally resident in it in a safe place) and installed Mint 12 I have to say it is very impressive. A few things that I couldn't figure out from a quick search or two made me decide not to upgrade my "main" drive to Mint 12:

• No Emerald. Or compiz. I've grown to like the pointless wobbly windows. Emerald has become an addiction as well.
• reminded me of how much I've customized my own install. At the current time the task of doting through config files to reproduce the same effect (and of course trying to get the data off the 250GB's Mint install, which is on a small partition iirc anyway but nonetheless would be a pain) is not something I am apt to find enjoyable. Who would. Not sure.

When I do further prodding, I may write a blog post to cover the experience. I've not written one in a while and it's starting to feel stagnate.

Not a whole lot to say. I've hardly touched BASeBlock aside from a few minor changes (writing a new function for bricks that makes a block break into a given number of columns and rows of bricks). More importantly, as a result of... other issues- I've no longer got internet access, at least for the time being, from my house. That makes things a bit tricky to get access to my website. Actually I was quite surprised I was even able to login, given that my hosting account was locked down for a while. Most annoying is having to use the UNIX ftp shell rather then the nice friendly interface that Editpad Provides. Oh well, it's usable, at least- that's really all we can ask for.

That said, the hosting account current is paid up until January 2012; I have enough in paypal to make that payment, but I will not be able to make the February 2012 payment, so unless circumstances- particularly those regarding my financial situation - change, It's unlikely the site will remain up past that point. I think the domain is up for renewal in Feb as well... that might be October, though.

LOL recanted

Basically, I might have a new version of BASeBlock up that resolves a few issues. I might not. I'd bet on the latter, though. It is far more likely.

BASeBlock news

BASeBlock development is moving along. I want to say I made "major changes" but I can't really remember anything specific that is huge. I added the ability for Levels to have "message" data, that basically allows text to appear at a given time index. This is utterly pointless for anything but making karaoke levels or something stupid like that. I will probably take advantage of it to make the credits better. However, I think it needs refactored so that it uses the existing Triggers/Events framework; instead of a series of "Messagedata" things, it can instead have a series of triggers that are fired at those appropriate times, and then a set of Events that are triggered by them that show the text. The only issue would be with making a clean UI for this that isn't too confusing, possibly relying on the current "import" feature to add all the necessary events and triggers as needed. Of course that would raise the issue of what to do with existing events and triggers since we can't simply wipe them all. Or, I could just leave this as is, and add the events/triggers for similar functionality as an "advanced" way of doing the same thing.

FrustratorBlock is done, and works well. Brick block, which acts something like the bricks in Super Mario Brothers (breaking into four pieces that fall) works well too. I fixed a few minor bugs that I encountered in a few areas; I believe I noted these in the development log so hopefully when I update it the changelog will actually be something more than "Added stuff. fixed stuff. enjoy version 1.5". Also changed it so that the sidebar and the colour of the text on the sidebar is dictated by the level. This allows something that could be called "theming" of levels. As it is now, the only issue with that is that the game over screen for some reason uses the same colour, but the default sidebar. (ideally it would use the same sidebar as the level that the player lost on). I've been meaning to rewrite BCSearch, as well, if only so that I can actually work on it. the VB6 project opens and now runs but vb6 just feels- dirty now, after working in Visual Studio 2008 and C# for so long. Even with the AxTools addon installed, which I recommend for anybody using VB6, and if you cannot afford that then you can use MZTools6, which is a fine product as well.

working on adding "scripting" support to BASeBlock. after struggling with IronPython and lua for far to long, I said screw it and decided to go a different route.

My original intent was to have scripts managed much like items; then have a single "scripted" block, ball, behaviours, etc that could be bound to script functions. Unfortunately all the references I could find seemed to be for .NET 4 and DLR... or something.

Anyway, what I ended up doing was using a different approach.

When BASeBlock starts, it was inspecting Assemblies that it found in it's Executable directory. What I did was added a bit of code that would not only do that but also find .csx and .vb files in the scripts folder, and attempt to use the CodeDOM (provided by the framework) to compile those files into an assembly that it then adds to the Array that it inspects later. Works great; had to add in some code to make sure the ignore code wouldn't ignore the script assemblies.

The only issue so far is that the one Block I tested with can't seem to call the base AddScore() routine in Block; even though it was copy-paste and name change from the already existing and working AddBallBlock... oh well.

Mild oversight during packaging of the BASeBlock 1.4 release; it's INI File refers to locations on my own filesystem. This can be fixed by deleting the INI file, located at %APPDATA%\BASeBlock\BASeBlock.ini That is all! I'll remember this for the next packagement, though; simply exclude the INI file from the package, since it will simply be created anyway.

No "real" news (the ideal case would be actually uploading a new version of BASeBlock!) but I did change it now so that when low on health the game area "flashes" red.

Main reason I don't want to create a new installer and upload it is pretty much just because I haven't finished what I intended, which would be the high-scores. They sorta work but have some issues I've not been able to sort out (Scores keep getting cleared for no reason).

With any luck I might be able to figure it out. At the very least I'd like the local high scores to work; then I can work on integrating the Web-based scoreboard stuff, the PHP for which is finished and ready, as is most of the "back-end" stuff in BASeBlock (the scores implementation).

EDIT: I lied. I uploaded the new version and it's source anyways.

Several things: Got involved in a Minecraft Spout plugin, called, at the moment, "SimpleProtect". Currently concentrating my efforts on some of the code for accessing the database via JDBC. I only really have two problems with developing bukkit/spout plugins, the main one being that they are practically impossible to test locally, and if you do set up a bukkit server simply to test the plugin, you'll find you have none of eclipse's (or whatever debugging capabilities your IDE exposes) available. So it's back to trying to print out errors to the console (or in this case, the minecraft chat) to try to isolate where things go sour.

For BASeBlock, I added a new "EmitterParticle" Which derives from Particle and, while having many of the same properties as a Particle (movement, location, velocity decay, etc) it isn't actually visible on it's own, but rather merely "emits" more particles. The effect is actually pretty impressive when done correctly. Switched a few of the Dust Particle instantiations (such as when blocks are destroyed and when a ball bounces off the paddle) to create EmitterParticle's instead. looks quite cool.

In other news, I REALLY need to switch parts of this main site to stop using tables. I think first I should turn this news page into DB content, rather than a static include. I've already started a script to manage and display news entries via the database, much like the Downloads, Links, and Flash pages, which are really just the downloads page wearing a different funny hat.

Also, these advertisements are getting extremely annoying. I'll leave them up for a week, but if the gains aren't worth it (I've not seen a cent so far) I'll just remove them.

I'm starting to get a tad desperate, so I've decided to experiment a bit with advertisements on the site. Up until now I've not really bothered; I had adsense for a while but I think in the last year or two that I had them, I've made like, 20 dollars. So with a heavy heart (heh) I tossed up some advertisements from other providers. I've no idea what will happen. No idea what to expect. So far one advantage is that the ads freaking show, which I imagine to be an advantage. Another is that these news, Downloads, etc entries are a bit more readable, being that they are now right-marginned for the ad space. I think even if I remove the ads (after receiving my copious bounty of a few cents) I will keep the gap, for readability's sake.

BASeBlock work is, as always, slow. Again, lethargic, etc.

I did do a few things though; made the TerminatorBehaviour (that is, the 'Terminator' powerup that allows the paddle to shoot stuff) "upgradable"; getting several of them will result in the power upgrading. It only has three levels- first level it shoots a ball from the center, second level it shoots two, one from each end, and the third level fires a laser from the center. The laser is a GameObject that will go through and destroy all blocks that return true for "MustDestroy", which basically means all non "solid" blocks, such as invincible blocks ,ray blocks,etc will not be destroyed.

Also added a "level browser" which highlighted a few issues with my serialization code, which I fixed. The cause was that a piece of code within a GetObjectData() ISerializable implementation was throwing an exception, which ended up essentially cancelling the rest of that write; the cause was my addition of the level images, which are stored in the CreatorProperties class; the exception was a result of trying to remove the existing items and recreate the new ones; the existing items were being removed within the loop, which caused an InvalidOperationException on the next iteration, which was caught at the higher level and the stream was closed, with only 18 bytes written. Then, reading that in would result in the GZipStream complaining about the lack of data.

Serialization has been something I've not been fond of in my implementation. Currently, it works. But it has a few distinct problems. First, I don't like using the BinaryFormatter(); it's far to platform dependent. Ideally, I would use something more documentable; I've had passing thoughts on trying to implement a serializer so that the data can be stored in a NBT-like structure, based on the minecraft format used for data files. It works fine as is, but I want to avoid issues.

As it is now, it saves and loads data by using BinaryFormatter to deserialize and serialize the "root" object, in this case, the EditorSet; it also passes it through a GZipStream instance that helps compress that data a little. It now plonks a basic boolean header to determine whether the remainder of the stream is a GZipStream or not (this is useful for debugging, since it's harder to isolate the cause of SerializationExceptions as a result).

Other interesting bits of news- working on more of my Wallpapers, and I recently got an E-mail about updates to Editpad Pro, which is the editor I use, and am in fact using right now. I haven't seen anything i nthe new version that justifies the price to upgrade, though; although the latest newsletter does implicate the pending release of a 64-bit version, which might tip the scale. In any case, for a text editor, I don't think anything else can compare to Editpad, and the Pro version is something I don't think I could go without anymore. Editpad Lite is free and an awesome editor. I cannot think of any other editor that I found better; notepad++ has shitty hard to follow menus that make no sense and a somewhat crap plugin interface that actually manages to look worse than the way my plugins worked in my old "BASeEdit" editor program. Most useful to me has been the FTP Panel, which has made editing my site FAR EASIER than I could have ever imagined. I basically open the panel (or more precisely, it stays open as a preference), connect to FTP, double-click the php or whatever file I want to edit, make my changes, and simply save them. No nonsense with an extra upload changes step- and timeouts are no issue since it will just reconnect when it needs to. Very slick.

Of course I'm not being paid off or sponsored by JGSoft in any way, although I would love to be, and could plug their software for hours shamelessly.

Progress is still slow on baseblock. Mostly because I am sort of lethargic when it comes to working on it. Occasionally I have a fun idea and will work for hours on it's implementation, but as for finishing the critical stuff, I find it extremely boring. Most of it seems fixed but there is a lot that needs to be done, and it involves the code I hate to mess around with, which is the code for dragging and selection in the editor. I did, however, decide to do two things: One, I finally hooked up the sound for the "Terminator" Power up, and additionally I added an additional "power level" whereby the paddle can shoot laser beams. Or, that is the intended affect, I have yet to test it yet.

In other news, portions of this site were down for the last day or so. Seems that somebody, or something, tried to- or, for all I know, is trying to- brute force my cpanel/ftp password, which caused the system to "lock" the account as a result. I was able to get a representative to reset the password, and more importantly to white-list my current IP, meaning that I would not be affected by the lockout. I also changed my passwords for nearly everything to a random string. This of course has the issue that I have no chance of ever remembering it, so I just store them in a safe place.

BASeBlock news: I've done virtually nothing on BASeBlock over the last few days. Here are the things I want to have finished before I release another version:

• High scores: These aren't quite working properly- they act sorta weird for custom levelsets.
• Path Editing in the editor: This "works" for low-ball definitions of "work", and it <can> be used for creating and editing paths, but it doesn't really work very intuitively. Selections sometimes act weird- and barring that another fix I made somehow broke the path node multiple selection code entirely, so you can only select a single point.
• The Editing Grid: It no longer works properly. Well, it does, but I need to properly move the blocks; right now they are "locking" their centers to each grid point, when each grid point was supposed to define the boundaries of where the block would be.

Honestly, there isn't a whole lot to get excited over- unlike minecraft for example it's hardly a unique concept, and it's a game that has already essentially been done to death. That and it uses GDI+ for the graphics rather than OpenGL, the Tao SDK or XNA like a 'real' game does. That said I've found the flexibility inherent in GDI+ over plain old GDI (such as, BASeBlock's predecessor, Poing) to be very enabling of all sort of effects; particles that fade out, neat ColorMatrix transforms, rotation, etc. And of course I have learned A LOT about C# in the meantime.

In other news, I created a DeviantArt account, shortly after some of my wallpapers were submitted to Equestria Daily, and showed up as part of a Wallpaper Compilation there. Of interesting note is what resulted after that post. First, this is my bandwidth usage for September:

Quite humble, nice and low volume. No problems.

Then, when I got home and learned of the eqD posting, I checked the bandwidth usage...

WOW. Of course since I had already used 13% of my monthly bandwidth on the first of the month, I thought it would be a good idea to reduce the bandwidth. In what can only be called providence, I had recently started a deviantArt account on which to post those wallpapers; the wallpapers themselves are huge, 2880x1800 for almost all of them, 5 to 6 megabytes each. And of course serving up the thumbnails, and the rest of the site (which some may have done to find out where they were).

Anyway, so I swapped the php gallery I had written to make automatic thumbnails of a web directory out for a static page, and swapped in the URL to the images on deviantart for each thumbnail. I'm fairly certain this explains the drop in bandwidth usage for the following day- (note how it is still quite a bit higher than the average for Sept.). I then slyly added links to both this main page here as well as my blog.

To be fair I'm kind of surprised about two things: the fact that any of them were featured; honestly, I didn't think the wallpapers were really that good, I'd hardly consider myself an artist by trade or even by hobby. I have however been convinced otherwise (that the wallpapers are good/ok, not that I'm an artist by trade or even by hobby, graphic or otherwise). The other thing that surprises me was that even in the case that one of them were to be featured, I sort of expected it to be a few of the images being rehosted (well, ideally) and/linked individually; I would have never expected all of them to be featured. (Maybe Cereal was just lazy, or thought they all had their merits and couldn't be bothered to post them all except for the megaman one (which of course garnered much commenting).

BASeBlock progress: upped the version to 1.4 for the next release, when the heck that is going to be I haven't a clue. It's not like I have a million people waiting for it to release. Actually I doubt anybody is waiting for it to be released. Anyway, so there's that. The implementation of DestructionBlock and ConstructionBlock are completed. Both use a new "GameObject", a explosion effect, one of which creates new blocks, and one that destroys them. After that, I also added a "Combo" feature, whereby the game knows when you destroyed a bunch of stuff using chain reactions. Demonstrated in this video:

Since then, I've tweaked a few things; the combo sound effects and their associated names are now totally random animal names, "Squirrel", "Chipmunk", "Badger", "Pidgeon", "Penguin", "Ostrich", "Kangaroo", "Platypus", "Koala", "Panda", "Possum", in order of their "values". the combo text now shows from the very bottom of the screen and scrolls a tad faster, and the explosion effects now include particles. The explosion emits dust particles along it's circumference each frame, giving them a speed moving outwords with a random variation, the creation effect is similar but emits waterparticles. No other particularly major tweaks to report, the Animal-based combos are HILARIOUS though. Also changed the mechanics of the CreeperBlock; instead of causing instant damage to the paddle on contact, it creates an ExplosionEffect; the ExplosionEffect itself has of course been changed to damage the paddle as well, and it works quite well.

After adding quite a number of different blocks (in various stages of working) I noticed something. The block addition menus are way too big when there are lots of elements. The solution? Categorize the blocks. I did this by creating a base BlockCategoryAttribute, and several classes that derive from that and implement the appropriate abstract methods for name, description, and icon. In the appropriate drop down routine, I added a parameter that accepts Type which ought to derive from BockCategoryAttribute. if null, the routine creates a element for each loaded attribute (these are loaded when the game starts) that derives from BlockCategoryAttribute, and sets the event handler for those so that when it drops down it calls the same routine(as the "parent" dropdown), and sets the tag appropriately. that routine will see the tag and will call the drop down routine using the Attribute passed in said tag, in which case the routine merely adds all items that have that attribute. The base level enumeration doesn't add elements that have attributes. The result is that uncategorized items appear at the "base" level, while categorized items appear in their respective drop downs, as can be seen here:

Looks pretty good to me. Another interesting issue, is that I managed to somehow "disassociate" the events I wrote for a few controls with their event handlers. The main result of this was that I thought my block categorization code had somehow broken multiple selection and dragging in the editor, but it turned out the code for MouseMove was simply never being called (as the event was unset). No clue how that happened.

I've also made a few refinements to other segments of code; fixed a few bugs, and added a new "Menu mode" that so far sits unused but shows a selection of options on the game screen and allows the player to choose one, firing the appropriate events. Sort of like the current Cheat Entry/Value Entry mode that allows the entering of both the high scores as well as cheats when the cheat combination is pressed. The current version also adds on to the Cheat entry mode; and uses the same code for entry of High scores, making it somewhat better integrated into the game itself, rather than popping up a separate form.

As it stands now, for example, the hiscores don't work properly; I've yet to investigate why. When finished, it should work in a way that the high score tables are stored individually for each levelset that is opened. My original implementations actually stored the highscores in the levelset itself, but that presents something of a problem when it comes to separate implementations of iLevelSetBuilder's, since they don't save. Instead, this table is stored in a separate file in the Application Data folder (HISCORES.DAT).

Current progress of features:

-The cNewSoundManager now supports playing back a "set" of music; that is, when the first one finishes, the next one will play. This is now possible by simply passing in a String array of keys. Also, the standard playmusic() routine now determines if the given sound name has a pipe character, and if so, splits the string into a array of strings and passes that to the other method for playing multiple files. The end result? Any properties changable in the editor will allow for multiple sounds. Currently it doesn't take into account sounds (rather than music) so if you try to play a series of sound effects in this way it will end up constantly looping them (this should be an easy fix I may attend to shortly).

-When the player get's game over, they are now properly "prompted" if their score made a place in the high-score table. The prompt uses the same code that was used for the Cheat Input- that is, it is shown in the game window, and manually drawn. I feel this makes it feel more "gamely"- better than a random inputbox, that is for sure. Half-implemented is the change to the game-over screen to account for high scores. Rather than show the Window displaying the scores it will display the top 10 or so scores in the game over window. Of course if the player wants more detail on the scores they can always use the menu option. (which would also be broken since it would try to view the high-scores for the game over level :/ (is it obvious why I've not released it yet?)

-Pointless Easter egg on the splash screen. I've wasted too much time on it.

-changed ball-block collision code to use Liang-Barsky, which basically means that balls no longer go straight through blocks if they are going really fast. The collision code still needs work, however.

-Editor has a bunch of features added; new blocks, one of which allows for showing a piece of a given image. That block is used by the editor's Image import routine (if the option is specified) so that you can get a full-resolution image into blocks. normally, one block would equate to one pixel.

-trying to fix a bug I'm encountering with the .NET TextureBrush, which gives a OutOfMemoryError. I'm convinced it's related to the size of the bitmap, since it works with smaller ones. As such I am refactoring that bit of code to draw the background using images manually if such an error occurs. A bit of a pain since the TextureBrush makes it so much easier, but oh well.

Other things I've been working on- although I haven't touched it in a while, I have got a mostly functional implementation of a bukkit plugin (bukkit being a minecraft server implementation) that allows players to create pixel art from images. Some screenshots of it can be found here and here.

First video: Early Alpha development:

Second video: far more "completed" development:

Comparing this one to the previous one blows that one out of the water; note the new "sidebar" which is actually drawn on the same surface as the game action (but is only drawn when necessary) additionally, I have added here Moving blocks, as well as a few other block types that aren't seen here, as well as the "Street block" (which is the one with the woody woodpecker image and sound effect). the latter is intended as a sort of tribute to a departed Internet friend. Water blocks are implemented here, along with their stellar particle effect that is oh so awesome (as I note in the video).

As it stands now, I have since added a assortment of changes; Paddle "Behaviours" which basically change how the paddle interacts with balls; a current implementation uses the "StickyBehaviour" class, which implements balls "sticking" to the paddle, and are released when the mouse is pressed. Speaking of which, I have also abstracted the input model; rather then handle events directly from the picture box, instead, the iGameClient interface (implemented by the main form) fires off relevant events which are handled by the GameState object as well as any interested classes; the StickyBehaviour class, for example, is interested in when to release the ball, so it registers for the button press events.

Needless to say, this will make it a million times easier to add in support for customization of the input as well as joystick support.

Sound

bcxinfo, while not quite abandoned, has definitely had it's development put on hold; I just don't feel that I can ever quite compete with any true utility in it's domain. As one can see on the downloads page, I've also created a new game; "BCDodger". This was more or less an early experiment at trying my hand at a graphics-based application in C#. The concept is simple; keep all drawing confined to the Paint event (using CreateGraphics() on the picturebox/form is a very bad idea, especially for a game). Basically, what I do is rather common- I create a separate thread that essentially does the game movements and then it tells the UI thread to redraw the picturebox using Invalidate() and Refresh() (via a cross-thread invocation); the paint even then goes through those same objects and says "hey, draw yourself to this this canvas" and the objects do so.

One mild caveat with regard to my implementation within BCDodger is that it doesn't use composition; that is, everything is drawn to the same graphics object every frame. as a sort of "upgrade" to my rudimentary 2-D engine, Poing 2, or, as I've renamed it since, BASeBlock, takes a more conservative (processing wise) approach, whereby various "layers" are created. These layers are drawn to (for example, blocks are drawn to one layer- animated blocks to another, the background to another, etc. and finally the layers are composited (drawn) to the actual picturebox canvas on top of one another; the advantage here is that when I draw the balls, I can simply clear the ball canvas; leaving the block images 100% intact; this means I only need to redraw the blocks when they change (usually when a ball hits them). Additionally, I created "animatable" blocks, which are drawn to yet another layer (otherwise drawing an animated block would require clearing the block canvas, which reduced performance quite a bit). A rather early alpha of the program can be found on youtube: http://www.youtube.com/watch?v=I3LUdIGjuXc Note however that what I have working currently is quite a far cry from what is represented there. Unlike BCDodger, I believe this one will take a bit longer to "perfect" since I need to get saving/loading of levels and of course a useful level editor, like my earlier game, Poing. Which of course received critical acclaim in the worlds leading gaming magazine for it's innovative gameplay and it's editing features. At least that's what I tell people.

Lately, I've taken it upon myself to "update" my skills with something a little more modern. I've used C# before but never anything more then a few simple programs here and there, and I decided it was time to actually port or make a new project in it. I chose to rewrite BASeParser for a third time. I felt that I had "lost touch" with some of the algorithms involved, and a refresher could help both my C# ability as well as make improvements. I have to say, the C# version has come along a lot faster then expected. there was still a lot of trial and error debugging, mostly involving 1-off errors in relation to arrays and string indices, but I managed to muddle through. It uses essentially the same algorithms as my VB6 version; what sped up development incredibly was the generic data types that the framework provides- I didn't have to write my own LinkedList-oriented class as I did for VB6 (cformitem) instead, I just created cformitem to contain the relevant members value, operation, etc. and used the generic LinkedList type to create a linkedList of them. Each formula item, like those in the data structures of it's VB6 predecessor, contain a number of critical values which have different meanings depending on it's item type- for a IT_FUNCTION (I kept the constant names that I used before) the "Operation" member is a name of a function- for a IT_OPERATOR, it reflects the operator, such as +, -, etc. Value, for IT_FUNCTION types, is a boxed array of CParser (the main parser class) objects. when the Function needs one of the parameters, the handler merely unboxes a reference to the appropriate CParser and calls it's Execute method. I considered using a separate member to prevent the boxing/unboxing operation, and may very well do so (perhaps I can simply check in the CFormItem class when the Value property is assigned, and if the new value is an array of CParser[] objects it can set an member variable of that type, and the handlers for IT_FUNCTION and related item types can simply grab the value from that member instead of having to unbox the value. There will still be boxing of the value when it is assigned, but largely the burden will occur during the Parse stage, rather then being done repeatedly for each execution.

After spending so much time using Visual Basic 6, Visual Studio 2008's debugger and IDE abilities are something to be amazed at. With VB6, I use an add-in- Codesmart- that provides a lot of the features that Visual Studio 2008 has built in.Refactoring, extract method, etc. The syntax highlighting is a huge improvement over the otherwise basic colouring provided by VB6, not to mention allowing you to choose more then 16 colours. And then there is, of course, the framework itself. hugely diverse, most data structures and features you could ever need are there.

As is evident if your eyes are working :P I added some advertisements to this page. This is an attempt to try to get something for my efforts with the various parts of maintaining both the website as well as the various downloadable applications that I make available. I certainly enjoy giving my programs away at no charge, even though, upon further thought many of them are at least as good as or even better then commercial equivalents. (for example, BASeParser, which, while only at the moment released as a component of BCScript, by and large outperforms a commercial product called "AXEval" (IIRC) that I found online when I was curious. It Costs upwards of 300 dollars, too, and you can get a better evaluator just by installing BCScript and using the DLL in your own applications, something which I don't mind at all :).

This posting seems a tad short so I think I'll share some "ideas" I had for new applications. These probably won't come around anytime soon but they give some food for thought.

"Grapher"

Currently, I have an otherwise ancient version of this program, a 2-D and 3-D(using Direct3d) function graphing program. It uses an even older version of "BASeParser" that is really just an adapted and heavily modified (bastardized and mutilated describes what I did to it more aptly) version of a functionparser I found online. The project was huge, consisting of 20-30 forms, countless classes and modules, etc. It doesn't run now simply because of all the heavy modifications I've made to the Parser- for example, the original version of the parser didn't support arrays like {1,2,3}... the graphing program had to hack in it's own support for them. It was awful. it worked... but it was slow.

Additionally, the interface is simply unwieldy. far too many forms being created, and no real automatic management of what window you're working in.

My idea is rather simple, and sort of even has a start. To recreate a Graphing program, and take advantage of the power of the BASeParser XP Expression Evaluator, as it stands now. Since I've already written an ActiveX Control that plots and graphs functions it's really just a matter of building a friendly face around the control for managing the functions it plots, and of course creating a 3-d version equivalent, which might be a little more work considering I haven't worked with Direct3d Since I worked on Grapher.

Another Program/Component I want to put back on my plate is my "colour selection" form/window, which I used in a variety of programs. due to a USB Drive failure, I was unable to recovery the form file and therefore lost this little gem. It's rather intermediate to rebuild it and shouldn't take too long, it leverages my Parser as well for the drawing of the selection box, which allowed great customization.

BASeEdit XP: This program was great. I even had it set as my default text editor.

But Alas- in the same disk crash I lost the Application.cls class as well as the resources for the program, which pretty much scrapped the whole thing. I couldn't bear to use the compiled version I had anymore, either. the pain was so great. I had an Older version, "BASEditor Pro" which... well it sorta sucked. Yes I wrote a text editor from scratch, twice. shuddap.

Another thing I've been tossing around the old noggin was the ability to play a game of walls over a network, or the internet. This will probably one of my more enterprising endeavours, but it doesn't take much imagination to see what would be possible with working netplay. haha, tournaments...

Not much to be told here; editing the website has become exponentially easier now that I purchased Editpad Pro. Excellent product. Notepad++ is a great tool, but it lacked what I needed as far as FTP support is concerned. Now, I can simply open the FTP panel, and edit files directly on the server; in fact, I can manage the entire website from editpad, save of course the blogs and the forum; I can upload images easily, look at the names of pictures so that I don't screw up their URL in the img tag, etc. But this is starting to sound more like a testimonial; anyway, with regards to the site itself, I've made a few slight cosmetic changes, such as the blue gradient in the headers of each item. It's still served up straight from a static page, though. Ideally, the news items would have a backend submission form that I use and the front end would simply load the news entries from the database and format it appropriately; not a huge amount of work but a slight PITA nonetheless, considering my awful luck with the downloads database recently with regards to keeping track of download counts. I recently updated the BCSearch installer; the release version is now at version 1.9. the next version I plan is 2.0, which will include support for a new feature I like to call "action filters" which are basically a group of operations to perform on a set of files, such as renaming, copying, moving, etc.

With any luck (and assuming I didn't mess-up my drive to drive partition copy with my new 1.5TB and somehow manage to overwrite my current data drive when the intention was to copy the data drive to the new disk) I will likely release a new version of BCScript soon; I'm starting to document it, also. I found it, oddly, easier to write the language then it has been to document it! In fact, I partly blame my enthusiasm for creating functions and operators and other things to the language for the difficulty I am having documenting it. I'm also planning a small tool that will be used to encrypt/decrypt files using the BCFile stream processing class that performs encryption. The encryption is performed using the Windows crypto API, so it should be pretty secure. It shouldn't be too hard to implement once I get started.

Revamped the crappy design scheme I had for the main pages. Awful. Simply, Awful, it was. It's not perfect now, but I don't think anybody can disagree that being able to read the text is a major plus. Still planning to implement some changes to the stylesheets and whatnot to facilitate spicing up the news entries shown here... and come to think of it, I've yet to even try to view the downloads page. *shudder*...

Planning a pretty major- actually, no, scratch that- I'm in the process of implementing some pretty radical new features to the site. For example, counting the number of times a certain file is downloaded (DEAR GAWD! that's AMAZING!)... but seriously, what I was thinking was a bug-tracking, or more precisely, a bug-reporting feature, that would allow anybody using a BASeCamp Program to report bugs they find in it easily. However- I'm not so sure that I'm quite up to the task; the design is pretty good; I have a few pages of designs for database tables and their relationships here, and it seems pretty solid; but If I know myself, I'll get to the point where I can build the database, and then I'll end up just using the same crappy PHP for displaying as I did for testing to make sure the database was being populated properly. Hell, that's pretty much what I'm doing with the downloads page.

Haven't updated my front page for a while. Looked lonely. Downloads PHP is working, I still need icons for a few of my projects, but adding them will be easy. The "articles" concept might be scrapped in favour of putting such things as blog entries, which has also been neglected. To be fair it's not entirely my fault; I was without internet for a week or so, which makes it a bit difficult to keep a web-site updated. I have a "updates" architecture working fine; my Visual basic programs can now easily query the site and see what version is current, and if it's newer recommend installing it. The GUI part of this still needs work, but I don't intend on releasing the current iteration of BCSearch or BCScript/BASeParser XP without this addition.