QuickDraw 3D, MacOS X, Quesa... an idea

[rum]

As far as I understand, the main problem what do prevent creation MacOS X native CM application is the usage of legacy technology, QuickDraw 3D RAVE.

As QD3D RAVE support dropped under MacOS X, and its support under Classic environment is very limited, Battlefront cannt build OS X native version and CM cannt run under Classic Environment.

I know what where is a "Quesa" library, (www.quesa.org) which allow some QuickDraw3D application run under MacOS X natively.

I.e. carbon application, linking against QuickDraw 3D, runs under OS 9 using standard Apple QD3D, and under MacOS X using Quesa libraries.

Is it possible to build CM version in such way?

[Colin]

I'd really like to see a battlefront.com response to this. That is the first really constructive solution. Right now OS 9 crashes all the time and I can't bear to go back to non-protected memory and no multitasking.

Booting back to OS 9 is such a hassle if I'm playing PBEM. I just wanna be able to open up CM play a turn (10-15 minutes) and then continue what I'm working on. It's just too much hassle to boot back and TCP/IP really isn't the right pace to be playing this type of game at.

Steve, Charles, Matt!!!! PLEASE LOOK INTO THIS!!! I will be your personal slave for life if this is possible and you do!! AT LEAST CHECK IT OUT!!!

[Michael Emrys]

I don't speak for BFC, but they have made it pretty plain that this is not going to happen for any of the existing CM games. I think it is a pretty safe bet that we will see X compatibility in the CMII engine though. Hang in there, keep breathing, and all will come right in the end.

Michael

[Schrullenhaft]

The 'Quesa library' has been mentioned before (back in the days of CMBO in fact). I don't think that BTS/BFC will follow this path of uprgading CMB0 or CMBB however.

As neato as it sounds, such library conversions of 3D API are not always complete or perfect. This could result in all sorts of possible problems trying to convert CM using these libraries. Some features that are currently present in CM may not convert properly, resulting in them being dropped. It may not result in a functional game and Charles would have to do a lot more coding to get things to work (more than likely). There's a multitude of possible problems with this approach and additional unique bugs related to this sort of API conversion/interpretation.

There's also licensing costs to consider, which can add up to a hefty fee. To be honest I don't know what kind of sales of Mac copies BFC/BTS would have to make to cover this additional expense.

As stated previously the future is not re-releasing CMB0 & CMBB with some improved features or compatibility fixes for different OS's, etc. The next engine will be written with OpenGL as the graphics API, possibly resulting in a little less work for Charles by allowing the graphic API to be the same for both platforms (though there may still be differences).

As much of a let down that this may be for customers, it is a brutal fact of the game development business. If BTS/BFC were to spend the time (and money) to convert the current games, they wouldn't make enough money to cover their costs. Proceeding with work on the next engine with enhanced features is probably a much better decision for them.

[Colin]

But I don't care about Battlefront I only care about my self!!

Seriously I just can't get the new engine fast enough. OS X needs this game!!!

[tar]

There's also licensing costs to consider, which can add up to a hefty fee. To be honest I don't know what kind of sales of Mac copies BFC/BTS would have to make to cover this additional expense.

Quesa is LGPL (Gnus' Lesser General Public License) which means that the licensing costs will be zero.

As much of a let down that this may be for customers, it is a brutal fact of the game development business. If BTS/BFC were to spend the time (and money) to convert the current games, they wouldn't make enough money to cover their costs. Proceeding with work on the next engine with enhanced features is probably a much better decision for them.

Well, I for one would be willing to pay an upgrade fee to be able to run the games in OS X. An extra $20-$30 to get this would not be a problem for me.

Now, whether this would be feasible really depends on the amount of work involved. I think that examining the API to see if it covers enough functions to support CM would, I hope, not take up too much time. If the features aren't in the library, that would, of course, end the story.

If the required features are there, I would expect that it would be worth the gamble of one day's time to build and link against this library. If that results in a functional game, then BFC wins big. If it won't work that easily, in other words, if it takes more effort than just building the library and linking to it, then abandon the development. I can accept that there isn't a business case for putting much effort into this, but a quick feasibility check should be warranted.

[Colin]

He makes a good case.

I musta smoked out my brains.

[kmead]

Yup its a nice argument, and the same one we had a year and a half ago when it became clear that CMBO would not run under X natively. At that time it was nearly unanimous that we would all pay for the privelage to have CM work under X in some way, as a Classic or native app.

The thing you need to understand, and Schrullenhaft tried to make clear, is that there is a economic issue here. CMBO and CMBB were coded/programmed by one man. One. That means if he is working on this then he is not working on anything else. This is a business, and you have to pay the bills, with the success of the CM series, BFC had to add staff which means the basic number of dollars to keep every body in beer and pretzels has gone up by 2.5 (2 staff to 5). To get the money you need to sell product, in this case you have a bifurcated market that is dominated by one platform. In this case it is MSW with Mac OS coming in a very distant second.

Lets say CMBB sells 100k units and to be charitable, 15k or so are sold to Mac users. (BFC has never stated what the real proportion is so this is just for argument sake.) So, lets say they decide to redo the Mac version for better compatibility and it takes 6 months of Charles's time. When it comes out, 10k of the installed base decides to upgrade (the other third no longer play and or resent the idea of paying for an upgrade) then over the next 2.5 years they sell an additional 15k copies to new Mac OS users, for a total of 25k copies sold that are Mac OSX compatible. (Remember, the wargame simulation market is quite limited and BFC's distribution method is somewhat less efficient than some others ie you have to have internet to get it in the US and most of the world. In addition the CM series is gettng old and new products are coming on the market all the time.) So lets say that BFC nets 30 bucks per copy for a net income on the OSX version of 450k dollars, a nice chunk of change, that then is divided among the employees of BFC in the form of salaries or whatever the enumeration is.

