Need advice... X11 vs. SDL

[takkaria]

True, but you can link.

Do you happen to have a rough idea of how much Angband code would be incorrect when compiled as C++ rather than C? (Obviously not counting trivial things like using "try" as the name of a variable, etc.)

I seem to recall the cases where things fail silently being pretty esoteric.

Not really. C++ uses extra consts in various standard library functions, enums are types, all memory allocation would need changing to use casts, non-externed const globals, probably some other bits and bobs. All minor nuisances, really, but the collective impact would be to make compiling as C++ a pain.

[Therem Harth]

*sigh*

Okay, I am now trying to make the GTK2 interface work properly. It's already there, it's cross-platform, it's fast enough, and it supports multiple windows, so why not? (Doubts about GTK's future notwithstanding, it's going to stick around for a while.)

I'm seeing two major problems...

1. Opening the Fonts and Terms menus will crash the game, because a g_assert catches that the widget is NULL.

The big issue here is that I can't get a backtrace; when I reproduce the crash under GDB, the menu captures my mouse, and keeps the mouse and keyboard captive until I switch to a VT and kill the T2 binary. So I have no real idea what is going on. It'd be nice if there were some way of keeping the menu from holding onto the mouse...

2. Shift + an arrow key moves one space instead of running.

This is quite annoying, and damned if I can see where it comes from. I *think* the GTK2 interface is intercepting certain key combinations when it shouldn't, but I'm not sure.

[zaimoni]

Not really. C++ uses extra consts in various standard library functions, enums are types, all memory allocation would need changing to use casts, non-externed const globals, probably some other bits and bobs. All minor nuisances, really, but the collective impact would be to make compiling as C++ a pain.

Of which the only one that actually bit when I forked Zaiband was "all memory allocation would need changing to use casts".

Yes enums are types but they have automatic conversion to their int representation so the effect on the V code base is next to non-existent.

[Therem Harth]

/resurrects

Okay this is weird. The GTK2 interface now works perfectly fine, with the one niggling exception of shift-to-run not working. AFAICT nothing has changed... But it works.

(Well, it does crash when I try to invoke graphics. But that's hardly surprising seeing as the graphics files aren't there.)

Does anyone maybe have any hints on why the GTK2 interface would fail intermittently like that?

Edit: in other news I've solved the running problem! In retrospect it should have been obvious, oh well. Anyway this section of code needs to be removed from main-gtk2.c.

		/* Hack - the cursor keys */
	case GDK_Up:
		{
			Term_keypress('8');
			return (TRUE);
		}

	case GDK_Down:
		{
			Term_keypress('2');
			return (TRUE);
		}

	case GDK_Left:
		{
			Term_keypress('4');
			return (TRUE);
		}

	case GDK_Right:
		{
			Term_keypress('6');
			return (TRUE);
		}

As I said, obvious in retrospect.

[Omnipact]

To go back to the SDL argument:

Firstly SDL can only ever display on one monitor - it is a limitation of the library.

To people who say the fonts are ugly/wrong then remember they are the .fon files which are used in the windows port - yet no-one moans about the fonts in the windows port! (does the windows port do anti-aliasing?)

The current SDL port doesn't do anti-aliasing, but it is very forgiving on lower end systems - its font renderer is very efficient.

I have recently been hacking around with the SDL port, getting ttf fonts to work with it... They work fine for stuff like the window labels and the top task bar thingy, BUT if you thought that they might look nicer than the original fonts then think again (they look worse!) - unless you bring in anti-aliasing.

