OpenUru.org

In the Deadline For Next MOULa Update - May 21. thread, Hoikas referenced an outstanding pull request on Bitbucket for an improvement to cursors and in the OP JW asked a question on the status of the (delayed) Unicode update. I didn't want to derail that thread, so brought my thoughts here.

Now, I may be mixing apples and oranges here, and if so I apologise in advance, but I have an idea that these two things are somewhat related...
Looking at the pull request, I see that it makes reference to a "client resource manager". I have a vague recollection that the Unicode stuff also made use of a resource manager and an even more vague recollection of rarified commenting that there was some problem getting the resource manager to work in the OU build, and that was why Unicode got put on a back burner. Assuming a) that I'm remembering correctly (of which there's no guarantee) and b) that the same "resource manager" applies in both cases then it would look like the problems rarified had with Unicode would also stymie the cursors?

As an aside, since the cursors update requires a newer libpng then that's probably something that needs to be flagged up to Cyan in plenty of time: Since we don't really know what else may be dependant on the MOULa build environment we ought to be cautious on things like that (we have inferred that Cyan's build engine is something of a custom "monolith" and possibly does a lot of things we know nothing of). It's probably unlikely to be a big issue, but it's worth mentioning, I think.

I’m not sure what the difficulties with the Unicode support were (I don’t even remember if rarified has ever publicly gone into details about it) and if there is a “resource manager” involved with it (and it’s too late at night now to do the research), but I think I can put your worries to rest based on the following arguments:

• The plClientResMgr that Deledrius added is something completely new and deals with loading images (such as cursors) from an external file. It shouldn’t have anything to do with Unicode support.
• While the Unicode support is something still to be ported (and apparently there are difficulties in that), the cursors are ported and work in CWE-ou right now. The revisions only need to be pulled, all that remains is determining that nothing else is wrong with them.

You are right about the libpng update. It would be nice if we could just quickly ask Cyan about that, but past experience unfortunately suggests that such attempts are hopeless.

Christian Walther wrote:It would be nice if we could just quickly ask Cyan about that, but past experience unfortunately suggests that such attempts are hopeless.

Mark guesses that libpng wouldn't be much of a problem. Make sure it is backward compatible. Maybe provide a way to have both old and new libs? Or maybe some kind of conversion process... or something.

Quick enough?

JWPlatt wrote:

Christian Walther wrote:It would be nice if we could just quickly ask Cyan about that, but past experience unfortunately suggests that such attempts are hopeless.

Mark guesses that libpng wouldn't be much of a problem. Make sure it is backward compatible. Maybe provide a way to have both old and new libs? Or maybe some kind of conversion process... or something.

Quick enough?

Are they already using it? I don't recall any part of the existing code referencing it.

Anyway, AFAIK libpng hasn't changed their API, so it shouldn't be any more trouble than the usual in updating which libs you're linking against.

Cool

Re libpng:

Deledrius wrote:Are they already using it? I don't recall any part of the existing code referencing it.

That's what I was getting at - the code that's so far been released might not reference it, but much of the build environment is shared with the server and its tools which we've no visibility of, and maybe other things too. I was just urging caution about possible unseen knock-on effects of changing a library.

Oh, good point.

Sadly, yeah... there's nothing we can do about the black box. Anything at all (or nothing) could very well be in there.

But, as for libpng, it should be fairly isolated.

JWPlatt wrote:

Christian Walther wrote:It would be nice if we could just quickly ask Cyan about that, but past experience unfortunately suggests that such attempts are hopeless.

Mark guesses that libpng wouldn't be much of a problem. Make sure it is backward compatible. Maybe provide a way to have both old and new libs? Or maybe some kind of conversion process... or something.

Quick enough?

Too quick! We haven’t had time to formulate the question yet! Good to hear anyway.

I don’t expect any issues with libpng, although anything is possible with the black box – there were API changes between 1.2 and 1.5, even though apparently mostly dealing with deprecated functions – but I’d rather not work around hypothetical problems before we know that they exist. “Make sure it is backward compatible” is easily said but impossible to do when you don’t know what you need to be compatible with – if it can be anything, then the only option is making no change at all.

However, there is a potential issue with zlib and projects in the black box, as described in the commit message of 9ab39e63d874: headers are now under XPlatform/zlib rather than XPlatform/zlib/inc. That’s where they are in current zlib source distributions. The projects we have I have adjusted to that, the ones we don’t have, if there are any, I obviously can’t. I could change that and require that developers create that folder and move the headers there when installing the library, but I would prefer not to, because adjusting the projects is something that can be done once in version control (and it’s a pretty simple search-and-replace change), while installing the library is something that every single developer must do when setting up their build environment.

Just since I saw it last night.....

While I was updating a few things in my build one of the errors that I hit is a Unicode specific one. There are several (less then a dozen) string comparisons buried in there that evaluate correctly in english but wrong in Unicode. It's a uppercase/lowercase thing in the file extension code (GIF, and gif) don't evaluate the same. It's also used in other places but that was the bit I saw last night.