next »

[IfThenSoftware]

News

The latest demo of SAO: Redux is version 24.  If you are interested in trying SAO: Redux as it is being developed, feel free to stop on by the online chat and ask for the latest demo.


From the Programmer
Written by Invisible

SAO: Redux now has graphics other than squares, lines, and arrows.  Getting the background to scroll correctly was a bit of a challenge, but handling world space like a 3D space helped solve the issues.  The homogeneous divide step was the main bit I was missing, although I did have to scrap most of my original idea (handling the background as a separate "space" did not work out at all).

In the current demo there are multiple characters: two stickmen, one pollenator, and one stinkbug.  To help find problems, the user can plug into the characters the same way a client or AI would and control them.  People seem to be particularly fond of flying the pollenator around the map.  This way of handling characters is new for me, and I am rather excited to see how well it works out once I need to write AI.

I spent the previous couple days working on a new state system.  Unfortunately, I was unable to find a cleaner way to represent states.  The states which exist are too intertwined to easily separate them into only a few groups, which was my plan.  I ended up using the same state system, although I have reorganized the code to make certain parts clearer.  I also added a couple new states, and improved the state handling when walking.  The world update code is still in need of some serious refactoring, but that will probably have to wait until there is more code to work with.

Be sure to checkout the community spotlight article for a video showing off the latest SAO: Redux demo.


Artist's Easel
Drawn by GreyKnight

iScribble Sketches #30

(Click to enlarge)


(Click to enlarge)



Community Spotlight
Written by jaythemage



If you have anything you would like to say in the next community spotlight article, please post it here.


Funny Quote of the Week
From the online chat

pifreak: this shushie is awesome
InvisibleMan: "shushie"?
pifreak: http://en.wikipedia.org/wiki/Slush_%28beverage%29
InvisibleMan: Oh, you mean a slushie?
pifreak: that's what I said
pifreak: oh xD

[IfThenSoftware]

News

The latest demo of SAO: Redux is version 28.3.  If you are interested in trying SAO: Redux as it is being developed, feel free to stop on by the online chat and ask for the latest demo.

Changes since version 24:
-WASD can now be used to walk/crawl/fly around.
-Numpad 0 can be used to jump.
-Numpad 1 can be used to equip/unequip a potion.
-You can now punch by left-clicking.
-The stuck-drinking bug should be fixed.
-An equipped potion can be thrown by right-clicking.  Hold down the right mouse button to aim.


From the Programmer
Written by Invisible

This week I added punching and potion chucking, although the latter still needs some work.  I also spent some time refactoring the code.

Rather than having the state integration and rendering code in the same class, I've split them into separate classes.  This is a step in the right direction for supporting multiple CPU cores, although there would likely be little if any gain with the current setup.  Currently, the state would need to be locked every time it needs to be rendered.  This would effectively eliminate any gains from multithreading.  When I start to seriously consider supporting multiple cores, I will need to find a way of fixing this.

I have spent the past couple days researching other collision detection methods.  They would (in theory) allow sloped ground.  However, it's unlikely that I will use these methods in SAO: Redux, due to time constraints; I don't want to work with experimental code if I can avoid it.  They will probably appear in future projects though, most notably Merki.


Artist's Easel
Drawn by GreyKnight

iScribble Sketches #31

(Click to enlarge)


(Click to enlarge)



Community Spotlight
Written by jaythemage



If you have anything you would like to say in the next community spotlight article, please post it here.


Funny Quote of the Week
From the online chat

sambi is going 2 chores
sambi: brb
InvisibleMan: Finally!
Acaceol: Lol at the three above lines
InvisibleMan: I just finished proving algebraically that physics problem
InvisibleMan: And yeah, now that I look, that wasn't the best time to shout that :|

[IfThenSoftware]

News

The crew at MMOVoices interviewed our programmer (InvisibleMan) in their latest podcast episode: http://www.ifthensoftware.net/forums/index.php?showtopic=2187


From the Programmer
Written by Invisible

What was originally a small detour into studying finite state machines has completely redirected development.

Due to the spaghetti code which was SAO state handling, I started researching finite state machines. The idea is that a finite state machine would clean up the code and make it easier to read, and bugs would be easier to detect as well. If you want to know more about finite state machines, I highly recommend these two articles: UML State Machine on Wikipedia and Finite State Machines (FSM) by Jason Brownlee.

