The free and open source software ecosystem is a rough, harsh place. Lots of initial work has to be put in to ensure your project is successful, the conditions need to be just right to get third-party contributions, and often you still need a thick skin to handle the conflicts that inevitably arise.
But as both those who contribute and those who maintain projects themselves know, it’s a labor of love. As a long-time supporter of many projects, I myself am willing to accept the risks and launch a new project of my own. I have been working on building a data-oriented game engine in C++11 for a few months now, and it has just recently seen a fully-fledged port to Rust. I thought I would share it with the world and have it be developed in the open.
Enter Amethyst. This is a work-in-progress game engine written in Rust that aims to be both data-oriented and data-driven, taking heavy inspiration from the industrial-strength Bitsquid engine (now called Autodesk Stingray). There are plans for an entity-component-system (ECS) architecture and a strong emphasis on modularity (e.g. multiple graphics API backends for the renderer, easy to bind to Lua/mruby/Python for scripting). Amethyst is in its early days yet, so don’t expect to be wowed. The most it can do now is transition between game states in a pushdown automaton design, and there is preliminary work being done on the renderer.
The virtual desktop system is an interesting feature that attempts to bring the massive benefits of multi-monitor computers to single-monitor people. With a simple key combo or button click, the screen is split into a tiled grid of several desktops in an Exposé (now called Mission Control)-type fashion with the ability to select one and switch to it (see fig. 1).
For all intents and purposes, a virtual desktop is treated like another physical monitor, giving you a tremendous amount of “screen space” to work with. This is excellent for developers or graphic artists whose careers require many programs to be up and running simultaneously but cannot use a multi-monitor system, whether it be due to high costs or space constraints of some kind.
When people think of virtual desktops, thoughts of Linux, Mac, and BSD come to mind, but never Windows! Believe it or not, the WinAPI does have full virtual desktop support (as shown by the screen that appears when you press CTRL+ALT+DEL), but Microsoft does not implement it in a user-accessible way. This tutorial will detail how to get access to it and embed it in your own application. So let’s get cracking!
My hobby shell replacement project, µShell, is improving a lot. It is still far from being finished, and it has a few glitches, but it is still a useable, but limited, shell replacement.
Originally, I was seriously concerened with its high memory usage, but I realized that it seemed to run slowly only because it was being compiled and executed from my USB backup drive. After unplugging the drive and executing the program from my desktop, it ran like a dream. Lately, I have managed to implement some new features during the past few months:
A proof-of-concept taskbar. It currently has only two functional buttons:
iTunes Hide: This button will check to see if iTunes is running. If it is, it will hide it.
iTunes Show: The exact opposite of the other button. I’m sure you can guess what it does.
Filled the code up to the brim with useful comments. You don’t really need extensive documentation (you will need to read the SOURCEMAP file, though) as the comments serve this purpose well enough.
The beginnings of a unified settings manager. It barely has any controls on it, but it’s starting to make use of C#’s Properties.Settings.Default plumbing under the hood. There is still much room for improvement, though.
Virtual Desktops! It took me so long to implement this. I feel my head gained weight with all of that reading. It is still limited, though: it only supports two desktops, and there seems to be a severe glitch where µShell doesn’t always start on the second desktop, so when you switch to the second one, you are stuck there.
I understand this shell may be sub-par in its present state, but please remember that although I have been working on it since 2010 (not counting the VB 2008 “Altershell” prototype made in 2009), but only one to six hours a day and with five-month breaks in between. I believe that if I could find a way to effectively juggle high school, summer camps, and my free time, I could really exploit its potential and make something great out of it.
If you wish, please check out my new YouTube video that I have uploaded, which showcases the latest nightly Git build of µShell, which can be found here. Also, if you wish to see the three new & recently added shell screenshots, you can find them in the Pictures page.
Sorry that this post is kind of short in comparison to others (or maybe you are happy that it isn’t a big lecture), but I just wanted to promote my project a bit, after so many long months of no status updates.
Most people are familiar with the following video game titles: Battlefield, Halo, Doom, Civilization, Call of Duty, Half-Life, the Sims, and Unreal Tournament. Chances are, you may have seen the term “game engine” associated with them, but don’t really know what the term means. Perhaps you know what game engines are and think you have what it takes to write your own? In either case, I will introduce you in this article to the wonders of game engines and attempt to explain their internals as simply as I can. I assume that you, the reader, is familiar with basic programming parlance. If not, you might not understand everything I’ve written here.
A game engine is essentially a software development kit (SDK) that contains the source code and tooling necessary to get a basic video game up and running fast, letting the developer script in the gameplay, levels, and characters, without needing to touch a single line (or at least, much fewer lines) of C/C++ code or know advanced programming.
This allows the game developer to focus more on the gameplay and the “fun factor”, spending less time on complex math and other mundane boilerplate trying to get everything set up. This is analogous to an automobile designer selecting a ready-made engine from a trusted third-party vendor, eliminating the need to build a custom engine from scratch and therefore saving time, money, and effort.