Easter Eggs Abound in Squadron 42 Trailer (October 11, 2012)

And lastly, I'm not sure that being 64-bit-OS-only makes any difference other than it guarantees that there are no limited memory address space issues that are inherent in a 32-bit OS. I'm sure Star Citizen, with its high-end-PC-only target would restrict itself to 64-bit OSs anyway, but I don't imagine this would necessarily be a conscious decision.
It is a conscious decision, actually - Chris Roberts wants to go all out with the graphics, and that means he can't afford to be backwards compatible :). I mean, already XP users don't have access to all the latest DirectX features, because the last couple of DX releases have been specifically for 64-bit OSes. Most games that come out today do still support 32-bit XP, for a very obvious reason - if they were too good for XP, they also wouldn't run on consoles, because both the X360 and the PS3 are now massively outdated, they were top-of-the-line in 2005. PC games today look nowhere near as good as they could, if they weren't being held back by the absence of a new generation of consoles. But if this game is going to be PC-only, there's no reason to hold back on anything.
 
And lastly, I'm not sure that being 64-bit-OS-only makes any difference other than it guarantees that there are no limited memory address space issues that are inherent in a 32-bit OS. I'm sure Star Citizen, with its high-end-PC-only target would restrict itself to 64-bit OSs anyway, but I don't imagine this would necessarily be a conscious decision.

It's not been done as of yet, most "x64" software isjust recompiled 32-bit software. Accept for the memory adressing issues you also get more raw calculating power and better parallel processing capabilities Sadly they are not building their own engine this time. But then again, I believe that bringing the games universe to life should be where the attention should go, and not optimizing it to use quad-SLI setups.

The only time I specifically had to upgrade for wing commander was wing commander 3, since it was one of the first games to demand a coprocessor and 8MB ram, but 486dx2's had been around in the stores since 1991
 
It is a conscious decision, actually - Chris Roberts wants to go all out with the graphics, and that means he can't afford to be backwards compatible.
I had a feeling someone might want to argue this point, but that's all right. I suppose my thinking is along the lines of just what you said - that using only 64-bit OSs is just inherent to the 'going all out' and 'not being backwards compatible'. Same conclusion, just funny way (on my part) of thinking about it. And not that I'm fully informed on who uses what game-engine (I still remember you making fun of me for not knowing that engines were re-used even in Wolf3D/Doom days), but I thought even today there are some engines that drop WinXP support, such as recent uses Frostbite. Although, I suppose there are still 32-bit versions of Vista and Win7 in use (for 16-bit compatibility).

Except for the memory addressing issues you also get more raw calculating power and better parallel processing capabilities. Sadly they are not building their own engine this time. But then again, I believe that bringing the games universe to life should be where the attention should go, and not optimizing it to use quad-SLI setups.
I would have thought the 'raw calculating power' and 'parallel processing capabilities' come from the newer operating systems, and isn't tied specifically to being 64-bit vs 32-bit. Using 32-bit word sizes doesn't automatically stop you from using parallel processing does it?

I would hope quad-SLI isn't targeted specifically. Any high-end video card set-up should be able to handle the workload, not just those from one vendor. But I suppose your point was about the allocation of development resources.
 
