Category Archives: code

A picture of things to come…

Posted on by

…maybe.
It’s still very early work in progress, despite being in development for 1.5 years. I easily get tangled up in technical engine stuff so there’s not much of an actual game yet, although there are other games you can play, such as mobile slots you can find online, which are really great to play and make money online.

The engine procedurally generates isometric tiles and renders them to textures. The actual engine is entirely in 2d, although for various effects, pseudo-3d information is calculated.

My vision for this is to become a single player RPG mixing elements from old-school JRPGs, WOW and Diablo, while trying not to focus too much on combat but story and exploration instead.

If the engine turns out to be flexible enough, I’d love to develop this into some sort of platform for further stories taking place in the same universe.

The engine so far is written entirely in c++, features a Lua interface for everything game-related and relies on SDL / OpenGL for rendering.

powered by

 

Fragmented Images

Posted on by

Proposal for a new image format (container)

In addition to several MIP-levels, the image file contains a matrix of fixed-size sub-images for each MIP-level (e.g. 1024x1024px).

Each sub-image has a set of coordinates/indexes attached to it so that the original image can easily be reconstructed by stitching the sub-images together.grid

The MIP-based file format will have to be altered slightly: Instead of a simple JPG-compressed MIP-level, a tiled image would have to be stored.

Since every MIP-level is only half the size of its previous level, the number of tiles will be reduced by a factor of 4 in each step.

The file header now consisting of a simple offset map would have to be extended to store the intra-MIP offsets for each tile in addition to the MIP-level offset.

Why all the effort?

if the user zooms in on a large image (several megapixels), decoding of the next higher res MIP-level takes a lot of time.

Current screens only have resolutions of 2-3 megapixels, meaning the full image is never visible, so decoding the whole image is a waste of memory and time. A simple grid-based visibility test would quickly yield which tiles are actually visible and which are hidden from view. Only the (partially) visible ones would have to send a load request to the image loader thread, greatly reducing decoding time and memory consumption.

The overhead

instead of reading just one offset and jumping directly to the data, the image loader thread will have to read two offsets.

The first offset value is necessary to jump to the MIP-level internal offset table describing the offset for each image tile.

The second offset value is necessary to jump from the MIP-level offset table directly to the tile data.

Each data request now consists of two offset lookups instead of just one, but considering the significant reduction in the amount of data actually read from the file, the overhead is neglectable.

Continue reading →

groups

Posted on by

A group is a simple rectangular area that has a title and contains several items.

New groups can be added by using the API function ‘addGroup(const QString& sGroupName)’ and populated by calling the group’s method ‘addItem()’ or ‘addItems()’.

If a group should be created that is to wrap exisiting items without destroying their layout, an overloaded API function ‘addGroup(const QString& sName, std::vector<CItem*>& vpItems)’ will create a new group and place it around the selected items, forming their bounding box.

If a group is moved, all its contained items will be moved accordingly.

Deletion of a group will result in the deletion of the items.

Ungrouping will delete the group but not its contents.

Continue reading →

Retrieving and storing EXIF information

Posted on by

using easyexif (http://code.google.com/p/easyexif/), each item should store an instance of its exif information that is re-loaded upon passing an image into the item.

This enables the sort plugin to add new sort functions for each of the exif properties, such as

  • sort by date taken
  • sort by geolocation (possibility of rendering an svg background displaying all the continents)
  • etc.

Continue reading →

swap pointer safety

Posted on by

The swap pointer should be NULLed after being fetched by another thread. The getter function should get a mutex that protects the pointer while being NULLed. After the swap has occurred in the fetcher-thread, the pointer can be written back to the item. This guarantees that no other thread accesses the current swap pointer while one of the cache threads writes new image data.