Setting a transparent color in Pixie

<< < (3/8) > >>

Mattias Gustavsson:
Hey, that's a *very* cool project :D I've always been a big fan of Dungeon Master, since playing the original on my Atari ST back in the 80:s. A while back, I even started on my own clone using Pixie, but I've stopped working on it for now - I have some other games I want to make first :D

Btw, you should check out the Dungeon Master forums - it's full of people who love the game, still play the game and make clones of the game :D

I'm still not sure what you mean with the inner/outer transparent colours... but please, do post an example of what you want to achieve, and I'll be happy to advice on a suitable approach within Pixie - I find these sort of problems very interesting, as it helps me to develop the engine to be more useful for more scenarios :D

Im enlisted in the Forum too :) In the Developer Area you can see my progress on developing the game under android. HAd a really cool engine in java until i got to the point to make the GFX  darker (torchlight and distance from player) .. so i had to darken each color in the bitmap. From 25fps on my HTC Desire Framerate dropped to 2FPS, since in java doing this:

for(pixel in bitmap)
bitmap[pixel] = darkenpixel(bitmap[pixel]);

is very costly in the android java engine since arrays in java are not directly the memory and also boundary checking is done and and and....

Guess what, from the dungeon master forum, i got notice of your clone. This is how i landed at pixie ;-) What would be nice, do you mind doing a screenshot of your source files form your clone? or even publish it? I would be very interessted how you split up the gamestates.

From my "first" aspect, i needed the following functions in pixie:
- Mirror RLE Sprites in X and Y
- Resize RLE Sprites

But after a thought, i just created more on harddisk and resized and mirrored them ;-)

For the Example look at this:
This is the Wall:

This is the "see through wall" sprite:

as you can see the "see through wall" has two transperency. The black in the outside and the pink in the inside.

at first i have to create a temporary buffer where i blit the wall, then i blit the hole image ontop and then i blit into the screen the temporary buffer with the pink as the transparent part.

i cant make both transparent in the beginning otherwise one couldnt see through the hole :)

The same problem occurs with "bashed" doors. One bitmap descriped the door, the other describes a 2 colored mask: the middle which is now transparent, as the door is bashed and the outer for thelook of the original door. See here:

and also here a special mask for the door look through:

while im typing it, i think of precalculating this with photoshop to a new sprite set. so it wont be needed as a function.. :-P

so a new PCT with an option telling which color is transparent would be nice ;-)

Mattias Gustavsson:
Ah, ok, I'm with you now :D

Well, for a case like that, I would definitely condsider combining the see-through/bashed masks with each image they can go on top of - it might mean more bitmaps, but it will mean that they can be stored in RLE8 format, which means it will be both smaller and much faster to render.

I can't stress enough how beneficial it is to use the RLE8 format. To give you an idea how it works, here's some detail on what it is actually doing:
When you run PixiePCT with the option -rle8, the first thing it does is reduce the colours of the bitmap to 256 (8-bit) and using a 16-bit colour space (this is done using the median cut algorithm, which gives very nice results - comparable to the pro art packages). For most bitmaps, you won't see much of a difference, since each individual bitmap will get its own 256-colour palette. If you find that some bitmaps get a bit too much banding, you can add the -dither flag, which will do floyd-steinberg dithering on the image, giving it somewhat smoother colour transitions.
Next, the PCT tool takes the palettised image, and compress it using RLE compression. This means that instead of storing a pixel per byte, it stores a byte for a count, followed by a byte for the colour - so if you have 12 pixels in a row that are all the same colour, it will store 12 and then the color index. Or, if there's a stretch of pixels where each one is different from the next, it stores one byte for count followed by a byte per pixel (basically storing that run uncompressed).

The nice thing though, is when rendering these RLE bitmaps - they are not decompressed on load, they are stored in RLE form (which means they take less memory), and blitting is done directly from the RLE format. This means, that for a run of pixels, one can do a pretty efficient straight fill of pixels, but more importantly, that any transparent pixels are not processed at all - they simply end up as a adding a value to the destination pointer, making it very efficient.

The actual RLE format is actually a bit more complex - for images that have an alpha channel with varying levels of transparency, it will make two different RLE streams, one for fully opaque pixels, and one for semi-transparent pixels, to make the blitting of each type as efficient as it can be, and avoid expensive test-and-branch in the inner loop.

RLE compressed images are by far the most efficient way of both storing and rendering bitmaps - have a play around with it if you want to get a feel for the difference they make.

Also, I thought I'd point out PixView, a picture viewer included with PIXIE which will display PIX files (including RLE bitmaps), and allow you to cycle through all images in a directory using SPACE and BACKSPACE - On my system, I've associated PIX files with PixView, which makes things quite easy :-) Also, PixView will display animated PIX files (such as you would get by making a "strip" using PixiePCT - bitmapstrips are the easiest way in Pixie to handle animations, as you'll be able to just call SetCel on a sprite to make it animate).

Btw, I made a quick update to the PixiePCT tool - you can download it here:
This new version will allow you to add a colorkey flag to the command line, to automatically make a specified colour transparent at conversion time - use it like this:
PixiePCT -rle8 -colorkey=FF00FF myBitmap.png

And any questions or problems, just let me know :-)

Thanks for the support.
the graphics i showed are the original graphics. i will have to see how the rle8 will work with my graphics from my gfx artist. He is pushing all graphics from 320x200 to 1280x800 and from 16 colors (as the examples) to 16bit. I will have to see how it fits with rle8.

Ok now i have a question about the size. I found the following:
PNG 11Kb
RLE8 54Kb

Now what im thinking about:
- Create all Images mirrored
- or do a mirror blit, when pixie 1.0 arrives

When i creeate all images mirrored, im considering space as crucial. Does your AssetManager (ArchiveManager) also compress the whole package? Because, when i run Winzip/Winrar over the RLE8 Images the size is shrinking incredible.

Mattias Gustavsson:
When comparing image sizes, it's worth noting that PNG images are stored in a compressed form, but they are decompressed at load time, as you can't blit straight from their compressed form. As pixie RLE images are not decompressed at load time, they will take less memory than the decompressed PNG equivalent.

If you zip the PIX files up, they should become significantly smaller - and in fact, PNG files use a similar, if not identical, compression algorithm as zip files. Currently, the pixie archive format doesn't support compression - I've never needed it, since I always zip my stuff up, and storage space on PC is not exactly limited :P I could see why you'd like to have compression on a mobile device though. It should certainly be possible, maybe even quite easy, to add compression to the archive system though - especially as I already have ZLIB in there (as it is needed by the PNG decoder). In fact, I make use of it in my application Poser Content Manager, to compress and decompress datafiles.

To add compression, all that should be needed is to add compression code to the archive generation tool, PixieAGT, and then add decompression when assets are loaded in PIXIEs asset system. I'm happy to give more pointers if you decide you need to add this - and depending on when it is needed, I might even be able to add it myself :-)


[0] Message Index

[#] Next page

[*] Previous page