Linear Transformations Ahoy!

Recently I have been attempting to learn the maths required for 3D graphics, and am currently learning matrices. As a way of testing my knowledge, I wrote a quick pygame program which transforms a funky collection of lines with a matrix. It's only two-dimensional at the moment, but the same principles demonstrated here apply in 3D as well. The only difficulty is projecting 3D points onto the camera (which apparently requires a 4*4 matrix, to include translation as well). So, before my incessant ramblings completely vanquish your interest, here's a screenie of the aforementioned program:

The matrix is displayed in the bottom-right corner. Thanks go to James for coding the nifty grid-drawing section (I only had two grey axes to begin with!).

Regarding post frequency

You may have noticed a cycle of sorts developing here recently. Like a sunny day in Scotland, or perhaps like the Blue Screen of Death (depends on your point of view), I have once again returned from out of nowhere.

But this time, I'm not going to optimistically promise to increase the frequency of my postings - funky though a stuck record may be, I'd prefer not to sound like one myself and so I'm going to inform you that the posting frequency here will vary inversely with the amount of other shizzle I have to do.

And at the moment, that formula would produce a value so close to zero that any self-respecting calculator would simply round it down and save you the hassle of counting decimal places, so being self-respecting (and possessing a calculator - I suppose that counts) I'm going to admit that I won't be updating here until the New Year. Perhaps then, when compulsory festive activities are finished and I still have some holiday time remaining, updates might come more often. Who knows? But for now, I'll leave you with the compulsory Christmas greeting:

MERRY CHRISTMAS

Ball physics - now with 100% more C++, and 50% more awesome

Please excuse the absence - I was on holiday, and then was flooded with exams immediately afterwards. And then afterwards I forgot to post. For a week.

So, here I am again, this time bringing you news of another mini-project of mine. Some of you may remember my python ball physics test; well, I've been working at re-creating it in C++ (using SDL for graphics of course). To date, I have created a Circle class which is affected by gravity, and can detect both circle-wall and circle-circle collisions (unlike in my Python attempt, you can have multiple circles). The circles can be added with right-click, and dragged around with left-click (and this time the ball is still affected by gravity and collisions whilst being dragged - it's just weighted towards the mouse cursor).

When it detects a wall collision, it bounces realistically - and this time it detects collisions before they happen, so it's impossible for a circle to go through the wall as happened frequently in my Python ball physics simulation. All that remains is adding realistic bouncing for circle-circle collisions; I have a sort of temporary bounce system in place but it's incredibly unrealistic. So, without further ado, here's a screenshot (white lines are the circles' vectors, the red line is connecting the circle that's being dragged to the mouse cursor):


In this screenshot, the ball that's being dragged is being swung round by the mouse cursor - this was impossible in the Python version where the ball simply locked to your cursor.

Next on the menu is working out how to do proper ball-ball collisions - the detection is all there, but making them bounce properly is actually surprisingly difficult. James and I are working on a system for doing that at the moment, so hopefully we'll have a solution in the near future.

Source code for this project

Tic Tac Twiddling

With the Game of Life simulation mostly finished, I today started a new mini-project: making a Tic Tac Toe game in SDL. This will be a player-versus-computer affair when it's completed, and has a spiffy hand-drawn look to it:



