SDL2 port when ?
 

Can anybody comment on when can we expect an SDL 2 port , not SDL 1.2 but SDL2 port.

As soon as someone with the necessary time, willingness, and expertise makes one. So far as I'm aware, nobody has expressed any interest in doing that yet. You'd be more than welcome to take a stab at it yourself though.

Hahaha... oh wow :rolleyes:

Nope :)

Hey Derakon... what if I told you that someone has already written an SDL2 frontend for Angband years ago? I'm not talking about textui2, but an honest-to-god frontend for Ben Harrison's z-term.c...

Whatever for?

Sounds like I need to eat some crow then. I sincerely apologize!

No problem. I think everyone just forgot about it after this story with rewriting the UI... I also forgot (hence my "oh wow" :)). So now that I remembered, I wonder what happened with this code? I don't have it, I only have textui2, cloned from Takkaria's repo (which also doesn't seem to have it)... Maybe it's lost forever. Meh, whatever...

Hey, I found it!
https://github.com/takkaria/angband/...rc/main-sdl2.c

Well, OP, now that you have it, what are you going to do with it? :)

I tried it actually :-


https://paste.debian.net/1043405/

The compilation fails as it looks for libsdl1.2 config

The relevant bits -

where it should be looking for libsdl2-config :-
FWIW, there are two libsdl2 audio libraries that upstream could look at -

http://www.libsdl.org/projects/SDL_mixer/

https://github.com/katajakasa/SDL_kitchensink

The first one is an all encompassing one, the second one is supposedly more narrower in scope.

I am no developer but can help with compiling and telling what seems to come up short.

Indeed, since it was never incorporated into Angband. I recall you need to run autoconf with "--disable-sdl" actually (which disables SDL1), and then manually hack the Makefile.std (that's what I did back then)...

You can try to go back futher in this branch and look for something like Makefile.sdl2... although it probably shouldn't be there. If not, I can write the Makefile, but not right now, maybe in several days (also, I still don't know how autoconf works :))

Hi,

It actually uses autogen.sh .

When I run ./autogen.sh the following takes place -

which forms the .configure script

The Makefile is generated when the .configure script is taken care of . Once it is complete, you get a makefile.

If I just do -

then a makefile will be generated which has the sdl frontline disabled.

There is a Makefile though but that's in -

There is this Q&A on stackoverflow I saw but dunno if its just what is needed

https://stackoverflow.com/questions/...n-linux-ubuntu

Reading it few times it seems it needs the following info. -
for libsdl2 and -

Edit - I found what needs to be fixed -

from https://wiki.libsdl.org/FAQLinux#How..._my_project.3F

it seems acinclude.m4 is what needs to be fixed -

it needs https://hg.libsdl.org/SDL/file/default/sdl2.m4

I did try to do a copy and replace but didn't get far.

This is what I did with acinclude.m4

https://paste.debian.net/1043458/

I get the following errors when I try to ./autogen.sh it -

Yeah, in principle, it should be simple enough. Replace main-sdl.c (SDL1 version) with main-sdl2.c, replace all references to main-sdl.c with references to main-sdl2.c in autogen stuff, link with SDL2 instead of SDL1, and then it should work. I just don't know how to do it :)
You'll also need libSDL2_ttf.so (for loading fonts) and libSDL2_image.so (for loading tiles).

Well, if you're serious about it, I'll write the Makefile. It'll be simpler than trying to figure out autoconf :) The only problem with that is I now have a new hobby , which is writing a roguelike, loosely inspired by (among other things) Angband. And I'm not using C or Make for that, so it'll cause me some moral suffering to go back to those, and I need to muster my strength first :)

All of these I have -

As far main-sdl.c I didn't find any changes to do apart from the comments -

There might be other things which might be contributing to the complexity -

My tooling -

so it's possible there might be bug-fixes, regressions etc. that I do not know about . As shared before I'm not a developer so don't know anything about C.

I personally like cmake for compiling as things are lot smoother and it's easier to debug, give feedback to developers etc. but it is what it is :)

OK, shirish, tell you what. When I'll have some free time and gather some strength (hopefully in the next several days) I'll fork Angband's repo on github, add SDL2 frontend to it, and post compilation instructions here (in this forum). Who knows, maybe I'll even make pull request to the upstream again... SDL1 is really getting obsolete... but then, so is Angband :)

