Journal

New Posts & Thoughts

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 →

watching the clipboard

Posted on by

upon firing up the application, a clipoard watch could be initiated.

This would lead to watching for changes in the clipboard, allowing the application to grab any link to images that are copied, and open them directly inside the application.

This behaviour would have to be configurable in the application settings dialog.

startup-performance

Posted on by

In order to increase startup-performance, a database of preview-images could be saved into a single file.

This would eliminate the need for having to access n files for their preview-data. File-access overhead for thousands of files is significant and greatly impacts the startup-performance of the application.

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 →