The FSM system which I wrote involves a main CStateMachine class, a base CState class, a CTransition class, and a CEvent class. There are also some derived state classes, namely CStateTopSimple, CStateTopComposite, CStateSubSimple, and CStateSubComposite. CStateMachine stores the root state, and manages the initial event processing. CState, CTransition, and CEvent are what you would expect them to be; they represent and manage a state, a transition between states, and an event respectively. The derived state classes are there mainly to make the code easier to both read and write by automatically setting default values and ignoring certain features of the base state class. A state can have multiple transitions attached to it, which are triggered by events.

An explicit FSM like what I just described is certainly useful, but it's a bit too much for managing character states in Stick Adventures Online. Because of this, I will be trying out an implicit FSM in one or two test projects. After I have experience using an implicit FSM, I will be returning to work on SAO: Redux. An implicit FSM is very similar to how I have been coding state handling already. However, with my experience in writing and using an explicit FSM, I should be able to write better state handling code.

I have also decided to scrap the engine and start from scratch. Like with FSMs, I now have more experience which means I can probably write an engine faster and better than I could before. There are some problems with using an engine for a long time. One problem is that you forget the original reason for a feature, for example the garbage collection system; it is intended to allow generic RAII and automatic management of memory, so it does not need to be used if these features are not required. Another problem is that the engine was written with less experience and knowledge, possibly made worse by later additions which piled more recent knowledge on top of the old, possibly bad, designs.

At any rate, I will be working on at least one test project before getting back to SAO: Redux. Just like with Redux though, I will probably release builds of these projects to people who are in the online chat.


Artist's Easel
Drawn by GreyKnight

iScribble Sketches #32

(Click to enlarge)


(Click to enlarge)



Community Spotlight
Written by willl and jaythemage

Anticipation arises as we wait for SAO:Redux demo 29. With the production of demos halted at the moment, many members are beginning to feel uneasy and think that Invisible has stopped working on SAO: Redux. Though that is not the case, many (typically younger members) tend to flame InvisibleMan and ITS saying that they could make a game like SAO a lot faster than this. Some of them try, fail to do so, and apologize; others ragequit and end up coming back later for any updates.

If you have anything you would like to say in the next community spotlight article, please post it here.


Funny Quote of the Week
From the online chat

pifreak: An Easter-egg I found on accident: hit F5 in notepad. It inserts the current date and time!
InvisibleMan: Edit->Time/Date F5
pifreak: cool, they hid the Easter egg in the menu <.>

[IfThenSoftware]

News

The first demo of our test project (a vertical scrolling SHMUP) has been released.  For details, click here.


From the Programmer
Written by Invisible

Starting fresh without any wrappers around the APIs has been interesting.  The code is actually a lot simpler, and I spend more time working on the actual game rather than the engine.  This has led me to wonder if the "game engine" which people sometimes talk about is actually a game specific framework, not a collection of generic wrappers and utilities.

I have decided to use exceptions for error handling.  This would also allow me to catch any other exception and report it in a more user-friendly way (although I have not taken advantage of this yet).  The exception class is pretty basic; just a message and a constructor which accepts a variable amount of arguments and constructs the message using vsprintf().  I have plans to create my own error reporting system which generates the crash dump and sends it to an error reporting server, but this will probably have to wait.

All transformations are now handled by Direct3D.  Besides some tests with 3D graphics, this is the first time I have written a game without using pre-transformed and lit vertices.  This makes the code a lot cleaner and easier to write.  I do have a tip for anyone attempting this though:  If you do not have any lights, make sure lighting is turned off.  I spent multiple hours debugging the rendering code before I realized that the graphics were invisible because they weren't lit.  Another nice thing about letting Direct3D handle transformations is that it is really easy to add parallax scrolling; simply place the layers infront of the camera and move the camera around.

I spent some time over the last couple weeks learning about aeronautics.  Because this is the first SHMUP I have worked on which is not in space, the only way to get it "feeling" right is to learn how planes fly in real life.  I don't feel like I have learned the subject well enough to teach it, so I won't be discussing my findings here.  However, if you are interested in learning about aeronautics, I recommend the following article: Aerodynamics in flight: flight principles applied to airplanes.  The game ended up using air resistance, banking, and multiple thrusters to get the ship moving in the right direction.  Not completely accurate, but close enough.


Artist's Easel
Drawn by GreyKnight

iScribble Sketches #33