Interestingly, it's actually there: https://github.com/takkaria/angband/.../Makefile.sdl2
So I guess the only thing to do is to add the module to the list in main.c...
Now the problem is remembering how Github works. And that also reminds me that Github was bought by the oligarchs from Microsoft. Argh! Well, life is cruel and unfair... I'll see what I can do :) In a couple of days, maybe?

Sure, take your time, although reading the makefile.sdl2 from whatever I could understand it is/was for the windows port and not *ix so it probably will need quite a bit of change :(

If you can't stand github.com I could put the takkaria's port on salsa.debian.org . I have access there. It's a gitlab instance. We could also use gitlab's own instance as well.

https://about.gitlab.com/

It's definitely for Unix, even specifically for Debian Wheezy :) I know it because I made it out of Angband's Makefile.std (which didn't work and probably still doesn't). Perhaps you're thinking about another Makefile in this directory? (Makefile.ms.ui2, which is an entirely different thing).

Thanks for the offer... the funny thing is, this port is actually written by me :) in the summer of 2016. And then everyone, including myself, forgot about it. Which is why I was shocked when you posted :) It's a long story... hmm... actually, it's a reasonably short story. It goes like this:

After writing the SDL2 port I decided that Angband's entire UI is outdated and has too many hacks (accumulated over decades) and needs to be rewritten. So I did rewrite the UI and it turned out pretty good (opinion :)). However, Angband's UI is large (about 1/3 of the whole program) and it was never pulled into the official repo. Currently, Angband's devteam seems to consist of one person who has limited time to work on it and there are just no resources for such a massive disruption. Meanwhile, everyone's forgotten that there is, in fact, a complete and working SDL2 frontend...

So... question to the maintainer:
NIck, let's be realistic here, textui2 will never make it into Angband. However, main-sdl2.c is a plausible addition to the game. It's just another frontend, after all. SDL1 is an obsolete library, and SDL2 port, as you know, has more and better functionality. I can register on Github again and send a pull request. What do you say?
If not, I'd rather go with shirish's suggestion and use Gitlab.

I would rather have the maintainer be with us rather than having a fork because a fork takes a lot of time. I do not know what targets the maintainer has but if mobile is going to be a space then android has quite a bit of support with libsdl2

https://wiki.libsdl.org/Android .

Of course all osses are moving to libsdl2 from libsdl1.2 . Even SBC's like raspberry pi and like are moving to libsdl2

See https://choccyhobnob.com/raspberry-p...-raspberry-pi/ as an example and games like bzflag https://github.com/BZFlag-Dev/bzflag/issues/94 , wine https://www.winehq.org/announce/3.0.3 and few others . There is also this interesting discussion at https://www.gamedev.net/forums/topic...n-to-use-sdl2/

That sounds good. I’m hoping to be back working on Angband in a couple of weeks, and will pull it in then.

I wouldn’t necessarily say never for textui2 either , but I am an optimist:)

Having the maintainer's blessings is good.

@t4nk now it's upto you, let me know when you want to sign up for either github.com or gitlab.com

