Language: 
To browser these website, it's necessary to store cookies on your computer.
The cookies contain no personal information, they are required for program control.
  the storage of cookies while browsing this website, on Login and Register.

Author Topic:  xray  (Read 180 times)

0 Members and 1 Guest are viewing this topic.

Dolfo

« on: 12, March 2024, 14:49:01 »
Our current grey scale on xray is pain. No player like this. Its killing eyes.

We can change this very easy in client, sprite.c, grey_scale(). We also loop and get/set each pixel for that mode. A lot of extra client processing. I tried another formula from web, but it feels same bad for eyes. Removing the grey manipulation instead, leads to a clean color with full light. From player site, that feels great.
Code: [Select]
    for (k=0;k<temp->h;k++)
    {
        for (j=0;j<temp->w;j++)
        {
            SDL_GetRGBA(getpixel(temp,j,k),temp->format,&r, &g, &b, &a);
            //r = g = b = (int) (0.212671 * r + 0.715160 * g + 0.072169 * b);
            //r = g = b = (int) (0.299 * r + 0.587 * g + 0.114 * b);
            putpixel(temp,j,k,SDL_MapRGBA(temp->format, r, g, b,a));
        }
    }
Do we need this greyscale or we try different like more red in? But could be we end same, with a view, killing players eyes?

Alternate we can try a kind of toggle option in client, where players can decide, if they want this grey. But I think coding this leads only to: experienced players toogle this always off, where new players still run around with this curse.
« Last Edit: 12, March 2024, 22:12:23 by Dolfo »
Don't believe the shit, you hear in mainstream. Believe your own body. Your body is speaking always the true to you. But you need to understand your body. Hear to your body, not to your ego. And when body is calling to you: "Hey something is wrong!" find the reason(s) for that. Man in White don't go for that, they don't want to heal you. They want earn money and sell you medicine, you should take rest of your life. You are not the patient, you are their customer. Never forget this!

_people_

« Reply #1 on: 13, March 2024, 00:46:43 »
Another option could be to do something like slightly desaturate the color of sprites which are visible only due to X-ray vision. That would require a small server change but as of 0.11.0 we now have room in the map view packet for more graphical flags.
-- _people_ :)

Dolfo

« Reply #2 on: 13, March 2024, 11:26:21 »
I tried to desaturate the colors client sided.
Code: [Select]
    float f = 0.2f; // desaturate by 20%
    float L;
    for (k=0;k<temp->h;k++)
    {
        for (j=0;j<temp->w;j++)
        {
            SDL_GetRGBA(getpixel(temp,j,k),temp->format,&r, &g, &b, &a);
            L = 0.3 * r + 0.6 * g + 0.1 * b;
            r = r + f * (L - r);
            g = g + f * (L - g);
            b = b + f * (L - b);

            //r = g = b = (int) (0.212671 * r + 0.715160 * g + 0.072169 * b);
            //r = g = b = (int) (0.299 * r + 0.587 * g + 0.114 * b);
            putpixel(temp,j,k,SDL_MapRGBA(temp->format, r, g, b,a));
        }
    }
If we want to desaturate instead of greyscale, we need to find a good percentage value.
20% is very close to normal view at full day light
50% was ok
80% is very close to greyscale, starting to "eyekill"
so perhaps 50% or a little higher?

Yes, i think using xray only the one tile behind walls, could be interesting. But xray also lights up the dark places. Perhaps we can try to increase the desaturate effect in relation to visible and light.

So normaly non visible tiles we go full greyscale, where on dark tiles we use desaturate in relation to light there.

This could look really cool, players running around full daylight, mainly have full view. Running around with torches at night, we have color around us, going more and more grey in distance. So players can also reduce this effect in dark places by using good light sources.
« Last Edit: 21, March 2024, 08:09:51 by Dolfo »
Don't believe the shit, you hear in mainstream. Believe your own body. Your body is speaking always the true to you. But you need to understand your body. Hear to your body, not to your ego. And when body is calling to you: "Hey something is wrong!" find the reason(s) for that. Man in White don't go for that, they don't want to heal you. They want earn money and sell you medicine, you should take rest of your life. You are not the patient, you are their customer. Never forget this!

