Thread: RE: [Algorithms] general engine question
Brought to you by:
vexxed72
From: Herb M. <HMarselas@EnsembleStudios.com> - 2001-03-14 23:47:56
|
Up until about 9 months ago we supported 3 renderers (D3D, OGL, NULL) using a simple abstraction layer, with each renderer in it's own DLL. Doing features in D3D and OGL took a lot of time, and there were a lot of driver bugs in OGL, but we supported it since our art team was only running NT4. When they moved to win2k we dropped OGL support since they could now run D3D. Now, we support only D3D and NULL. I'm sure that as long as we keep things clean we could go in later and put OGL back in, but there's little reason to do so. - herb Ensemble Studios http://www.ensemblestudios.com mailto:hma...@en... ICQ:35921824 -----Original Message----- From: Daniel Renkel [mailto:Dan...@ho...] Sent: Wednesday, March 14, 2001 5:40 PM To: gda...@li... Subject: [Algorithms] general engine question hi there, a simple question to all programmer's who do code actually complex 3d engine's for commercial games: how many of you use ONLY directx or ONLY opengl for it and how many use both via a layer / wrapper sort of - for their interface(s). we are somehow stuck in our discussion about it, in our team; Daniel 'SirLeto' Renkel [D.Renkel@FutureInt.de] technical design director - creactivity and technowhow =8O) Future Interactive [http://www.FutureInt.de] _______________________________________________ GDAlgorithms-list mailing list GDA...@li... http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list |
From: Jamie F. <jfo...@re...> - 2001-03-15 12:11:49
|
My personal view on this is that it's not worth getting too uptight about it. If you're going to have time to tweak for each platform, you may well end up with things you want to do and can do but which violate your API layer (especially if it's your first time round trying to make such a layer, as it is mine). The API's good while it lets you do what you want. When it gets in the way, fix it or modify as you see fit. Jamie -----Original Message----- From: Neal Tringham [mailto:ne...@ps...] Sent: 15 March 2001 12:03 To: gda...@li... Subject: Re: [Algorithms] general engine question From: Daniel Renkel <Dan...@ho...> > a simple question to all programmer's who do code actually complex 3d > engine's for commercial games: > how many of you use ONLY directx or ONLY opengl for it > and how many use both via a layer / wrapper sort of - for their > interface(s). > we are somehow stuck in our discussion about it, in our team At present we use OpenGL (for PCs) and PlayStation 2 "native mode". To be honest, though, I suspect the important question is not exactly which APIs or targets you support as whether you should have some sort of intermediate layer which allows you to support more than one target. I'd suggest that the answer to this is definitely yes, given that you might want to port to any of several consoles, and you can't be sure when you start which systems you might be asked to support in the end. I'd also suggest building your intermediate layer to use reasonably high level concepts rather than being simply an API wrapper. Essentially, if I were on your team I'd want to have a fairly high level "platform layer" and then implement it initially for either D3D or OpenGL and a NULL (empty) renderer. Neal Tringham (Sick Puppies / Empire Interactive) ne...@ps... ne...@em... _______________________________________________ GDAlgorithms-list mailing list GDA...@li... http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list -Virus scanned and cleared ok |
From: David 'M. Z. <myt...@gm...> - 2001-03-15 15:12:07
|
----- Original Message ----- From: "Jamie Fowlston" <jfo...@re...> To: <gda...@li...> Sent: Thursday, March 15, 2001 1:01 PM Subject: RE: [Algorithms] general engine question > My personal view on this is that it's not worth getting too uptight about > it. If you're going to have time to tweak for each platform, you may well > end up with things you want to do and can do but which violate your API > layer (especially if it's your first time round trying to make such a layer, > as it is mine). The API's good while it lets you do what you want. When it > gets in the way, fix it or modify as you see fit. > > Jamie yeah that's exactly the point why we are arguing about that. It's our first game and we'd like to get it finished. Building such a layer might improve the overall quality of the engine since it's easily portable and extensible but it costs us even more time to do something like that. And since we are pretty sure that the game will be PC-only some of us think it's not necessary to build such a layer. And even if we port the game to consoles like the XBox that shouldn't be a problem 'cause the XBox supports DX8. So why bother about it? A compromise would be just to code the high-level functions (as mentioned before) and on low-level everything is API-specific. But the problems I see are for example that APIs use different coordinate systems, handle their renderstates in a different manner and maybe even are totally different in their design. That's why I just think: Code it in DX8, need half the time and get the game finished rather than wasting lots of time on the engine just to realize in the end that we can't get it done in a proper way. And THEN when we have experience in how to write an engine (all of us are "newbies") we can write a better one for our second project. Opinions on that? What would you do if it was your first engine? Go the fast and safe way or the 'better' one? > > -----Original Message----- > From: Neal Tringham [mailto:ne...@ps...] > Sent: 15 March 2001 12:03 > To: gda...@li... > Subject: Re: [Algorithms] general engine question > > > From: Daniel Renkel <Dan...@ho...> > > > > a simple question to all programmer's who do code actually complex 3d > > engine's for commercial games: > > how many of you use ONLY directx or ONLY opengl for it > > and how many use both via a layer / wrapper sort of - for their > > interface(s). > > we are somehow stuck in our discussion about it, in our team > > At present we use OpenGL (for PCs) and PlayStation 2 "native mode". To be > honest, though, I suspect the important question is not exactly which APIs > or targets you support as whether you should have some sort of intermediate > layer which allows you to support more than one target. I'd suggest that > the answer to this is definitely yes, given that you might want to port to > any of several consoles, and you can't be sure when you start which systems > you might be asked to support in the end. I'd also suggest building your > intermediate layer to use reasonably high level concepts rather than being > simply an API wrapper. Essentially, if I were on your team I'd want to have > a fairly high level "platform layer" and then implement it initially for > either D3D or OpenGL and a NULL (empty) renderer. > > Neal Tringham (Sick Puppies / Empire Interactive) > > ne...@ps... > ne...@em... > > > > > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > -Virus scanned and cleared ok > > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > |
From: Michael H. <mha...@pe...> - 2001-03-15 15:32:20
|
In my opinion, this is similar to many optimization arguments. My general rule is: Make it work, then make it fast. For your question, I might turn it around and say Make it work, then make it portable. If you're all newbies, I would recommend that you concentrate on the things you *know* you'll need for your game (if it's PC-only, you don't really need support for anything but DX). If you *think* you might want to port it to other platforms later, you can do simple things like encapsulating platform specific data types (matrices and such) in your own classes, isolating the the use of DX in just a few files now, but mainly worry about getting the engine and game *done*. It doesn't matter how flexible and portable your design is if the game never gets finished or is very late. At 03:48 PM 3/15/2001 +0100, you wrote: >----- Original Message ----- >From: "Jamie Fowlston" <jfo...@re...> >To: <gda...@li...> >Sent: Thursday, March 15, 2001 1:01 PM >Subject: RE: [Algorithms] general engine question > > > > My personal view on this is that it's not worth getting too uptight about > > it. If you're going to have time to tweak for each platform, you may well > > end up with things you want to do and can do but which violate your API > > layer (especially if it's your first time round trying to make such a >layer, > > as it is mine). The API's good while it lets you do what you want. When it > > gets in the way, fix it or modify as you see fit. > > > > Jamie > >yeah that's exactly the point why we are arguing about that. It's our first >game and we'd like to get it finished. Building such a layer might improve >the overall quality of the engine since it's easily portable and extensible >but it costs us even more time to do something like that. And since we are >pretty sure that the game will be PC-only some of us think it's not >necessary to build such a layer. And even if we port the game to consoles >like the XBox that shouldn't be a problem 'cause the XBox supports DX8. So >why bother about it? >A compromise would be just to code the high-level functions (as mentioned >before) and on low-level everything is API-specific. But the problems I see >are for example that APIs use different coordinate systems, handle their >renderstates in a different manner and maybe even are totally different in >their design. >That's why I just think: Code it in DX8, need half the time and get the game >finished rather than wasting lots of time on the engine just to realize in >the end that we can't get it done in a proper way. And THEN when we have >experience in how to write an engine (all of us are "newbies") we can write >a better one for our second project. >Opinions on that? What would you do if it was your first engine? Go the fast >and safe way or the 'better' one? > > > > > > -----Original Message----- > > From: Neal Tringham [mailto:ne...@ps...] > > Sent: 15 March 2001 12:03 > > To: gda...@li... > > Subject: Re: [Algorithms] general engine question > > > > > > From: Daniel Renkel <Dan...@ho...> > > > > > > > a simple question to all programmer's who do code actually complex 3d > > > engine's for commercial games: > > > how many of you use ONLY directx or ONLY opengl for it > > > and how many use both via a layer / wrapper sort of - for their > > > interface(s). > > > we are somehow stuck in our discussion about it, in our team > > > > At present we use OpenGL (for PCs) and PlayStation 2 "native mode". To be > > honest, though, I suspect the important question is not exactly which APIs > > or targets you support as whether you should have some sort of >intermediate > > layer which allows you to support more than one target. I'd suggest that > > the answer to this is definitely yes, given that you might want to port to > > any of several consoles, and you can't be sure when you start which >systems > > you might be asked to support in the end. I'd also suggest building your > > intermediate layer to use reasonably high level concepts rather than being > > simply an API wrapper. Essentially, if I were on your team I'd want to >have > > a fairly high level "platform layer" and then implement it initially for > > either D3D or OpenGL and a NULL (empty) renderer. > > > > Neal Tringham (Sick Puppies / Empire Interactive) > > > > ne...@ps... > > ne...@em... > > > > > > > > > > _______________________________________________ > > GDAlgorithms-list mailing list > > GDA...@li... > > http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > > -Virus scanned and cleared ok > > > > _______________________________________________ > > GDAlgorithms-list mailing list > > GDA...@li... > > http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > > > > >_______________________________________________ >GDAlgorithms-list mailing list >GDA...@li... >http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list - Michael Harrison Senior Software Engineer Paradigm Entertainment Voice 972-488-6393 |
From: Thatcher U. <tu...@tu...> - 2001-03-15 16:29:38
|
On Mar 15, 2001 at 03:48 +0100, David 'Mythomania' Zaadstra wrote: > ----- Original Message ----- > From: "Jamie Fowlston" <jfo...@re...> > To: <gda...@li...> > Sent: Thursday, March 15, 2001 1:01 PM > Subject: RE: [Algorithms] general engine question > > > My personal view on this is that it's not worth getting too > > uptight about it. If you're going to have time to tweak for each > > platform, you may well end up with things you want to do and can > > do but which violate your API layer (especially if it's your first > > time round trying to make such a > layer, as it is mine). The > > API's good while it lets you do what you want. When it gets in the > > way, fix it or modify as you see fit. > > yeah that's exactly the point why we are arguing about that. It's our first > game and we'd like to get it finished. Building such a layer might improve > the overall quality of the engine since it's easily portable and extensible > but it costs us even more time to do something like that. And since we are > pretty sure that the game will be PC-only some of us think it's not > necessary to build such a layer. And even if we port the game to consoles > like the XBox that shouldn't be a problem 'cause the XBox supports DX8. So > why bother about it? > A compromise would be just to code the high-level functions (as mentioned > before) and on low-level everything is API-specific. But the problems I see > are for example that APIs use different coordinate systems, handle their > renderstates in a different manner and maybe even are totally different in > their design. > That's why I just think: Code it in DX8, need half the time and get the game > finished rather than wasting lots of time on the engine just to realize in > the end that we can't get it done in a proper way. And THEN when we have > experience in how to write an engine (all of us are "newbies") we can write > a better one for our second project. > Opinions on that? What would you do if it was your first engine? Go the fast > and safe way or the 'better' one? I'm not a big fan of API wrapper layers. I started out writing one for Soul Ride, but it turned into a time sink with little tangible benefit that I could see. You either spend a bunch of time becoming an API lawyer to figure out what exactly the lowest common denominator is, or you define things at such a high level that you make low-level hacks prohibitive to even try. In either case, you only ever have multiple functioning back ends if you have an excess of coding time or a paucity of rendering features. After a while I decided to dispense with the layer in order to save time and effort. I picked the other API because I think it's easier to use, less intrusive on your data, and saves coding time and headaches, which are exactly the benefits I wanted from a wrapper in the first place. But lots of people are perfectly happy coding directly to DX, so don't be afraid to go for it. -- Thatcher Ulrich <tu...@tu...> == Soul Ride -- pure snowboarding for the PC -- http://soulride.com == real-world terrain -- physics-based gameplay -- no view limits |
From: Akbar A. <sye...@ea...> - 2001-03-15 20:32:37
|
>Opinions on that? What would you do if it was your first engine? Go the fast >and safe way or the 'better' one? wow. some really interesting ideas in this topic. this is the way i look at it. learn as you code. and don't worry if your always rewriting your engine blocks or if file formats never stick :) like even "professional engines" go through lots of rewrites, unreal tournament went through about 8. and iirc with *quake1, abrash said they probably wrote around 10-15 engines at his gdc talk("good to be balk" iirc). *john told me this was the hardest engine to write i can't emphasize more, screw "official" design initially, just rewrite code :D i see people that have never written 3d software in there life and ponder on how they are going to write the most optimal texture manager using classes(virtual, private, protected, friends, way to much to think about for your first try) and how they should use inheritance cause it seems like the right thing to do. ;) laterz, -akbar A. ;vertexabuse.cjb.net or ;www.vertexabuse.com cjb goes down once in a while "plastic or metallic. please pick your version of lighting ;) " .me -----Original Message----- From: gda...@li... [mailto:gda...@li...]On Behalf Of David 'Mythomania' Zaadstra Sent: Thursday, March 15, 2001 8:48 AM To: gda...@li... Subject: Re: [Algorithms] general engine question ----- Original Message ----- From: "Jamie Fowlston" <jfo...@re...> To: <gda...@li...> Sent: Thursday, March 15, 2001 1:01 PM Subject: RE: [Algorithms] general engine question > My personal view on this is that it's not worth getting too uptight about > it. If you're going to have time to tweak for each platform, you may well > end up with things you want to do and can do but which violate your API > layer (especially if it's your first time round trying to make such a layer, > as it is mine). The API's good while it lets you do what you want. When it > gets in the way, fix it or modify as you see fit. > > Jamie yeah that's exactly the point why we are arguing about that. It's our first game and we'd like to get it finished. Building such a layer might improve the overall quality of the engine since it's easily portable and extensible but it costs us even more time to do something like that. And since we are pretty sure that the game will be PC-only some of us think it's not necessary to build such a layer. And even if we port the game to consoles like the XBox that shouldn't be a problem 'cause the XBox supports DX8. So why bother about it? A compromise would be just to code the high-level functions (as mentioned before) and on low-level everything is API-specific. But the problems I see are for example that APIs use different coordinate systems, handle their renderstates in a different manner and maybe even are totally different in their design. That's why I just think: Code it in DX8, need half the time and get the game finished rather than wasting lots of time on the engine just to realize in the end that we can't get it done in a proper way. And THEN when we have experience in how to write an engine (all of us are "newbies") we can write a better one for our second project. Opinions on that? What would you do if it was your first engine? Go the fast and safe way or the 'better' one? > > -----Original Message----- > From: Neal Tringham [mailto:ne...@ps...] > Sent: 15 March 2001 12:03 > To: gda...@li... > Subject: Re: [Algorithms] general engine question > > > From: Daniel Renkel <Dan...@ho...> > > > > a simple question to all programmer's who do code actually complex 3d > > engine's for commercial games: > > how many of you use ONLY directx or ONLY opengl for it > > and how many use both via a layer / wrapper sort of - for their > > interface(s). > > we are somehow stuck in our discussion about it, in our team > > At present we use OpenGL (for PCs) and PlayStation 2 "native mode". To be > honest, though, I suspect the important question is not exactly which APIs > or targets you support as whether you should have some sort of intermediate > layer which allows you to support more than one target. I'd suggest that > the answer to this is definitely yes, given that you might want to port to > any of several consoles, and you can't be sure when you start which systems > you might be asked to support in the end. I'd also suggest building your > intermediate layer to use reasonably high level concepts rather than being > simply an API wrapper. Essentially, if I were on your team I'd want to have > a fairly high level "platform layer" and then implement it initially for > either D3D or OpenGL and a NULL (empty) renderer. > > Neal Tringham (Sick Puppies / Empire Interactive) > > ne...@ps... > ne...@em... > > > > > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > -Virus scanned and cleared ok > > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > _______________________________________________ GDAlgorithms-list mailing list GDA...@li... http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list |
From: Jamie F. <jfo...@re...> - 2001-03-15 15:36:53
|
I would say that the extra layer of abstraction is quite useful; it helps keep clear what you're working on, and where it belongs in the grand scheme of things. We've already experienced that benefit over our previous quick and dirty methods. Well, I have, anyway :) We're not finished yet, but we have a fairly reasonable abstraction for the moment. There are a few things (e.g. how dynamic lighting in the environment works) which threaten to violate the current API, and may be different when it comes to cross-platform stuff. When that happens, I'll be prepared to violate the API, as it's not sacrosanct... it's just some code. In my mind, the big mistake is thinking that 'cos some chunk of code has worked well up till now, it should remain the way it is indefinitely :) And if it's turning into a big argument, it may be better just to get on with it :) You learn so much first time round that however well you plan it, there'll be things you'll wish you'd done differently by the end of the project. Jamie -----Original Message----- From: David 'Mythomania' Zaadstra [mailto:myt...@gm...] Sent: 15 March 2001 14:48 To: gda...@li... Subject: Re: [Algorithms] general engine question ----- Original Message ----- From: "Jamie Fowlston" <jfo...@re...> To: <gda...@li...> Sent: Thursday, March 15, 2001 1:01 PM Subject: RE: [Algorithms] general engine question > My personal view on this is that it's not worth getting too uptight about > it. If you're going to have time to tweak for each platform, you may well > end up with things you want to do and can do but which violate your API > layer (especially if it's your first time round trying to make such a layer, > as it is mine). The API's good while it lets you do what you want. When it > gets in the way, fix it or modify as you see fit. > > Jamie yeah that's exactly the point why we are arguing about that. It's our first game and we'd like to get it finished. Building such a layer might improve the overall quality of the engine since it's easily portable and extensible but it costs us even more time to do something like that. And since we are pretty sure that the game will be PC-only some of us think it's not necessary to build such a layer. And even if we port the game to consoles like the XBox that shouldn't be a problem 'cause the XBox supports DX8. So why bother about it? A compromise would be just to code the high-level functions (as mentioned before) and on low-level everything is API-specific. But the problems I see are for example that APIs use different coordinate systems, handle their renderstates in a different manner and maybe even are totally different in their design. That's why I just think: Code it in DX8, need half the time and get the game finished rather than wasting lots of time on the engine just to realize in the end that we can't get it done in a proper way. And THEN when we have experience in how to write an engine (all of us are "newbies") we can write a better one for our second project. Opinions on that? What would you do if it was your first engine? Go the fast and safe way or the 'better' one? > > -----Original Message----- > From: Neal Tringham [mailto:ne...@ps...] > Sent: 15 March 2001 12:03 > To: gda...@li... > Subject: Re: [Algorithms] general engine question > > > From: Daniel Renkel <Dan...@ho...> > > > > a simple question to all programmer's who do code actually complex 3d > > engine's for commercial games: > > how many of you use ONLY directx or ONLY opengl for it > > and how many use both via a layer / wrapper sort of - for their > > interface(s). > > we are somehow stuck in our discussion about it, in our team > > At present we use OpenGL (for PCs) and PlayStation 2 "native mode". To be > honest, though, I suspect the important question is not exactly which APIs > or targets you support as whether you should have some sort of intermediate > layer which allows you to support more than one target. I'd suggest that > the answer to this is definitely yes, given that you might want to port to > any of several consoles, and you can't be sure when you start which systems > you might be asked to support in the end. I'd also suggest building your > intermediate layer to use reasonably high level concepts rather than being > simply an API wrapper. Essentially, if I were on your team I'd want to have > a fairly high level "platform layer" and then implement it initially for > either D3D or OpenGL and a NULL (empty) renderer. > > Neal Tringham (Sick Puppies / Empire Interactive) > > ne...@ps... > ne...@em... > > > > > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > -Virus scanned and cleared ok > > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > _______________________________________________ GDAlgorithms-list mailing list GDA...@li... http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list -Virus scanned and cleared ok |
From: Jamie F. <jfo...@re...> - 2001-03-15 16:07:30
|
-----Original Message----- From: Jeffrey Cahyono [mailto:jef...@ya...] Sent: 15 March 2001 15:49 To: gda...@li... Subject: Re: [Algorithms] general engine question [Snip] aggred, but we still need primitives rendering to draw billboards, view frustum, and Object's bounding volume(for debugging purpose). [/Snip] Not so. Such things can be drawn as meshes just like everything else. Our current solution is only to render meshes, and provide means to modify meshes. Although properly double buffering them promises to be interesting :) Jamie -Virus scanned and cleared ok |
From: Paul F. <pf...@at...> - 2001-03-15 18:42:01
|
Jamie Fowlston wrote: > -----Original Message----- > From: Jeffrey Cahyono [mailto:jef...@ya...] > Sent: 15 March 2001 15:49 > To: gda...@li... > Subject: Re: [Algorithms] general engine question > > [Snip] > aggred, but we still need primitives rendering to draw > billboards, view frustum, and Object's bounding > volume(for debugging purpose). > > [/Snip] > > Not so. Such things can be drawn as meshes just like everything else. Our > current solution is only to render meshes, and provide means to modify > meshes. Although properly double buffering them promises to be interesting > :) What about stuff like HUDs and particles and cases where you need to procedurally generate geometry like subdivision etc? Cheers, Paul. |
From: Tom F. <to...@mu...> - 2001-03-15 18:26:47
|
The lowest level of abstraction I would advocate has calls like: Mesh::DrawThisMesh ( Matrix &orn ); TriBucket::AddTheseEffectTrisToABucket(...); TriBucket::FlushToScreen(); etc. Stuff like vertex buffers, index buffers, material setup, texture management, etc is just so different between APIs that it's madness to try to wrap anything lower-level than the above, IMHO. Tom Forsyth - Muckyfoot bloke. What's he up to now? http://www.muckyfoot.com/startopia/cam.html > -----Original Message----- > From: Jamie Fowlston [mailto:jfo...@re...] > Sent: 15 March 2001 15:32 > To: 'gda...@li...' > Subject: RE: [Algorithms] general engine question > > > I would say that the extra layer of abstraction is quite > useful; it helps > keep clear what you're working on, and where it belongs in > the grand scheme > of things. We've already experienced that benefit over our > previous quick > and dirty methods. Well, I have, anyway :) > > We're not finished yet, but we have a fairly reasonable > abstraction for the > moment. There are a few things (e.g. how dynamic lighting in > the environment > works) which threaten to violate the current API, and may be > different when > it comes to cross-platform stuff. When that happens, I'll be > prepared to > violate the API, as it's not sacrosanct... it's just some code. > > In my mind, the big mistake is thinking that 'cos some chunk > of code has > worked well up till now, it should remain the way it is > indefinitely :) And > if it's turning into a big argument, it may be better just to > get on with it > :) You learn so much first time round that however well you plan it, > there'll be things you'll wish you'd done differently by the > end of the > project. > > Jamie |
From: Jamie F. <jfo...@re...> - 2001-03-16 10:01:19
|
I've also found that the whole rendering thing (bearing in mind we don't have things like OpenGL / DirectX to hide stuff from us on PS2) is too complicated to keep all in your head at one time. You'll need to have done it at least once to be able to do it properly... and then will think you need to do it again.... :) Jamie -----Original Message----- From: Akbar A. [mailto:sye...@ea...] Sent: 15 March 2001 20:37 To: gda...@li... Subject: RE: [Algorithms] general engine question >Opinions on that? What would you do if it was your first engine? Go the fast >and safe way or the 'better' one? wow. some really interesting ideas in this topic. this is the way i look at it. learn as you code. and don't worry if your always rewriting your engine blocks or if file formats never stick :) like even "professional engines" go through lots of rewrites, unreal tournament went through about 8. and iirc with *quake1, abrash said they probably wrote around 10-15 engines at his gdc talk("good to be balk" iirc). *john told me this was the hardest engine to write i can't emphasize more, screw "official" design initially, just rewrite code :D i see people that have never written 3d software in there life and ponder on how they are going to write the most optimal texture manager using classes(virtual, private, protected, friends, way to much to think about for your first try) and how they should use inheritance cause it seems like the right thing to do. ;) laterz, -akbar A. ;vertexabuse.cjb.net or ;www.vertexabuse.com cjb goes down once in a while "plastic or metallic. please pick your version of lighting ;) " .me -----Original Message----- From: gda...@li... [mailto:gda...@li...]On Behalf Of David 'Mythomania' Zaadstra Sent: Thursday, March 15, 2001 8:48 AM To: gda...@li... Subject: Re: [Algorithms] general engine question ----- Original Message ----- From: "Jamie Fowlston" <jfo...@re...> To: <gda...@li...> Sent: Thursday, March 15, 2001 1:01 PM Subject: RE: [Algorithms] general engine question > My personal view on this is that it's not worth getting too uptight about > it. If you're going to have time to tweak for each platform, you may well > end up with things you want to do and can do but which violate your API > layer (especially if it's your first time round trying to make such a layer, > as it is mine). The API's good while it lets you do what you want. When it > gets in the way, fix it or modify as you see fit. > > Jamie yeah that's exactly the point why we are arguing about that. It's our first game and we'd like to get it finished. Building such a layer might improve the overall quality of the engine since it's easily portable and extensible but it costs us even more time to do something like that. And since we are pretty sure that the game will be PC-only some of us think it's not necessary to build such a layer. And even if we port the game to consoles like the XBox that shouldn't be a problem 'cause the XBox supports DX8. So why bother about it? A compromise would be just to code the high-level functions (as mentioned before) and on low-level everything is API-specific. But the problems I see are for example that APIs use different coordinate systems, handle their renderstates in a different manner and maybe even are totally different in their design. That's why I just think: Code it in DX8, need half the time and get the game finished rather than wasting lots of time on the engine just to realize in the end that we can't get it done in a proper way. And THEN when we have experience in how to write an engine (all of us are "newbies") we can write a better one for our second project. Opinions on that? What would you do if it was your first engine? Go the fast and safe way or the 'better' one? > > -----Original Message----- > From: Neal Tringham [mailto:ne...@ps...] > Sent: 15 March 2001 12:03 > To: gda...@li... > Subject: Re: [Algorithms] general engine question > > > From: Daniel Renkel <Dan...@ho...> > > > > a simple question to all programmer's who do code actually complex 3d > > engine's for commercial games: > > how many of you use ONLY directx or ONLY opengl for it > > and how many use both via a layer / wrapper sort of - for their > > interface(s). > > we are somehow stuck in our discussion about it, in our team > > At present we use OpenGL (for PCs) and PlayStation 2 "native mode". To be > honest, though, I suspect the important question is not exactly which APIs > or targets you support as whether you should have some sort of intermediate > layer which allows you to support more than one target. I'd suggest that > the answer to this is definitely yes, given that you might want to port to > any of several consoles, and you can't be sure when you start which systems > you might be asked to support in the end. I'd also suggest building your > intermediate layer to use reasonably high level concepts rather than being > simply an API wrapper. Essentially, if I were on your team I'd want to have > a fairly high level "platform layer" and then implement it initially for > either D3D or OpenGL and a NULL (empty) renderer. > > Neal Tringham (Sick Puppies / Empire Interactive) > > ne...@ps... > ne...@em... > > > > > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > -Virus scanned and cleared ok > > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > _______________________________________________ GDAlgorithms-list mailing list GDA...@li... http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list _______________________________________________ GDAlgorithms-list mailing list GDA...@li... http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list -Virus scanned and cleared ok |
From: Jamie F. <jfo...@re...> - 2001-03-16 10:05:33
|
-----Original Message----- From: Paul Firth [mailto:pf...@at...] Sent: 15 March 2001 16:56 To: gda...@li... Subject: Re: [Algorithms] general engine question What about stuff like HUDs and particles and cases where you need to procedurally generate geometry like subdivision etc? Particles are just a type of mesh. When the particles are updated, you update the mesh. You can do the same for HUD, subdivision (although that may end up lower down in the renderer) and so on. You know the format for your meshes. So you can edit them. We're planning on putting a useful interface on top of the mesh so people don't have to understand the full intricacies of the mesh format, but the principle's the same. A mesh is just a way of batching polys together. There doesn't seem any point adding individual poly functionality to our renderer: the stalls would kill performance, and it would be hardly ever used anyway. Jamie -Virus scanned and cleared ok |
From: Jamie F. <jfo...@re...> - 2001-03-16 10:09:46
|
We have (not actual names, but close in spirit :) initialise startFrame addModel addSprite ... and some functions to initialise stuff when it's loaded, and that's it. Keeps everything sane :) Jamie -----Original Message----- From: Tom Forsyth [mailto:to...@mu...] Sent: 15 March 2001 18:27 To: gda...@li... Subject: RE: [Algorithms] general engine question The lowest level of abstraction I would advocate has calls like: Mesh::DrawThisMesh ( Matrix &orn ); TriBucket::AddTheseEffectTrisToABucket(...); TriBucket::FlushToScreen(); etc. Stuff like vertex buffers, index buffers, material setup, texture management, etc is just so different between APIs that it's madness to try to wrap anything lower-level than the above, IMHO. Tom Forsyth - Muckyfoot bloke. What's he up to now? http://www.muckyfoot.com/startopia/cam.html > -----Original Message----- > From: Jamie Fowlston [mailto:jfo...@re...] > Sent: 15 March 2001 15:32 > To: 'gda...@li...' > Subject: RE: [Algorithms] general engine question > > > I would say that the extra layer of abstraction is quite > useful; it helps > keep clear what you're working on, and where it belongs in > the grand scheme > of things. We've already experienced that benefit over our > previous quick > and dirty methods. Well, I have, anyway :) > > We're not finished yet, but we have a fairly reasonable > abstraction for the > moment. There are a few things (e.g. how dynamic lighting in > the environment > works) which threaten to violate the current API, and may be > different when > it comes to cross-platform stuff. When that happens, I'll be > prepared to > violate the API, as it's not sacrosanct... it's just some code. > > In my mind, the big mistake is thinking that 'cos some chunk > of code has > worked well up till now, it should remain the way it is > indefinitely :) And > if it's turning into a big argument, it may be better just to > get on with it > :) You learn so much first time round that however well you plan it, > there'll be things you'll wish you'd done differently by the > end of the > project. > > Jamie _______________________________________________ GDAlgorithms-list mailing list GDA...@li... http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list -Virus scanned and cleared ok |
From: Peter W. <Pet...@vi...> - 2001-03-16 10:33:00
|
Jamie Fowlston wrote: > A mesh is just a way of batching polys together. There > doesn't seem any point adding individual poly > functionality to our renderer: the stalls would > kill performance, and it would be hardly ever used anyway. As a couple of other people have said, we've found it quite useful to write a very streamlined low and mid level renderer that deals only with meshes (eg buckets of tris), and then build a really simplistic and easy to use 'draw a single rectangle/sprite/line' interface on the top. This is the graphics interface for the non-graphics programmers who need to draw stuff, either for debugging, or in a frontend screen, or for prototyping, or whilst a pause menu is up, ie any situation where the performance hit isn't going to be a problem. Certainly this interface is hardly ever used by any of the graphics guys, but it's been very handy for the rest of the team! Of course, if any of this code shows up on the profiler in a master build, it gets converted over to 'proper' graphics code, but that's been quite rare. Peter |
From: Jamie F. <jfo...@re...> - 2001-03-16 10:46:43
|
Yeah, we've got it for sprites, I suppose (as they're very simple anyway). But we're aiming for such things to be (in general) built from editable meshes. Performs the same job, keeps polys batched nicely from the word go, and just as easy for those who don't know what the renderer's really up to, but keeps the renderer itself somewhat cleaner (in my opinion :). Jamie -----Original Message----- From: Peter Warden [mailto:Pet...@vi...] Sent: 16 March 2001 10:40 To: gda...@li... Subject: RE: [Algorithms] general engine question Jamie Fowlston wrote: > A mesh is just a way of batching polys together. There > doesn't seem any point adding individual poly > functionality to our renderer: the stalls would > kill performance, and it would be hardly ever used anyway. As a couple of other people have said, we've found it quite useful to write a very streamlined low and mid level renderer that deals only with meshes (eg buckets of tris), and then build a really simplistic and easy to use 'draw a single rectangle/sprite/line' interface on the top. This is the graphics interface for the non-graphics programmers who need to draw stuff, either for debugging, or in a frontend screen, or for prototyping, or whilst a pause menu is up, ie any situation where the performance hit isn't going to be a problem. Certainly this interface is hardly ever used by any of the graphics guys, but it's been very handy for the rest of the team! Of course, if any of this code shows up on the profiler in a master build, it gets converted over to 'proper' graphics code, but that's been quite rare. Peter _______________________________________________ GDAlgorithms-list mailing list GDA...@li... http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list -Virus scanned and cleared ok |
From: Tom F. <to...@mu...> - 2001-03-16 11:22:19
|
> From: Peter Warden [mailto:Pet...@vi...] > > As a couple of other people have said, we've found it quite > useful to write > a very streamlined low and mid level renderer that deals only > with meshes > (eg buckets of tris), and then build a really simplistic and > easy to use > 'draw a single rectangle/sprite/line' interface on the top. > This is the > graphics interface for the non-graphics programmers who need > to draw stuff, > either for debugging, or in a frontend screen, or for > prototyping, or whilst > a pause menu is up, ie any situation where the performance > hit isn't going > to be a problem. Certainly this interface is hardly ever used > by any of the > graphics guys, but it's been very handy for the rest of the team! > Of course, if any of this code shows up on the profiler > in a master > build, it gets converted over to 'proper' graphics code, but > that's been > quite rare. > > Peter Works for us too. We also have some really grim-looking effects code that can animate and draw a mesh just like normal, except that instead of rendering the thing, for each triangle it calls a user-specified function that can then do anything it wants with the data. This is useful for stuff like teleporter effects, disintegration effects, exploding, diseases, rotting flesh, deformations, blobbiness, etc. You only get a few on-screen at any time, so the performance hit is fine, despite the massive inefficiency of the code. But it allows non-core people to easily throw some very cute effects together (we have one of those cartoon X-ray machines that shows skeletons, and a "space warp" disease that makes people look like they are reflected in a wibbly mirror) Tom Forsyth - Muckyfoot bloke. What's he up to now? http://www.muckyfoot.com/startopia/cam.html |
From: Michael T. <mi...@st...> - 2001-03-15 00:36:06
|
RE: [Algorithms] general engine questionWe have the same architecture = and currently only support a D3D renderer. The bigger benefit, IMHO, = from wrapping your 3D API is that you can upgrade through the API = versions during development without much hassle. We moved from DX6 to = DX7 in no time. -Mike ----- Original Message -----=20 From: Herb Marselas=20 To: 'gda...@li...'=20 Sent: Wednesday, March 14, 2001 6:47 PM Subject: RE: [Algorithms] general engine question Up until about 9 months ago we supported 3 renderers (D3D, OGL, NULL) = using a simple abstraction layer, with each renderer in it's own DLL. Doing features in D3D and OGL took a lot of time, and there were a lot = of driver bugs in OGL, but we supported it since our art team was only = running NT4. When they moved to win2k we dropped OGL support since they = could now run D3D. Now, we support only D3D and NULL.=20 I'm sure that as long as we keep things clean we could go in later and = put OGL back in, but there's little reason to do so. - herb=20 Ensemble Studios=20 http://www.ensemblestudios.com=20 mailto:hma...@en...=20 ICQ:35921824=20 -----Original Message-----=20 From: Daniel Renkel [mailto:Dan...@ho...]=20 Sent: Wednesday, March 14, 2001 5:40 PM=20 To: gda...@li...=20 Subject: [Algorithms] general engine question=20 hi there,=20 a simple question to all programmer's who do code actually complex 3d=20 engine's for commercial games:=20 how many of you use ONLY directx or ONLY opengl for it=20 and how many use both via a layer / wrapper sort of - for their=20 interface(s).=20 we are somehow stuck in our discussion about it, in our team;=20 Daniel 'SirLeto' Renkel [D.Renkel@FutureInt.de]=20 technical design director - creactivity and technowhow =3D8O)=20 Future Interactive [http://www.FutureInt.de]=20 _______________________________________________=20 GDAlgorithms-list mailing list=20 GDA...@li...=20 http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list=20 |