Update - The repo. (wherever it's hosted) would be to test and get feedback from each other and if and when it's clean and mergeable state get it into angband main repo. Win, win for all.

OK. I'll be busy tomorrow, I think I can do it the day after tomorrow. Or at least, I'll upload somewhere the three files required - main-sdl2.c, the updated main.c and the Makefile (which also needs updating), as you seem to have some interest in trying it out. The frontend does have some revolutionary features, such as the ability to use resizable fonts - .ttf, .otf and stuff. Amazing, right? :) (or, rather, it's amazing that Angband still uses the .fon files in 2018...)

sure, take your time. This is how angband is shown in Debian testing -

There are however couple of angband audio bugs which have been there a while -

https://bugs.debian.org/793668

and

https://bugs.debian.org/793452

maybe an updated SDL build with the SDL2 frontend, audio etc. may fix some of the problems. Of course the maintainer would have to do the packaging part but it might work. I would signal to the maintainer that we are going to try and have an updated build with SDL2 .

This is how most libsdl2 libraries look , just sharing the working parts at the moment -

There are coding documentation examples in -
Unfortunately (or not) the bigtiles package is no more there :(

Let's focus though on one thing at one time, the other things we can try to do later if we can.

Hi Shirish, thanks for the email. It's funny how life happens sometimes, I was thinking only the other day it's time I updated Angband in Debian, 4.x must be pretty mature now and I expect some free time this fall ... and lo, something happens to pull me back.

I can't promise anything soon, but months rather than years. I'll start with a bog-standard package of Angband 4.x, then I'm going to fix up angband-audio, then I'll see if I can help on SDL2.

Derakon, Nick - hope you're well.

CC

Good to hear from you! Am currently recovering from surgery according to plan, so let's call that well :)

Good to see you, Magnate! I'm doing decently well. Life continues on, no great peaks nor abyssal chasms.

I sent the pull request:
https://github.com/angband/angband/pull/502

For those who are interested in compiling it (instructions for Debian-based systems!):

You'll need three libraries: the "base" SDL2, SDL2_ttf (fonts stuff) and SDL2_image (loading .png files and such). Also, their dependecies (Freetype, zlib and co). If you want sounds, you'll also need SDL2_mixer. In short:
Clone the repo and switch to sdl2 branch:
Configure Angband without any frontends (just in case):
(I think other stuff is disabled by default)

Now compile the game using Makefile.sdl2:
If you want sounds, use this instead:
Now it should work... well, works for me :)
Let me know if there are any problems!

Reply in-line :-

Shouldn't this be from inside the repo. I have done the following -

Then -

I would be updating my answer as I do the next steps.

The compilation terminated see https://paste.debian.net/1043948/

This is when I have all the -dev versions that were needed -

You should probably run ./configure with --disable-sdl-mixer too. (Hi magnate!)

Hi all,

I retried and failed -

and then - will be sharing just the start and end messages -

Still got the same issue -

Perhaps it should be -
SDL2/SDL.h

I was able to fix it by doing in sdl2.c -

just changed SDL/SDL.h and SDL/SDL_mixer.h to SDL2/SDL.h and SDL2/SDL.mixer.h

and was able to compile -

Ah, I see. I have SDL1 headers installed, so gcc looks into /usr/include and there is "SDL" directory there. You have only SDL2, so you have /usr/include/SDL2 (but not /usr/include/SDL). So it fails to find it (SDL_mixer API hasn't changed between 1 and 2).

Anyway, looks like you're close :) snd-sdl.c has two lines:

(lines 25 and 26)

Those need to be replaced with:

@t4nk, I just did that, see above ;)

Btw we don't seem to have any graphics, it still shows up in ASCII mode with the skeletons as background.

I did try -
Also angband doesn't seem to have any options for windowed mode from what all I could see/gather -

Also for the mixer, shouldn't it be sdl2_mixer. I haven't been able to hear any sound :(

p.s. Hi, Takkaria :)

Good. We still have enough time: I'll amend the pull request tomorrow :)

@tn4k hope you are able to see my edited answer. It would be nice to have a windowed mode if possible, at least to show/share screenshots.

something like -
Another one which might be of immense help is -

For the record apart from having skeleton as a wallpaper there isn't much difference in the SDL2 front-end.

Also there is no sound.

There also seems to be missing a debug-mode, something which tells what is going on :(

Maybe at configure time I need to add some -debugging symbols as well ?

Yes, I saw it. And there is a windowed mode! There is a menu in the top left corner with various functionality; clicking on "Fullscreen" toggles fullscreen on and off. Also, click on "Size" and "Move" buttons and drag the subwindows... Well, it shouldn't be hard to figure out (in my opinion :))

Menu -> "About". Also the "V" command in Angband :)

right, my bad. So all looks good, except I don't hear either any sound or music :(

https://imgur.com/a/UGwkjEa

The main differences are: the easier to use menu, less nasty color scheme, different method for controlling subwindows position and size, ability to use resizable fonts (put them in angband/lib/fonts directory), multiple windows.

Did you enable it in options? ("=" -> "User interface options" -> "Use sound").
Sound is a bit problematic, because Angband uses MP3, which SDL2_mixer doesn't like very much. Alghough I'd expect Debian has it figured out (and used correct codecs when compiling SDL2_mixer...)

Hmm... why would you want debug mode?

right.

I can't see it in the menu, the options, it doesn't seem to be anywhere. I tried but perhaps I need a nudge to see in the right direction.

Press "=" in game, then "a" ("User interface options"), then "b" twice ("Use sound"). From a cursory look, the option itself can't be compiled out, so it should be there.
Angband's interface is far from ideal, don't you think? :) I imagine what many new players think when they try to figure out what to do with additional windows...

