SDL2 port when ?

[t4nk]

Initially the game window was partially transparent, with the @ warrior picture below it. Which was quite distracting. When I restarted, either the main game window became fully opaque, or the picture below vanished.

Hmmm, that's not normal...
It's possible to make most subwindows partially transparent (e.g., Menu -> Term-1 -> Alpha), but not the main one.
Also, some terminology: "window" is the stuff that your window manager (like GNOME or XFCE or whatever) creates - "window" can be fullscreen; "subwindows" are those rectangles inside main window that react to "Move" and "Size" buttons and display game state (map, messages, monster list, etc).

Anyway, the background is black now, which is what I wanted.

There is a file "~/.angband/Angband/sdl2init.txt", which containts various settings for the port. Post it here, please.

The only problem: 'size' ends at 21 points, and the font (being cheaply generated from a bitmap font) looks best at 16, 24, 32, etc. For 4K monitors it would make sense to bump it to 32 or even 64.

Noted. I take it the button becomes red when you try to increase above 21? (the max size is hardcoded to be 24 anyway). What's the resolution of your monitor? The main subwindow (that displays dungeon) must be at least 80x24 characters.
"sdl2init.txt" should have some useful information about it, so don't forget it

[t4nk]

Well, I started to make some progress - namely, at last I remembered my password for Github Openmailbox seems to be down...

So, the plan is, as discussed with various people:

1) Revive Makefile.std (Nick)
2) Remove "Cursor" option from the menu (fph)
3) Change menu colors (wkmanire)
4) Write a help file (wkmanire)
5) Windows version (Grotug)
6) Bigger font size with high DPI displays (Bandobras)

Let me know if I'm forgetting something.

[Bandobras]

Huh, suddenly between this

https://github.com/Mikolaj/angband/commit/70657c3055cc80ed2a8024fda255ad910fbbce00

and this commit

https://github.com/Mikolaj/angband/commit/61b5285d6a3df52b05e496d270ec29ce9301bb1d

the WOFF font no longer shows up on the list and when I force it via `.angband/Angband/sdl2init.txt`, it fails with

