SDL2 port when ?

[Flambard]

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.

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.

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.

[PowerWyrm]

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

[Nick]

I guess these days it matters less to me because I tend to write shorter functions than I used to, but in the past I found that putting definitions not at the top of functions was useful for figuring out what was used when. I think Angband is particularly bad in some of its older code for this. You have a 3 page long function with variable names like 'seen' and 'flag' which are defined at the top of a function and used twice somewhere in the middle. It's really difficult to understand what is going on.

I tend to be with takkaria on this one (not least because most of the C I write is for Angband). I also agree about the length of the functions, with calc_bonuses() and some of the object handling and targeting functions being among the big offenders.

All that said, my comment to PowerWyrm was mainly to encourage the continued finding of bugs in V code. I'm not sure if anyone else has noticed, but the 4.x.y releases where y > 0 are usually heavily loaded with bugfixes provided by PowerWyrm while implementing 4.x.y-1 features into PWMAngband

[takkaria]

I guess these days it matters less to me because I tend to write shorter functions than I used to, but in the past I found that putting definitions not at the top of functions was useful for figuring out what was used when. I think Angband is particularly bad in some of its older code for this. You have a 3 page long function with variable names like 'seen' and 'flag' which are defined at the top of a function and used twice somewhere in the middle. It's really difficult to understand what is going on.

Arguably the problem here is that the function is too long and the variables are named badly, rather than that they're not defined as used. But I think Derakon's example of for-scoped variables is the most obviously good use case.

Languages like Elm, F#, Haskell always put their variables at the top of the function. But those are paradigmatically functional languages so it's a lot easier to reason about the code anyway.

[Derakon]

Not really. I'm used to declare my variables at the beginning of functions even when using C++ or Java and I find the code much easier to read that way. But of course I'm an old developer... In my time, RAD environments didn't even exist, you had to code everything. Heck, at my time we were coding using Pascal...

There's a lot of reasons why on-the-fly declarations is the standard these days. The biggest one IMO is that it allows you to scope a variable to just the block of code it is used in. For example, in many languages this:

for (int i = 0; i < 10; ++i) {
  ...
}

means that the `i` variable does not exist outside of that for loop. This is a great way to avoid accidentally using your loop iterator in the wrong context. And if you do need it outside of that context, then it's trivial to explicitly declare it, which is then a signal to the reader that "hey, this loop variable will probably be needed later."

[PowerWyrm]

Nick--
I am not convinced that going back to archaic C is an improvement. Variable declarations as needed is a whole lot easier to read.

Not really. I'm used to declare my variables at the beginning of functions even when using C++ or Java and I find the code much easier to read that way. But of course I'm an old developer... In my time, RAD environments didn't even exist, you had to code everything. Heck, at my time we were coding using Pascal...

[Pete Mack]

Nick--
I am not convinced that going back to archaic C is an improvement. Variable declarations as needed is a whole lot easier to read.

[Nick]

Trying to port the SDL2 frontend to PWMAngband at this time.

Any improvements you make to this frontend gratefully received

[takkaria]

Ah, it's BCC, not MSVC. That is ancient!

[Pete Mack]

powerwyrm-
those declrations are all thru the code, not just in sdl2. And the standard is 20 years old, back to C99.

[takkaria]

Oh wow, has Microsoft still not caught up with their C tooling with this? The spec is only 8 years old...

[PowerWyrm]

Trying to port the SDL2 frontend to PWMAngband at this time. Since I'm using BCC to compile, I'm probably gonna kill the guy who wrote main-sdl2.c without putting all the variable declarations at the beginning of functions...

E2140 Declaration is not allowed here
E2140 Declaration is not allowed here
E2140 Declaration is not allowed here
E2140 Declaration is not allowed here
E2140 Declaration is not allowed here
E2140 Declaration is not allowed here
...
E2140 Declaration is not allowed here
E2228 Too many errors or warnings

Day 2 of fixing this... and I'm not even at the half of the file.

[dos350]

keep up the great work, sdl2 is such a great improvement over sdl

[tangar]

Cool Could this shadow-issue be included to TRAC then, to be implemented one day? It would make tileset support MUCH easier. Also there is a problem with object transparency (rubbles).

[takkaria]

Tak--
You could do this with sheets pretty easily: paint the background with yellow-white-grey-black (lantern-lit-seen-detected.)
Then lay on background tiles with variable parts with 100% transparency. You could of course do this once, then put the rendered tiles into reserved tile slots in the lookup sheet. This would allow you to use the current main-xxx.c interface unchanged.

Yeah, none of it would be particularly technically difficult, just no-one has done it yet!