Progress and Decisions

The mouse-look is now working entirely correctly.

I have added Newton's first and second laws of motion. I need to handle collision detection before I can add the third law.

To keep things running fast and to make the programming simpler, I will handle free-moving objects as non-rotating 'fuzzy' cylinders. What I mean by 'fuzzy', is that the radius of the cylinder is not constant, but rather depends on the kind of check one is doing. Horizontal checks will use the full radius, but for vertical checks round objects will have a radius of zero. This will allow flat objects to stack, round objects to stand on flat objects, and round objects to form piles. Most objects will be round, but I can definitely see some use for flat objects.

I have not decided how the map itself will be handled yet, because I first have to decide whether I should stick to cubes. I have read up on a technique called 'dual-contouring', which would allow me to use both smooth and angular shapes as I see fit.

Whether or not to use OpenCL is also a big decision to make.

Look around in wonder

Got the mouse-look working, more-or-less. I can now fly around in Cyclopean.

I had to lock the mouse to the center of the window somehow. I could not find any advice on how to do this in Java, but fortunately it does have the functionality.

I used a MouseListener to catch the mouse movement events as usual, a ComponentListener to discover when the window was moved, and a Robot to move the mouse cursor to the center of the GLCanvas each time the mouse moved. The amount that the mouse moved is just the difference between its position and the center of the GLCanvas.

These mouse movements are accumulated over the gameplay/physics frame and the total used to rotate the player's viewpoint when the gameplay frame is processed. This is necessary since the gameplay and mouse are handled in separate threads. Each keyboard event also has its own thread and the graphics renderer as well. When I implement streamed loading of the world, this will also have its own thread.

I considered making this game multiplayer-capable, but real-time games aren't really suited to this; both latency and lag have always been significant in my experience.

Going Faster

I have been working on Cyclopean again.

I have modified the texture loader to be compatible with OpenGL 1.1, and to use direct buffers for sending the texture data to OpenGL. The compatibility issues were caused by my use of GL_UNSIGNED_INT_8_8_8_8_REV as the data type parameter. GL_UNSIGNED_BYTE works just as well, even though the buffer is an IntBuffer.

The process for creating a Vertex Buffer Object from map data now also uses a direct buffer, and I fixed a problem in the calculation of the size of the buffer, so there are no weird gigantic intermittent polygons anymore.

The rendering speed has increased dramatically now that everything is working right, so I am considering using a variant of this renderer for Nation Builder, instead of my shader-heavy normal-mapped high-detail 2-D renderer. The problem with the 2-D renderer is that it will take a lot of time to create good images for all the objects and creatures, and I just don't have the resources for that. Even if I decide to still use the 2-D renderer, I will have to downgrade the images to pixel-art level for practicality and remove the then-no-longer-needed shader programs.

Got my texture on

Seems the texture wasn't working because the video memory was full. Rebooting cleared it right up. I added a placeholder for the lighting.

Clearly, I need to work on the memory cleanup next.

Many many cubes

Finally got the Cyclopean Engine's renderer fast enough for usage. Now I need to get the texture working.

When I was playing Minecraft the other day, I realized the potential for this kind of engine. It would be a bit stupid if Minecraft and Infiniminer were the only games to ever use it, or if everyone had to write their own. (It is trickier than one would think.) So, I decided to make my own engine, which will be free to use and probably open source (eventually), and my own game with that engine.

The name Cyclopean Engine refers to cyclopean architecture, which is when a building is constructed from huge stone blocks, usually made to fit neatly together. The game will probably be called Cyclopean Adventures, and will have some Lovecraft-style horror in it if I can manage that.

While most of the game world will be strictly Cartesian and/or Euclidean, I programmed it with see-through portals in mind, so it will be possible to have areas linked in impossible ways by invisible portals you might not notice, deviating from Cartesian and Euclidean concepts of space. For instance, a mysterious house might be larger on the inside than the outside, and breaking though a certain wall could lead you to a different universe.

I could even make one side of the portal larger than the other, so that objects can change size when passing through, although building stuff will make even less sense then.

By the way, the zone which is rendered consists of 262144 cubes, but it only renders the possibly-visible surfaces, which is why it is fast. If one were to fill the zone with a checkerboard pattern of translucent cubes, it could become very slow indeed.