-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
implement PNG brightmaps #1921
base: master
Are you sure you want to change the base?
implement PNG brightmaps #1921
Conversation
// get light level | ||
if (thing->flags & MF_SHADOW) | ||
vis->colormap[0] = vis->colormap[1] = NULL; // shadow draw | ||
else if (fixedcolormap) | ||
vis->colormap[0] = vis->colormap[1] = fixedcolormap; // fixed map | ||
else if (thing->frame & FF_FULLBRIGHT) | ||
else if (thing->frame & FF_FULLBRIGHT && !brightmaps) // TODO |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've disabled FF_FULLBRIGHT
for now, it looks like we need some kind of config file for brightmaps, like this: https://github.com/NightFright2k19/gzdoom_brightmaps/blob/master/bmplus_vanilla/brightmaps/sprites/doom2.bm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FF_FULLBRIGHT
is just a flag that we can remove or set at will, depending on the presence of a brightmap for the sprite. However, we should keep a copy if we want to allow in-game toggle. 🤔
So far, only the sprites are working.
|
||
boolean brightmaps; | ||
|
||
static patch_t *spr_brightmaps[NUMSPRITES][MAX_FRAMES][MAX_ROTATIONS]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's 261 pointers per sprite, even if no brightmaps are ever loaded. Should we turn this into dynamic allocation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, this is temporary, for simplification. By the way, I'm not sure if the frames/rotations are working correctly.
// 0x37, 0x37, 0x37, 0x2F, 0x2F, 0x2F, 0x27, 0x27, 0x27, 0x23, 0x23, 0x23 | ||
}; | ||
|
||
static byte GetGrayscaleColor(int r, int g, int b) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I don't quite get this part. If we transform brightmap PNGs to grayscale, why do we need a lookup table for this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We map brightmap colors to "light levels". The grayscale
table corresponds to colormaps
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah! Maybe that's worth a comment here. 😉
Since I made (or, to some degree, collected) these brightmaps: If you guys need any help or adjustments for this from my side, feel free to poke me. Also: If you think it sucks to have monsters with glowing eyes (which kinda gives them away in dark areas and therefore sort of affects gameplay), I may find new motivation to create an alternate version. |
Thanks. We are currently planning to convert Woof's existing brightmaps to PNG format, as we know who made them and they are minimalist, so there won't be any copyright issues. |
So far, only the sprites are working.
Brightmaps for test: brightmaps.zip (taken from https://github.com/NightFright2k19/gzdoom_brightmaps). Just run
woof -file brighmaps.zip
It seems GZDoom brightmaps are too subtle.