I have some ideas for making the angband SDL experience much better - (especially with those gorgeous 64x64 tiles that shockbolt is creating) - with things like :
* 'Transparent' windows - have your messages/stats/stuff show over the main 'screen'
* Icon/Button thingies: click a button to cast/quaff etc - useful for beginners. (should easily mesh with the keypress/macro code)
* The ability to show subwindows using variable-width fonts (easier on the eye, uses less screen area)
* Some of shockbolt's stuff has alpha channels? SDL handles alpha channels out of the box... (I think)
* Anti-aliasing fonts
* Make the SDL port look less like 'angband within an application'
(after a year or two not playing and coming back to play with the SDL frontend - I realised what a truely unique and erm, quirky interface I had made! (I'm still proud that no major bugs were ever found though!))

The thing is, is that angband is designed around a 'terminal' display, and for a modern looking game display, is not very suitable.

On the wiki at rephial: improving the look of angband

The main terminal [Angband or Term0] is the main hurdle to getting a modern display - currently the message line and the stats bar on the left are hard-coded. If you want to write a nifty front-end for Angband, then it is going to turn ugly and very hacky with this current setup. (separating gfx and text)

Removing the stats section from the left of the screen is (probably) quite trivial, and there is a sub-window that you can bring up with the same info. The message line is somewhat more insiduous and deep-rooted in its implementation.

***

Okay, I've ranted a bit too much and this maybe should have gone into a new thread, but what I want to say is that I would love to bring some improvements to the SDL port, but I keep hitting a wall that says "but this is a 'terminal' application"!

I would love to see some more discussion about the future of the angband UI - as a hardcore ASCII player who has seen shockbolts tiles, I now want the whole screen to to filled with tiles and all my subwindows transparently displayed on top, and even stuff like histograms for my hp/mana/moster HP...
Not a 'window' based setup but a game with HUD elements to show me info.

Right, I'll shut up now.

Omni.

P.S. What happened to the mailing list?

[artes]

OpenGL is cool, and there are good tutorials on the Internet that makes learning it easy.

[Tobias]

Removing the stats section from the left of the screen is (probably) quite trivial, and there is a sub-window that you can bring up with the same info. The message line is somewhat more insiduous and deep-rooted in its implementation.

Remember to increase the number of subwindows, when you change this.
When I run the borg, I already have less subwindows then I need.

I do like the sdl-version. Having only one window makes it play nicer with buggy and exotic window manager.

I never look at the message line. Just use the log-window.

But if you look at LPs of the game, it looks like there are a lot of people who use no subwindows at all. And very few people ever find suwbwindow specific bugs, so it is probably even uncommon among the forum goers.

[Therem Harth]

/* Resurrected! */

Okay, I'm trying once again to revitalize the SDL interface. But as usual I'm running into problems.

The main problem is sluggishness. Even with shimmer and stuff turned off, rendering is very slow compared to X11 or GTK2.

It looked to me like there were several reasons for this...
1. Truetype fonts are used. Vanilla uses bitmap fonts.
2. The fonts are rendered blended, which is reputedly slow.
3. The fonts are antialiased.
4. Hardware surface is used when available, possibly leading to laggy copies between video and main RAM.

(1) I'm not touching yet, because Truetype fonts seem easier to deal with via SDL_ttf.

(2) I experimented with changing, using solid rendering instead (TTF_RenderGlyph_Solid()). But far from speeding the game up, this slowed it down, by roughly 50% if my eyes are anything to go by - and with max CPU usage when the character is running! I have to say this stumps me completely. OTOH, the solid fonts are much cleaner and more readable than blended ones.

(3) I tried to change, but old versions of SDL_ttf (e.g. the one used by Debian Stable) don't allow this, so I gave up for compatibility reasons.

(4) I changed so that the game uses only software surfaces, but it didn't seem to make any difference.

The only thing that seems to improve rendering speed visibly is disabling shimmer effects, and this doesn't work too well in e.g. swamps where there's a lot of mixed terrain in the field of vision. And that's a workaround anyway, not a real fix.

Are there any other things I should look at re the performance problems?

[Therem Harth]

Bah, forget it. The codebase for the SDL interface is clearly beyond my skills to turn into anything on par with the X11 one.

Future work will focus instead on improving the curses interface. Eventually, if I get good enough with C, I might try writing an interface with OpenGL and GLUT... But don't count on it.

[ogozi4]

I think OpenGL is a more preferable option.

[BreathesFire]

I am in the process of building a Windows OpenGL port, no guarantees though.