Dolfo

« Reply #3 on: 21, March 2024, 08:09:39 »
I tested to undo the xray grey logic in client. Then using RoGT is lightning all up and let allow look behind walls, if you are close. Looks like lite preparation is done server sided?

Looking server sited, with xray on, server is unblocking nearby blocked positions in

los_update()
Code: [Select]
if (QUERY_FLAG(who, FLAG_XRAYS))
{
 for (j = 1; j <= 24; j++)
 {
  ax = pl->socket.mapx_2 + LosX[j],
  ay = pl->socket.mapy_2 + LosY[j];
  pl->los_array[ax][ay] &= ~LOS_FLAG_BLOCKED;
 }
}

and adjust visible to 100 in view_map.c draw_client_map2() for the titles <=0.

Code: [Select]
if (d <= 0) /* tile is not normal visible */
{
 /* (xray) or (infravision with entity on a tile)? */
 if (xrays ||
  (infra &&
  (msp->flags & (MSP_FLAG_PLAYER | MSP_FLAG_MONSTER))))
 {
  d = 100; /* make spot visible again */
 }
...

If i understand this correct, we send all visible items with the correct brightness to client, where all non visible items where tuned to 100?

So client sided there must be an additionally light adjustment to show all tiles same brightness?

Implementing another flag could be an idea, but wouldn't help on the brightness. Mainly we need to send 0 brightness tiles to client, instead of 100, but with the los "hack" above we get problems on the brightness behind walls. We need to adjust these hacked tiles also to 0 brightness.

If we can change server code this way, that we send all map tiles we want to show in xray mode and additionally send clean brightness infos (0 for dark normally not visible spots) client could do some magic, with desaturate in relation to brightness.

I dunno if this is worth the time to code that. I describe the final view, so we can think of, if its worth to code that. Xray would mean then:

At day light we have full colors.
When spots go darker and darker, we go more and more to grey effect instead of darker.
When spots are fully dark, by light or because behind walls, the xray effect shows pure grey tiles.
Running around with torches our other lightsources would remove the grey effect around us, in relation to the power of the light sources.
« Last Edit: 21, March 2024, 08:14:59 by Dolfo »
Don't believe the shit, you hear in mainstream. Believe your own body. Your body is speaking always the true to you. But you need to understand your body. Hear to your body, not to your ego. And when body is calling to you: "Hey something is wrong!" find the reason(s) for that. Man in White don't go for that, they don't want to heal you. They want earn money and sell you medicine, you should take rest of your life. You are not the patient, you are their customer. Never forget this!

Dolfo

« Reply #4 on: 26, March 2024, 11:15:17 »
Ok, this leads to more work.

Tested so far:

When I don't react on SF_XRAYS I have full colors with darkness scaling AND can see behind walls.

This color scaling is working in relation to BLTFX_FLAG_DARK and bltfx->dark_level. SF_XRAYS switch on BLTFX_FLAG_GREY but not BLTFX_FLAG_DARK.

Theoretically it would be nice to use BLTFX_FLAG_GREY and BLTFX_FLAG_DARK, but client is caching the bitmaps.

Grey scaled bitmaps were cached in sprite->grey, where the different darkness bitmaps where cached in a hashtable.

So its "easy" to calculate a kind of different desaturation effect in relation to bltfx->dark_level, but to build another hashtable logic for the different grey scaling is more complex.  ::)
Don't believe the shit, you hear in mainstream. Believe your own body. Your body is speaking always the true to you. But you need to understand your body. Hear to your body, not to your ego. And when body is calling to you: "Hey something is wrong!" find the reason(s) for that. Man in White don't go for that, they don't want to heal you. They want earn money and sell you medicine, you should take rest of your life. You are not the patient, you are their customer. Never forget this!

