NOGDUS $1670.00 has been donated to NOGDUS!
August 23, 2017, 08:04:54 PM *
Welcome, Guest. Please login or register.

Login with username, password and session length
 
   Home   Help Search Login Register  
Pages: [1] 2 3   Go Down
  Print  
Author Topic: Setting a transparent color in Pixie  (Read 12882 times)
0 Members and 1 Guest are viewing this topic.
Cycl0ne
Guest
« on: April 12, 2011, 10:16:25 AM »

Hi,

its me again, while fiddling around, i stumbled upon the following problem. How do I set a color to be transparent? At first I thought it could be done with SetColor() but this will completly draw the sprite/image in this color ;-)

Any Ideas?
Logged
Cycl0ne
Guest
« Reply #1 on: April 12, 2011, 10:41:30 AM »

Ohh and while i am at it. is it possible to:

Flip Sprites (draw them mirrored x or mirrored y)
Crop Sprites (draw only parts of the sprite)
Size Sprites (draw them smaller or bigger)

?
Logged
Cycl0ne
Guest
« Reply #2 on: April 12, 2011, 12:57:54 PM »

Ok i found it perhaps. The Sprite Class cant do the job, so i implemented a "Bob" Class (Blitter OBject):

Code:
#include "Pixie.h"

class Bob:public Sprite
{
public:
Bob();
Bob(SpriteManager* spriteManager);
virtual ~Bob();
virtual void SetSize(float x1, float y1, float x2, float y2);

private:
virtual void Render(Bitmap& bitmap);

private:
float x1_, y1_;
float x2_, y2_;
};

Code:
#include "Bob.h"

Bob::Bob(): x1_(-1),y1_(-1), x2_(-1), y2_(-1)
{
}

Bob::Bob(SpriteManager* spriteManager):Sprite(spriteManager),x1_(-1),y1_(-1), x2_(-1), y2_(-1)
{
}

Bob::~Bob()
{
}

void Bob::SetSize(float x1, float y1, float x2, float y2)
{
x1_ = x1;
y1_ = y1;
x2_ = x2;
y2_ = y2;
}

void Bob::Render(Bitmap& bitmap)
{
if (IsVisible())
{
if (x1_<0 && x2_<0 && y1_<0 && y2_ <0)
{
GetBitmap().Blit((int)GetCel(),bitmap,(int)(GetX()-GetOriginX()),(int)(GetY()-GetOriginY()),GetColor(),GetAlpha());
} else
{
GetBitmap().Blit((int)GetCel(), (int)x1_, (int)y1_, (int)x2_, (int)y2_, bitmap,(int)(GetX()-GetOriginX()),(int)(GetY()-GetOriginY()),GetColor(),GetAlpha());
}
}
}

I will extend this class to do some Flipping too. Only "Resizing" seems to be not implemented in the bitmap class.....
Logged
Mattias Gustavsson
Moderator
Offline Offline

Respect: 58
« Reply #3 on: April 12, 2011, 01:21:13 PM »

Ha, I haven't really needed to be able to crop sprites, so I guess that's why that functionality is missing... It should probable be added, but on the other hand, your "Bob" class is just as good a solution - In Pixie, it is meant to be easy to extend the system with your own Sprite types. Maybe I should work the cropping code into the next release of Pixie... what do you think? Just out of curiosity, what do you need it for?  Smiley

To make a sprite semi-transparent, you simply need to call SetAlpha. The reason for this is that colours are 16 bits in Pixie, and thus there's no room for an alpha (transparency) component, which is why it has a separate function.

There's currently no way of doing scaling or rotation of sprites. This is quite a limitation, but as I didn't need it at the time, I didn't get around to adding this, as it is quite a non-trivial problem to do efficiently in a software blitter. However, I have plans to add systems for this to the next version of Pixie. A preview can be seen in the project here: http://ccpssolutions.com/nogdusforums/index.php?topic=705.0

The new version is still some way off, so if someone needs the code I have so far, just let me know and I'll share it - but it's not at all integrated to the sprite system properly yet.

Another addition to go into the new release is support for transforms on RLE bitmaps (flip, mirror etc), including easy ways to add custom transforms, as well as support for multiple blending modes (add, multiply, subtract etc), including easy ways to set up custom blend modes. Again, this code is not finished, but I'm happy to supply previews if someone is specifically interested - but it's not quite ready to be used in an actual game yet.

Logged
Cycl0ne
Guest
« Reply #4 on: April 12, 2011, 01:31:35 PM »

Ok great to hear.

I need the "Crop" Functions for a small game i write to understand pixie completly. it has a door sprite, which need to slide to the right/left to open (or up). I know i could use lots of sprites for this as an animation. but i was too lazy and thought the pcu could calculate it for me.

