Raytracing is fun

I decided the other day to write a raytracer in C#, since I haven’t done that before and I thought it might be fun. I have to say, I haven’t had this much fun in a while. Unfortunately I didn’t have the foresight to take screenshots whenever I changed something, so I don’t have many images to show the process, but I do have a few images.

This was yesterday’s state, with support for diffuse shading and reflections. The plane at the bottom has some broken shading, which was fixed in the later version.

Raytracer 11-5-14

 

This is the current state of the raytracer, with support for specular highlights, hard shadows, diffuse shading, and reflections.Raytracer 11-6-14

Next up is either going to be support for more shapes or antialiasing, not sure which at the moment.

Update: I added antialiasing support. Image rendered at 1920×1080, 16 samples per pixel.

AA Raytracer render

Playing with compilers

Over the past few weeks I’ve been working on a rewrite of Shogun. It is still a stack machine, but now includes two registers, a sane assembler, a mostly complete set of opcodes, and now even a language that compiles to it!

Shogun

Shogun has been rewritten in its entirety, though it does use snippets of the original here and there (specifically, Shogun::Object is almost cut-and-paste from Shogun::Data). Binaries still use the same header, but the version has been changed to 0.2.x. New versions of Shogun will refuse to run old binaries and old versions will refuse to run new binaries. This is necessary as first of all the opcodes have changed, but more importantly the entire layout of the binary has changed.

The single biggest change to both the VM and the binary layout is the way Shogun now handles memory. There are only two segments of memory: The stack and the heap. There is no separate program memory, as Shogun simply reads the program from the heap. What this means for the binaries is that they only have two sections: the header and raw memory. There is no separation between what an opcode is and what data in memory is. What is nice about this is that you can actually pre-store memory you need inside your binary, and it will immediately be available inside the VM as long as you know where to address.

Now, as for the registers I mentioned, there are only two. They each can only hold an unsigned integer (internally known as the address type). The first is known as PRI, or program index. It simply stores the next address for the VM to execute. The second is known as MMX, which stores a local position of memory. When a program is loaded, MMX is set to the first unallocated position of memory. The VM never uses MMX itself, so it is up to the programmer as to how to use it. Sholan uses it to denote the current scope’s local memory.

I’m probably not going to be updating the online Shogun sandbox, as I don’t want to put the horribly written memory limiters on the new version of SVM. In fact, I’ll probably be taking down the sandbox at some point simply because it is horribly outdated.

Some other miscellaneous improvements:

  • Labels and JUMPing are now sane
  • No more global variables; you can’t define variables in your assembly, you have to hardcode addresses (or use the stack)
    • This was mostly done as it adds a bit of complexity to the assembler and is useless for an actual compiler to use
  • New filename extensions: *.shasm for assembly and *.sx for binaries.
    • On that note, Sholan files are *.sl

Sholan

Sholan is a new project that was added to Shogun a couple of weeks ago. It is my experimental compiler for a language also known as Sholan. I’ve been designing this language around Shogun, and have decided to finally build a toolchain for it. The compiler is written in C#, much to my chagrin, as the lexer/parser generator ANTLR4 doesn’t currently have a C++ target. Luckily, Sholan should run fine on Mono.

As for using the language itself… I’ll be writing a whole lot more about it in some followup posts.

Moving on from here

Looking to the future, I’m mostly focusing on Sholan development. Building something that uses SVM rather than building the VM itself forces me to think about what I really need from it. Here’s a list of some of the things that are in the works for both SVM and Sholan:

  • [SVM] Dynamic library support – some way to tell AsmReader to import external dependencies
    • Currently Sholan just throws every imported file into one binary. Woohoo monolithic code!
    • I want to try to get this done without really adding much to the VM itself.
  • [Sholan] Not all operators are supported
    • Stuff like bitwise operations
  • [Sholan] Actually use the heap as a heap and not as a stack
  • [Sholan] Some sort of OOP system
    • Not sure how I want to do this, as it is a huge beast to tackle.

Now I’ll leave you with a small snippet of code from Sholan:

// FizzBuzz
import "lib/standard.sl"

entry {
	print("N?")
	var count = readline()

	for(var i = 1; i <= count; i = i + 1) {
		var output = ""

		if(i % 3 === 0) {
			output = "Fizz"
		}

		if(i % 5 === 0) {
			output = output .. "Buzz"
		}

		if(i % 3 !== 0 && i % 5 !== 0) {
			output = i
		}

		print(output)
	}
}

