Rework rendering logic and code to increase efficiency when player transgresses landscape cells

As a refresher, the game world stored server-side is divided into cells which are 32x32 tiles each. One tile is 128x128 pixels and represents one square foot. The client is only aware of a 3x3 grid of cells at any given time, with the player always located in the center cell. This area represents a 96x96 foot squared area of the game world.

Previously what is now called the “tile grid” was called the “cell grid” and was a full-resolution image buffer of the entire 9x9 cell cell grid (12288x12288 pixels). When the player crossed from the center cell into an adjacent cell, the cell grid buffer had to be shifted an entire cell in any of eight directions. Due to the inefficiency of this operation (5+ second lag) it was required that the rendering engine be redesigned so that such large image blits (transfers) were not required.

Another consideration was the amount of memory consumed by maintaining such large images, which would prove significant should the game client be ported to other platforms in the future (game consoles, portable devices, etc.).

To achieve this I decided to discard the cell grid buffer and instead use what I call the tile grid buffer. It is essentially a smaller version of the cell grid buffer, just large enough to overlap the render window by a few tiles in each direction. The buffer is updated every time the player transgresses a tile, rather than every time the player transgresses a cell. If the player moves north and crosses over a tile, the tile grid buffer if shifted south one tile and a new row of tiles is drawn on the north edge of the tile grid buffer.

Items that were improved as a side effect of the rendering engine rewrite

The client now supports completely arbitrary full-screen and windowed resolutions, automatically adjusting at run time the tile grid width and height to what is appropriate to the specified resolution. Now you can run the game in a small 640x480 window, full screen at 1920x1080 (1080p), or whatever crazy screen resolution your computer setup may require.

Items that worked previously but are now slightly broken

An unfortunate side effect of the engine rewrite is that a small lag (100 – 250 ms) was introduced every time the player transgresses a tile. The lag that occurred when transgressing a cell, however, was virtually non-existent. Work is currently being performed to minimize the lag when transgressing tiles.

The proper display of elevation hill shading and the water layer are no longer working correctly due to the rendering engine redesign.

Further modify the camera algorithm to be more natural

Since the “camera” which determines what part of the tile grid to render to the render window is detached from the player's position, I also further refined the camera movement algorithm so that it speeds up and slows down realistically as it follows the player.

Draw the player's avatar (graphical representation) on the landscape

The player is now graphically represented on the landscape, so you can see yourself move around when using the gamepad. Currently player movement physics have not been implemented, though it's awesome to see your character move around and the camera try to keep up with him.

Improve techniques for creating seamless megatextures for landscape layers

I discovered a GIMP plugin called Resynthesizer and successfully tested it in creating a new seamless texture for one of the vegetation landscape layers. Will probably use it in the future to create new versions of the other landscape layer megatextures.

Miscellaneous

Server module variable for storing players' positions was an integer datatype when it needed to be a floating point datatype, which caused updated player positions to be rounded and the client and server to become out of sync. Problem was fixed and extensively tested by flailing the hell out of the gamepad for extended periods of time and comparing the client and server player position values.

Several other bugs were fixed but I can't remember what they were.

Experiemented with the imlib component of GAMBAS 3 (gb3), creating a frames per second test app to compare rendering efficiency with the normal gb3 image component. Imlib proved to be anywhere from 8.5 to 35+ times faster, which is incredible. Attempted to implement the library in code but experienced a bug which I reported to Benoit Minisini (lead dev of GAMBAS) for correction. He hasn't yet responded to it, but hopefully will as using that component should greatly increase the frame rate of the rendering engine.

Contributed about $68 (50 EURO) to Benoit Minisini via PayPal to encourage him to fix the damn bug in the imlib component.