Same goes for the scaling. The door sprites need to be scaled from small to big as the player approaches the door.

and to be even more lazier: I want to take only one sprite for the door and mirror it for the other side. And here comes my next question:
I extended the blit function in the Bob Class to:

Code:
GetBitmap().Blit((int)GetCel(), (int)x1_, (int)y1_, (int)x2_, (int)y2_, bitmap,(int)(GetX()-GetOriginX()),(int)(GetY()-GetOriginY()),GetColor(),GetAlpha(), Bitmap::Mirror_Y);

But this doenst work? Havent you properly implemented this transformation?

As far as I can see these two things: Mirroring and Scaling are the only things I need in my small game which seems to be missing ;-)
Logged
Cycl0ne
Guest
« Reply #5 on: April 12, 2011, 01:36:26 PM »

Quote
To make a sprite semi-transparent, you simply need to call SetAlpha. The reason for this is that colours are 16 bits in Pixie, and thus there's no room for an alpha (transparency) component, which is why it has a separate function.

Ohh you dindt get me on this. I dont want the whole sprite to be transparent. I want to select one color to be transparent.
I know, that i can select with irfanview (saving it as a png file) to select a transparent pixel. And that pixie recognizes this. But what should i do, if i would like to change this transparent pixel on the fly? In SDL you have the Function: SDL_SetColorKey(); With this you can say, that one special kind of color is transparent for the Sprite.
Logged
Mattias Gustavsson
Moderator
Offline Offline

Respect: 58
« Reply #6 on: April 18, 2011, 12:58:31 PM »

Hmm, using transformations should work with the current code... Mirror_Y should flip the sprite upside down. But it won't work if the bitmap type is any of the RLE formats (but again, next version of pixie will have support for transforms even on RLE bitmaps).

Ah, ok, I hear you on the colour key issue. The reason I don't support color keys, is mostly for efficiency reasons - to do blitting with a colour key means doing a comparison for each pixel. On the other hand, using an alpha channel and .PIX files in RLE format, means that empty pixels will just be skipped - so it will in fact be faster than blitting non-compressed files.

If I were to add colour key support, I would actually add it to PixiePCT, the picture conversion tool, as an option to automatically generate an alpha channel from the specified colour...
Logged
Cycl0ne
Guest
« Reply #7 on: April 19, 2011, 06:56:06 AM »

MIRROR_Y didnt work.. because it was an RLE .. correct ;-)

Hmm, so you tell me, if i work through the sprite bitmap and set every pixel i find, i wish to be transparent, in the alphachannel, this should work?

then this would be a very easy "colorkey" implementation or?
Logged
Mattias Gustavsson
Moderator
Offline Offline

Respect: 58
« Reply #8 on: April 19, 2011, 08:18:24 AM »

yes, that should definitely work - but if you put it into the code which generates RLE files, and use them, it will be much faster (but if you don't use many sprites, that's not a problem)
Logged
Cycl0ne
Guest
« Reply #9 on: April 19, 2011, 01:01:42 PM »

Hmm, the problem is, that i have a special sprite with two transparent colors. At first i need to blit it to a wall or door sprite with the outer transparent color set. after that i need to blit both with the inner transparent color to the screen to "see" whats behind it. Thats the "look through wall/door" spell.

To be honest, im working on a Clone of Dungeon Master with new Graphics for mobile devices as tablets in 1280x800x16. Here are some graphics from my gfx artist:



I think this is a perfect game for tablets/mobile devices and pixie is great for developing under windows and porting it to android.
Logged
Mattias Gustavsson
Moderator
Offline Offline

Respect: 58
« Reply #10 on: April 19, 2011, 02:35:02 PM »

Hey, that's a *very* cool project Cheesy 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 Cheesy

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 Cheesy

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 Cheesy
Logged
Cycl0ne
Guest
« Reply #11 on: April 19, 2011, 05:18:27 PM »

Im enlisted in the Forum too Smiley 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 Smiley

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 ;-)
Logged
Mattias Gustavsson
Moderator
Offline Offline

Respect: 58
« Reply #12 on: April 21, 2011, 02:15:58 AM »

Ah, ok, I'm with you now Cheesy

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:
http://colossusentertainment.com/forumref/PixiePCT_colorkey.zip
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 :-)
Logged
Cycl0ne
Guest
« Reply #13 on: April 21, 2011, 02:58:37 AM »

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.

Logged
Mattias Gustavsson
Moderator
Offline Offline

Respect: 58
« Reply #14 on: April 21, 2011, 02:12:57 PM »

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 Tongue 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 :-)
Logged
Tags:
Pages: [1] 2 3   Go Up
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines
.: Theme by Richard Marks :.
Valid XHTML 1.0! Valid CSS!