My relationship with Minecraft

Over the past few months, I’ve just seen everything to do with Minecraft slowly become shittier and shittier. First the whole EULA drama: I don’t care to take a side in this post, but at the very least it showed that Mojang seriously needs to reign in their developers. Specifically one who I won’t mention here, who in a public chat said some nasty things about server owners. Justified or not, employees should not be making public statements about their company.

Then came Mineorama. This one certainly wasn’t Mojang’s fault, but it is just one of a plague of similar events that has happened in the past few years and it certainly doesn’t help the community at all.

Now we have the Bukkit drama. First Mojang comes out as the secret owner of Bukkit, which is highly unethical. Developers were freely giving contributions to an open source project that was assumed to be under independent ownership. Then we have the DMCA takedowns due to a former Bukkit developer claiming that the license to his code was invalidated by the fact that Mojang allowed their closed source code to be distributed with his GPL’d code. The scary thing is, I actually sort of agree with what he did. I’d certainly feel pretty damn betrayed if I suddenly found out that a company secretly owned a project I’d dedicated a part of my life to. I’m not saying what he did is right, but I certainly don’t blame him.

All in all, Minecraft has not had a good year. Not even close. Now that I’ve made that point, I get to talk about me: I’ve had enough. Enough of the drama, enough of the bullshit from a company that has way too much money and doesn’t now how to manage itself. I’ve made quite a few friends, and I’ve had a lot of fun creating games that many people have played. At some point, however, I just have to say enough. I don’t want to be a part of this community any more. I’ve had my fun, but I have enough to deal with in my personal life without having to sift through a pile of shit drama every day.

This doesn’t mean I’m leaving Minecraft right away, in fact I will likely stay at my position at The Chunk for a few more months. I still have quite a bit of unfinished business to complete, and I’m not about to completely leave everything I’ve created behind, but consider this a notice of my future intent.

Thank you everyone, it has been quite a ride.

-Sam “Red” Bloomberg

Current projects

I haven’t posted here for a while, and it’s because I’ve been working on a lot of new stuff, most notably a brand new game. I’m not going to say exactly what it is, but what I will say is that it is a neat little 2D platformer built with Unity.

 

I’m also thinking about what the future for Dive engine is. It was mostly an experiment in the beginning, and it worked out pretty well, but there are numerous problems with it at the moment. I really want to get around to writing a successor to it, or even a 3D variant (adding 2D support afterwords). I’ve been thinking about the best way to do this, and originally I was going to go with C++ this time around, but I’ve gone back on that decision and I’m currently planning on using C# once again. For me, C# is just too nice of a language to pass up. I might go back on the decision once again, but at this point I really can’t say.

Graphdat

I could be horribly late to the party, but I was just shown this awesome service, graphdat:

Graphdat graphs

Graphdat is a service which allows you to easily make a dashboard for graphing different things on a server. Here, I have a dashboard for redxdev.com’s CPU usage, memory usage, disk IO, network IO, application info, nginx connections, and mysql connections.

Go check it out at http://www.graphdat.com/, it’s free for a single server!

DivePong

Since there aren’t really any samples on how to use Dive to actually make a game, I decided to start doing that myself. For the first sample, I have started working on a very simple pong clone. You can find the repository here.

Right now all that is implemented are the components for the player to control their paddle. You can test it out by setting up the project, launching the engine, and running the command “entity_create_template Pong.Player”. Use the up and down arrow keys to control the paddle. Not much, but it’s a start. I should have the sample done pretty soon.

Update: The game is almost fully implemented. It allows you to play a basic game of pong and it keeps score. There are a few bugs with the ball movement, but it is playable.

New Dive Engine feature: game assembly

This is something I’ve wanted to implement for a while but only just got around to doing, but Dive engine now separates engine logic from game logic.

As of the most recent commit (at the time of this writing), the engine code is in a separate project from the game code. The engine still compiles to an executable, but the game code now resides inside of a dll. This is a breaking change; anything on Dive engine previously will likely not work after updating to the latest version. It should be simple to port old code over, but it is just something to keep in mind.

In other news, I have removed the old tutorials as they are now very out of date, and it would be better to either just look through the code or to wait until I get around to writing new tutorials.