The options don't seem to be saved :(

I did try to see if ~/.angband/Angband has any options although ideally it should be using ~/.config/angband/$whatever to be in-line with freedesktop specifications but that's something for another day.

see https://specifications.freedesktop.o...t/ar01s02.html for what I mean but as shared that's something that angband people might think of looking into.

FWIW, even after toggling sound=yes I don't get any sound and there is also no way to know if that option is being saved in-game.

That's the reason I was thinking of having a debug-mode so you could knwo what all is happening, for things like this.

Well, that's the standard Angband thing... they're saved in the character savefile (and, if you run configure --with-no-install, the savefile is in angband/lib/save).

There are still some things we can do. We can look into object files:
and
(run them in the directory with the angband executable)

In any case, since there were some problems with compiling with sound initally, try to recompile:
Sound is a thing quite unrelated to main-sdl2.c... it doesn't require the SDL2 port at all and can work without it (still using the SDL2 library). I always suspected that Angband's sound doesn't work very well with SDL (either 1 or 2), but most people play without sound, so there weren't a lot of bug reports. Also, Angband on Windows uses the Windows method of playing sounds, instead of SDL.

[QUOTE=t4nk;133428]Well, that's the standard Angband thing... they're saved in the character savefile (and, if you run configure --with-no-install, the savefile is in angband/lib/save). /QUOTE]

argh... that's horrible if I am seeing this right -

I was expecting a nice .json type file but it's not to be :(

I find games boring without having their own sounds and music , makes for an immersive experience.

I did as you shared and this time did hear a thunder but that's about it.



Nice. So it seems we have sounds, but doesn't seem to have any background music, although you might be better judge of that. Is that it as far as music is concerned ?

@Magnate , hope you are following the thread, please input if you have any questions/queries about sound/music etc as you know the game much better than I do.

Yes, Angband is pretty old :) Older than Javascript...

TBH, I never played it with sound either. All sounds are in angband/lib/sound: looks like there are some twangs and clicks and that's about it. Pretty sure it doesn't have any music.

If anyone has any bug reports or comments about the SDL2 port, don't hesitate to post here. Now that I opened the pull request, I'll be maintaining it. The compilation instructions are here: http://angband.oook.cz/forum/showpos...1&postcount=24
If you get errors, try to compile without sound. Anyway, I'll fix the branch soon :)

I pushed some more small cleanups (to snd-sdl.c, as discussed previously, and also fixes to some comments), but it looks like sdl2 is already merged :) Thanks, Takkaria. I guess Makefile.sdl2 is not necessary. Anyway, you can find three more commits here: https://github.com/t4nk074/angband/commits/sdl2

Not sending it as a pull request, since it's utterly trivial stuff, but might be useful to Nick when he'll get around to it.

And hello takk!

Thanks, I have merged these.

The latest build on the nightlies page has this plus a failed attempt to get the standard build system to build the SDL2 port. I have at least left it so that the build system works if you don't try to use SDL2, and so that you can use Makefile.sdl2 to use the SDL2 port. If anyone is better at getting the build system and autotools to work (and surely someone must be), please have a go.

Thanks, Nick! After some f...g around it seems to work for me:
https://github.com/angband/angband/pull/503
At least, it brings us closer to the goal, I think :)

Works for me, too (Ubuntu 18.04), after installing the sdl2 devel packages and running autogen.sh from scratch. Thanks t4nk!

Awesome! That all works for me too - you can't configure with both SDL2 and SDL, but (a) they both work separately and (b) why would you want to? That's merged now and the new build is up on the nightlies page. I guess at some point the guts of Makefile.sdl2 can be rolled into Makefile.std and Makefile.sdl2 removed.

The thing that was really getting me was why I couldn't get it to use sdl2-config, which I assume was the AM_PATH_SDL2 thing. Thanks for clearing that up :)

It's impossible to link with both at the same time anyway - they have plenty of functions with same names (and use headers with same names, too, like that SDL.h). The build system should probably prevent attempts to use both... alternatively, consider deprecating SDL1 :)

Well, if you want to revive Makefile.std, I can do it.
I also noticed that the long-standing bug with panel redraws while running is still there. I should probably fix that, too.
Again, in several days, maybe :)

