Re: Angband with an accent: displaying extended characters

On 2005-10-21, Antony Sidwell <ajps@xxxxxxxxxxxxx> wrote:
> Christer Nyfalt <christer.nyfalt@xxxxxxxxxxxxxx> wrote:
>
>> On 2005-10-20, Antony Sidwell <ajps@xxxxxxxxxxxxx> wrote:
>
> [Sangband and making it work on RISC OS]
>
>> > It is possible to make it work, I believe, because everything compiled
>> > reasonably straightforwardly when I last looked into it. It just lacks
>> > platform specifics. I'd certainly expect a port to be possible, because
>> > there's no particular reason to stray from ANSI (or ISO, whatever) C
>> > except in the frontends, and Leon knows what he's doing. :) What sort
>> > of things are you thinking of when you say "...don't have to take it
>> > into consideration any more", out of interest? Removal of all
>> > platform-specific hooks such as for file and memory handling?
>> >
>> Well, mainly that there are (or was) several places where unused #ifdefs
>> clutter the code and making things harder to test and modify.
>> Things related to RISCOS aren't so bad anymore, fortunately, because I moved
>> the file handling functions from util.c to z-file.
>>
>> About platform stuff, the ideal situation would be if all platform dependent
>> things was located in the main-xxx files and the ordinary *band files
>> was kept clean of non-include-guard ifdefs.
>
> Couldn't agree more, code which uses such things (the mess of checks for
> whether to call stat() or not comes to mind in most variants) really
> needs rewriting to shift the implementation details into main-xxx files.
> My problem when maintaining ports of many variants is that changes that
> aren't reflected in all variants makes it that much more trouble to keep
> frontends up to date, but I think I covered that already.
>
I considered using the main-gtk2 from ToME as the base GTK port for
Sangband, but the liberal use of ifdefs scared me away from it.

Is the following lines in externs.h really neccessary for the RISCOS port?
#ifdef RISCOS
/* main-ros.c */
extern char *riscosify_name(cptr path);
#endif /* RISCOS */

It seems to me that the function shouldn't be declared extern because
it isn't used by the main Sangband code.

>> If something is broken and if the ones who might be interested
>> in using it doesn't care about fixing it, why should we who doesn't need
>> it care about support it?
>>
>> We are at least not in a hurry to remove support for RISCOS, AMIGA or OS/2.
>> Non-Unix mainframe support is removed. I would rather remove NeXT support
>> because it has some very ugly hacks (fat binaries, non-standard C library
>> include names) that are getting on my nerves.
>
> Well, yes, but that's a limited definition of "support" really. If I
> don't send you fixes for stuff that breaks on my platform you can't make
> the changes. I'm supporting the platform, you're being good enough to
> incorporate that support back into the main trunk. :)
>
:)

> Removing support for a platform implied to me an effort to remove the
> abstractions which currently make it possible to port it to all these
> platforms, rather than removing stuff which shouldn't have been there
> anyway.

Like rewriting the way z-term works.

> The idea isn't to code new assumptions into the game that you
> know to be true on the two or three "supported" platforms, just that you
> don't want to make life harder for somone who *is* compiling for another
> platform by making them reimplement things which work now. Is that
> about right?
>

Yes, we want to find out which ports that might become supported in the
future and which ones are lost cases that none care or compile for anymore.
This makes it easier to make decisions. We have considered getting a platform
independent port however, and have toyed around with GTK and SDL as candidates.
GTK was rejected because it requires quite sizeable libraries to be installed
to Windows.

AFAIK, the port status for Sangband is as follows:
- Windows, Linux and other POSIX.1 compatible Unixes -- supported.
- Mac -- files are in, but not actively supported(???)
- Acorn RISCOS -- not supported, but the relevant main files are
maintained and compiled for other variants.
- OS/2 & Amiga -- not supported, no one has compiled any *band for these
platforms in a long time, but there is player interest.
- The rest -- not supported, no interest, no support in any *band for a long
time.

>> > As for whether I intend to provide a port - no, I don't. The
>> > introduction of "hot bigscreen" made it more trouble than it's worth for
>> > me to make and support a port for this platform. It's complicated
>> > enough keeping track of the minor differences over all the variants I
>> > compile without worrying about the larger changes S requires, and at the
>> > moment I have neither the time nor the inclination. The inclination
>> > might come once 1.0.0 comes out, of course. That would seem the most
>> > appropriate time to do a one-off port outside of my usual build system.
>> >
>> Would a change to non-hot bigscreen help (50-rows only)?
>> (I'm assuming that hot means the use of dual fonts and ability to change
>> from 25 to 50 rows and back.)
>
> It's Leon's term, not mine, and that's what I've taken it to mean. :)
> Yes, it would be easier to implement it as a single-font, fixed-size
> window, and that's where I thought I'd start if I ever got that far. If
> it's a fixed size 80x50 window, I'd also have to check that there are
> fonts which will still let the game play on smaller displays, and
> make a few other changes, but it would be easier at least.

I wonder if it's possible to code the port in a way that it just refuses to
change the number of rows in use.
I leave further discussion on this subject to you and Leon.


--
Christer Nyfalt

.

Relevant Pages

  • Re: Angband with an accent: displaying extended characters
    ... I'd certainly expect a port to be possible, ... > About platform stuff, the ideal situation would be if all platform dependent ... needs rewriting to shift the implementation details into main-xxx files. ... > We are at least not in a hurry to remove support for RISCOS, ...
    (rec.games.roguelike.angband)
  • Re: Actually I am a little bit disappointed...
    ... I do prefare to be able to compile ... > each platform than to use .net. ... Joanna Carter ... TeamMM support for ModelMaker ...
    (borland.public.delphi.non-technical)
  • Re: Defining int64
    ... will fail to compile on such an implementation; ... attempting to port it will at least be ade aware of the trouble. ... is mandated by C99 but was absent from C90, ... support for `long long' in things like printfmay not ...
    (comp.lang.c)
  • Re: Opteron
    ... the processor and HP Integrity is the platform. ... OpenVMS I64 and for HP-UX, it works, and Integrity servers available. ... I know of no plans to port OpenVMS to x86-64. ... dumping OpenVMS support to India will also enable more North American ...
    (comp.os.vms)
  • Re: ternary expression validity
    ... I've been asked to port some old code to a new platform. ... The code above is valid and should compile properly. ...
    (comp.lang.c)