View Single Post
Old September 2, 2019, 11:59   #90
Flambard
Rookie
 
Flambard's Avatar
 
Join Date: Mar 2019
Posts: 22
Flambard is on a distinguished road
My 2 cents on variable scope, it does indeed make code more readable (obviously), yet it's not properly supported by many ancient compilers So it's either this either that.

Quote:
Originally Posted by PowerWyrm View Post
Unfortunately SDL2 is allergic to BCC for some reasons so I gave up porting SDL2 to PWMAngband. And it seems that you would need at least DX8 which isn't available in the header list of the compiler (SDL1 uses DX5 which seems supported).
SDL2 supports OpenGL on windows, and, yeesh, a Software Renderer. I believe you could use those, setting some flags during CreateRenderer, or as SDL_Hints.

Quote:
Originally Posted by tangar View Post
A newbie question:

could SDL 2 give possibility to add proper shading to tileset? Cause currently we need to have 3 similar terrain tiles for light purposes
I've been doing some work on this front, and I wanted to share some progress.

Note: this is going to be MAngband-biased, but I believe it's of some value here.

1. Passing 2 more params to Z-Term pict hook.
So I've settled on 2 additional bytes, called 'la' and 'lc' (I know those are horrible names), to go with 'a', 'c', 'ta' and 'tc'. For newever Angband versions, I believe those are encompassed into a struct. For old Angband variants, one will have to pass them over a long, long, long chain.

Those are set in `map_info`, using the regular ASCII rules, i.e., TERM_SLATE for dark, TERM_WHITE for glow, TERM_YELLOW for torch-lit (with additional bits, see below).

The chain is truly horrible, all those va, vaa, vta, vtaa inside the term struct have to be duplicated for the 2 additional bytes. Sigh.

2. Variable format is:
for 'la' (aka 'terrain light'):
Highest Bit (8) is reserved (for MAngband-related network compression).
Bits 1-5 denote a color, that's your TERM_WHITE stuff. I believe modern V has 27 colors, we're still on 16 colors, but either way 5 bits give enough room for 32 colors (0-31), so all is good.
Bit 6 is used to mark CAVE_VIEW flag.
Bit 7 is used to mark CAVE_GLOW flag.
If both bits 5 and 6 are set, this means TORCH-LIT.
While this data is redundant, as TERM_YELLOW color should be enough, it can allow display frontends to display the colors in a more interesting way (e.g. variable glow for torches or additive mode blending for glow).

BTW, the reason I'm compressing this thing like a madman is because we have to transmit this data over network, so every bit counts.

for 'lc' (aka 'entity light'):
Bit 8 - reserved for network stuff
Bit 7 - CLEAR_ATTR (clear monsters)
Bit 6 - CLEAR_CHAR (monsters that are supposed to re-color terrain, yet lack own picture! unused in V since inception, but who knows, maybe one day...)
If both bits 6 and 7 are set, that's your MULTI-HUED monster!
Bits 1-5 are for colors, once again, TERM_WHITE, TERM_SLATE, whatever.

In both cases, the special value 0 means that "no re-coloring is needed, draw the tile as is".

3. Actually displaying this.

On SDL2 this is super easy. I just modulate the terrain/monster tile with the needed color, and if I need additional bling, I examine the special bits.

On GCU, nothing needs to be done. It already has lightmaps

On SDL1, WIN, X11 and any other software rendereres, I'm a bit stumped. At first I wanted to pre-generate 16 variations of each tileset (for each color modulation), but that's wasting lots of CPU time and memory...

I'm now experimenting with a pixel dither mode. Basically, it draws a "dithered" square on top of each tile, this is working more-or-less fine for terrain, but not so well for monsters.

If anyone has any suggestions (I keep reading this is an easy thing to do), please share. Keep in mind, that working with bitmaps in window port is a major pain, those aren't like SDL_Surfaces at all :/

If there's any interest I'll port the code to latest V Z-term, but I gotta figure out the software rendering part.
Flambard is offline   Reply With Quote