(Click to enlarge)


(Click to enlarge)


(Click to enlarge)



Community Spotlight
Written by jaythemage



If you have anything you would like to say in the next community spotlight article, please post it here.

[IfThenSoftware]

News

The second demo of our test project (a vertical scrolling SHMUP) has been released.  For details, click here.

Forum account registration has been temporarily disabled.
http://www.ifthensoftware.net/forums/index.php?showtopic=2197


From the Programmer
Written by Invisible

To make it easier to create the background images, our artist GreyKnight requested that I create a tool for him.  This tool would allow him to create the rough outline of the terrain by stacking blocks.  Blocks would be stacked by clicking the mouse over the area where you want the block to be placed, and it would appear at the top of the stack at that location.  Blocks would then be removed in a similar fashion by right-clicking.

Unfortunately, I seem to be cursed when it comes to tool development (just ask GreyKnight about the map editor I created for Volund).  Things started out fine; the base framework was put together in a few days and I didn't run into any problems.  However, I hit something of a brick wall when I tried to implement the mouse control.  The original plan was to have things set at an isometric angle, but I quickly realized that due to the variable height of the terrain, this would require a 3D mesh of the terrain in order to figure out where the mouse was (ray vs. triangle mesh).  In an effort to simplify the problem, we decided to make it top-down but at a slight slant.  Loradon and Volund both used this view angle, but the height and angle were faked by the artwork.  This change helped simplify the camera setup, but still required a 3D triangle mesh.  One solution, which we are currently considering, is to not use the mouse.  This would allow me to use an easy to keep track of position, and alter whatever is at that position when another key is pressed.


Artist's Easel
Drawn by GreyKnight

iScribble Sketches #34

(Click to enlarge)


(Click to enlarge)



Community Spotlight
Written by jaythemage

Documenting the progress of Ifthen Software's SHMUP in video format, Jay (a community member) created a video of the latest demo.


If you have anything you would like to say in the next community spotlight article, please post it here.

[IfThenSoftware]

News

The third demo of our test project (a vertical scrolling SHMUP) has been released.  For details, click here.

Forum account registration has been reopened.
http://www.ifthensoftware.net/forums/index.php?showtopic=2201


From the Programmer
Written by Invisible

We have postponed the heightmap tool which I discussed in the previous newsletter issue.  This is good news for me, since I can work on the fun stuff (destroying alien ships) and I don't need to worry about the problems with the tool yet.  Our artist doesn't need to work on backgrounds right now, so this shouldn't hurt that side of development.

So yes, I worked on making it so that you can destroy alien ships.  I personally think that it turned out quite nicely, and have been found to sit and constantly kill aliens just for the fun of it.  Feedback is part of the reason why they are fun to kill.  When your projectiles hit the alien, it jerks back from the impact and the projectile seems to encounter the alien and explosively disperse into and around it.  When the alien reaches about 30% of its health, there is an explosion inside of it which causes visible damage.  And there is a final explosion when the alien is destroyed.  More can be done of course, most notably the addition of sound effects, but it works well so far.

I ran into a couple problems while making it possible to destroy alien ships.  The first one I remember involved a lot of debugging and turned out to be a somewhat embarrassing oversight.  Your ship's projectiles would appear inside of the alien ship for an instant before colliding with it.  The alien's collision area is large enough to prevent this kind of problem, so that wasn't the issue.  The next thing I investigated was the depth of the projectile with respect to the alien ship; maybe Direct3D was translating it a bit further than I was expecting due to depth?  This was an issue with other things, but it apparently wasn't causing the present problem since the projectiles were given the same exact depth as the aliens and they still penetrated too far.  I eventually thought to check if collision detection was being performed after movement, and found that it wasn't.  Because of this, the projectile was allowed to penetrate the alien ship for a single state (one or two frames) before it was finally detected and removed.

The other issue wasn't a bug, but it was a task I hate dealing with: orientation interpolation.  States are interpolated by the renderer in order to ensure that there is no "jitter".  The "jitter" is caused by an accumulated extra amount of time when updating at a fixed time-step; you eventually create multiple frames at once, and the screen appears to "jit" because of this.  Interpolation is easy, but you run into trouble when you try and do it with Euler angles.  One of the issues is that you could spin around multiple times before reaching what it thinks is the correct destination angle.  Another issue is that the interpolation code may interpolate in the wrong direction.  Fortunately, 3D Math Primer for Graphics and Game Development has a section dealing with this issue, 10.3.4 page 156 which describes a solution.  I recommend reading that section for a proper description, but it boils down to limiting the angles to within 360 degrees (-180 to 180 is what the book uses) and calculating which direction is the shortest path to the destination angle and using that to interpolate.

