You're not the only Nova developer, Pipe

I am still in 9, for example. Though I do concede that I am among the minority

rmx256, on Sep 25 2005, 10:48 AM, said:

You're not the only Nova developer, Pipe

I am still in 9, for example. Though I do concede that I am among the minority
View Post

Jeepers. They haven't shipped a machine with OS 9 on it by default since... what, 2001?

My 9500/132 (daily driver) and my 8500/120 (renderfarm, webserver) are October 1995 vintage

Run quite well, also; at least as long as I only have one large ship in system.

rmx256, on Sep 24 2005, 09:03 PM, said:

Run quite well, also; at least as long as I only have one large ship in system.
View Post

Of course, ...

David Arthur, on Sep 23 2005, 11:15 AM, said:

Version 3.1 fixed the original resource-loss problem

There was another?

You know, there are other people out there with newer versions of REALbasic - SpacePirate and I both have 4.5.3, for instance, and Tom35 probably has the newest (that's all I can think of, though - seant has RB, but I think he still has 2.x or so) - and might it not be out of the question to ask one of them to try compiling MC for you, to see if it helps with the poor OS X support? Just a thought.

pipeline said:

Have you considered porting this across to XCode and Cocoa, David?

I have considered it, but given that it would involve re-writing it more or less from scratch (I could re-use the icon and maybe some of the interface ideas, but that's about it), I haven't considered it for very long.

The fact is, I'm still interested in EV and MissionComputer, but not nearly enough to re-write everything I've done since 2001 over again.

orcaloverbri9 said:

There was another?

3.1 fixed the original resource-loss problem, but introduced another, smaller one, which you experienced; 3.2 works around that one, along with a third, even-smaller one which as far as I know nobody ever actually experienced.

orcaloverbri9 said:

...might it not be out of the question to ask one of them to try compiling MC for you, to see if it helps with the poor OS X support?

It's not just a matter of re-compiling; it would take extensive re-coding to make MissionComputer work in a newer version of REALbasic, which I couldn't do without the new version to test it on, and even this was somehow accomplished, I wouldn't be able to upgrade it any further, since developing it would be dependent on software that I don't have.

David Arthur, on Sep 25 2005, 05:23 PM, said:

orcaloverbri9 said:

...might it not be out of the question to ask one of them to try compiling MC for you, to see if it helps with the poor OS X support?

It's not just a matter of re-compiling; it would take extensive re-coding to make MissionComputer work in a newer version of REALbasic, which I couldn't do without the new version to test it on, and even this was somehow accomplished, I wouldn't be able to upgrade it any further, since developing it would be dependent on software that I don't have.

Are you sure? I've found REALbasic migration to be fairly simple in my experience. I even managed to back-port an application from the demo of 5.5.3 to the full version of 4.5.3 with only a little bit of tweaking, and forward-porting is easier if 4 is anywhere near as smart as 5, which actually converted code for you.

MissionComputer is ~not~ a simple programme. I've done some experiments with demos of more recent versions, and there's no way I could produce code which would work in two different versions of REALbasic without substantial modifications each way.

Hmm. Oh well. Maybe Cocoa-fication is the best route for improved OS X support then. Granted it will be painfully difficult and time-consuming, but it is definitely superior to RB and will increase the overall quality of MC on OS X, not just the little quirks. Of course, even if you do take this route, it will be a long time, possibly after you have "completed" MC (i.e. implemented every good idea you can think of), but I don't think you should completely disregard the option. But hell, it's your program, do whatever you like with it.

Something tells me that by the time that our author in question completes his current upgrade path of MC, and was to begin the long process of creating a new Cocoa version EV's popularity would be fading- and most people would be using the os9 version (as most of the people playing it would be happy that such a good game existed for os9 )

David Arthur, on Sep 24 2005, 11:03 PM, said:

How else could I fit them in? There's so many that it would take several tabs to hold them all, and I don't want a NovaTools-like wasteland of uncategorised checkboxes.
View Post

Hm, I don't quite see what you're saying there. The only categorisation I can see is the separation of Flags1 and Flags2, which doesn't make a lot of sense for the user. NovaTools has positioned 3 of the flags near other related fields (I see you've done that for Xenophobic which is good). What if you put the flags in a separate window (like the jamming) so that you can see them all at once without making the original window any bigger?

I was referring to the fact that many NovaTools editors are predominantly a sea of check-boxes and other inputs; personally, I find it very difficult to locate anything. I may explore alternate arrangements at the same time as moving the jamming back in (I think the original reason for the jamming being separate was that I couldn't fit it in and still support 640x480 monitors, which remained an issue at that time).

I have given the idea of a Cocoa editor (it wouldn't be MissionComputer in any meaningful sense, since I'd have to start over) serious consideration, but the amount of time and effort involved is simply far more than is justified, especially given the age that EV would have reached by the time it was finished; it would also cut off support for older systems (a problem given that the market for ageing games is disproportionately biased towards older systems for obvious reasons), as well as any potential for adding Windows support.