aka_tom_w
-
Posts
8,130 -
Joined
-
Last visited
Posts posted by aka_tom_w
-
-
Now, THAT is the question we should be talking about it.Originally posted by MikeyD:About this causing game imbalance, CMSF's trend towards 'assymetric warfare' is going to make it interesting to set up games that both sides will agree are 'even'. How many untrained Jihadists and unarmed collaborators would equal a full-up Stryker Brigade company in tournament play? :eek:
It might come down to a "bidding thing"
Sort of like a game show where one player says "I can name that tune in 5 notes", the other player says I can name that tune in 3 notes (note, he one upped the bid so as not to get stuck with a counter offer of only 2 notes
).....so what is a fair fight?
NOW that is a HUGE question.
I would imagine there will be some for of bid and counter bid as to what each side/player considers they can win with.
"How many untrained (but fanatical) Jihadists, IED's, technicals and unarmed collaborators would equal a full-up Stryker Brigade company"??
dug into an urban environment with "home field advantage" IED's, RPG's, HMG technicals, and stealthy uncon "operatives" the real issue will be getting the numbers right for play balance, and I am guessing Rune and Steve are working on this very issue right now.
Great question though!
How's that for an answer, Victoria?
-tom w
[ February 22, 2007, 09:00 AM: Message edited by: aka_tom_w ]
-
nothing.
[ February 22, 2007, 04:47 PM: Message edited by: aka_tom_w ]
-
um
well
Well, I guess its back to the drawing board for Steve and the gang, maybe they should just start working on the WW II version of CMx2 now that we have that settled.Battlespace Shaping is the military doctrine for the elimination of the enemy's capability to fight in a coherent manner before committing forces to decisive operations.
-tom w
-
my guess is its running at:Originally posted by Battlefront.com:The bigger the screen, the slower the performance. Just a reminder for you big screen guys
I actually don't know what resolutions we are going to support. I'm running on an external 19" flatpanel. Can't remember what the resolution is so I'll check on that.
Steve
1680 x 1050
on the 19 inch Apple LCD
but I am just guessing
-tom w
-
worth noting:
Apple underclocking MacBook Pro graphics cardsBy Prince McLean
Friday, April 21, 2006
Published: 04:00 PM EST
Apple is trading graphics performance for battery life with its new line of Intel-based MacBook Pro notebooks.
The ATI Radeon X1600 graphics card inside each MacBook Pro is capable of running both its graphics processing unit and memory at about 470MHz, but avid computer users have discovered the cards are underclocked to 310MHz (GPU) and 278MHz (RAM).
The modifications cripple the speed of the graphics processor by about 34 percent and the memory by 41 percent.
Users discovered the change after installing Microsoft's Windows XP (with the help of Apple's Boot Camp software) and running a third party application called ATITool (0.25).
By sacrificing graphics performance, Apple was able to improve the MacBook Pro's battery life and keep the units near-silent.
Some daring MacBook Pro users successfully used the third party ATITool software to uncap the full potential of the ATI chip. They found it reduced the battery life of their MacBook Pro by about 30 minutes, but did not over heat the notebooks or cause any other side effects such as display artifacts.
However, one user said the uncapping "took only couple of seconds" to cause the system's cooling system fan to spin at a speed he "never experienced before."
-
worth the read
Thanks
that was a great story
-tom w
-
1280 x 854
This is ONLY a guess but in the OS X thread Steve has posted that he is running the beta code in XP on a MacBook Pro and my guess is (unless there is something funky in the beta code and he is seeing black bars on each side :confused: ) that he is running in wide screen mode at about 1280 x 854 which is the standard wide screen resolution of the 15inch Macbook Pro (I think).
I am on a 15 inch G4 Powerbook Mac (PPC NON intel) now and it is 1280 x 854.
The other large format Mac wide screen LCD is 1680 x 1050.
There has been no official comment but wide screen Macs never had any problem with any of the CMx1 games. FWIW
-tom w
[ February 21, 2007, 06:20 PM: Message edited by: aka_tom_w ]
-
Hi BatAttack
welcome
just a reminder, this is a very old thread, I bumped it because another new member was asking something about how cover and concealment would work in the new game.
Previous to the bump the posts in the thread were from Nov 2005.
FWIW
-tom w
-
um
" And if I were developing CM:SF with a feature like dynamic lighting, I'd have been bragging about it already."
They have it covered!
from the features section of the new CM:SF web site (its there).Stunning high resolution graphics featuring dynamic lighting and object self shadowingthis thread is old news from Sept 2005
Steve says Dynamic light is in, captured in the massive Winecap synposis thread.
Dynamic lightingYes, dynamic lighting has been in and working great for a long time. Time of day is set by the scenario and that changes, obviously, how things are lit up. Dynamic lighting game effects -> honestly I don't know. Not sure what Charles is planning on doing. It likely is something that can be improved upon even if we don't do much with it right away.
-
andAgain, the terrain mesh supports changes every 8m with variable depth. There is no special terrain type to discuss because it's up to the guy who makes the map how to make the topography. If he wants to simulate gullies and what not, he most certainly can within the 8m limitations I just mentioned.Steve
cassh says:
Steve-
Please tell me I am reading the above wrongly and you still have specific trench type engineering defences that can be placed; and that this can be done at the start of a battle by either player who has "trenchline" units or locked in place by the designer?
I would hate to think we had lost this basic military engineering ability that we've had since CMBB.
posted August 21, 2006 01:44 AM
Steve says:
cassh,
quote:
Please tell me I am reading the above wrongly and you still have specific trench type engineering defences that can be placed
end
Sorry, defenders are just going to have to make do with the trenches as they are placed by the scenario designer. On the fly placement of trenches is extremely involved because, unlike CMx1, they have to alter the map structure since they are truly 3D. They also have to alter the Action Spot map, which is set up at the time the map is made. It is possible these things can be worked around, but we aren't going to try to for 1.0. Too many things on the ToDo list.
Steve
Posts: 12938 | Registered: May 1999 | IP: Logged
dan/california
Member
Member # 17776
posted August 21, 2006 02:21 AM
How are you simulating large underground bunkers and some of the other more exotic digging enterprises that Hezbollah balked the Israelis with. Can it be put in at the scenario design stage or is that too much to hope for for 1.0?
Posts: 205 | Registered: Jul 2005 | IP: Logged
Battlefront.com
Administrator
Member # 42
posted August 21, 2006 02:45 AM
We have bunkers and, unlike CMx1, they can be dynamically occupied. We have two sizes right now... one that can hold 7men or less and the other up to 14 men. Headcount is relevant, not how many units. Meaning, you can in theory have four 3 man Teams in the large bunker or a single 12 man Squad and a 2 man Team.
Bunker types are yet to be defined, but I'm expecting at least wood/earth and concrete.
Steve
-
one more:
The terrain mesh allows us for 8m wide trenches, gullies, or whatever you want to call them. There is a lot of control over how deep these can be too.However, most of your post talks about things which have little to do with terrain, rather the ability to sneak around undetected based on presumptions of who was good or not good at it historically. This is a separate issue.
We never have, and never will, base modeling decisions on stereotypes. If there was a reason for Germans being better at night infiltration than some other nation (which is a VERY dangerous position to take ), it must be for some specific reason. For example, specialized training that another nation lacked. Or it could be that the Germans simply picked their best and most experienced soldiers and had them do the mission. Different reasons, different implications for modeling decisions.
For CM:SF we are not modeling any special abilities that can not be tied to equipment, training, or experience. If you use the right units in the right terrain the right way then you should have a pretty good chance of avoiding detection. EVEN IF the other side has Night Vision capabilities. These systems can't see everything all the time
Steve
-
bump for Lt Bull
-
bump
this is an old thread for Lt Bull
-
I think there some bones and hints about this somewhere
this post does not really "cover" it but so far I can't find the comment or post by Steve that I am searching for.
in my first search I found this: (the thread was called "Cover and concealment")
Battlefront.comAdministrator
Member # 42 posted October 22, 2006 12:37 PM
Hi all,
Concealment in buildings is the main reason for being in there since, as discussed, a modern dismounted force can make Swiss Cheese out of most structures. However, one must remember that ammunition and colateral damage concerns do have a part to play in this too. In order to effectively engage an enemy in a structure you have to know roughly where that enemy is within the structure itself. Not just which room, but where in that room and in what stance (standing, kneeling, prone). Otherewise suppression is the more likely end result not destruction.
Sure, there might be some bad guys in a building that your small arms can penetrate, but in a conventional MOUT setting how likely is it that a Rifle Squad will be able to put its full attention on that one building and fire until the structure is completely shot through? The situations like Saddam's sons' last stand are not that common in a high intensity fight, therefore buildings do offer quite a bit of practical protection.
BTW, this is one of the advantages the Stryker guys have over Mech Infantry and certainly over Light Infantry. Strykers have a gun that is quite capable of punching through pretty much any structure the infantry is likely to come upon. Since the Strykers can approach faster and far more silently than a Bradely, and offer more defensive protection than a Humvee, the Strykers can get right into the thick of the firefight and have maximum impact on the enemy. Not that having a Bradley pumping rounds into a structure is a bad thing Just pointing out that the .50 Cal is generally good enough and therefore the "stealth" attributes of the Stryker probably give it more chances to catch the enemy unaware compared to a Bradley.
Steve
[ February 20, 2007, 06:53 AM: Message edited by: aka_tom_w ]
-
Steve said no thanks to Cider in the "Running on Intel Mac Thread:Originally posted by grunt_GI:Steve.
I also wanted to thank you for all the prompt responses. As another poster reminded us, what about the new Cider technology?
re: Cider
There have been development kits like this in the past, though with the Intel hardware in place it has become a lot more viable. We're not interested in such a solution. It's likely easier for us to just port the game and probably cheaper too. Especially since this is not a one off game engine. If we use a 3rd party product we have to pay them for each release we do. If we do a port we don't.Steve
-
Thanks Steve for all your very prompt and informative replies!
-
Good pointOriginally posted by Sequoia:I assume additinal plans can always be devised and added to a scenario by some one other than the original designer? If so It'll mean a whole new category of files at the Scenario Depot. :cool:
if the plan or design or intention of BFC is the same as CMx1 there should be a form or "locked" scenario like the "Tournement Save" feature from CMx1.
That would mean (if they use that feature again) that scenarios could be locked or open. AND therefore one would hope other folks could add other optional or alternative plans to anyone else's scenario, especially after playing it, and seeing what could be done different or better.
Good thinking Sequoia!
-tom w
-
Dunno if it's of a any use... </font>Originally posted by Vanir Ausf B:Ran across this today.
</font><blockquote>quote:</font><hr />Cider is a sophisticated portability engine that allows Windows games to be run on Intel Macs without any modifications to the original game source code. Cider works by directly loading a Windows program into memory on an Intel-Mac and linking it to an optimized version of the Win32 APIs. Games are simply wrapped up in the Cider engine and they work on the Mac. This means developers only have one code base to maintain while keeping the ability to target multiple platforms. Cider powered games use the same copy protection, lobbies, game matching and connectivity as the original. All this means less work and lower costs. Cider is targeted at game developers and publishers and, unlike Cedega, is not an end user product.
-
Has anyone looked at "Cider" yet?
web page Cider FAQTransGaming's brand new Mac portability engine, Cider, gets Apple users to the core of gaming.No longer will Mac users be forced to wait months or years for the few top tier titles to get into their hands. With Cider, video game developers and publishers will finally have access to the rapidly growing Mac market, quickly, easily, without the costly price tag of traditional, arduous porting. Thanks to Cider, video game developers and publishers can extend their content to the Intel Macs quickly, cost-effectively, and with little to no effort on their part.
Stemming from the same technology foundation as TransGaming’s technical sensation, Cedega, Cider empowers game developers and publishers to release Mac editions of their titles. Cider is so effective that publishers will be able to simultaneously deploy the Mac and Windows versions of their titles, even for new games already in development. With Cider, whole catalogues of games can be easily brought to a brand new audience starving for games. Another great benefit is that games migrated to Intel Mac using Cider will also run on Linux under Cedega, forging a path to another game hungry market.
How Cider Works
Cider Screenshot
Cider is a sophisticated portability engine that allows Windows games to be run on Intel Macs without any modifications to the original game source code. Cider works by directly loading a Windows program into memory on an Intel-Mac and linking it to an optimized version of the Win32 APIs. Games are simply wrapped up in the Cider engine and they work on the Mac. This means developers only have one code base to maintain while keeping the ability to target multiple platforms. Cider powered games use the same copy protection, lobbies, game matching and connectivity as the original. All this means less work and lower costs. Cider is targeted at game developers and publishers and, unlike Cedega, is not an end user product.
The Intel-Mac Explosion
Cider Screenshot
Why should developers and publishers consider the Mac market? In the last quarter alone, Apple shipped almost a million Intel Macs, outpacing iPod sales for the first time in 2 years. Ben Reitzes for UBS Investment Research expects Apple to sell over 1.3 million Macs next quarter and between 5.1 and 6.7 million units over the 2006-2007 fiscal year. A poll of Mac purchasers conducted by Apple shows that nearly 50% of buyers are “new to Mac”. This means more and more Windows users are switching to Mac. Furthermore, analyst Charles Wolfe of Needham & Company expects Apple to triple its share of the home computer market. With only a small collection of games available, the Mac gaming market is a void waiting to be filled.
To get your games available to Mac users today contact TransGaming at: cider@transgaming.com
Cider is TransGaming's answer to the lack of Mac gaming. Based on the same core technology found in TransGaming's flagship Linux product Cedega, Cider is able to run Windows games on the Intel Mac OS.
2) How does Cider work?
Cider works by directly loading a Windows program into memory on an Intel Mac system and linking it to an optimized version of the Win32 APIs. TransGaming's Cider implements common multimedia Windows APIs such as Direct3D, DirectInput, DirectSound and many others by mapping them to Mac equivalents. This allows games to run with equivalent game play and performance but without the typical brute force porting effort typically required to bring games to Mac.
3) Who is Cider for?
Cider has been created for use by game developers and publishers to release Mac versions of their products. By integrating their games with Cider, developers and publishers will be able to easily provide a Mac version of their game in conjunction with the Windows release. Cider is a business to business application is not available to end-users.
4) How long will it take to get my game to market?
Since Cider encapsulates the original source code to make it work on the Mac, your game will be ready for market in record time. TransGaming works with the game developers and publishers to optimize the game for Intel Mac but this process takes hours to a mere few days. Thus, games currently in production can be ready in time for a simultaneous release as the Windows versions. Cider can also be used to revitalize already released games by offering them to a brand new market, quickly and easily.
[ February 18, 2007, 06:48 AM: Message edited by: aka_tom_w ]
-
Current news Feb 15 2007 on the state of mac Gaming:
Apple still quiet on game strategy @ Cnet news.com
Some believe Apple might have some enhancements planned for Leopard, the next version of Mac OS X that's scheduled to arrive this spring. Last year at Apple's Worldwide Developer's Conference, Steve Jobs demonstrated some graphics-friendly technology such as Core Animation, which will make it easier for developers to create high-powered graphics. It's also possible that Jobs has other surprises in mind for this year's show, scheduled for June.One development that has given Mac developers a rosier outlook is the switch to Intel's processors. Unfortunately, developers still have to do a lot of work porting games over to Mac OS X because most games are created as universal applications, ensuring they can also run on older Macs with PowerPC chips. But going forward, developers are encouraged by the relative ease of creating Intel-only Mac OS X applications, and the switch also ensures that there are a lot more machines out in the market with a defined level of performance, Morrison said.
The switch to Intel has also paved the way for Apple to release Boot Camp, a piece of software that lets Intel-based Macs run Windows. Boot Camp will be included along with Leopard, allowing those who want to keep their Macs but have a hankering for the latest and greatest video games to run Windows games the day they are released. Virtualization technology from companies like Parallels might make this even easier in the future.
When Boot Camp was first released, Destineer Studios was a little worried that Mac users would eventually stop buying Mac versions of games and just run the Windows versions, said Al Schilling, general manager of Destineer's MacSoft label, which ports games to Mac OS X. But Mac game software does not appear to have been affected by Boot Camp, and Schilling doesn't believe that will change with the release of Leopard.
Programs like Boot Camp and Apple's quiet approach to Mac gaming seems to indicate that the company has made a decision to let the Windows companies pursue the hard-core gamer, said Stephen Baker, an analyst with The NPD Group.
The Windows-based world loves gamers, especially those who spend thousands of dollars on new PCs and related equipment in hopes of having the best score on the block. Smaller PC makers like Falcon Northwest and Velocity Micro cater almost exclusively to this group, but the big guys want in on the action, too. Last year, Dell bought Alienware and Hewlett-Packard bought Voodoo PC in hopes of capturing more of these customers and learning how to reach that profitable segment.
-
another opinion:
Programming games for OS-X is difficult. You need to take into account endian issues (for the old processors), operating system issues, support for a bunch of screen resolutions, the fact that many of the computers have only one mouse button, OpenGL vs. Direct-X issues, etc. Using a cross platform game engine such as Torque Game Engine or Torque Game Builder, there are still issues, mainly due to the single mouse button. Beyond that issue, probably the largest problem that any game on the Mac faces is the Mac UI snobbery that all Mac users seem to have. Even though there are few games on the OS-X platform, if a Mac user even sniffs of a “port” they will complain.Apple has purposely disdained games. Games are not considered a “real” use of computers, while graphics, music, and videos are true art. Talking to pro gamers inside in the company, they are frustrated with Apple’s commitment to games.
On the opposite end of the spectrum Microsoft totally “gets” games. They realize that games are a driver of hardware sales and one of the biggest uses of computers in the home. Bill Gates announcing his retirement last month was bittersweet for me. In the early days, I was a total Microsoft groupie, rooting for them in their big fight against Apple on UI issues, then I was a Microsoft opponent at the height of their monopoly power a few years ago, now I’m back in the MS camp as their gaming vision is paying off for so many companies. Regardless of what you thought of MS through the years, they have been the glue that has allowed games to even exist on the PC. From the earliest days of Microsoft producing games like Olympic Decathlon and Flight Simulator to the days of Direct-X to shipping XBox consoles, Bill Gates has understood that games drive hardware sales. For that I have to thank him. It will feel strange to not have Bill Gates in the industry.
So, back to the question of whether or not to make games for OS-X. You can make some money there since the market is fairly game starved. If you use a cross platform game engine, and your additional costs are not too high, the ROI is worth it. However, in the future, I am not so sure. Since all Macs are now Intel based, your users can all use Boot Camp to play PC games on their OS-X machines. Of course, you won’t get the Cocoa UI snobs, but anybody else that wants to play games will be able to take advantage of all that Bill Gates has done for gamers over the years.
Apple could change this. Since they control all of the hardware, they could easily add in controller support. Standardized controllers annointed by Apple would quickly become ubiquitous and cheap. Apple could make sure their computers ship with better graphics hardware than the built in GPU of the recent Mac Mini, so developers are assured of a minimum graphics standard that will not go down. Apple has wonderful design and awesome software engineers. They could easily add game download support into iTunes. What is more important, games or podcasts? I love podcasts, but the answer to the question is obvious.
Come on Apple, make me a believer again.
-Jeff Tunnell, Game Maker ::: Make It Big In Games ::: GarageGames
-
I have posted WHOLE chuncks of text here, because you need a log in and password to read those pages on gamasutra (its free but its a bother.)
How to Port to OS X
Porting Games to Mac OS XPower PC Specifics
The code snippets in the example programs are sufficient to build a game that runs on the Mac, but in order to make a game that runs as well as possible, there are a few Power PC-specific issues that you may need to address, depending upon the architecture of your game.
Pitfalls
The Macintosh does not have the memory bandwidth that Intel boxes have. This is less true on the newer machines, but if you are targeting older iMacs, you will need to be aware of this. There are things that you can do to help avoid this problem. First, stay away from back-to-back load and store operations. Instead, load several values, operate on them, and then store them. The Power PC chip has a huge register file compared to Pentiums. You can avoid a lot of memory operations simply by putting more values in registers. The Power PC also provides a set of cache control instructions that allow you to preload cache lines, flush them, or zero out entire cache lines (much faster than doing it yourself, since you avoid the read to load the cache line).
Converting between floating-point and integer formats is expensive on the Power PC. There are two reasons for this. First, since the Power PC is RISC, the floating-point and integer units are only connected via memory through the load and store unit. Additionally, the Power PC (prior to the G4 Altivec instruction set) does not have architecture-level support for converting from integers to floats. Casting between float and integer is never free on any architecture, but it is definitely more expensive on the Power PC. You can often get large performance increases by eliminating needless casting back and forth between int and float.
If your game engine is in C++, you will not be able to mix Objective-C code snippets as listed into the same files as your core C++ code. This isn't a huge problem, since all the platform-specific code should be isolated in its own files anyway. Currently, the simplest way to call between C++ and Objective-C is to use a vanilla C interface. If you design your platform support library interface in pure C, you won't even notice this problem. Apple is devoting engineering resources to this issue, however, and was scheduled to report on their progress at the 2001 Apple Worldwide Developers Conference in May.
Optimizations
The Power PC has a few instructions that deserve to be pointed out for possible optimizations.
If your engine uses the square root math library function, you might be able to use the frsqrte instruction. This instruction computes an estimate of the inverse of the square root. Depending upon your precision needs, you can use multiple Newton-Raphson refinement steps to extend the precision of the result. The frsqrte instruction can in practice be up to 16 times faster than 1.0 / sqrt(x). In addition to using this instruction for the reciprocal square root, you can also use it to compute a normal square root by simply multiplying its result by the original value, since x / sqrt(x) = sqrt(x).
The Power PC provides an fsel instruction for performing simple if/else assignments. This can eliminate branches in inner loops, which not only reduces the total number of instructions issued, but also frees up branch prediction slots and eliminates the possibility of an incorrectly predicted branch.
Another interesting group of instructions is the lwbrx family (load word byte reversed indexed). This family of instructions allows you to load or store two- and four-byte values and also perform endian swapping. This is much faster than loading the value and then performing bitwise operations in order to swap the value around manually.
Performance-Monitoring Tools
Mac OS X ships with a full set of developer tools. Included in this are several performance monitoring tools. The Sampler application (and the "sampler" command line tool) will periodically stop all the threads in your application, record their stacks, and then let them continue. This provides you with a tree of wall clock time spent, easily allowing you to find the portions of your program that are using the most time. You can also invert the tree, putting the leaves at the root, allowing you to find small leaf routines that are taking a large amount of time.
Omni also provides the OmniTimer framework (see For More Information). This allows you to insert instrumentation calls into your application at key points (typically determined by running Sampler) in order to get very high precision timings. OmniTimer uses the Power PC TBR (time base register) in order to minimize the overhead of collecting the timestamps.
Advanced topics
The Power PC G4 ships with what is considered by many to be the best SIMD instruction set in a consumer CPU. With the right type of task, Altivec can provide huge performance gains. It is also possible to store floating-point (X, Y, Z, W) vector data in single Altivec registers and operate on those registers using macros or inline functions. Care must be taken to keep the values in the vector registers to yield performance gains. The jury is still out on the feasibility of this approach, but it is worth considering.
Mac OS X provides full symmetric multi-processing. If you have the right sort of tasks (that is, very few synchronization points and low data flow), you can break them up into separate threads and Mac OS X will automatically schedule them to different CPUs (if available).
Mac Attack
In the past couple of years, Apple has increased its focus on gaming, and it shows. The Macintosh is now a great gaming platform and only looks to improve in the coming years. By porting to the Mac you can experience increased portability and robustness for all platforms.
Even better, by adding the Mac enthusiasts to your customer base, you can increase your revenue stream while continuing to produce excellent games.
-
Port to Mac OS X information
gamasutra how to Port to Mac OS X
Porting Games to Mac OS XWith the release of Mac OS X, the Macintosh platform gains a new path to easy-to-use and high-performance gaming. This article will address how you can easily port your current game over to the Mac and the APIs in Mac OS X that you can use to do so. Many of the issues involved with porting to a new operating system are common to porting to any new OS, not just the Mac.
snip
Finally, moving your code to another platform can help uncover many latent bugs in your code. In this case, the extra effort involved in supporting multiple platforms can actually reduce the amount of work at the tail end of a project by ensuring that the base you are building your game on is as stable as possible.
Planning Your Game
As with any complicated task, large gains in productivity can be had if you plan your effort before embarking on it. The first step in planning a project is deciding where you want to end up after all your effort has been expended. This applies to both the features you want in your game and the platforms on which it will run. The earlier you decide on your supported platforms, the easier it will be to achieve your goals.
The decision of which features your game will include is related to the platforms you will support. For example, if you are planning on supporting wireless gaming, you probably won't be using Open GL for at least a couple of years (beyond that, who knows?). Likewise, if you are going to write games that are going to run on the Mac, you need to pick foundation technologies that are available there. This excludes proprietary technologies like DirectThis and DirectThat (and Mac proprietary technologies such as Core Graphics, Cocoa, Carbon, and so on if you are going to run on Windows).
There are many well-known software techniques for multi-platform development. I'll assume you are familiar with these for the purpose of this article, and I'll focus exclusively on Mac OS X-specific techniques. Some of the arrows in your quiver for multi-platform development should include separating code using ifdefs based on the platform, using custom data types to steer clear of standard type system dependencies, avoiding depending on bitfield order, steering clear of compiler- and linker-specific behaviors, and of course using a good source code control system and open APIs.
Porting Games to Mac OS X
Mac OS X Technology
Mac OS X has two primary high-level toolboxes, Cocoa and Carbon. Mac OS X also has two object file formats, Mach-O and CFM. There are some choices to be considered when choosing between these. In this article, I'll be talking about the Cocoa/Mach-O approach. This choice is primarily due to the fact that fewer lines of code are necessary to accomplish similar functionality in Cocoa, and Cocoa requires Mach-O.
Cocoa is Apple's advanced object-oriented application toolkit, which is based on the technology it acquired from Next. Carbon is a distillation of the classic Mac OS toolbox APIs that removes a bunch of the less commonly used functions which were not easily implemented in the new world. This includes removing things such as direct access to the hardware, completely obsolete APIs, and so on. The remaining APIs have been modified to work in terms of the new underlying OS. So, a Carbon application can run on both OS 9 and OS X (as long as it doesn't make use of any new OS X services).
The foundation of Mac OS X is the Mach kernel. Mach provides the hardware abstraction and lowest-level OS services. This includes interprocess communication, protected virtual memory, threads, symmetric multi-processing, and driver services. The BSD/POSIX layer sits on top of Mach (so a BSD process is really a Mach task with a little extra goo, and a POSIX thread is really a Mach thread with some of its own goo). All of the API sets are accessible from a user program written using Carbon or Cocoa, but the vast majority of users will be able simply to use the high-level APIs or maybe occasionally use the intermediate BSD APIs. Only in special cases is it necessary to access the Mach API directly, so most of the time Mach sits in the background, providing a rock-solid OS infrastructure. As an example, Mach provides an API for pausing a thread, getting or setting its registers, and then allowing it to continue. Programs don't need to typically do this, but if you were writing a debugger, this would be very important.
Screenshot from Quake 3: Arena.
Platform-Specific APIs
There are a few platform-specific APIs that most games depend on. These are APIs for performing the following tasks:
System functions (file and network access, memory management, threading, code loading and unloading)
Display management
3D graphics rendering
Music and sound effect playback
Reading input devices.
I'll address each of these functional groups in turn.
System functions
Mac OS X has a BSD 4.4 API layer as part of its Mach-based kernel. Apple has stated that their goal is to be POSIX-compliant. This means that a large portion of the platform-specific APIs can be addressed via both BSD and POSIX APIs.
The Windows stdio interface is very similar to the BSD functionality from which it was copied (except for Windows' strange notion of binary versus text files). The stdio API can be used for all file I/O, with the option of accessing the Mach API for memory-mapping files.
Likewise, the BSD sockets API served as the template for the Windows version. There are some minor differences here (select() versus WaitForSingleEvent() and the list of supported socket options), but nothing terribly surprising.
Unlike on many systems, the standard memory allocation package on Mac OS X performs very well. Still, for portability with other platforms you may choose simply to use malloc to allocate large chunks of memory for your internal memory allocator.
For threading, Mac OS X uses the POSIX threading library (pthreads). The implementation of this library isn't 100 percent complete, but the items which aren't implemented are more esoteric. If your game uses threads at all, you likely only want to create threads, mutexes, and conditions -- this portion of the API works fine. If you do want to do anything more interesting, there is the option to use the underlying Mach thread APIs (each pthread corresponds to a Mach thread).
Mac OS X uses a dynamic linker called "dyld," which handles both launch-time linking of shared libraries and run-time linking of code modules. While it is possible to call dyld directly for your code-loading needs, it is probably easier to use the "dl" API defined in Linux, Solaris, and other Unix platforms. A wrapper for dyld that provides the dl interface can be found as part of the open source Darwin kernel that resides underneath Mac OS X (see For More Information).
The input to the dl wrapper API should be a Mach-O "bundle" file (as opposed to a dynamic library, or "dylib"). Using Project Builder, the IDE that ships with Mac OS X, or whichever IDE you prefer (Codewarrior, for example), you can easily build a bundle file. Bundles are typically file wrappers, which simply means that they are directories that contain a variety of resources, one of which is code to be loaded. The path to this code is what should be passed to the dl API functions.
It is also possible to load CFM libraries into Mach-O processes using the Carbon Code Fragment Manager APIs. You might choose to do this if you want to use a toolkit that is only available in CFM format for the Mac (for example, the Bink video library).
-
Other Games use "artificial" edge constraints like steep canyon walls and the like. Given the freedom in the new terrain editor, I am guessing it would be possible to design steep rugged cliff faces ALL around the edges of the playing area, but that would be a gamey way to fix a potential gamey problem, and does nothing to add to the asthetics of the look of the game or the battle field edges.
just a thought
-tom w
[ February 17, 2007, 11:29 AM: Message edited by: aka_tom_w ]
).....
Concealment?
in Combat Mission Shock Force 1
Posted
I tried