Setting a transparent color in Pixie

<< < (5/8) > >>

Cycl0ne:
Ill have to try. At the moment im fiddling with the original graphics around to see how thinks could work best until the new graphics are finished (around november or so). but do you think it is so slow? In Java i did something like this in the graphics drawing routine:

if (dirtyflag) drawnewdungeonscreen();
else drawdungeonbuffer();

i seperated everything on screen into smaller "screens" only updating those, which got dirty. the dungeonview can only get dirty by two things:
- Monster AI moving (i think ai was set to move every 1 sek)
- Player moving.

so you should get a decent frame per seconds, since you draw often the buffered image.

The dungeonview itself (which gets darkend) is 896*544. its gets darken by 6 steps down. 100% = normal light, 16.6% with every step.

when using the modulate way, how am i going to calculate the right color for the blit?

here is the example i done for the distance blitting in the java code as c example:

Code:

ui32 distance_lighting(ui32 col,i16 distance)
{
  ui32 ret;
  i16 r,g,b;
  if (col == MASKCOLOR)
    ret = col;
  else
  {
    r = getr32(col);
    g = getg32(col);
    b = getb32(col);
    switch (distance)
    {
      case -1:
      case 0:
        ret = col;
      break;
      case 1:
        r = MAX(0,r-20); g = MAX(0,g-20); b = MAX(0,b-20);
      break;
      case 2:
        r = MAX(0,r-40); g = MAX(0,g-40); b = MAX(0,b-40);
      break;
      case 3:
        r = MAX(0,r-50); g = MAX(0,g-50); b = MAX(0,b-50);
      break;
    }
    ret = makecol32(r,g,b);
  }
  return ret;
}

Mattias Gustavsson:
Quote from: Cycl0ne on April 22, 2011, 05:48:01 PM

Ill have to try. At the moment im fiddling with the original graphics around to see how thinks could work best until the new graphics are finished (around november or so). but do you think it is so slow?

Well, doing alpha-blending in software is quite slow - you need to calculate the inverse of the alpha value, read the original colour value, multiply it with alpha, multiply the colour you're blending with the inverse alpha, add the two together, scale it back to the right range, and write it back to the original location. That's a lot of operations to do per pixel, so that's why I wouldn't recommend using an alpha-blended blit to darken the screen...

Quote from: Cycl0ne on April 22, 2011, 05:48:01 PM

In Java i did something like this in the graphics drawing routine:

if (dirtyflag) drawnewdungeonscreen();
else drawdungeonbuffer();

i seperated everything on screen into smaller "screens" only updating those, which got dirty.

I know some people get good results using some sort of "dirty rects" scheme, but I usually don't bother with it - it makes things more complicated, and for the kind of things I've been doing so far, it seems that more often than not, I end up redrawing most tiles all the time anyway, because of things changing on screen. So I tend to just redraw everything every frame, but try to make that drawing as efficient as possible. But since you're working on different hardware, the rules you have to play by is probably different...

Quote from: Cycl0ne on April 22, 2011, 05:48:01 PM

The dungeonview itself (which gets darkend) is 896*544. its gets darken by 6 steps down. 100% = normal light, 16.6% with every step.

when using the modulate way, how am i going to calculate the right color for the blit?

here is the example i done for the distance blitting in the java code as c example:

Hmm, I'm not quite sure how you're using this... Is this function called per pixel to darken things?

What I was thinking, is that if we take an example where you're drawing a long wall going into the screen... in that case, I would draw it using 6 draw calls, not just one. Where each draw call would use a different modulate value, depending on the distance. The modulate value passed to the blit would just be:

Code:

unsigned short modulate = RGB32TO16( distance_lighting( 0xffffff, distance ) );


Basically, just running your existing lighting calculation on a white colour, with the appropriate distance, and then converting it to a 16-bit colour using one of the Pixie conversion functions. This value is then sent along with the blit and, assuming it is an RLE8 image, each colour of its palette will be multiplied by the value, and then used for the blit - nice and efficient, as it will be, at most, 256 values being multiplied :D


Does this make sense at all, or am I missing something here?

Cycl0ne:
Yes and no. :)
Ok sorry.. the function i gave was for the new color of items and their distance lying away from me. :-) and yes it is in a loop with (for all pixel do this).

for the "dungeon" gets darker, im not sure if this would work too. Since the walls are precalculated sprites. so all walls dran in position 2 are allready darker than on position 1 and 3 at its darkest (this is why i had to use such a function in java, because the items sprites on floor are not precalculated).

ill give it a try with the original graphics and see what happens ;)

Cycl0ne:
Ok i builded the rendering engine now. I will see how it will work with the color set to darken the map.

another question i have. how to i "clear" the screen from GameState? I did a workaround and made a screen.clear() in main before sprite update. But there has to be a cleaner way or?

Mattias Gustavsson:
First of all, if you draw on the whole screen, you might not even need a clear, as you'd overwrite everything anyway. But if you do need a clear, the easiest way is to create a Rectangle object. This is a type of sprite, which draws a solid or transparent colour as specified, so if you make one which is solid black and the same size as your screen, then it will in fact use the screen.Clear() call. So create a fullscreen Rectangle instance and place it behind all your other sprites :-)

Navigation

[0] Message Index

[#] Next page

[*] Previous page