I would have thought the 'raw calculating power' and 'parallel processing capabilities' come from the newer operating systems.
(True the os has a role in that, but true optimized 64-bit versions of software does run considerably faster(Try Waterfox vs. Firefox, or Gzip or LAME). Just recompiling in 64bit and running on a 64bit os is not thesame as optimizing for it.

Also, the still will be 32-bit windows 8 around, primarily target at older machines and netbooks, but also for 16bit compatibility

And the another sidenote; Around this time next year the "durango, or xbox720" will be introduced, why should that machine not be capable to match or exceed the target platform?
 
I think I may have found another easter egg involving the date that the series now takes place:

2942: 2 + 9 + 4 + 2 = 17
2654: 2 + 6 + 5 + 4 = 17

Coincidence? I think unlikely.
 
I am a bit late to this, but as I watched the reveal trailer, the bit with the three vanduul fighters streaking out of the asteroids on a seemingly suicide attack reminded me of a recreation of the kilrathi ambush on the Tigers Claw in WC:Academy TV episode "most delicate instrument" where the deranged kilrathi were hiding out in the asteroid field waiting for a victim. I know a parallel has been drawn to the beginning of WCII where stealth fighters attack the claw, so I am just throwing that out there too.
 
It's not been done as of yet, most "x64" software isjust recompiled 32-bit software. Accept for the memory adressing issues you also get more raw calculating power and better parallel processing capabilities Sadly they are not building their own engine this time. But then again, I believe that bringing the games universe to life should be where the attention should go, and not optimizing it to use quad-SLI setups.
I don't think it's sad at all that they're not building their own engine. What would the benefit of that be? There are, naturally, situations where it makes sense to develop a new engine. But for most companies, it's absolutely the wrong choice.
 
I don't think it's sad at all that they're not building their own engine. What would the benefit of that be? There are, naturally, situations where it makes sense to develop a new engine. But for most companies, it's absolutely the wrong choice.

I would suggest a space sim to based on an engine developed for a space sim, just like flying a plane in battlefield is not thesame experience as flying a plane in a flightsim. Ofcourse, development will cost you a pretty penny, and I don't think updating the Realspace or Vision engine would be an option so they'll have to start from scratch.
 
I would suggest a space sim to based on an engine developed for a space sim, just like flying a plane in battlefield is not thesame experience as flying a plane in a flightsim. Ofcourse, development will cost you a pretty penny, and I don't think updating the Realspace or Vision engine would be an option so they'll have to start from scratch.
That's the thing, though - this is a space sim. If they were making a flight sim, I would agree, using an existing FPS engine would carry great risks, because of the amount of terrain you have to display. Although even for a flight sim, arguably, a really good outdoor-oriented FPS engine - and Cry Engine is definitely one of them - could be adapted easily. But for a space sim, there's just no question about it - you can take almost any decent FPS engine and make a great-looking space sim on top of it.

You have to keep in mind, an engine is much more than gameplay mechanics. In fact, it's usually much less than gameplay mechanics, in the sense that gameplay mechanics are the least important aspect. When you buy Cry Engine in particular, the support isn't too great gameplay-wise. Depending on how good you are at negotiating, you may not even get the AI (this is not speculation, by the way - it's genuine experience). But you get a set of fantastic tools that allow you to get to work on importing graphical objects, setting up gameplay scenarios, creating particle effects, and so on. You get a vast amount of stuff that's absolutely universal - genre-neutral, that is. Will you program the sound interface differently depending on what kind of game you're making? Will you create a different graphical object pipeline depending on what kind of game you're making? Will you integrate network support differently? Create particles differently? Et cetera, et cetera. When you examine what you actually get in an engine, you quickly realise that the gameplay mechanics are the least relevant - as long as the game engine is designed to be flexible (which Cry Engine absolutely is).
 
What Quarto said ^^

From the sounds of it, they're using CryEngine primarily as a rendering engine, but building the rest from the ground up.

I'm a huge fan of 3rd-party software/middleware. Imagine how much cashmoneydollars they would need to crowd source if ey were building the whole engine! Not to mention the years of extra dev time...
 
Will you program the sound interface differently depending on what kind of game you're making?
Obviously, you're experienced in game development work and I'm not quite sure what you mean by interface (is this just the basics, like frequency rate, stereo vs surround, etc, or piping audio channels from one layer to another?). But I read a mention of developing algorithms to handle things like occlusion by walls and other sorts of 'physical' objects. Clearly, programming details into graphics is a lot more noticeable than programming details into sound rendering, but I was wondering: do modern engines already take care of things like this? I know there's APIs for '3D' audio processing as well... while engines might have processing for graphics, lighting, physics and such, I am wondering what sort of resources are put into audio processing in popular high-end game engines. Just curious, is all.
 
Clearly, programming details into graphics is a lot more noticeable than programming details into sound rendering, but I was wondering: do modern engines already take care of things like this? I know there's APIs for '3D' audio processing as well... while engines might have processing for graphics, lighting, physics and such, I am wondering what sort of resources are put into audio processing in popular high-end game engines. Just curious, is all.
The answer is yes... and no. In fact, many modern engines do handle sound. Some handle it well, some handle it tolerably, most handle it badly. In the last few years, fortunately, more and more companies have decided to go the middleware route - instead of dealing with sound themselves, they add in a system like FMOD, and they're good to go. Also, this makes the sound engineers incredibly happy. Sound engineers love FMOD, and hate game engines that don't have FMOD (or some equivalent system - but really, FMOD rules the roost).

What does it mean, to handle sound? Well, look at it this way - how many sounds do you hear at any one time in a game? If you have twenty soldiers on-screen, firing away at you from all directions, that's twenty sounds already. Add to that that some of them are moving, and you hear their footsteps. Add the guys off-screen, whom you can also hear moving and firing. Add the player's sounds. Then add voiceovers. On top of all that, add the background sounds - the aircraft flying past overhead, the wind shuffling through the leaves, the repeated explosions of artillery shells, etc., etc. Finally, you have music. In extreme situations, you're talking several hundred sounds all at once.

How many sounds can the hardware handle at once? I don't remember. It might be 64, possibly 128. In some cases it might still be 32, I don't know. The point is, it's nowhere near the number of the sounds you actually need - the limit is basically what the sound card can process at any one time, because the sound card must then boil these sounds down to something the speakers can handle. This is why in some games you might notice sounds suddenly cutting out in the middle of a big event. In WC Saga, for example, time and again I find that that voiceovers don't play. We had some similar problems in Standoff, where we found that the game would occasionally cut the music off in cutscenes, because there was too much going on, and the sound component had been programmed to discard the longest-playing sounds first (to be fair: the music system is separatate and not affected - the problem arose when we tried playing music as a sound effect rather than as music, for sync purposes). Now, of course, both Saga and Standoff were done on outdated engines - but sound technology does not progress anywhere near as fast as graphics progress, so these problems are very much still there.

Anyway, this is where the sound API comes in. You don't just need to process the volume of the sounds being played, and set them up in 3d space - you need to dynamically mix them together to reduce the strain on the hardware and ensure that you don't wind up dropping sounds. Besides that, there is the aspect of setting the sounds up in the game. If you're working on a level, you will need to set up the sounds in the editor, add them into the game's sound database, and so on. You probably also need to do a dozen other things that I, not being a programmer or a sound engineer, have no idea about. In any case, it does get complicated, and much more so than most people actually think.

By the way, I mentioned that sound engineers love FMOD, and usually don't much like game engines that handle sound without middleware. Why is that? Well, unlike most other specialists working on games, sound engineers tend to be relatively few, often working as freelancers on multiple projects - or, if working internally, will work on a number of different projects for a company. You just don't need that many sound engineers, you don't need them as often, and if an average project spans two years, then there will probably only be two or three months of full-time work for the sound people. What this means is that sound engineers generally want sound to work the same in different games - they don't want to have to re-learn everything every time.
 
By the by, we have one of the best sound guys in the business working on Star Citizen: Martin Galway!
 
I had a feeling audio development was a lot different to the high-profile graphics side of things. Thanks, Q.

Sounds as though we have a lot of former Origin or WC developers working with or for RSI. That's great news.
 
Back
Top