I am currently tackling the problem of how to control the alien ships.  One idea involves springs, and the other involves a destination position and AI which directs the alien towards that point.  I might discuss this in more detail in the next issue, by which point I should have this solved.


Artist's Easel
Drawn by GreyKnight

iScribble Sketches #35

(Click to enlarge)


(Click to enlarge)



Community Spotlight
Written by jaythemage

Jay has once again made a video featuring the latest demo of Ifthen Software's SHMUP.


If you have anything you would like to say in the next community spotlight article, please post it here.

[IfThenSoftware]

News

The fourth demo of our test project (a vertical scrolling SHMUP) has been released.  For details, click here.


From the Programmer
Written by Invisible

I spent the majority of last week working on the alien ship's movement.  They needed to enter the screen and then circle around in front of the player's ship, both in an effort to avoid the player's shots and to hit the player's ship with their own projectiles (a moving target is difficult to hit).  There are several ways you can go about this, and it took me a while to both discover those systems and try them out.  These are some of the systems which I found: track, track and spring, move commands, waypoints, and a waypoint track.

Track
With this system, the alien ship would be on a fixed track.  This fixed track would most likely be determined offline by the designer.  The ship has a specific shape which it is following, setting its position to exactly match that shape.  For example, if you wanted the ship to fly down the screen from the top to the bottom, you would use a line beginning at the ship's starting point and ending at the bottom of the screen.  The most useful shapes would probably be lines, line segments, circles, ellipses, and curves.  These shapes could be strung together to make more complicated shapes, and thus more interesting movement patterns.  The disadvantage of this system is that the ship will be very rigid.  For example, you can't knock the ships back when they get hit by a projectile.  This could be solved by using an animation to give the illusion of the ship being knocked back.

Track and Spring
A modification to the track system.  This method attaches the ship to the track with a spring.  The spring fixes the inflexibility issues which the track system had, allowing ships to be knocked back, and jostled around in general.  The spring causes the ship to... Well, spring back to where it is supposed to be.  Unfortunately, this can cause the ship's movement to become too bouncy, flinging the ship back and forth as the track it is on curves this way and that.  This is the system I ultimately decided to use, but I made the springs heavily dampened to prevent excessive bouncing.

Move Commands
With this movement system, you have an AI which controls each alien ship in the same way that the player controls his ship.  The AI examines the state of the game and decides which way the ship should be moved.  Once the AI knows what it wants to do, it sends the appropriate commands to the ship it is controlling, just like the player sends commands to his ship by pressing keys on the keyboard.  This will ideally result in the best possible movement.  The main disadvantage with this system is that the AI can be very difficult to program.  I tried this system, but coding the AI would have been too big of a job for this project.

Waypoints
Each ship has its own list of waypoints.  These waypoints form the shape that the ship should move in, and can be easily updated to reflect changes in the game.  For example, the alien ship can follow the player's ship simply by having its waypoints move along with the player.  The alien ship has its velocity set so that it moves towards its next waypoint.  When that waypoint has been reached, it moves on to the next, and the next, etc.  A waypoint list can either loop around when the end is reached, or load another waypoint list.  Being able to load different waypoint lists makes movement more flexible, and editing the waypoints list in real-time is easier.  This system is flexible enough to allow the ship to be jostled around as much as you want, and it will still make its way towards its target.  The disadvantage to this system is that it forms rather rough and jagged paths.  You can smooth them out by adding more waypoints, but it will be difficult to get it as smooth as it would have been if a track had been used.

Waypoint Track
This is a combination of the track system and the waypoints system.  Basically, you have a waypoints list which contains a single waypoint, and the list is set to loop.  This waypoint is moved along the track as long as the ship is at the waypoint.  I did not get the chance to try this exact system myself, but it seems like a "best of both worlds" solution.  Unlike the track system, this allows the ships to be knocked around.  This also takes advantage of the smoothness which the track system provides.  This could be thought of as a very dampened track and spring system, but you do not need to worry about the high accelerations which are caused by being too far from the track.

