Wednesday, April 19, 2017

Real Time Ray Tracing for games.

In 2015, I've been tinkering with a real-time photon mapper to do Global Illumination for simple voxel worlds. Recently, I thought there should be more I could do with this idea.

So my Real Time Ray Tracing experiments are back, but with a twist. The minimalistic voxel world was a little too minimalistic. And it couldn't be much more detailed if I were to keep a 60 FPS target. So something had to give.

This time, I have dropped the Global Illumination feature, and no longer compute indirect light. Instead, I just fire one primary ray, and one shadow ray for each pixel in the projection. Granted, this does not give you much advantage in quality over rasterizing. But it does give nice crisp shadows, that can be cast from a local light, casting shadows in all directions.

To have a little more detail than simple voxel models, I went with AABB primitives. To avoid confusion: Normally AABBs are used in ray tracing for spatial indexing. In my project, however, I use the AABBs are the geometric primitives. They are more efficient than voxels, as large blocks and planes only need a single AABB primitive.

I do use spatial indexing to cull primitives though, but for this I use a simple voxel grid. In each grid cell, I have an instance of a primitive model. These primitive models are packed up as SIMD friendly sets of 8 AABBs in SoA form. Using 8-way SIMD, a single set of 8 AABBs are intersection-tested against a ray, in just a few instructions.

Target platform is AVX2 equipped CPUs, and it's currently running on GNU/Linux and MacOS. It's running close to 60Hz on a 4-core Haswell, at the expense of loud fans running, unfortunately.

Game Play is yet to be determined. Post your ideas in the comments. Thanks!

Saturday, March 4, 2017

The Little Bike That Could

So, I released a game yesterday. You can grab a free copy of The Little Bike That Could over at the itch.io site.

I made this over the course of one month, using the same custom game engine that I use for all my games. I had tremendous fun creating it.

Bicycle dynamics are so fascinating. It's a lot more involved than it appears to be at first glance. As a matter of fact, scientists had a really hard time determining where a bicycle's stability comes from. It turns out it is not caused by gyroscopic effect of the wheels.

It's pretty amazing that humans can cycle at all, as the process is so much different than it appears. For starters... imagine your self riding in a straight line on a bicycle. You want to make a left turn. What do you do with the handlebar?

If you answered: for a left turn, you turn the handlebar left... No, that is not what happens, surprisingly! Instead, you turn the handlebar in the opposite direction (called counter steering.) So you turn them right, which causes the bike to fall (lean) to the left. Only now, do you turn the handle bars to the left, to stop the fall to the left. This maintains the left-lean, and causes a left turn.

To stop the left-lean, you briefly steer further left which brings the bike upright again, and thereby ending the turn.

How remarkable is that? To start a left turn, you first steer right. To end a left turn, you steer left. As a child, our brain somehow is trained on this behaviour, and for the rest of our lives, it enables us to ride and steer a bicycle.

So I made a scientifically valid physics simulation for a bicycle. The player will choose a lean angle (to left or right) and then the computer will turn the handlebar to reach a desired lean-angle, causing the turn. I also added independent controls for rear and front brakes. This enables rear-wheel slides and front wheel stoppies. I created 10 levels with different challenges.

It's hard to really explain the game play, and others do a much better job of it. So allow me to introduce Iwan who played my game and made an excellent video about it.

Wednesday, March 1, 2017

The alternate universe without a computer mouse.

Consider the de facto standard user interface for computers and computer software. It is what we call the Graphical User Interface, or GUI. Comprised of a mouse cursor and windows, sliders, buttons, scrollbars and such.

I remember seeing my first computer mouse on a trade show. I'm going to venture that it was a Macintosh mouse. And it seemed magical to me. All I knew was 8-bit micros from Sinclair, Commodore, Acorn and the like. And suddenly there was this element on the screen that somehow was moved in sync with the movement of a little device. I seemed from the future!

The computer mouse may have been popularized by Macintosh, but its way was paved by Xerox Parc.

