Emergent developing Floodgate engine for PS3

[Pumpkin Head]

Emergent Game Technologies is working on a new stream processing engine called Floodgate which will enable the company's game engine, Gamebryo, to take advantage of what the cell chip offers. According to the ps3.qj.net article, the development of Floodgate was confirmed by Emergent's Senior Engineer Vincent Scheib during an interview.

Scheib announced that Emergent was hard at work optimizing Gamebryo for the PlayStation 3, and although the console's processor, the Cell chip, was powerful, its 8 cores meant that developing for it would not be easy. Floodgate is currently being made in order to make development for the PlayStation 3 easier, and with it, game developers may utilize the Cell's full potential sooner than expected.

Currently, Floodgate is being developed as a cross-platform engine, which not only makes developing for the PlayStation 3 easier, but also means that porting games to other consoles or PC would be just as breezy.


http://www.news4gamers.com/ClickOut.aspx?ObjID=8800

[Kiosko]

Ah, so this should make porting games easy? Not bad.

[xbdestroya]

I guess the big question I have here... is what games are we talking about?

[version]

stream processing cross-platform engine rotfl

[xbdestroya]

stream processing cross-platform engine rotfl

Riiiighht... but is Emergent a Middleware company, or is this an in-house engine for a developer? If it's the later, I'm wondering what games they're responsible for, and if it's the former - well I guess either way, I haven't heard of them! :smoke:

[Red_Eyes]

Cool. The good side: Development on the PS3 is easy. The ugly side: It won't be full advantage of the PS3 as portability will not allow that.

[DofD]

Not necessarily. The engine itself will probably be custom to the platform, but the API to make use of the engine will be cross platform. Thus each platform will have a Floodgate engine optimized for that platform. With games that make use of the API, porting them to other platforms becomes much easier.

[cpiasminc]

Riiiighht... but is Emergent a Middleware company, or is this an in-house engine for a developer? If it's the later, I'm wondering what games they're responsible for, and if it's the former - well I guess either way, I haven't heard of them!
Emergent is strictly a middleware provider. It used to be that it was NDL (Numerical Design Limited) working on a middleware package called "NetImmerse", which later became known as "Gamebryo" for some reason that escapes me. Though it just as much makes me wonder why it was called NetImmerse in the first place since it doesn't have any networking tools of its own (yet).

It is out of the box, strictly nothing more than a render engine and tools to move data into the renderer. Offers basically nothing else on its own, but it is designed such that most every subsystem is black-boxed so you can plug in other middleware (though they obviously favor certain specific partners with whom they've worked like Havok and SpeedTree).

Eventually, NDL got bought out by Emergent, who was originally more of a venture capitalist in games (I was surprised that such a thing even existed, actually). A handful of games I've seen have used Gamebryo (e.g. Freedom Force, Civ IV, Oblivion), but it does need to be ripped apart to be useful.

It's interesting how many companies have gone through changes like this that nobody knows about. e.g. High Moon Studios, Visual Concepts, etc.

BTW, AFAICT, this isn't about a complete engine, but a subcomponent to their next-gen engine specifically for streaming. Presumably, when they speak of exercising CELL on this, they're probably talking about decompression matters.

[xbdestroya]

Gotcha. Awesome Cpi, thanks for the clarification on exactly who Emergent is and what this development is geared towards.

[Smurf]

Cool this could be a really great tool to use until the Octopiler comes out from IBM programming labs. The Octopiler will do everything that engine does plus more. It's able to translate any code into a code that the Cell can understand and run. Its very useful and when it comes out, all developers should get it as it would definately make things easier on them.

[xbdestroya]

If and when IBM finishes building out the Octopiler, it's uses will be primarily in porting and recompiling existing code to Cell. Anyone looking to extract the best from the architecture though will code natively with the Cell and it's SPE's in mind. For our purposes, that includes PS3 devs.

Some relevent portions from the recent interview with Mike Acton on compiler technology:

PSINext: Earlier you mentioned that simply re-compiling code is not enough if one aims to bring out the performance of the BE architecture. In a similar vein, what do you feel is the present level of sophistication of the tools offered by IBM, Transmeta, and SN Systems?

Mike Acton: I find the available toolchains for the CBE to be both familiar and usable.

o GCC for the PPU is based on the standard Power build of GCC that has some quirks, but is certainly usable once you are familiar with it. However, I would like to see some more PPU specific modifications in the machine description. Also, the microcoded instructions and the optional instructions of the PPU aren't fully accounted for in the current public build.

o GCC for the SPU is an excellent port. In general, I find that the transformations are very clean. The only thing for programmers to watch out for is a significant penalty for using scalar code. There are limitations on C++ usage and available standard libraries, but I'm not a fan of using C++ for high-performance code nor on the SPU in particular, so I don't personally find this a problem at all.

o XLC is currently available (for free) from IBM for both the PPU and SPU, and it represents best-in-class compilers. Yet because I am more familiar with the unique issues of GCC and with its available source code, I prefer it over XLC.

I should mention two main toolchain features that have received a lot of interest lately:

o Auto-SIMDification. This is the process of taking scalar code and automatically combining it into vector operations. At the moment this is generally limited to certain classes of loops. XLC currently features some amount of SIMDification, and I think once a GCC 4.x release of the PPU and SPU builds are available, there will probably be a certain amount possible in GCC as well.

o Single source compilation. This is the process of taking a single source base and automatically re-targeting certain common, critical functions to the SPEs. IBM research has demonstrated some work on this front with their Octopiler.

In my opinion, neither of these features are particularly relevant to the high-performance or game programming world. Auto-SIMDification is still not very sophisticated and requires that the programmer write scalar code in the first place, when there is a much larger benefit to simply writing SIMD code initially. Auto-SIMDification will have a larger impact on legacy scalar code and will primarily benefit programmers who do not have an interest in SIMD programming. In much the same way, I don't anticipate much practical benefit from a single source compilation strategy outside of compiler research and certain limited classes of legacy, or perhaps high-level code.

http://psinext.e-mpire.com/index.php?categoryid=3&m_articles_articleid=669

[GodMachine_Iridius_Dio]

BTW, AFAICT, this isn't about a complete engine, but a subcomponent to their next-gen engine specifically for streaming.

Pretty sure you're correct - Pretty sure it is just a sub-component/add-in for Gamebryo.