I am sure this is not a list of every single option available, but I hope it helps anyone who is currently interested in this.  Another thing to keep in mind when choosing a movement system is how you want the game to feel, and how the ships should act.  If the ship is a scary attack drone, using a very fast speed and the waypoints system would give the effect of sharpness and decisiveness.


Artist's Easel
Drawn by GreyKnight

iScribble Sketches #36

(Click to enlarge)


(Click to enlarge)



Community Spotlight
Written by jaythemage

Another week, another video; Jay has created yet another video showing off the latest SHMUP demo:


If you have anything you would like to say in the next community spotlight article, please post it here.

[IfThenSoftware]

News

The fifth demo of our test project (a vertical scrolling SHMUP) has been released.  For details, click here.


From the Programmer
Written by Invisible

The heightmap tool is finally finished!  Since I decided to use the arrow keys rather than the mouse to move the tile selector, the tool was completed easily.  The tool isn't very well optimized (every tile in the map is being rendered) but it runs fast enough to get the job done.  The one tricky bit I ran into was making the selector turn green when behind tiles.  I eventually got it to work by checking for intersection between the selector and any tiles with the same x coordinate as it, but a lower y coordinate (in map space, not screen space).

The one big feature I added to the SHMUP was the mission selection screen.  The dotted lines in particular were somewhat difficult to code.  I ended up storing a dotted line graphic in a texture, which is then attached to a quad.  One end of the quad is attached to the mission's starting point and the whole thing is rotated around to point at the mission's destination.  The angle for this rotation is calculated by taking the dot product between the unit vector pointing from the mission's initial position to its final position and the unit vector i=(1, 0).  This dot product is the cosine of the angle between the two vectors, so the angle is calculated by using acos().  This will only return an angle between 0 and 180 degrees though, so we need to figure out which half it is in.  This is done by performing another dot product, this time against the unit vector j=(0, 1).  If this dot product is less than 0, the following is used to recalculate the angle: angle = PI + (PI - angle).  The line changes its length by modifying the width of the quad based on a "path progress" percentage.  I will probably change that last bit in order to get a certain effect though.


Artist's Easel
Drawn by GreyKnight

iScribble Sketches #37

(Click to enlarge)


(Click to enlarge)



Community Spotlight
Written by jaythemage

In the past few weeks, several players have begun playing Volund. The source of this income of players is unknown, but we are glad they decided to play.

Jay made another video spotlighting the SHMUP:


If you have anything you would like to say in the next community spotlight article, please post it here.

[IfThenSoftware]

News

The sixth demo of the SHMUP has been released.  For details, click here.

The SHMUP is now officially an IfThen Software project.  http://www.ifthensoftware.net/forums/index.php?showtopic=2231.


From the Programmer
Written by Invisible

Last week I was stuck on what should have been a simple problem: Calculating the time at which two objects will intersect.  The objects in question have constant velocity, so that helps simplify things a bit.  My original plan was to set both object's motion formulas equal to each other and solve for time.  This would have worked splendidly, if not for the fact that division is undefined for vectors...  It was impossible to get time alone on one side of the equation.  The breakthrough which helped me finally solve this problem was the realization that both objects are moving parallel (along the same line).  This allowed me to get rid of the vectors and use the well known equation d = r*t.  In order to use that equation, I needed one of the objects to be stationary so I calculated the relative velocity of one of the objects.  vrel = va - vb  vrel is the relative velocity of object a with respect to object b.  So the final equation became: t = |(rb - ra)|/|vrel|  where ra and rb are the positions of the objects.

I still don't know how I would handle this if the velocities are not parallel.  I'll have to tackle that eventually, so you may be able to read the solution in a future newsletter issue.

It appears as though the alpha component of specular is not added to the color like the red, green, and blue components are.  This was unfortunate, since a certain visual effect was depending on it.  We eventually got a similar effect in another way though.  From what I have read, the alpha component is largely (and possibly only) used for fog calculations.  It is possible that this could be taken advantage of and used to get the desired effect, but I did not have enough time to research that.  It is worth keeping in mind though.


Artist's Easel
Drawn by GreyKnight

iScribble Sketches #38

(Click to enlarge)


(Click to enlarge)



Community Spotlight
Written by jaythemage

For the latest SHMUP demo, Jay created yet another video:


If you have anything you would like to say in the next community spotlight article, please post it here.


Funny Quote of the Week
From the online chat

