Need advice... X11 vs. SDL

[Therem Harth]

As most of you probably know, I've been working for some time on a T2 variant (or maybe more accurately "semi-variant"). Currently I think it's almost ready to release... But first I'd like to clean up the user interface stuff.

I've got two choices for the UI, as far as I can tell...

1. Use the Windows interface for Windows and the X11 interface for everything else.

The good: more effort seems to have gone into maintaining these interfaces than SDL, and X11 gives me the least grief on Linux.

The bad: sound support only exists for Windows. X11 works on Linux and Mac, but might not work on OSes like Haiku down the road. I don't have a Windows machine I can do development on, so bugfixes for the Windows interface would be... difficult. Finally, shipping binaries for different Linux distros (let alone Mac) might be an issue.

2. Use SDL and ditch everything else.

The good: it's only one UI, and it's cross platform, which should make things easier (once I get my footing with it).

The bad: the T2 SDL interface appears not to have been maintained for a while, and is missing a LOT of features. It is also excruciatingly sluggish, for reasons I'm having trouble figuring out.

...

Which path do you guys think I should take? Seeing as V uses SDL as the default I'm inclined to go that way, but I have a feeling it might be kind of painful.

[Derakon]

I really don't like the SDL interface for Angband, since I'm heavily reliant on having multiple windows, and SDL only supports one window. Sure you can subdivide that window, but it's nowhere near as usable as having multiple distinct windows.

I don't see lack of sound as being an issue...but then again I haven't tried playing with sound for over a decade. Being unable to debug Windows problems is going to be an issue for you regardless of what you do since you don't have a Windows machine to test on.

[d_m]

In a selfish way, I would like for you to work on SDL. I think V's SDL is better than T2's SDL and we could maybe try to port many of its features over. Also, I think SDL has good support for sound and other features.

As far as I know the one big "problem" with SDL is that it only supports using a single window, so you end up with "virtual windows" inside one big (possibly fullscreen) window. I personally like this behavior pretty well although some people might not. The biggest problem I have with SDL right now are the fonts (which I think are ugly) and also the general Angband UI (I think it needs some work, some of the text is too small, weird feel) but I think it's definitely fixable.

Takkaria has talked about moving more of our ports over to SDL and it would need to get some love and attention for that to happen. It'd be great to get another developer on board who's excited about working on SDL and who we could collaborate with.

If you want to chat about it, feel free to hang out in #angband-dev and ask about it. Many of us are idle there but usually someone is around to chat.

[d_m]

Being unable to debug Windows problems is going to be an issue for you regardless of what you do since you don't have a Windows machine to test on.

This is a huge problem for the current V devteam. As far as I know Fizzix is the only dev who actually runs Windows. I end up working on lots of Windows issues using Mingw + WINE, which is kind of frustrating but does (mostly) work.

If you try to do this I recommend getting crossbuilding working using Mingw + WINE. I can help you get this set up if you're using Linux.

[Derakon]

Getting off-topic, but personally, I think the best way to go moving forwards is OpenGL. This gives you plenty of flexibility at the cost of some increased complexity. I know it took me awhile to figure out how to do 2D display properly in OpenGL, but now that I have it it makes things much simpler for me. And there's no single-window constraint (using a UI library like Qt or wxWidgets), but if you want to you can still do the "virtual subwindow" thing. You just render to a texture and then render that texture to the canvas as a subwindow, instead of rendering directly to the canvas. Presumably the current SDL implementation does something similar using surfaces.

Two big things you can do in OpenGL that SDL doesn't handle well: image transformations and 3D. 'Nuff said about the latter, but for the former, OpenGL could trivially do the 'M' map functionality by simply applying a scaling factor before rendering. SDL does everything in software which makes such effects much more expensive. Of course Angband currently does some "smart" downscaling to fit within the constraints of the ASCII tileset, at the cost of fidelity.

[Therem Harth]

Wow, thanks for the replies... I kind of expected nobody to say anything.

Derakon: What are the alternatives? Tk maybe? I know pretty much zilch about GUI programming, but TK looks rather easy to use (at least in scripting languages)...