Issue: the SDL2 port does not display the cursor. This makes the 'look' command, for instance, almost unusable.

You probably disabled it in menu? (the one in the top left corner: Menu -> Angband -> Cursor). TBH, I don't even remember why this option is there :confused:

Yep, good call, thanks! I must have clicked on it inadvertently when I was playing around to get the window sizes right.

Looking good!
 

I tried out the new SDL2 graphics mode and it is really looking great. I love the @ background too. I have a couple of suggestions for the menu behavior though.

Toggling Menu Items
For toggle-able menu options, such as whether to show the cursor or not, there really should be some kind of checkbox interface. When menu items are "greyed out" or "black", they seem like they're disabled and not available for being clicked on as opposed to being toggled off.

Resizing Windows
For some reason, I did not see the resize and move options in the right hand side of the menu bar for a good 5 minutes. I kept searching for a way to resize the windows the same way it worked in the SDL1.2 version. I think this new design is clean and it reduces the possibility of accidentally moving or resizing windows (for people that use the mouse to interact with the game). At the same time, it's probably not intuitive, especially for users going to SDL2 from SDL1. I don't have a suggestion for how to improve this though, other than the standard resize behavior of mousing over the border of a window and seeing the cursor change.

Great work dudes! Looking forward to seeing this UI land in an official release.

Hi, thanks for feedback! Sorry for abandoning you guys temporarily.

Reasonable complaint. Perhaps the text of menu items should also be highlighted on mouseover? (like buttons do)

Actually the main reason for doing the UI like that was what Grotug said ("I don't like to see any elements that aren't part of the game on my screen. Therefore, it's really important to me to have the main Angband window take up as much of my screen as possible, and for there to be no white space anywhere on the screen ...")
One of the things I really didn't like about SDL1 port is that UI elements are small and bright (yellow), while the game itself is very dark. Small, bright elements of dark background attract attention, which is the opposite of how the UI should be - it's the game that is the foreground, and UI is background! The buttons (especially "Size" and "Move") are hard to notice, which is a problem, but on the other hand, it's a feature :)
Anyway, it's indeed a bit of a problem and I think the way to fix it is to add "Help" item to the menu, which will display a short help file, describing how to use the UI. Come to think of it, I can reuse Angband's help reader for that... Anyone wants to write the help file? :)

Oooh, great news! I'd like to try that. I couldn't find any summary on the first post of this thread. Could you tell me how to compile your work? Is it on some branch or just master?

@Bandobras: it is in master. I have recently posted instructions on how to compile it (for Linux) in another thread: http://angband.oook.cz/forum/showpos...63&postcount=9 .

Thank you very much. I've got it to compile on Ubuntu 16.04 with `./configure --with-no-install --enable-sdl2 --disable-sdl2-mixer` and it runs perfectly, except for 2 quirks. First, I couldn't get rid of the transparency and actually start playing until I quit and restarted for the first time. Second, I can't get rid of the top row, the SDL menu. If the "Top" option is supposed to show/hide it, it doesn't and it seems to have no effect.

What do you mean "get rid of transparency"?

It's always shown. I considered adding an option to hide it, but decided that it's small enough already.

This option is applied to terms (subwindows), and it means "always on top". This can be useful if you play with a mouse (except noone plays Angband with a mouse :) )
Someone really should write a readme :)
I am still pretty busy ATM, but hopefully soon I will find some time to work on the port. In the meantime, people, keep reporting about various issues!

All fair enough.

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. Anyway, the background is black now, which is what I wanted.

BTW, I'd like to report the scaled font I'm aspiring to contribute to Angband (https://github.com/angband/angband/b...s/16x16xw.woff) works fine with the SDL2 frontend. 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.

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

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

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

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.

Huh, suddenly between this

https://github.com/Mikolaj/angband/c...55ad910fbbce00

and this commit

https://github.com/Mikolaj/angband/c...ec29ce9301bb1d

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

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

Edit: my .angband/Angband/sdl2init.txt

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.

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

Not recommended, sdl2init.txt is not really human editable :)

Then most likely FT_IS_FIXED_WIDTH() fails.

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

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?

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.

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.

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.

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

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.

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.

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

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! :)

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

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 :(

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/

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.

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!

Cool :D 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).

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

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... :D

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. :D

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

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

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

Any improvements you make to this frontend gratefully received :)

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... :D

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: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."

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.

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

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

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.

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.

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.