Personally, I'm more at home with command-line interfaces, with text based commands. As I've put it earlier: How reproducible is a mouse click? I use the Visual Studio IDE to port my games to windows. But because I use it so intermittently, I tend to forget my work flow. Where do I click, in which sub-sub-sub-menu to solve this issue with the compilation? I spent too much time wrestling with the GUI, wishing I was back in the command line environment with Makefile, as I do under Linux. If I need to reproduce something, I can just examine, and re-run the script.

While taking a shower, a thought struck me: what if the GUI was never popularized, or even invented? What if the text based interface, on a command line, would have persisted from the 70s into 2016. Let's visit this alternate universe, where the computer mouse, and the GUI, never evolved.

What would this alternate universe look like? I'm going to make a bold statement here: I think it would have been more technologically advanced than our current society.

Without a computer mouse, and without the GUI, we would still have an Internet. And we would still be ordering pizzas over the Internet. Just not with clicking buttons, but by typing in a command:

$ order-food -restaurant=marios -cheese=gorgonzola -meat=proscuitto -size=m

...or something similar.

The real kicker here, is that all these internet-based services would be text based, thus so much easier to extend and compose into more complex services. Maybe in a script, you want to combine the pizza-order with another command send to your fridge to chill the wine. If there is a text based API for service A, and one for service B, anyone (not just programmers working for the corporations behind A and B) would be capable of layering new services on top of these. No source-code of the web-sites would be needed. Extending a GUI based application typically cannot be done with no access to the source code. Even if source code is available, it is pretty hard. Extending a command line based application is much easier, and does not require source code. We could invoke services in scripts, sequence them, layer them, schedule them, whatever we desire.

This means that in our alternate universe, software applications will be far easier to extend. Developers can build on top of what others have made. Being able to extend third party GUI applications tends to be impossible, or at the very least hard, and would require things like plug-in infrastructures, and SDKs. Of the gazillion services available on the Internet today, very few are customizable, extensible. In our universe we spend a lot more time reimplementing the 'full stack' over and over again, instead of building on top of what others have made.

To conclude, I think the invention of the computer mouse was a curse, that just looked like a blessing. Sure, it may make the life of creatives easier. Producing digital art is so much easier with it. But in terms of computer technology, I fear that we are poorer for it, not richer. The GUI killed the command line, and that may very well not have been a good thing.

Did the computer mouse doom the technological progress in our society?

Saturday, February 11, 2017

The Little Bike That Could.

I am announcing my latest indie title, which is currently under development: "The Little Bike That Could." Like many of my previous titles, it comes with an exceptional physics simulation. It's been fun implementing and tweaking it. Wheelies, Stoppies, Slides and even loopings on a half-pipe are possible.

It is currently implemented for use with a gamepad on linux. The initial release will probably be on the ich.io portal, and after that I may experiment with phone-tilt control. So far, I've designed and implemented 6 different game levels, the last of which is fiendishly difficult.

If you want to follow the progress of this game, or participate in early testing, join the Google+ community for it.

Tuesday, January 3, 2017

New windows install

I've reinstalled windows on my PC, going to Windows 10. Here's a list of things to do on a new install:

  • Expand the explorer 'ribbon' to set the 'View' properties on your local drive. This is needed if you want to see file extensions.
  • Installed Visual Studio 2015
  • Installed Sys Internals Process Monitor.
  • Installed git for windows, which comes with the great git bash, that lets you do UNIX on windows.
  • Set Google as Default Search.
  • Using a git shell, make a new RSA key using 'ssh-keygen.exe -t rsa' command. Paste the public key in GitHub.com site's settings.
  • Set privacy options. Settings -> Update & security -> Advanced Options -> Privacy Settings. Switch everything off here. Note that windows will sometimes set them all back 'on' after a windows update. Sneaky if you ask me.

Sunday, January 1, 2017

2016 totals

So, The Little Crane That Could is holding stable on Android, but dropping on other platforms. Here are the 2016 results (Number of free Downloads.)

2016 2015 2014 2013 2012 2011
iOS 416K 630K 1300K 3199K 3454K 1550K
Android 1515K 1525K 825K 1579K 1656K -
Mac 10K 20K 30K 53K 81K -
OUYA - 0K 4K 15K - -
Kindle 48K 52K 46K 95K - -
Rasp Pi - ? ? 6K - -