d_m: I was thinking of trying to port V's SDL interface to T2, but frankly I may not have the skills to do it on my own, so thank you for the offer of help!

Re MinGW and Wine, that sounds like a good idea, and maybe less of a pain than developing on Windows (which I find to be very annoying).

As for OpenGL... In theory, it sounds wonderful. In practice, I'm really not sure. My netbook can run Nexuiz with no problems, but it almost chokes on ToME 4, which makes me think that software rendering in OpenGL is a lot more expensive than in SDL (seeing how fast the Vanilla SDL interface is). And as for hardware acceleration, ideally that should be optional I think. IMO a text-based game should be able to run under Xvesa, or on machines with really bad hardware (think S3 Savage and Unichrome).

[Derakon]

I've never used Tk myself, so I don't really know what its limitations and capabilities are.

Properly-written OpenGL should be strictly faster than properly-written SDL. SDL uses software rendering for everything, even if you have a graphics card; OpenGL just uses software rendering if a graphics card isn't available. If ToME 4 has a laggy UI, then that's ToME 4's fault, not OpenGL's fault. Put another way, there are thousands of games out there that use OpenGL for rendering, do way more complicated stuff than turn-based tile-based RPGs, and run just fine on ten-year-old hardware.

OpenGL can run over the network, too. I have some apps I maintain for work that use OpenGL rendering and can be run over the network. Of course you wouldn't be able to play inside a terminal (you'd have to use X forwarding instead), but any multi-window mode is going to have that problem.

[Therem Harth]

Okay, I think I've reached a decision... I'm going to start trying to port over the V SDL interface in a new branch. For now I figure I'll leave the X11, curses, and Windows modes in; but I will eventually remove stuff like XAW and GTK support.

This is mostly because SDL looks fairly simple to deal with, from what I've seen of it, and a lot of the stuff is there already; whereas OpenGL is a whole new thing, and looks more complicated. Here's to hoping it won't eventually bite me in the rear.

[Tobias]

How do I even start the windows sdl version? I never figured that out.

On linux I only use the sdl version. Having all the subwindows together in a big window is just so convenient.

[AnonymousHero]

As far as I know the one big "problem" with SDL is that it only supports using a single window, so you end up with "virtual windows" inside one big (possibly fullscreen) window.

This is the reason I never use SDL. Using a single window completely breaks multi-monitor setups. (Most games can get away with it, but in *banding I rely heavily on the various status windows.)

EDIT: Btw, one of the reasons the X11 interface is awful (from a programming point of view) is its reliance on Xlib/Xaw. If you were to use Qt or WxWindows it'd be a lot nicer to program.

[Therem Harth]

Hmm. If I could get the GTK interface working it would be nice... It just seems to suffer from a lot of strange bugs. Also there's the whole thing with GTK3.

(Though I wonder about GTK3's future. Gnome 3 is a dead end if ever I saw one.)

Qt, WxWidgets, FLTK, and FOX all seem to rely on C++, so I think they're out... I mean I could fork AH's C++ branch, but I still can't get the thing to compile on 32-bit machines.

I wish I had the skill and the time to port this whole thing to another language. I'm starting to hate C and its pointers with a fiery passion.

[AnonymousHero]

Almost all your code can remain in C even if you're using Qt/WxWindows. Since C and C++ are ABI compatible the GUI code can call into the C code without problems and if you compile the C code with the C++ compiler you're also free to actually call C++ code in your C functions.

[Therem Harth]

Oh... Thanks.

[takkaria]

Almost all your code can remain in C even if you're using Qt/WxWindows. Since C and C++ are ABI compatible the GUI code can call into the C code without problems and if you compile the C code with the C++ compiler you're also free to actually call C++ code in your C functions.

You can't just compile C with a C++ compiler and expect it all to work though - there's differences that may create subtle bugs.

And, if you want to write a Qt frontent, that would be brilliant - we could then use it both on Windows and Linux for people who didn't like SDL.

[AnonymousHero]

You can't just compile C with a C++ compiler and expect it all to work though - there's differences that may create subtle bugs.

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.