Cocoa build on OSX

[Derakon]

I'd like to be able to get some coding done while I'm on vacation. However, my (newly-replaced after the old one died) laptop is running OSX 10.7. The Carbon build no longer compiles, presumably because Apple got around to nixing support for Carbon. The Cocoa build does compile...but it has some issues. Here's the splash screen, for example:



Looks an awful lot like the UTF-8 display bug, and reminds me of the other time I encountered garbled text. Is this known?

[Nick]

The Cocoa issue is known, and (at least) believed to be a UTF-8 thing.

This thread may has some information, but maybe not the full story.

I am currently able to compile FAangband (and Beleriand, such as it is) on 10.7 - they are both on github. In both cases I have made a main-leo.c and a Makefile.leo (yes, I know) and it all works fine, but as the thread shows, camb had some difficulties with NPP.

Of course, you could always spend your time fixing the Cocoa port

[Derakon]

I opted for the latter, on the theory that Cocoa is the way of the future. And progress is being made. So.

In z-term.c, we're tossing around wchar_t character arrays. term_text_cocoa in main-cocoa.m didn't know this and was treating them as char arrays. This had two main effects:

* Only 1/4th of the string to be drawn actually got drawn.
* The characters in what was drawn were drawn 4 times further apart than they should have been.

Fortunately, just changing the type of the argument to the function, and a few manual casts, fixed that issue, so now the game will run legibly, at least in my brief tests.

UTF-8 support isn't perfect yet; Mumaks are displayed as "Mûmak" (that's M, A with a tilde, double-close-wakka (i.e. ">>" as a single character), "mak"). Still, this is a damned sight better than what we used to have.

One concern: the Cocoa port scales the fort size with the window size (the fonts menu lets you set the font size, but that just tweaks how detailed the fonts are). I'd much rather scale the viewable area with the window size and set the font size elsewhere. Does anyone know offhand how to enable that behavior? Or am I going to have to figure it out myself? (EDIT: also, no extra term windows = sad Derakon)

Anyway, here's the change.

[Nick]

This is awesome.

Originally Posted by Derakon

One concern: the Cocoa port scales the fort size with the window size (the fonts menu lets you set the font size, but that just tweaks how detailed the fonts are). I'd much rather scale the viewable area with the window size and set the font size elsewhere. Does anyone know offhand how to enable that behavior? Or am I going to have to figure it out myself? (EDIT: also, no extra term windows = sad Derakon)

Those are the two immediate issues for me, too. One other thing I noticed (I'm not sure if it's just v4 or V as well); 'K' for unignore conflicts with run north using the roguelike keys. Filed as #1604.

[d_m]

Originally Posted by Derakon

One concern: the Cocoa port scales the fort size with the window size (the fonts menu lets you set the font size, but that just tweaks how detailed the fonts are). I'd much rather scale the viewable area with the window size and set the font size elsewhere. Does anyone know offhand how to enable that behavior? Or am I going to have to figure it out myself? (EDIT: also, no extra term windows = sad Derakon)

Hey.

I've been absent for awhile but I will just pop in to say that:

1. The guy who coded up this port is here: http://ridiculousfish.com/blog/

2. I think he specifically wanted the scaling for e.g. Angband screensavers and full screen mode. It may be possible to compromise on a menu option or a preference or something for how to handle scaling--I'm not sure.

I too find that the scaling (especially with subwindows) to be a bit of a weird thing.

[ghengiz]

Originally Posted by Derakon

no extra term windows = sad Derakon

that's exactly why I ditch the osx version (which would be native on my laptop) in favour of compiling the console version with X11 support

[Derakon]

Magnate asked me to put the Cocoa stuff in its own branch...so, only forty-five minutes of wrestling with git later, here we are.

Thanks for pointing me to the original port creator, Fizzix. We'll see how much effort I'm willing to devote to Cocoa instead of the new combat system; my main objective was just to get something that would run nicely on my laptop, and that's accomplished.

EDIT: ah, extra term windows work differently in the Cocoa branch. Instead of opening a new window, then telling the game what to draw there (via the window settings options), you just set the options and new terms are automatically created or destroyed. That's neat, if a bit contrary to how I'm used to things working.

[myshkin]

Originally Posted by ghengiz

that's exactly why I ditch the osx version (which would be native on my laptop) in favour of compiling the console version with X11 support

Hm, are you talking about the Cocoa version or the Carbon version? The latter supports subwindows just fine, albeit slightly differently from how other ports handle them.

[myshkin]

Originally Posted by Nick

Those are the two immediate issues for me, too. One other thing I noticed (I'm not sure if it's just v4 or V as well); 'K' for unignore conflicts with run north using the roguelike keys. Filed as #1604.

Thanks. I thought I'd noted that before, but I can't find a ticket. A workaround for the moment is \K, but of course that's obnoxious to use.

[ghengiz]

Originally Posted by myshkin

Hm, are you talking about the Cocoa version or the Carbon version? The latter supports subwindows just fine, albeit slightly differently from how other ports handle them.

I know...but I have a little nuisance that can be sintetized in the following two points:
1) the last osx pre-made version for vanilla is 3.2, which works fine, even the sub-windows part, but I like 3.3.2 more;
2) I cannot compile successfully main-crb.c of v3.3.2 on lion 10.7.2 with neither xcode 4.2 nor fink' gcc' libraries, due apparently to some issues introduced with the mouse routines.

I don't mind to tinker with the source files to make the mouse working (and therefore to finish the compilation), when I can just compile the curses version with X11 support

In order to answer your question, I suppose it's the carbon version, because the makefile.osx tries to compile main-crb.c