NOGDUS $1670.00 has been donated to NOGDUS!
May 28, 2017, 08:58:44 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 12141 times)
0 Members and 1 Guest are viewing this topic.
Mattias Gustavsson
Moderator
Offline Offline

Respect: 58
« Reply #15 on: April 21, 2011, 02:22:16 PM »

Oh, and one more thing:

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.

Yeah, I'd be happy to share the source of what I have so far - but I'm not sure how useful it would be, as I just barely started - I only have one gamestate for walking around - so it's not even a game yet, just a simple walk-around demo. But let me know if you'd like to have a look anyway, and I'll dig out the source.

Oh, and one more thing about the RLE8 format - when blitting them, you may specify a colour, which it modulates the bitmap with, which is useful for making things darker far away. But the nice thing is, that since RLE8 bitmaps are palettised, I only need to modulate the colours of the palette into a temporary palette, rather than having to modulate each pixel - so at most it will darken 256 colours, and then blit the actual bitmap the same way as if it was unmodulated, but using the modulated palette - which is great for speed Cheesy
Logged
Cycl0ne
Guest
« Reply #16 on: April 21, 2011, 06:27:09 PM »

Wow that sounds really cool, since i need to darken the sprites the farer they are away. Where it wont help me, is to darken the whole DungeonView, since it is already blittet. i will use the transission code perhaps for this effect Wink
Logged
Mattias Gustavsson
Moderator
Offline Offline

Respect: 58
« Reply #17 on: April 22, 2011, 05:09:48 AM »

Hmm, wouldn't you be able to use this to darken anything? I mean, when you're blitting the dungeon view, you could just modulate each blit?
Logged
Cycl0ne
Guest
« Reply #18 on: April 22, 2011, 12:20:33 PM »

Yes could be an Idea, a friend of mine said, i should try to blit a black screen and alphablend it.
Logged
Mattias Gustavsson
Moderator
Offline Offline

Respect: 58
« Reply #19 on: April 22, 2011, 01:54:21 PM »

Well, alphablending in software is slow, so I wouldn't recommend it... But what I was thinking is, that for each bitmap you blit, you give it the right value to modulate with? That way, you'd be able to use the fast way for modulate for everything on screen, even the view of the dungeon (as each bit of the dungeon gets modulated when you blit it...)
Logged
Cycl0ne
Guest
« Reply #20 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? 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;
}
Logged
Mattias Gustavsson
Moderator
Offline Offline

Respect: 58
« Reply #21 on: April 23, 2011, 04:06:34 AM »

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...

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...

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 Cheesy


Does this make sense at all, or am I missing something here?
Logged
Cycl0ne
Guest
« Reply #22 on: April 23, 2011, 05:13:10 AM »

Yes and no. Smiley
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 Wink
Logged
Cycl0ne
Guest
« Reply #23 on: April 23, 2011, 06:48:43 PM »

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

Respect: 58
« Reply #24 on: April 24, 2011, 01:00:28 AM »

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 :-)
Logged
Cycl0ne
Guest
« Reply #25 on: April 24, 2011, 01:24:30 AM »

Im redrawing the whole screen, but, since im using transparency it looks like this without a clear():


its because the black in the distance is not a sprite Smiley so im nearly ready to implement darkening. my gfx artist needs a new version of the drawing engine for sprite testing, i just have to build a new one with 1280x800 today :-P but after that.....

the wiki server is also ready. SVN is installed. im still thinking between : Trac or MediaWiki+SVN Plugin. I will have to see.
Logged
Mattias Gustavsson
Moderator
Offline Offline

Respect: 58
« Reply #26 on: April 24, 2011, 02:46:14 AM »

Ah, I see - yes, you'd need to clear in that case. But you could probably get away with just creating a black Rectangle covering only the part of the screen that needs to be cleared, which I guess would be this:



That way, you avoid clearing pixels which you will later redraw anyway :-)
Logged
Cycl0ne
Guest
« Reply #27 on: April 24, 2011, 04:24:44 AM »

Yup i did that for performance. only the small recatngle is now cleared.
Logged
Richard Marks
Administrator
Offline Offline

Respect: 3425
« Reply #28 on: April 24, 2011, 04:26:38 AM »

the wiki server is also ready. SVN is installed. im still thinking between : Trac or MediaWiki+SVN Plugin. I will have to see.

Trac is the better of the two.
My personal preference is to use the git plugin for Trac. I hate SVN with a passion.
Logged

Cycl0ne
Guest
« Reply #29 on: April 24, 2011, 12:15:07 PM »

hmm im still thinking... trac is good for development. but what pixie needs is more on information/documentation. I would like to see somthing like an online documentation which clearly describes every piece of this engine.
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!