Thread: [GD-Consoles] pipelines
Brought to you by:
vexxed72
Menu
▾
▴
gamedevlists-consoles
|
From: Research \(GameBrains\) <res...@ga...> - 2003-04-28 13:06:03
|
Hello, I was wondering how people here handle the different rendering pipelines = across multiple platforms from a tool chain perspective. For instance, = if you had VU code for PS2, TEV settings for GCN and PS/VS for PC how do = you tag the asset to use the correct "pipe" on different platforms for = assets that are multi-platform capable? Currently we use XML as a scene description language on the front-end, = with MAKE utility on the backend, and we tie the asset, data and = miscellaneous stuff to it in there (XML, not makefile). Works well so = far (although a bit ugly), but wondering if we ought to do it another = way.... Cheers, Brett Bibby GameBrains |
|
From: MAIL <ma...@si...> - 2003-04-28 15:40:41
|
I hope I understand what you are saying, are you saying that you put all your data assets for every console into one file format, so one file can be loaded into any console? If so wouldn't it be easier to just have separate data assets for each console type and then just tack on XML and whatever else onto each one. Wouldn't it save on space, be less confusing and have faster load times. It would probably be better to have a separate export function in your tools for each different console. IE: PC has it's own data format and a specific export function in the tool and PS2 will have it's own ect... If you look at it from a more simplistic view, you would not have PS2 textures and Directx surface textures each in the same file so that only one file would be created that could be loaded on any console, would you? But to answer your question and not tell you to not do what you are doing, I would just simply have a console type hook in the file that the console specific engine looks for when it is loading the file, and you could abstract the hook type function into your platform independent engine so that at load time the engine would know what specific console hook to look for, since that was loaded at run-time and it handles itself without the engine having to know what console it is running on. cheers, Paul Hope SimuDream. ----- Original Message ----- From: "Research (GameBrains)" <res...@ga...> To: <gam...@li...> Sent: Monday, April 28, 2003 9:05 PM Subject: [GD-Consoles] pipelines Hello, I was wondering how people here handle the different rendering pipelines across multiple platforms from a tool chain perspective. For instance, if you had VU code for PS2, TEV settings for GCN and PS/VS for PC how do you tag the asset to use the correct "pipe" on different platforms for assets that are multi-platform capable? Currently we use XML as a scene description language on the front-end, with MAKE utility on the backend, and we tie the asset, data and miscellaneous stuff to it in there (XML, not makefile). Works well so far (although a bit ugly), but wondering if we ought to do it another way.... Cheers, Brett Bibby GameBrains ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Gamedevlists-consoles mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-consoles Archives: http://sourceforge.net/mailarchive/forum.php?forum_idU3 |
|
From: <phi...@pl...> - 2003-04-28 17:55:05
|
> I hope I understand what you are saying, are you saying that you put all your data assets for every console into one file format, so one file can be loaded into any console? I read it as the first half, but not the second half. As in you'd author for cross-platform, and all of that data would be held in one file. Then you have back ends for each platform that compiles into platform specific formats. Even if your output container format is fundamentally cross platform (which I'd reccomend), most of your larger chunks are going to be platform specific (i.e. texture, model and audio data), or your load times are going to be needlessly long as you'd be doing the per-platform processing on the fly. Cheers, Phil |
|
From: Research \(GameBrains\) <res...@ga...> - 2003-04-28 23:48:43
|
Should have been clearer :-) Our 3d assets come out with a root file = name and an extension as to their type (e.g. LVL001.BSP). If the source = asset needs/has platform specific versions (e.g. higher poly, = multi-texture, etc.) it comes out with a platform code in the name (e.g. = LVL001.PS2.BSP). We use MAKE to process the files, extract the platform = code, and pass the files to custom (platform specific) backend tools to = generate optimized runtime assets. The glue to hold it all together is XML via a scenegraph. So for a = given actor (or light, camera, texture, etc.), I specify the model name, = attributes, position, etc., etc. in the XML (level editor can read/write = scenegraph or you can use text editor). It is here that we are = currently specifying what pipes go with what assets on which platform. = Where the model data comes out with platform specific versions, all = platforms use the XML scenegraph to build the runtime database. Without = the pipeline info in the XML, it is clean so I wanted to get it out, and = I wondered how others are storing their shaders, etc. and keeping them = linked to the assets they render. In case anybody is wondering why we do it in XML and not MAX it's = because a) it's easier b) the programmers can change the pipe without = bugging an artist (or needing their own license for MAX) and c) we = seldom need Tom's Big-Artist-Stick (tm) because the artists don't need = to worry about pipelines (but they do use the various effects and our = exporters figure out what they are trying to do and we take care of = reproducing it on the console) The final phase is building a runtime scenegraph with pre-selected, = pre-instanced assets so that at runtime we just load the graph in the = blink of an eye and we're done. So we don't carry any excess baggage = around, no load searching, etc. So more exactly, is anybody binding the shaders/custom code to the = assets in their tool chain like we are? Or is the binding done ad hoc = in code by programmers? Or are the pipes loaded, asset tagged, and = binding done at runtime? Or are they being embedded in the assets in = the 3d package? Or??? Thanks, Brett Bibby GameBrains ----- Original Message -----=20 From: <phi...@pl...> To: <gam...@li...> Sent: Tuesday, April 29, 2003 1:54 AM Subject: Re: [GD-Consoles] pipelines >=20 >=20 >=20 >=20 > > I hope I understand what you are saying, are you saying that you put = all > your data assets for every console into one file format, so one file = can be > loaded into any console? >=20 > I read it as the first half, but not the second half. As in you'd = author > for cross-platform, and all of that data would be held in one file. = Then > you have back ends for each platform that compiles into platform = specific > formats. >=20 > Even if your output container format is fundamentally cross platform = (which > I'd reccomend), most of your larger chunks are going to be platform > specific (i.e. texture, model and audio data), or your load times are = going > to be needlessly long as you'd be doing the per-platform processing on = the > fly. >=20 > Cheers, > Phil >=20 >=20 >=20 > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Gamedevlists-consoles mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-consoles > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D553 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X