In the mean time MSW sales continue, but are levelling off as other products come available and so lets say from the day Mac development begins to CMER intro, another 100k units are moved.

At CMER introduction with great accolades sells 200k MSW units and 20k Mac units (not all users buy again) for a total of 6.6m in the first year) three years from now.

OK here is the interesting part, imagine not doing a MacOSX version. So, over the intervening 2.5 years a smaller and smaller percentage of Mac users buy CM products (which truly is a shame) but its reality as OS9 bootable computers are no longer available new so few people buy an unsupported product. So they sell only another 5k units to Mac users.

In this case when its intro'd CMER sells a bit better to MSW users 210k, as there is more latent buzz from CMBB. Mac sales, for many reasons are only 15k units (lack of previous OSX version, declining MacOS market share, small wargame market etc.) So we have a difference of 20k Mac units sold but a gain of 10k MSW sales for a total net loss of 10k units sold.

This 300k dollars is the opportunity cost of not doing a Mac OSX version. In all likelyhood there would be considerable pull through sales of old CM products which would likely more than offset the cost of not doing a Mac version.

So for a 6 month delay in the development of a new product they do have some income, but it delays the introduction of CM Eritrea to Rome by 6-8 months. As it is likely that there will really be almost no difference in total income whether they do a X version or not, I can assure you they would much rather have the 6m or so dollars 6 months sooner for CMER and the next iterations of CM that would likely be able to follow much quicker than CMBB did CMBO.

I am just as disappointed as you all are that we will never have CMBO or CMBB under X (unless the Apple gods make a remarkable change). I have owned an Apple computer of one type or another since1983, so I really want it as I find myself playing X compatible games much more than I do CM with its attendant reboot to OS9.

My apologies for any logic faults or errors in my long winded arguement, I am not an economics, marketing or other soulless professional, it was just to roughly illustrate the point of why there will be no X version.

[ February 22, 2003, 09:33 AM: Message edited by: kmead ]

[tar]

Well, the rebuttal fundamenally relies on the estimate that it would take 6 months of Matt's time to make the compatible version.

We pretty much all understand that an effort of that magnitude would not be economical. The solution that was the basis of this thread is to see if there is a much simpler, quicker technical solution, one that would only require a day or two of programming time.

A short development time, along with a fee to upgrade would change the economics of the situation, since a successful upgrade would only require enough sales to cover a few days engineering time. It would also help keep the Mac sales up during the time (2 years?) of the expected new engine implementation.

[kmead]

Tar:

I am pretty sure that I covered each of your points already. Including, added sales from Mac users buying for 10. I suspect you over estimate the Mac wargamer market, of course I could be underestimating it as well .

As a point of interest, the programmer is Charles and not Matt. Matt has many other responsibilities that are equally important.

I chose 6 months as I thought it would be a reasonable time frame for one person to go through all the code and testing. Having been here a while, the time from Beta to Gold Demo was @6 months and the time to release after that was an additional 3. That was for polishing up the already finished program.

Maybe Steve will wiegh in on this, but in any case, I am pretty sure that this issue has been closed.

[tar]

Oops. My bad. I misremembered who was programming.

I suspect that the issue is closed, but hope springs eternal...

[kmead]

Indeed, hope springs eternal.

[Ben Galanti]

The thing one needs to understand about Quesa is that it is a replacement for the QuickDraw3D APIs not RAVE. QD3D was/is a higher level API for dealing with 3D graphics in terms of objects and scenes and what not. It's a level higher then RAVE. Now, originally they were intertwined, because RAVE was the low level API that QD3D used. What the Quesa developers have done is allowed the QD3D API to sit on top of different rendering engines. So, you can use the same QD3D calls but the underneath stuff is RAVE, OpenGL, or even DirectX (I think). The programmer is the insulated from the low level calls and can just use the higher level stuff.

Now, CMBO/CMBB apparently does use at least a few QD3D calls (I recently read that the models are in 3DMF format) but I think the problem is the low level RAVE calls themselves.

Obviously, this is a lot of conjecture on my part, but for the most part QD3D calls weren't used in games, it was the direct RAVE calls for better speed. Quesa really wouldn't fit the bill for this.

Now, the graphics library that translates DirectX calls to OpenGL (I forget the name off the top of my head) might be something that would work, but that won't happen for the reasons already outlined in other posts in this thread.

Ben