Angband.oook.cz
Angband.oook.cz
AboutVariantsLadderForumCompetitionComicScreenshotsFunniesLinks

Go Back   Angband Forums > Angband > Development

Reply
 
Thread Tools Display Modes
Old June 9, 2011, 01:17   #11
Therem Harth
Knight
 
Therem Harth's Avatar
 
Join Date: Jan 2008
Location: New England winter
Posts: 908
Therem Harth is on a distinguished road
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.
Therem Harth is offline   Reply With Quote
Old June 9, 2011, 03:08   #12
AnonymousHero
Veteran
 
AnonymousHero's Avatar
 
Join Date: Jun 2007
Posts: 1,367
AnonymousHero is on a distinguished road
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.
AnonymousHero is offline   Reply With Quote
Old June 9, 2011, 04:42   #13
Therem Harth
Knight
 
Therem Harth's Avatar
 
Join Date: Jan 2008
Location: New England winter
Posts: 908
Therem Harth is on a distinguished road
Oh... Thanks.
Therem Harth is offline   Reply With Quote
Old June 9, 2011, 13:23   #14
takkaria
Veteran
 
takkaria's Avatar
 
Join Date: Apr 2007
Posts: 1,923
Donated: $40
takkaria is on a distinguished road
Quote:
Originally Posted by AnonymousHero View Post
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.
__________________
takkaria whispers something about options. -more-
takkaria is offline   Reply With Quote
Old June 9, 2011, 16:20   #15
AnonymousHero
Veteran
 
AnonymousHero's Avatar
 
Join Date: Jun 2007
Posts: 1,367
AnonymousHero is on a distinguished road
Quote:
Originally Posted by takkaria View Post
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.
AnonymousHero is offline   Reply With Quote
Old June 9, 2011, 16:57   #16
takkaria
Veteran
 
takkaria's Avatar
 
Join Date: Apr 2007
Posts: 1,923
Donated: $40
takkaria is on a distinguished road
Quote:
Originally Posted by AnonymousHero View Post
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.
__________________
takkaria whispers something about options. -more-
takkaria is offline   Reply With Quote
Old June 9, 2011, 21:59   #17
Therem Harth
Knight
 
Therem Harth's Avatar
 
Join Date: Jan 2008
Location: New England winter
Posts: 908
Therem Harth is on a distinguished road
*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.
Therem Harth is offline   Reply With Quote
Old June 10, 2011, 05:37   #18
zaimoni
Knight
 
zaimoni's Avatar
 
Join Date: Apr 2007
Posts: 590
zaimoni is on a distinguished road
Quote:
Originally Posted by takkaria View Post
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.
__________________
Zaiband: end the "I shouldn't have survived that" experience. V3.0.6 fork on Hg.
Zaiband 3.0.10 ETA Mar. 7 2011 (Yes, schedule slipped. Latest testing indicates not enough assert() calls to allow release.)
Z.C++: pre-alpha C/C++ compiler system (usable preprocessor). Also on Hg. Z.C++ 0.0.10 ETA December 31 2011
zaimoni is offline   Reply With Quote
Old July 30, 2011, 03:26   #19
Therem Harth
Knight
 
Therem Harth's Avatar
 
Join Date: Jan 2008
Location: New England winter
Posts: 908
Therem Harth is on a distinguished road
/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.

Code:
		/* 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.

Last edited by Therem Harth; July 30, 2011 at 03:49.
Therem Harth is offline   Reply With Quote
Old July 31, 2011, 05:52   #20
Omnipact
Rookie
 
Join Date: Jun 2007
Location: Bristol, UK
Posts: 23
Omnipact is on a distinguished road
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?
Omnipact is offline   Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
NPP sdl Nick Variants 10 July 15, 2010 06:23
Angband under X11 Magnate Vanilla 3 December 13, 2009 21:56
Down with the SDL! Pete Mack Development 0 August 13, 2009 04:26
SDL sound Nick Development 1 July 16, 2009 21:14
Ubuntu SDL Help? benhamill Vanilla 12 February 24, 2009 21:19


All times are GMT +1. The time now is 15:22.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.