So far I've finished the GUI (as you may have noticed) and most of the logic. The turns system is implemented, the player and computer can both insert their respective symbols, and it can tell if someone has won. All that's missing is the computer AI that puts in its pieces (which is why there are no crosses in the above image - the computer doesn't actually do anything during its turn yet). The next step is to try and work out an algorithm for determining which move to make each turn, and ultimately try and make the computer unbeatable. It should prove somewhat challenging, at best...

UPDATE
It's finished! The source code is available here.

Game of Life... now with more SDL!

You might have been wondering why there have been no updates recently - and it's very likely that you've assumed that the cause of this is a lack of progress. Well, actually progress has been incredibly good recently; however, I have been having problems getting recent videos of the Game of Life simulation onto Vimeo. As it's been a full week since my last update, I decided that I'll just post screenshots for now and post videos when Vimeo works again.

So, firstly, I completely finished my text-based version of Conway's Game of Life. It now supports the loading of user-made text files (containing a grid of 50*25 ones and zeroes) into the simulation, and has been cleaned up significantly. The new source code is available here for your viewing pleasure.

Then, deciding it was time to continue my SDL learnings with a view to getting the GUI done soon, I continued on with some tutorials, and soon created a game/test thingy where you can add, delete and drag around a collection of clouds (each inscribed with a helpful "Drag me!" message):


Finally, after much procrastination (and feature creep of the test above), I decided the time was right to start making the Game of Life GUI. So, after many hours of fiddly coding and battling with screenfuls (literally) of errors, here it is - the SDLGOL:


As you'll notice, now that it's drawn onto a window instead of being displayed as ASCII in a command-line view the simulation grid is significantly larger. 200*150 cells, to be exact. And yet despite the fact that TestNeighbour() alone is now run around 240,000 times per frame, it still runs incredibly quickly - which is a testimony to the speed of C++. So, in true open-source fashion, here is the source code.

Everybody Play the Game

So, as has been tradition for a while now, the updates here have gone all sparse again - although the last post was but two days ago, the one before is weeks old. So once again, I'm aiming to change that, the only way I know how...
A progress update!

Now, the last time I posted, I mentioned that I was learning SDL. This has been continuing, but now there is a goal - I'm trying to create a C++ implementation of Conway's Game of Life. So far, I've been battling with the most confusing errors under the sun for almost 270 lines' worth of coding, and after fixing The Strangest Two Bugs Ever To Crop Up Directly One After The Other Just To Annoy Me this morning I have got a working command-line version up and running! Here's a nice and shiny demo of it, straight from the new ExeSoft Vimeo page:



Keep watching for an SDL interface soon!

Silly Drawing Layer? Super-Duper Loveliness? Someone Did Loads?

Well, no-one really knows what it stands for. But it is in fact the main reason I came here today with a view to posting.

SDL, or Stupid Digital Lollipop, is essentially Pygame for C++. Well, in truth, Pygame is Slimy Duck Lice for Python; Someone's Dung-Ledge is the original module. And now that I've gained some sort of coding ability in C++, I decided now would be the time to learn Scary Doodling Lithuanians. As it turns out, Scale-Drawn Lithium is quite hard. Yes, Splendidly Drunken Leige is very hard indeed.

As I'm running out of acromym ideas, I believe now would be a good time to tell of my SDL ventures thus far. Well, I decided a few days ago that I would start trying to make graphical programs in C++ instead of just console-driven ones. Firstly, I tried out wxWidgets (which spawned the awesome wxPython). Unfortunately, I couldn't even get as far as include "wx/wx.h", as MinGW (the compiler I'm using) simply refused to include it - perhaps I compiled it incorrectly, perhaps I put it in the wrong place, perhaps my system variable was dodgy; whatever the cause, it simply wasn't going to happen. So, having failed at the first wxHurdle, I decided that as Pygame is the graphics module in which I am most comfortable I should probably give SDL a go.

This ended up being an absolute unholy 'mare to install as well, but to a slightly lesser degree - I got it installed eventually! And so, having followed the obligatory "Hello World" tutorial, I now proudly present to you the fruits of my labour:


Awesome, no? Well, it's kinda cool if you've seen the source code - over 100 lines went into this simple marriage of two images on-screen. Admittedly, many of those lines were expended in superfluous comments and whitespace, but it's still gigametres away from the ~10-line Pygame version.

More updates on my progress will follow, so watch this space: " ".
WATCH IT.



It might do an amusing trick.

Exesoft ToyBox

I was messing around in physics this morning getting bored while copying out some stuff in fiberoptics and I wrote a little crystal ball program in python (in my book). The moment I got home I wrote it up and decided to bundle it with the random story generator and a Work in Progress, AutoRap. The crystal ball is a really simple console application like the story generator and auto rap. CrystalBall works by randomly choosing a yes/no type answer from a list and displaying it after user input. We/I might make some nice little interfaces for theese little apps. I hope to release theese soon and add to them in the future. The ExeSoft Toy Box will be updated when we take breaks from the larger apps and do some quick collab code.

-James

ShinyPic is here!

After many tiresome hours of bugfixing, we at ExeSoft finally come bearing The Shiniest Image Viewer In The Known Universe, ExeSoft ShinyPic version 1.0


Download links can be found at exesoft.co.nr/shinypic. Enjoy!

Finishing touches...

We're now getting incredibly close to the final release of ShinyPic. All the features have been implemented, and all that remains is to polish a few of them up and hunt for bugs. The first few test compiles have been very successful, and I've managed to make a nifty little icon for the program in GIMP.

If all goes to plan, installer files and source code should be going up by the end of the weekend!

So we took a break...

David and I got together earlier on today and did a little small collaboration on a program. It is a fun little thing that generates random sentences and paragraphs from a set of words. I will try and create a little program that will allow you to add your own sentence structures and add your own words. We may make a simple GUI for it but at the moment it is a console based thing that allows saving to a file. To find the code click here > http://pasteall.org/2478/python < Have a play around with it and feel free to post funny paragraphs in the comments section. Right now we are back to work on getting ShinyPic ready for the first release.

-James

Wallpaper!

A sneak peak at one of my wallpaper designs for ShinyPic. I hope David manages to find a nice way of getting a nice customisable interface :P. I am after all obsessed with graphics and the visual element of things. I may post a few more designs closer to the first release or I may just let you discover them if they are included.

This wallpaper was made in Blender (http://www.blender.org), I made some nice blue shapes and then messed the hell outta them with blenders awesome nodes. I may make a tutorial on messing with nodes sometime (probably wont) for anyone who has an interest. Meanwhile I gotta go for now and sleep on some wallpaper ideas.

And then... there was a loading bar!

This turned out to be incredibly easy to code, and so only really took me about 30 minutes. It's displayed every time you select a different directory to view images from, and gives a much better visual representation of the loading process than the old system did (where it printed the name of the image being loaded to the separate command-line window). At the moment, it moves up by the same amount for every image, but soon I'll make it so that larger images cover a greater amount of bar-space than smaller images (so that it's more accurate). Much thankingness to James for making the bar image!

Building a Basic Browser

Having almost completed the full-size viewer, I decided now would be a good time to start work on the directory picker (for selecting a directory to load images from). So far, I've made pretty good progress - you can browse directories by clicking to open a folder, or clicking "Move up" to move up a directory. Right-clicking on a folder selects it, and makes the program close the browser and load up the images from inside the folder. However, it's not all that aesthetically pleasing yet, as you'll see from the screenshot:


Don't worry though, as I'm hoping to polish it's appearance over the next few days, so soon it will be shiny.

More pressing are the bugs; for example, if a folder's name is too long it will go right of the edges of the window. Also, if a directory you're viewing has more than around 40 folders in it, many of them will be off the bottom of the screen - I'll be needing to implement some form of scrolling to resolve this. Both bugs are entirely fixable however, so we should be seeing the browser complete by the end of the week.

Panning works, and I don't know why.

So there I was, hacking away at the keyboard, trying to make magic happen on-screen. Every approach I tried for panning gave incredibly strange results, often causing the image to fly off-screen as soon as I moved the mouse. My Slipslide 2 menu / ShinyPic grid view formula simply didn't want to work in this particular situation.

Irritated, I decided to slam out a quick death-or-glory mess to see what would happen. Well, it started fairly neat and orderly, but as I typed I kept thinking of random things to put in, and so the line got longer and longer and ended up with at least ten nested layers of brackets. Sniggering, I did a quick test run to see how buggered it would be.

And guess what? The code ran perfectly, and the panning was smooth and precise. It is at times like these where my usual response, "Oh shit", simply doesn't cover the magnitude of the situation. After a few seconds of pondering what to do instead, I opted for a more obscene word. Sadly, this was to no avail as pronunciation becomes somewhat impossible when your jaw is lost somewhere on the floor behind the computer-related spaghetti heap.

I have to say, this speaks volumes of my subconscious' programming skills. I never could have done it,anyway. Behold the majestic solution proposed by an unknown entity hiding somewhere within the back of my mind:

mouseoffsetx = ((float(self.screen.get_width()) / 2.0) - float(mousepos[0]))
centrex = (float(self.screen.get_width()) / 2.0) + (mouseoffsetx * ( ((float(self.scaledimage.get_width()) - float(self.screen.get_width()) ) / 2.0) / (float(self.screen.get_width() / 2.0) ) ))
mouseoffsety = ((float(self.screen.get_height()) / 2.0) - float(mousepos[1]))
centrey = (float(self.screen.get_height()) / 2.0) + (mouseoffsety * ( ((float(self.scaledimage.get_height()) - float(self.screen.get_height()) ) / 2.0) / (float(self.screen.get_height() / 2.0) ) ))

Ridiculous, no? Well, now I have to try and work out why that stuff works. If I'm not back in five months' time, send in a search party.

Getting closer...

The first release of ShinyPic is drawing ever nearer; all that remains is to add panning to the full-size viewer and add a way of letting the user choose a folder to load images from.

However, the former is turning into a major challenge as my standard mouse-scroll-system, which I used not only on the tile view but on the Slipslide 2 main menu, is causing strange glitches such as the image being drawn a good thirty pixels to left of where it probably should be. I'm thinking this is probably due to me using it to calculate the wrong position - the image centre position and the actual draw position are easy to confuse here.

With any luck, I'll get it fixed today and then start thinking about the latter of the two objectives: loading from a user-specified folder. For this, I may need to develop some sort of folder browser which is opened when the user clicks a button; however, I'm not certain how the browser will work or where to place the button. A few minutes ago I had the 'brilliant' idea of placing it at the same side as the text and keep it on the opposite side of the screen to the mouse so that it can never obscure any images, but this fantastic approach fell flat on its face seconds later when I realised that the user would therefore never be able to click it. So it's back to the drawing board on that one.

Funky animation

Today's piece of new, shiny and awesomeful news is that the full-size image viewer is beginning to work! Now when you click on an image, it scales it up to fill the screen (this is animated, of course) and then enters a neat little redraw loop so you can view the image. Sadly there is no screenshot, as it's a bit difficult to take a screenshot of an animation. I'll post screenies of the full-screen viewer when it's working properly, however.

Now I just need to make it possible to close the view, and then add pan/zoom to it, and it'll be done! And so ends the shortest update in ExeSoft history. Yes, I'm feeling lazy right now.

MOAR SHINIE

And then there was awesome!


I know I've been forgetting to post updates here for a while, but I hope that this image will make up for it. As you can see, not only are images implemented but there is also alpha - so the images further from your mouse cursor will appear semi-transparent! Also, the text you see in the bottom right changes sides depending on where your mouse is so that it never obscures the image you're looking at.

What I'm now working on is the full-size image viewer - when you click an image, it will scale up to fill the screen and you can then pan and zoom all around it. However, this is currently proving somewhat... impossible. So I may take a while with this...

Scroll on!

I've developed the SSSSSS (Sepcialised System for Super-Shiny Square Scaling) algorithm further, and it can now handle scrolling! To celebrate, I implemented scrolling in the original demo. So now, with the mouse on the far right of the screen you'll see the images on that side, and as you move the mouse left the grid will scroll to reveal those on the left!

As promised, the equation thingy has increased in complexity somewhat. In fact, it could probably do with a bit of tidying up. But here it is anyway, for your viewing pleasure:


You're probably best viewing this one full-size. Just click as always.
Tomorrow I intend to make this work with actual images (insert exclamation of shock here), so keep refreshing this page every few seconds!

Or I suppose you could just come back and check tomorrow.

Some Super-Shiny Square-Scaling!

Today, I present to you the result of much mathematical fiddling and error-induced pain. I have been working on the image gallery program I fell short of properly describing in the last post, and have created a system that displays a grid of images (white squares at the moment) which scale up as your mouse approaches. In the final program, the grid of images will also scroll with your mouse cursor, but that will be added later. For now, bask in the awesomeness of the algorithm I like to call "SSSSSS" (Specialised System for Super-Shiny Square Scaling):


If you like, you can take a look at the source code for this at http://pasteall.org/2333/python. However, it must be noted that the code is uncommented and incredibly messy, so I wouldn't advise trying to understand it.

The basic scaling algorithm is as follows:
Mx = Mouse x-position
My = Mouse y-position
Cx = Centre of the tile (x-axis)
Cy = Centre of the tile (y-axis)
Tx = Tile size (x-axis)
Ty = Tile size (y-axis)


Click on the image to view it full-size as always.
As you can see, the scale factor must be in range 1.0 <= x <= 2.0, so it's necessary to also add code that clips the scale factor at these values.
This is probably going to get a lot more complicated when I add scrolling...

Anyway, that's all for this update. Watch this space for more soon!

So what's been happening?

Try not to jump in fright at this, but this is a new post.

Yes. Really.

It's been a while, hasn't it? Well, allow me to explain the post-nuclear-blast-esque silence. You may remember that I was being constantly attacked from all sides by the dreaded exams as I wrote my last post. Well, they got worse, and I was soon spending a steadily increasing proportion of my time revising every day. Ultimately, all my non-school-related projects were all but forgotten, and Slipslide 2 was but a distant memory.

Thankfully, my revision was not in vain, as I got a 1 for every subject (1 = A, for those of you unfamiliar with our system)! However, Slipslide was left to gather dust for months, and it wasn't until I stumbled onto this page again a while ago that I remembered about it. In the time that passed between the hellish onslaught and my fateful rediscovery of the long-lost relic that is this blog, many events have taken place. Some were exciting, some were intriguing, and some were nifty, and if you continue reading I shall elaborate on the most significant of them.

Firstly, I have begun learning C++, which is probably around 50 times more confusing than Python (yet 50 times more powerful at the same time). I've come some way with it, but it's unlikely I'll be doing anything spiffy with it for a good while as there's a massive amount still to learn.

Back in the world of Python, a few friends and I recently started what seemed like an incredibly simple project - a program that lets you make text adventure games in Python using a node-based system - but has grown in complexity as all the little things that you normally take for granted (text boxes, for example) have proven near-impossible to code properly, and the code structure (originally completely modal, with GUI elements designed to be usable by other programs) has melted together to form a big ugly monstrosity that will soon be near-impossible to safely edit. So we're going to have to consider redesigning the whole thing, possibly coding GUI elements completely separately and adding them in when the whole thing's finished. Whatever approach we take, it's definitely going to involve a friggin' massive flowchart.

Now, while this project is being semi-restarted, I have started on a little side-project - a Python-based image gallery program not unlike the Firefox PicLens extension, but in 2D and with file info display and a full-size image viewer (with zooming and panning). It's proving to be challenging so far, but I have managed to get it to load images, resize them to fit into tiles, draw them to the screen in a grid pattern and display the details for whichever image you hover the mouse cursor over. Next comes some spiffy mouse-driven scrolling and scaling effects which can't really be described through text but are illustrated in my crude drawing on the right (click to view it properly). Admittedly, it doesn't do much better at conveying what I mean. But all will become clear when I post screenshots if it in action when I get it working!

Omni-update!

I only just noticed how old the last post here actually is; the update-rate seems to have decreased exponentially now that exams have taken over. However, for now at least, all that is going to change. After an epic silence, I have finally returned from the Pit of Procrastination bearing news!

First, Slipslide 2. In the last post you may have noticed that it had reached a brick wall of sorts, in that it was running like Windows Vista on an Apple II. Luckily, illume was able to show me how to fix it:

"if you're on windows pygame now uses the windib (GDI) driver instead of the directx one by default.

We had to do this for compatibility with, funnily enough, vista :)

You can do the following, and it should become similar to before...

import os
os.environ['SDL_VIDEO_DRIVER'] = 'directx' "

So as a result, Slipslide is now running as it did before - well, visually at least. The sound still crackles and pops constantly, but apparently there is a fix for it:

"I think some nice people have found and fixed the sound crackling...

You can try it out with the development builds of pygame here:
http://thorbrian.com/pygame/builds.php"

I intend to try this out when I have time, hopefully it should solve the problem.

Meanwhile, a few folders away from Slipslide 2, I have been working on getting my music on the Internet. My new site, which is mostly finished now, can be found at purevolume.com/animatinator. Feel free to have a listen, although the sound quality isn't perfect due to downsampling by purevolume.com (so the files don't take up too much bandwidth).

Pygame upgrade (well, something-grade...)

So I recently upgraded PyGame to the new version 1.8.0 release... GARGANTUAN mistake. As it happens, 1.8.0 is to PyGame as Vista is to Windows. While Slipslide 2 previously ran like a cat wearing a rocket booster, it could now be compared with an arthritic snail wearing chainmail armour. The initial fade-in took a full 10 seconds (compared to less than 1), and the music was so crackly it was like listening to white noise. The levels were even worse; the character was seemingly incapable of moving at any more than three pixels per hour and the pause menu window lagged several frames behind the mouse's movement.

The cause for this appeared to be that the new PyGame release's blit() method (used for copying images onto the screen) is far slower than before. Thankfully, there is a solution. I only had to make it convert all the images into a pixel format that PyGame prefers, and now blits are much faster. It seems this release is much less tolerant of unconverted images, and will run incredibly slowly when given images that worked perfectly in previous versions.

I'm happy to say that it's almost completely fixed now; the music still pops occasionally but I'm gradually eliminating that. As well as converting all the images, I've also been optimising redraw methods and minimising the number of times it has to update objects. With luck, it'll soon be usable again!

Good news and bad news...

I'll begin with the bad news - due to the massive volume of school exams coming very soon, progress updates here will be sparse(r) over the coming months. I'll post when I can, but there won't be much Slipslide progress to post about.

At present, Slipslide has two complete levels, one very-nearly-complete level and one that's about halfway done. A lot of the music is already in progress, with three pieces completed, and the story is 90% finished. I hope to gain more speed in the level-creation department soon as my digital painting skills improve, so it shouldn't take too long - but "Spring 2008" is unfortunately looking quite unlikely now.

However, the good news is that our blog has been rated 8.4/10 (or "Great") by blogged.com, a blog listing site (which I don't recall submitting myself to, but meh). I've even got a score badge to prove it!

Digi-paint!

Having written a few tunes, I decided that it was time to start on the rest of the levels. So, I now have a layout for level 3 (which is set in Slipsville, Dan's hometown) and have started the background (digitally painted in the GNU Image Manipulation Program). So far, I have a lone building in a vast field of grey:

As you can see I'm going for a fairly cartoony style with this. The building currently casts no shadow, but that'll be fixed as soon as there's something to cast a shadow onto.
In this level, there will be three main buildings at the front, a large square at the top-left and an airport at the back, with a runway on the right of it. The object of this level is to get Dan from his house to the airport, where he hopes to catch a flight to Antarctica. Naturally all doesn't go to plan, but that's a story for later on...

The silence is broken!

If you visit this blog frequently, you may have noticed a complete lack of anything at all over the last two weeks. Don't worry, the Slipslide 2 project is not dead. But time has been short, even more so than normal, and the exams have been coming thick and fast.

I have recently invested in Image Line's FL Studio 7 XXL for producing the game's music, which allows for much better instrument sounds and sound quality, as well as compression, stereo separation and parametric equalisation which all help make the music sound much better. The powerful synthesisers included also mean that I can use it to make the sound effects as well. With this extra power at my disposal, I have now started work on the remainder of the songs which will be required by the game - I hope to post some of these here in the near future.

The release date is, as always, still hazy. I'm estimating about a month or so, but you can never really tell with these sorts of projects. Whatever happens, I'm sure that I will still hit my "spring 2008" target which I set at the beginning of the project - "spring" gives me a good few months' leeway thankfully!

It's a double-update!

Let's start off with what I did two days ago - level intros! Finally after many weeks of faffing with nonfunctional alpha effects and funky text boxes, I have a properly working level intro display with automatic word-wrapping and everything. You can see it in the screenshot on the right. I've designed this module so that it can be displayed in-game with a mere two lines once it's been imported:

intro_screen = Intro("Level number", "Level name", "Level description") intro_screen.ShowIntro()

Once ShowIntro() is called, the levelintros module takes control until it is destroyed when the user clicks "Start" (or closes the game window), so no event handling needs to be done at all whilst the level intro is running.

The second of today's updates concerns the custom levels system - levels can now be loaded in-game! Over the past two days, I've designed and coded a super-spiffy menu for doing just that. When you click "Load custom levels", a little vertical menu pops up on the right with a list of all the custom levels existing on the user's computer. And just in case they make so many levels that they go off the bottom of the screen, I've also written a method that scrolls the menu in the opposite direction to the mouse (as is used in the horizontal menu at the bottom) so that you can easily access all the items in it without any difficulty whatsoever.

Now, back to building levels!

Finally, the level creation process begins!

After over two months of development, we've finally got to the level-building stage! And as promised, the levels can be made incredibly quickly thanks to Penuine's design. So far this afternoon I have made two levels, one of which you can see in the screenshot. These are both from the "retro" area, which takes place inside an outdated computer. I'm not saying how he gets there though...

Another day, another Penuine module...

This time a class that displays a "Level complete!" message which stays until you press a key. It's called by the levelcontrol class upon completion of a level, and looks very spiffy as you'll see from the screenshot. Pygame's per-pixel alpha capabilities are proving incredibly useful, they make some very nifty effects possible.

But that's not all that's been done! As well as this, I've got a new idea for the level intros screen which involves a cool text scrolling effect similar to the one on the main menu, but this time it's vertical and the text at the top and bottom is slightly smaller than the text where the mouse is. It'll naturally be incredibly difficult to code, but I've already made some progress - I've made a simple text wrapping system that takes a string and splits it into lines which are then made into an array containing text colours and positions as well. I'm hoping that this method will make it possible to animate the completely arbitrary number of lines necessary to display the story. The length of the algorithm for this is going to be ridiculous though...

Version 0.67!

Yes, we now have a version numbering system!
Well, a lot has been done recently. First off, there's a proper character sprite now! You can see it in the screenshot at the top.

Also, after A LOT of battling with Python, character animation is fully implemented! The character now slips, slides and even turns whilst you navigate your way around the levels.This was done by making a module which loads a filmstrip-style image containing all the frames of the character's animation, then splitting them up and returning them as an array. The character then sets its own image to the next in this array every few frames, going back to the first one when it reaches the end, so a cycle begins. When it stops, it stays on frame 1, and when it turns left, right or down the image displayed is rotated as necessary.

And last but not least, Slipinator (the level editor) is almost complete. The levels made with it are now playable in-game as well! So, now we just need a level intros system and then we're looking at the final stretch.

Project Penuine is still alive!

Although it may seem to be dead from the serious lack of updates recently...
So what's been going on to warrant such a lapse in blog activity? Well, not all that much, unfortunately. I've been mainly working on my new music website, freewebs.com/animatinator. Besides that, I've been documenting existing Penuine code with massive amounts of comments to make certain that the code is readable, and also doing some work on the level editor. As the level editor is the only change that is visible, I'll explain that now. Behold a screenshot! And you HAVE to view this one full-size to actually see it properly. Click away!



First, the visible stuff. I've done some new images for it to use, still a work in progress at the moment but they're basically finished. Also added is the option to turn off the grid which is overlaid onto the level. You'll see in the screenshot that there is now a nifty toolbox too, that's where the draggable character and finish point objects will be. You simply drag and drop them onto the grid, and it's done!

As the "Open level" dialog suggests, saving and loading of levels is fully functional too. Loading them in-game will prove problematic until a character and finish point can be added, but that's next on the list. Files can also be renamed, and the current level's title is shown in the window caption.

Right now I'm working on implementing holes, and then I'll finally get around to putting in the drag and drop functionality which will make adding the character, finish point and other objects possible.

Slipinator progress

Slipinator's the level editor, in case you were wondering. And it's starting to take shape! almost three hundred lines in, and we have a functional level canvas class that lets you place blocks on the level (with a grid to make it easier), and also drag and drop other objects onto. At the moment only the block editing is implemented, but it works perfectly! Here's a screengrab:
Click it to view full-size as per usual. At this point, clicking in a square will add a block there and clicking on an existing block will remove it (the latter of which took a very long time to get working). The graphics are still placeholders at the moment, as is currently the case for nearly everything in the game. But graphics will come as soon as level development properly begins.

Anyway, back one the subject of the level editor, the saving system is also working. It can properly create a level folder with the *.slf file inside, and append the name of the folder to a list of custom levels which is read by the game. Editing level properties isn't yet in, though, as we've not finished deciding on those. The basic idea is that there will be a level name and difficulty rating for each one (supplied by the user), and possibly an author. But that'll all come after the main challenge - implementing drag-and-drop!

#%£@!!!

We've run into a bit of a problem here...
Unfortunately, the idea I had for the level intro sections is impossible without use of an extra module and a shizelload of manual pixel-by-pixel fiddling to make it fade in. See, in SDL (the C++ module PyGame uses), there are three types of alpha: colourkey, surface and per-pixel. Colourkey is the 1970's-reminiscent idea of having one colour in an image that is converted to transparency, so you'd put your non-rectangular image on a purple background for example and that background would be removed by the program. It's not particularly useful when you want smooth edges. Surface transparency makes an entire image (rectangular of course) have a certain alpha value - so, for example, every pixel in the image would be half-visible. This is what I use for fading in scenes. And finally, per-pixel is where every pixel has its own alpha value - this is necessary for the spiffy transparency effects on the level intros text box.

And here's the thing - you can't use surface alpha and per-pixel alpha on the same image. So to have it fade in, the text box needs to be completely opaque and rectangular. And to have the cool alpha effects and rounded corners, I leave myself unable to utilise the benefits of surface alpha for fading in. Without the fading, the text box's entrance looks particularly rubbish; and it's just disgusting as a rectangle. So, it's back to the drawing board.

I've decided after some deliberation, collaboration and thinkingination that actually the level intro sequence might look better without a text box. If I implement a text box, I know I'll end up making it draggable simply because draggability is so cool and it's always enjoyable to code, and then the continue button will be attached to the text box, and suddenly we have Microsoft Windows in game form. It'll almost certainly be better for Slipslide (and the player) if I actually design a unique interface for it, as I've done with the main menu.

But meanwhile, on the brighter side of things, Slipinator (the level editor) is now underway again. I'm working on a drag-'n'-drop method where you drag objects onto the level, and it's actually been very successful so far. Not only does it not crash now that I've done away with the 500 buttons approach, it also means that holes and other things can now be added as well as just blocks. And it's only taken me 200 lines so far!

Level intro text box demo

I've now finished a working demo of the text box system that will be used in the level intros module. Using a bit of nifty programming, I've created a system that builds a text box from four images; the two top corners, a 1*24 pixel image to tile between them and a 1*2 pixel image to tile across the rest of the area. I also coded a spiffy effect that makes it fade in whilst expanding when the intro scene first starts - and although this is impossible to properly show through screenshots, I'll have a go...

When the scene starts:


When it's finished fading and expanding:


To see the box properly you really need to view it full-size by clicking it; the scaled-down versions above lose all the detail and look almost plain blue, whereas full-size there are lots of nifty details. There's also a transparency effect that'll be visible when I put the animated clouds in the background (coming soon!).

Many, many bugs fixed

The original fade-in method turned out to be very buggy; firstly, when fading levels in the character appeared on top of the fading level. Also, the fade was incredibly jerky at times, as the algorithm was particularly inaccurate. And on top of this, the scene was completely frozen whilst fading was taking place, which to be honest looked rubbish - for example, this meant that if you moved the mouse whilst the title screen was fading in, the text would remain still and then jump to the right place once the fade was finished.

So I completely re-coded the fade-in method so that instead of capturing the screen, altering the alpha value and then blitting it each time, it now uses the parent object's update method so that the scene you're fading into runs normally. Meanwhile, it blits in a plain black square with an alpha value on top of the scene, so that it's really just a black square that fades out with the scene behind it. This is now working perfectly, with no glitches at all so far!

As well as bugfixing, I've also been redesigning the filesystem some more. At the beginning of development, it was decided that music would be put in the level folders so it could be easily loaded with the level by supplying only the folder name. But this means that there needs to be a music file inside every single level folder, and with the average file being around 2 megabytes, 25 levels will take up a massive amount of space. So instead of that, I'm now storing all music in the engine's Data folder, and and the level controller has been modified so it takes the path to the music as an argument. I'm going to have a total of ten tunes, one for each main area in the game, so the final game's file size will be a lot smaller this way.

Now I'm moving on to designing and coding the level intro sequence module. Screenshots to come!

The joys of fading

Today I've started writing a new class for Penuine that can be used for fading scenes in and out at an arbitrary speed (and the fadeout end colour is also variable). So far the fade in method is working, and I've implemented it in the main menu scene and the level controller. The difficulty with this new class will be not overusing it to the point of it becoming annoying; it's very hard to resist making almost every scene fade in and out simply because it looks cool!

The superawesome menu of awesomeness!

Finally, the main menu is complete. And I have to say, I'm incredibly proud of how it turned out! Take a look for yourself:

Unfortunately, a screenshot can't do it proper justice - that's not just a cloudy background image you see there, it's actually four layers of fully animated clouds moving in real-time with the text in between them. And the options at the bottom aren't static either; move your mouse to the right-hand side of the screen and they'll all slide over to the left to reveal the options on the right.

All this has resulted in a 250-line file, making the main menu module the largest module in the entire engine - larger even than the level controller! It's been incredibly complicated to program all the effects and get them running at a reasonable speed, but I can honestly say it was worth the effort.

Anyway, I'm off to spend the next few days patting myself on the back.

The finished pause menu

And now it's complete!
It now renders text, and has clickable options for continuing and quitting. Also, it's draggable so you can place it in any part of the screen. This could be useful when you want to look around the level while the game is paused. It also looks incredibly cool, which is the main reason I developed it that way - now Slipslide has a Windows Vista-esque interface! Yaay!
But my words probably mean nothing to you without a screenie, so here you go:
Unfortunately the scaled-down image above doesn't do proper justice to the menu; click it to view full-size with all the subtle yet nifty effects visible.

With this done, we just need a proper character and animation to be implemented before we can finally release gameplay screenshots outside of this development blog. And at that point, it'll be less than a month before the final game is complete!

The countdown begins...

Pause menu now working - with perfect alpha!

After many an epic duel, I've finally got the pause menu to display. Well, the background anyway. The rest will come in time. For now, behold the screenshot!

As you can see, the character and level are partially visible through it! That's the incredible power of per-pixel alpha in action there. Thanks go to Pash for the making the amazing image of course.

The per-pixel alpha didn't come easily unfortunately; it's taken a lot of faffing to get it to work. For a long time it was drawing it with absolutely no alpha whatsoever, and there were nasty pixellated sections everywhere. However, it turned out to be caused by simply forgetting to update the background behind it each frame - so the pause menu was being drawn on top of itself again and again, which naturally would eliminate all transparency after a few frames. I fixed it by adding one single line to the pausemenu module. That's programming for you.

Latest Slipslide 2 progress update

At the moment, development's completely all over the place; we're stuck in the twilight zone between the basic engine being complete and starting work on levels, characters and sounds. There's still no character sprite, there are broken test levels scattered everywhere, and the engine has a lot of holes in it. As well as this, we've had to temporarily stop soundtrack development due to a disagreement over how to do it.

However, on the positive side, the story is almost finished, and it grows more interesting by the day. For example, Dan's going to end up skating around the surface of Pluto by about the middle of the game! My idea is that once the story is finished we will agree on a plan for finishing the rest of the game; possibly beginning by designing the character. However, this will need to be discussed when we next meet.

Level Layout Design

Hey, well I have been doing some level layouts for the game and I have quite a few different difficulties ranging from hard to.. well, erm hard. I am finding it awkward to design a level easier than what I have already. in my second post I will maybe show you a couple of layouts that I have designed to see whether you can crack them. if you can then I will continue to make more and if you cant... I will continue to make more.

The engine redesign is complete!... or is it?

I say this as a strange new bug has cropped up - when the level is restarted, the player simply won't redraw! So now we have a secret, "not actually programmed at all" multiplayer mode appearing every time the level's restarted. Luckily, it can still redraw when the player hits a block (bye bye, second player) but it can be very confusing having two iterations of the character on-screen at once.

But fear not, as this bug is balanced out by lots of superawesome goodness! Firstly, look closer at the screenshot above. Click it to view it full-size if you need to. Or, better still, I'll stick in a close-up shot on the left. Done. What's that odd brown thing then? That, my friends, is a hole; a bottomless chasm leading to instant death. Touching one of these will make you restart the level (the result of many a battle with Python). Impressive, no? Well, yes, the image used there doesn't work all that well. But it's just a place holder of course; any 24*24 tile could be used.

And, as mentioned in an earlier post, non-rectangular layouts have been made possible by a new system that reads the wall from a file. A text file in courier font speaks a thousand words in the Trebuchet font, so here's an example:
WWWWWWWWWWWWWWWWWWWWWWWWW
WWWWWWWWWWWWFWWWWWWWWWWWW
WW00B000000000000000000WW
WW0000000000000000000B0WW
WW0B000000000B000000000WW
WW000B00000000000000000WW
WW000000000000000000000WW
WW000000000000000000000WW
WW000000000000000000000WW
WW000000000000000000000WW
WW000000000000000000000WW
WW00000000000000000B000WW
WW000000B00000000000B00WW
WW00000BCB0000B00000000WW
WW00000B0B0000000000000WW
WW000000000000000000000WW
WW00000000000000000H000WW
WW000000000000000000B00WW
WWWWWWWWWWWWWWWWWWWWWWWWW
WWWWWWWWWWWWWWWWWWWWWWWWW

Those of you who were paying attention during the last paragraph will probably have guessed that the W's denote walls. The more intelligent among you will have inferred that the B's represent blocks and the 0's are for empty space. But the other two may confuse you slightly, so I'll explain them - C is the character start point and F is the level goal (or finish). This method means an end to complicated *.DAT files that had to be stored in a level's folder to explain where the walls are and where the end is, and as the area doesn't need to be rectangular it is now possible to have a level goal that is actually within a path leading out of the level boundaries.

With any luck, you'll now have forgotten all about the disastrous bug I mentioned earlier so we (I actually - no-one else understands the arcane engine design yet) can go back to trying to fix it. Enjoy your blissful ignorance, fools!

Mwahahaha.

Major design shakeups

It's now been a full month since we first began Project Penuine (that's Slipslide 2). Still no in-game screenshots to show. However, a lot's been happening, despite the fact that the blog activity may suggest otherwise. The story's now in progress, and without giving too much away I can say it's going to be epic. Dan (the main character) has moved house this time, so the next-door neighbor's dogs are now gone. However, there twenty-five brand new levels full of risks far worse than just dogs. For example, there will now be holes in the ground for Dan to fall through, made possible by a redesigned level system.

Whereas the level loader just used zeroes and ones when the project began, it's now undergoing heavy redesign to allow for many more features. For one thing, the levels no longer have to be rectangular. The new system uses letters instead of numbers, and has removed the need for putting in extra files into each level's folder telling it where the walls are and where the finish is. It can be stored entirely in the layout.slf file, with the only other necessary files being the level's images.

Another thing that's being redesigned is the file system structure - all the game levels are now being put into one folder called "Levels", with sub-folders for each level located inside. Data such as the character images and saved game files are being stored in a folder called "Data". This is mainly to make the game simpler for me to organise, as the number of folders getting a top-level directory before was verging on ludicrous.

Of course, all the redesigning work that's going on at the moment is causing a lot of problems with the test levels. Once the work is finished I'll be going back and converting them all in case they're used in the final game, but at the moment the only one that works is the very first one (which I've been updating in order to use it to test the new system). I also had to fix a major bug this afternoon that meant the character was being drawn at the position (-1, -1). Now although this wouldn't seem too odd using a normal Cartesian co-ordinate system, in computer programming it's generally not a good sign. In Python, "-1" denotes an unspecified value - for example, if you passed this as an object's ID this would make it automatically generate a new ID; or if you supplied it as the number of times to loop a sound, it would continuously loop forever until you killed the program. So it was essentially drawing the character everywhere, anywhere and nowhere all at once. Eventually I found it out to be caused by remains of the old system conflicting with the new one, which was quite easy to fix once I'd narrowed it down.

There are still a lot of things needing added to the new loader (and the character file NEEDS some comments to explain the convoluted coding). Luckily however, we have a new member on the team, which will make it a lot less difficult to get it up and running. Also, the blog just surpassed 100 hits! Now wouldn't it be nice if we actually got a comment or two at some point... ;-)

Just in time!

I suddenly remembered that it's actually bad luck to have decorations up after Twelfth Night yesterday, and with but minutes to spare I leapt into action and took down the Christmas banner. The luck of ExeSoft is saved! So don't worry, Slipslide will probably be released on time!

What do you mean 500 buttons is too many?

So I started on the level editor today, and it's actually been going quite well. However, it turns out that my method of programmatically adding in a grid of 25*20 toggle buttons to represent the grid squares isn't really going to work apparently - I didn't think the idea through long enough to realise that adding five hundred individually functioning buttons, each with two 16*16 pixel high-quality *.PNG images to load, would crash the computer.

But on the bright side, it was a very spectacular crash. First I got the classic sandtimer cursor to appear and then freeze mid-animation, so it was actually sitting sideways, then the application's window appeared in two places at once - half was in the normal position and half was in the top-left corner of the screen, with funky black and white lines attempting to hold them together. Then a window appeared saying "Error: Out of system resources!" before promptly disappearing under a wave of long-awaited buttons which proceeded to draw themselves very slowly, one after the other. At this point, I quickly killed the process using the Windows task manager. And with all the speed with which the carnage had arrived, everything fell silent.

So, yeah, computers aren't meant to handle 500 buttons. Which means I'm going to have to look for a different approach; maybe I'll write a custom GUI grid thingy myself at some point. It can't be that hard to do anyway; Microsoft had something similar in their Minesweeper game that comes with Windows and it loads in milliseconds whilst using almost no system resources at all.

Another year ends, another begins

Once again, it's time to make unreasonable promises to yourself, break them within the hour, drink obscene amounts and set off spectacular explosives all in the name of tradition. 2007 is now last year's thing, long live 2008!
For ExeSoft, the last year was an eventful one. For one thing, ExeSoft didn't even exist until just after the halfway mark. So, to celebrate the year's success, here's the year in JPEGs (with a couple of PNGs thrown in for good measure of course):

First, there was the long-awaited release of Slipslide 1. This one had been delayed for months, and unfortunately didn't end up being as good as had been hoped. It was ultimately too glitchy and had only five levels, one of which was a slide-downhill-avoiding-obstacles affair thrown in to stretch out the length and difficulty. However, the lesson was learned. That style of puzzle game does not work in 3D.

Then, much later in the year, David's Random Programs, inc. and David's Random Games, inc. were merged and renamed (thankfully) to ExeSoft, as the old names were terrible to be perfectly honest. The newly formed company began by re-doing programs made by David's Random Programs, inc., beginning with Txtinator.

Version 4.0 was almost 1000 lines in length and utilised the powerful wxPython module for its GUI. It had hundreds of extra features, and also included the 1337-speak translation system which had been originally developed as a standalone application by David's Random Programs, inc. near the beginning of the year.

Overall, the best ExeSoft application that year (in my opinion) was Converzion 2.0, an extremely fast unit conversion program with pretty much every unit you could possibly think of implemented. It also had a fully customisable interface, and a customisable toolbar that let you access the conversion types (money, weight, length etc.) that you use most often.

Towards the end of the year, it was decided that they would make a sequel to Slipslide, but this time using the PyGame module to write a specialised engine from scratch so that the game could be developed faster, use more levels and have less bugs. So far it's lived up to that hope (and then some), and with luck it will be released around February or March of 2008. Only time will tell, however...