parse error in /home/mikolaj//.angband/Angband/sdl2init.txt line 15 column 4: : invaild value
angband: main-sdl2.c:5683: get_new_window: Assertion `!window->inited' failed.
Aborted (core dumped)

The very same font file works fine in my Allure of the Stars with SDL2 frontend.

Edit: my .angband/Angband/sdl2init.txt

window-display:0:0
window-full-rect:0:0:0:1920:1080
window-fullscreen:0:true
window-renderer:0:hardware
window-wallpaper-path:0:/home/mikolaj/r/angband/lib/icons/att-128.png
window-wallpaper-mode:0:tiled
window-status-bar-font:0:0:8x13x.fon
window-graphics-id:0:0
window-tile-scale:0:width:1
window-tile-scale:0:height:1
window-cursor:0:true

subwindow-window:0:0
subwindow-full-rect:0:0:22:1920:1058
subwindow-font:0:12:16x16xw.fon
subwindow-borders:0:false
subwindow-top:0:true:false
subwindow-alpha:0:255

Edit2: When I increase the WOFF font size, after size 21 it goes back to size 4. My monitor is Full HD and the font at size 24 results in exactly Full HD size with 80 columns and 45 rows, so it should still fit at size 24.

[t4nk]

Huh, suddenly between this

https://github.com/Mikolaj/angband/commit/70657c3055cc80ed2a8024fda255ad910fbbce00

and this commit

https://github.com/Mikolaj/angband/commit/61b5285d6a3df52b05e496d270ec29ce9301bb1d

the WOFF font no longer shows up on the list

Either freetype can't open it, or it thinks it's not a monospace font (FT_IS_FIXED_WIDTH()). What does that commit do?

and when I force it via `.angband/Angband/sdl2init.txt`, it fails with

Not recommended, sdl2init.txt is not really human editable

The very same font file works fine in my Allure of the Stars with SDL2 frontend.

Then most likely FT_IS_FIXED_WIDTH() fails.

I'll take a look at it after dealing with makefiles and other things (see plan).

[t4nk]

My monitor is Full HD and the font at size 24 results in exactly Full HD size with 80 columns and 45 rows, so it should still fit at size 24.

Each subwindow has an 8 pixel border on all sides (top, bottom, left, right), so subtract 16 from your monitor size... there is also the status bar at the top (with buttons - "Menu" and others), so subtract this also (edit: it's 22 pixels high)... So maybe it's correct?

I guess, these things can be made configurable at least, but it looks like you won't get a lot bigger than 21?

[Bandobras]

Then most likely FT_IS_FIXED_WIDTH() fails.

Spot on. I copied some glyphs from another file, but didn't correct their width from 1600 to 1602 pixels (don't ask). Fixed and pushed.

Each subwindow has an 8 pixel border on all sides (top, bottom, left, right), so subtract 16 from your monitor size... there is also the status bar at the top (with buttons - "Menu" and others), so subtract this also (edit: it's 22 pixels high)... So maybe it's correct?

That should still fit in a 23 pixels font comfortably. But something is not right, because at 21 pixels I've counted only 81 columns in a line in monster recall menu.

[Bandobras]

I've looked closer and it seems, compared to bitmap font, for WOFF you are adding 2 pixels extra between glyphs adjacent horizontally and 3 between lines.

Allure of the Stars manages to mimic bitmap font treatment by displaying each glyph separately at calculated coordinates and so there is no extra space between glyphs.

Edit: Wow, you are actually doing that with bitmap fonts as well, which means even with a square font distances are not true on the map. I'm surprised, because bitmap fonts (or only the old-school ones?) are designed pixel-perfect, for display without any extra borders. You probably do that due to the cursor, because your fonts (as opposed to mine) are not designed to accommodate the cursor, so that it doesn't obscure important parts of the font and never touches stems at more that a couple of points. I'd probably only do that for fonts smaller (or equal?) than 9x15, because glyph stems in larger fonts rarely, if ever, run exactly at the border or only 1 pixel away (so cursor would fuse with the stem). This is all assuming your cursor is 1 pixel wide. But is looks so.

[t4nk]

I've looked closer and it seems, compared to bitmap font, for WOFF you are adding 2 pixels extra between glyphs adjacent horizontally and 3 between lines.

Ah, right! Forgot about it. You have sharp eye, Bandobras

Edit: Wow, you are actually doing that with bitmap fonts as well, which means even with a square font distances are not true on the map. I'm surprised, because bitmap fonts (or only the old-school ones?) are designed pixel-perfect, for display without any extra borders. You probably do that due to the cursor

It's actually because of vector fonts (.ttf, .otf and stuff). Those are not pixel perfect (even if monospace) - the sizes of glyphs can differ by a pixel (e.g, "t" is 8 pixels wide, while "m" is 9 pixels). So I just add a one pixel border to what freetype reports is the font size. Otherwise, erasing glyphs can leave some stray pixels.
Bitmap fonts are indeed pixel perfect... they're also not really resizable, which is why Angband ships with tons of them. I don't like Angband's default fonts, so I didn't even consider adjusting their size back... I guess I should do that.

[Bandobras]

My ttf (that is WOFF) font doesn't lie about its size, I hope.

Anyway, I handle scalable fonts by always creating a black texture of the nominal size and pasting the texture I got from sdl2-ttf in the center, cutting off any portions that stick out. In this way I get no border and no stray pixels after wiping out previous glyphs.

[t4nk]

My ttf (that is WOFF) font doesn't lie about its size, I hope.

It not really a lie... as the Freetype maintainer likes to explain, the only REAL way to determine font size in pixels is to render all glyphs For example, I recall DejaVuSansMono does leave stray pixels (at some sizes).

Anyway, I handle scalable fonts by always creating a black texture of the nominal size and pasting the texture I got from sdl2-ttf in the center, cutting off any portions that stick out. In this way I get no border and no stray pixels after wiping out previous glyphs.

Very reasonable idea. I decided to add borders to (most) glyphs because I didn't want to "lose data", but I didn't consider that one-pixel borders would actually add up to a rather big number of wasted pixels... Getting rid of them would allow to display several more lines/columns (or use bigger font size with the same term size)... yeah, I really should be cropping glyphs instead. Thanks!

[Bandobras]

That would be awesome. For me it's especially important, because square fonts are very hard to read longer texts in, so I designed the font in a way that looks strange, but has very narrow space between letters in a word to help the eye organize characters in lines, rather than in columns. And so any extra horizontal space makes all that effort moot.

Yes, you are right, glyphs larger than the official size is not a lie, especially with some capital letters with two (!) accents over them, one over another. However, I specifically did not add such letters and for others mimicked the approach in older Angband fonts, by making accented capital letters lower and the accents on them smaller than on lowercase letters.

BTW, the code I mentioned is here, in case I mixed up details (and I did --- I resize surfaces, not textures): https://github.com/LambdaHack/Lambda...nd/Sdl.hs#L349

Edit: and I probably resize instead of cropping...

[tangar]

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

[Bandobras]

Looking at https://www.libsdl.org/projects/SDL_...SDL_image.html there is nothing specific. So I guess you'd combine images, possibly with alpha channel, possibly using blendmodes: https://www.reddit.com/r/gamedev/com..._sdl2/ce7oyo6/

[takkaria]

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

The problem here is not really SDL but Angband's total lack of an intelligent graphics mode. Any of the ports could do this, it's not a difficult graphics operation (draw a tile but darken it by 80%), but no-one has stepped up to do the work yet to get Angband supporting this kind of thing.

[Pete Mack]

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.