Dolfo

« Reply #5 on: 29, March 2024, 00:25:40 »
This is wild. We have mainly a pointer for 4 different unstretched sprites.
blt_sprite = sprite->bitmap;
blt_sprite = sprite->fog_of_war;
blt_sprite = sprite->red;
blt_sprite = sprite->grey;

where bitmap is the original bitmap and 3 other were calulated when we need this, by using a loop manipulating each pixel.

Behind this, we have the cached stretched bitmaps, stored in a cachetable. The calulcation for this is mainly done with sdl intern logic for streching and alpha changes. So a little faster.

Sdl has no intern desaturation logics, so we would need to calc each desaturation effect with the loop and pixel by pixel. This would slow down client, but with the cache could still be fast enough.

So when the normal darkness derives from this original bitmap, a desaturation would need to calc desaturation and stretch effect. Normally we need 7 more caching pointers for possible 7 different desaturation effects. We could add an extra array, like desaturate_filter[] equivalent to the darkness_filter[] array.

But to kill everything, we have a nice hashtable logic, I tried to understand several hours now.  ::)

Finding the comment in head is a small help, but ...
Code: [Select]
/*
The cache is implemented using a hash chain technique.  The incoming pointer
and the stretch number is converted to a reasonably(?) unique key and hashed.
The cache entries also has a double linked list to maintain a LRU method where
a successful fetch will place the entry at the head. When the table gets full
the tail end is recycled.
Limitations: I don't expect more than 64K-1 cache entries so the entries
are 16 bit. The key is currently reduced to 8 bit since I don't expect the hash
table to be very big.  Just change the CalcHash routine if you want a larger key.
*/

static Uint16 CalcHash(const SDL_Surface * src,Uint32 stretch, Uint32 darkness)
{
Uint16 sum;

// dunno, why we calculate key with old high word, low word split logic?
// very strange, also darkness (0-7) is always 0 on high word, so unnecessary code
// stretch is 0 or = bottom+(left<<8)+(right<<16)+(top<<24);
// so 8 bits for each direction

// typecast around const SDL_Surface *src pointer is wild
// we build the sum from high/lo word
// this means address 0x00010001 is leading to same key than address 0x00000002

// looking on stretch, bottom 1 would lead to same key value than right 1

// a stretch bottom 1 darkness 0 would lead to same result as bottom 0 darkness 1

// then we could overflow because sum is uint16

// and in final step this uint16 is interpreted in high byte and low byte,
// where both where added, only to typecast the sum to uint8

// so with all this knowledge its still wild how the key is generated here
// building an index for the hashtable with below logic looks chaotic
 
// its very easy to produce same keys for different situations.

sum=
(Uint16)((Uint32)src >> 16) +
(Uint16)((Uint32)src) + // unnecessary typecast to Unit32
(Uint16)((Uint32)stretch >> 16) +
(Uint16)stretch +
(Uint16)((Uint32)darkness>> 16) + // always 0
(Uint16)darkness; // 0-7

sum=(Uint8)(sum>>8)+(Uint8)sum; /* Limits the hash head table to 256 entries */

return HASH_MOD(sum);
}
... I really tried it, but I refuse to build a new xray logic, above this hashtable logic. Perhaps I try a 50% desaturation effect, instead of the pure grey effect as a temporary solution.

I commented this here, so we have this for later. I spend several days now, looking in this logics, between other things. I stop this atm, and change my focus back to other things.  ::)
« Last Edit: 29, March 2024, 00:28:09 by Dolfo »
Don't believe the shit, you hear in mainstream. Believe your own body. Your body is speaking always the true to you. But you need to understand your body. Hear to your body, not to your ego. And when body is calling to you: "Hey something is wrong!" find the reason(s) for that. Man in White don't go for that, they don't want to heal you. They want earn money and sell you medicine, you should take rest of your life. You are not the patient, you are their customer. Never forget this!

Tags: