Tuesday, 29 July 2014

My code - MM3D loader for three.js


I previously made a MD2 loader for three.js. But the MD2 format has several problems, it's very outdated, it gets enormous and takes a while to load if you many animation frames, and it does not have skeleton data, so you can't attach things like weapons to the hands or armor to the chest or hats to the head.

So since I had no idea of the hell I was bringing upon myself, I decided to make a MM3D loader. That is Misfit Model 3D loader for those who never had contact with this infuriating piece of code. The quality of the model editor's code should have alerted me. It uses unsigned integers as pointers (so it does not compile for 64 bits) and has class declarations larger than 1kloc. A true case of bad C++. Problem is, the specification looked quite trivial!

Now I have learned what lies beneath the surface of Misfit Model 3D model format.

First, the way the model is stored is quite strange, there are lots of unused flags. And the resulting data structures are all disconnected. For example, the vertices. Vertices of a 3D model have attributes like texture coordinates, for example. Instead of having a vertex data structure arranged sequentially, each of those having flags to say which data is available for the current vertex, the data is arranged all over the file, and therefore each element of vertex information has to have a vertex index. This makes parsing the files a lot harder. I call my index variables in loops letters starting from "i", like "i j k l ...". You know a data structure is no good when you have to go all way down to "l".

Second, the specs don't tell you you have to add the default bone translation and rotation values to the animation keys to get the right values, I had to find this on my own.

Third, the specs contained not one, but two errors, the second of which cost me a lot of time, because I had no idea where it came from. I even thought it could be a problem with three.js animation system.

To speak of which, three.js's animation system, specially for skeletal animation, is horribly non-documented. I had to look at a lot of source code to figure out how to generate the bone and geometry data.

But now that this is over, I am pretty happy, because it actually works quite well. I pretend to use it instead of the MD2 loader for any upcoming 3D games.

Check out the github repo below, and the live demo here. Models are: Ronaldo by me, the others from opengameart.org.


Monday, 28 July 2014

My "games" - Super Mario 64 in HTML5 and WebGL using three.js

A small experiment I made in three.js, to test it's capabilities.

Most three.js examples available on the web are very simple and do not show interactivity like the one you see in a videogame. So I chose to replicate Super Mario 64's first level, Bob-omb Battlefield, in three.js and HTML5 technologies.

The art is actually ripped from the original game. The models I got from this site, "The models resource". They all come in .obj and .mtl models, which are easy to load with three.js (one of the examples show how, I modified the MTLLoader to use MeshBasicMaterials instead of MeshPhongMaterials to get the look a Nintendo 64 game). The jump sounds I got from this pack of sounds from SM64 at Mario Fan Games Galaxy. Last but not least, the level's theme I got from this video. I downloaded the audio of the video with Youtube to MP3 and I converted the MP3 to OGG for greater HTML5 usability with this online audio converter.

I really hope I don't receive a good old Nintendo cease & desist letter :D

I am considering releasing the code. I am very fond of releasing code actually, but the code for this demo is quite quick & dirty, a horrible mess. In fact, it's shameful. If I do release the code, I will also create new art, my own jumping sounds, some music from opengameart, my own models and textures... I have some ideas, like replacing Mario with a farmer called Anthony and the goombas with evil brocoli.

P.S.: I actually started this as a test for some collision code I am writing, that's why you can see some collision glitches at the video if you look carefully. As it is, it certainly does not do decent collision testing.

Tuesday, 22 July 2014

My code - MD2 loader for three.js

three.js is a fine library but it suffers from a lack of file loaders. three.js contributors have this naive "we don't need file loaders! we have our own shiny JSON formats!" bullshit. Since I am planning to use three.js in LD30, I decided to roll my own model loader. And as everyone knows, id software's MD2 is the most modern and featured model format ever.

Doing some research on previous efforts in loading binary model formats in Javascript, I found this WebGL MD2 loader and renderer. At first I thought I could simply use this guy's loading code and write some code to convert the loaded mesh to a three.js geometry object, but I was wrong, as his code was quite bug-ridden. So I ended up changing a lot of things.

Summary of changes:

  • First of all, I renamed his inferior snake_case variables to use my superior camelCase standards.
  • I also changed things like a "vertex index" array to a "verticum indices" array, as I mind to use proper latin.
  • I changed the loading with XMLHttpRequest to be asynchronous, as is the standard when loading resources from different files in web development.
  • I changed the binary interface, the original was buggy and no longer mantained, to use jDataView instead.
  • I made it sure that the file is loaded in the correct endiannes (little endian).
  • I rewrote the file ID checking, because the identifier is not an actual string.
  • I don't divide the texture coordinates by the texture size to get s and t as I load them, since some MD2 exporters set invalid texture sizes.
  • I solved a problem with the loading of frame and animation names.
  • I added skin name loading code.
  • I wrote code to convert the loaded model to a three.js geometry.
I changed so much I can't even call my code "derivative" anymore, it's totally different.

You can check out the live demo of the loader here. And you can click on the cat below to check out the Github repo:


Sunday, 20 July 2014

My games - Breakout clone for 6502asm

The screenshot above doesn't look very interesting, as it is from a pretty standard Breakout-style game. However, it will surely look more interesting if I tell you I made this in Assembly, 6502 CPU (the same the NES used) Assembly nonetheless.

More specifically, for this 6502 virtual machine in HTML5. I actually recommend you play the game at this development version of the VM, as it's way faster.

I made this after someone (the logs say bitslap and/or voxel) mentioned this VM in the #ludumdare @ AfterNET chat. Jedi helped me with some issues.

I enjoyed this experience in the lower levels of programming. I may find the will to do another game for this VM, most likely Tetris, and perhaps I may try making a NES game.

Here is the github repo for the game. The code does have detailed explanations, mostly in what I imagine to be C code equivalent (it would be more adequate to say mimetic) to the Assembly code.