ace: I'm hanging up a sweater, and my closet is organized from most like a trench coat (a trench coat) to least like a trench coat (a travel toiletries case that functions as a gameboy case)

[IfThenSoftware]

News

The seventh demo of the SHMUP has been released.  For details, click here.


From the Programmer
Written by Invisible

Now that the SHMUP has been in development for a while, it's starting to get a bit texture heavy.  Because of this, some users have been unable to run the game due to a lack of video memory.  My initial attempt at solving this was to load textures into system memory after video memory runs out.  Unfortunately, your graphics card needs to support rendering with textures in system memory for this to work.  This seems to be a somewhat rare capability, so I ended up scrapping the code.  The proper way to solve the memory issue is to load textures only when they are needed and unload them when they are not.

In the last demo, we added the ability to fire missiles at the enemies.  I experimented with steering to control the missiles, but that didn't feel quite right.  The method I eventually settled on was to generate the missile's velocity based on its heading.  If the missile is not flying straight for the target, its heading is gradually adjusted until it is.  This sometimes causes the missiles to circle a target for a long time, but that can be fixed by increasing the missile's rate of turn.

The game will no longer freeze when you press one of the alt keys.  For those wondering how to do this, it's pretty simple: All you have to do is handle the WM_SYSKEYDOWN message when it is for the VK_MENU key.

If you are creating the trail for something (such as a missile) by placing particles behind it, you should keep in mind that if the rate of placement is greater than the update rate of the game you will need to place multiple particles per frame.  If multiple particles have to be placed per frame, you need to interpolate the position of whatever they are following otherwise they will all bunch up in one spot.

As I said in a previous issue, I had to tackle the problem of calculating the intercept time and vector for your ship's mission screen blip to one of the mission blips.  And as I predicted in said issue, this was rather difficult.  I finally found a post on the GameDev forums which discusses how to go about this.  You can find the post here.  The breakthrough for me was that the distance your ship travels in the interception time is equal to the distance between the mission blip at that time and your ship at the initial time.  This provides the necessary equation to find the time of interception since only scalars (distances) are required.  Calculating the intercept vector once I had the time of interception was a simple matter of getting the vector between your ship's initial position and the mission blip's final position (at the time of interception), normalizing it, and scaling the resulting unit vector by the speed of your ship.

The code for the SHMUP is starting to become too cumbersome to easily change.  Mostly due to the way it is structured, compiling and linking takes between three and four minutes to complete.  Because of this, I have spent the past week experimenting with new techniques.

The first thing I wanted to get straight was the difference between the "game logic" step and "physics" step.  After a little research and several discussions with other programmers, the following definitions seem to be commonly used:  "Physics" is any code which moves things (this includes collision detection and response) and "game logic" is code which regenerates a character's health, counts down the timer on a trap, shoots a gun, etc.  These definitions get a bit blurry if you think through each action too much (shooting a gun is technically movement since your character is moving his finger on the trigger and the internals of the gun are moving) but the following rule should help define the line better: If the movement literally takes place in the game, it's physics; otherwise, it's game logic.  For example, if your character does not actually move his finger to squeeze the trigger, and the internals of the gun do not actually move, then it is game logic.  Sure these could be animations, but if that is all they are (they aren't separate movable entities which trigger the various parts of firing a gun) then they do not belong in the physics step.

With those definitions squared away, I was able to work on a new code structure.  The code is split up into systems, game states, and utilities.  The systems include debug, render, window, main, and input.  Utilities are things such as an interpolation macro and an exception class.  Examples of game states are banner, menu, and game.  Each game state is split up into input, state, and render.  State is further broken up into physics and game logic.  A game state could also be split up into UI and game sub-states, but I haven't experimented with this yet.  The idea behind this structure is to separate the code to make the addition of features easier (because it is more obvious where the feature belongs), make debugging easier, and reduce compile+link times.  I may have to cut out some of this structure in the end though, since adding structure to code also makes it more complicated.


Artist's Easel
Drawn by GreyKnight

iScribble Sketches #39

(Click to enlarge)


(Click to enlarge)



Community Spotlight
Written by jaythemage and miotatsu

Miotatsu has written a detailed tutorial on how to setup WINE to run IfThen Software games.  You can find it here.

The seventh SHMUP Demo has been accompanied with a Youtube video by Jay showing the new features:


If you have anything you would like to say in the next community spotlight article, please post it here.