chosing a 3D engine at runtime - how?
BlitzMax Forums/BlitzMax Beginners Area/chosing a 3D engine at runtime - how?
| ||
| Hello! It seems as if the Blitz3D API acts as a template for several 3D engines which can be used from within BlitzMAX (e.g., MiniB3D, iB3D, the Leadwerks engine). This leads to the next question: if several engines share the same API, will it be possible to chose a specific engine while a BlitzMAX program is running? One benefit would be: let the program find out which engine is actually installed on a given system an use that - there may be free and commercial engines and users may have different engines on their system... |
| ||
| no. regardless of the MODULE that might be installed in a persons particular BlitzMAX Mod folder, the Compiled Executable does not care. you should develop with the best system and set of modules for you, once it gets "baked" into a runtime EXE, the modules you used to make it don't matter much. you CAN choose the 3D API generally on some modules (OpenGL or Direct3D). but miniB3D for instance is OpenGL only. |
| ||
| Bill, thanks for the info - I was afraid that exactly that would be the answer... The best module for *me* might not be the best module for somebody else - but currently there seems no alternative than to build one executable for every 3D module that might be used (sigh) |
| ||
| The best module for *me* might not be the best module for somebody else While that's true from a programmers perspective, from an end-users perspective... but currently there seems no alternative than to build one executable for every 3D module that might be used (sigh) ... this is absurd. Why on earth would you do that?!? |
| ||
| One benefit would be: let the program find out which engine is actually installed on a given system an use that - there may be free and commercial engines and users may have different engines on their system... but currently there seems no alternative than to build one executable for every 3D module that might be used (sigh) I dont think you know what a 3d engine is. |
| ||
| Hmmm, in my opinion, a 3D engine is nothing but a module with a given functionality. There are several of them with their own avantages or disadvantages (free/commercial, run on a given graphics card or not, faster or slower) To give a very simple example: the Leadwerks engine seems impressive, but it (currently) has its problems with ATI cards. Given, that all engines share a common (basic) command set, a customer could choose a version which runs on his/her system - or, even better, choose it when the program starts. |
| ||
| Given, that all engines share a common (basic) command set, Your assumption here is disastrously wrong. a customer could choose a version which runs on his/her system How could the customer know (much less care) which Engine was best suited to his machine configuration?A better alternative would be for the developer to figure out his target audience, and then pick an engine suitable for that. |
| ||
| some definitions: 3D API: a set of low-level 3D functions that help draw stuff on your monitor. There are 2 to choose from: 1. OpenGL (Mac, Windows, Linux) 2. Direct3D (Windows) 3D Engine: a set of routines that handles the drawing of 3D objects using one of the aforementioned low-level API's. There are quite a few of these, 3D Engines will have collisions,terrains, BSP or other Occlusion techniques, 3D model loaders, etc.: 1. IIrrlicht (can use OpenGL or D3D) 2. OGRE (OpenGL or D3D) 3D Game Engine: usually has a 3D engine plus lots of game specific tools, like editors, scripting, etc: 1. Source SDK (Half-Life 2) 2. UnrealED 3. Torque Game Engine With Source you can make a Mod for HL2. 3D Programming Language. A programming language with a set of special commands that simplify the process of creating 3D games and apps. no level editors, no media creators, just code. all will allow you to load media (sounds, 3d models and textures) 1. DarkBasic (? D3D i think) 2. Blitz3D (Direct3D) 3. miniB3D (OpenGL) is a Module for BlitzMax. miniB3D uses it's own rendering system that is written in BlitzMax and based on the Blitz3D commandset. The MAJOR differences between miniB3D and Blitz3D are: MiniB3D=OpenGL / Blitz3D=Direct3D 7 miniB3D is a module for blitzmax / Blitz3D is a standalone, complete language miniB3D= <1yr old (i think) and at 0.41 stage Blitz3D = 5+ years at 1.9x stage I prefer a Game/3D programming language. It gives the most flexibility. a AAA engine such as Source Is tremendously powerful and feature rich but lock you in to the type of game it was desgned for (FPS for instance). Some creative souls have pushed the limits and made some excellent mods but generally, mod development requires you to stick to the genre. |
| ||
| I think there's a fundamental misunderstand of what Andreas is looking for. I don't believe he is talking about gamers as customers, he is talking about developers. I believe what he's looking for is an abstract 3d game engine API which can utilize more than one of the BlitzMax 3d renderers, likely so that he can provide LUA bindings which will be usable for people using various engines. No such thing exists, to my knowledge, at least not publicly. I have my own private module which does precisely this, but since it currenly only supports a TV3D renderer ( because that's all I need ) it wouldn't be any use and I have no plans to release it anyway. It's a good idea though. miniB3D uses it's own rendering system that is written in BlitzMax and based on the Blitz3D commandset. So then it's not a language, because BlitzMax is the language. |
| ||
| Hello again, Bill came up with some "definitions", which is probably a good starting point. Unfortunately, none of the terms fits exactly: what I am talking about would be a "3D Engine API", as I don't care about OpenGL vs. DirectX, not about a Game Engine and the term "3D programming language" is probably to broad... MiniB3D and iB3D already have a very common set of routines. In fact, both of them have been designed after Blitz3D which seems quite common. What if *all* "3D Engines" would share the same BlitzMAX function set? The BlitzMAX program would then be independent of them (to a certain degree, as usual with "standards") and the final customer could then choose among several "3D engines" if he/she recognizes that a certain engine does not work on his/her machine, e.g. |
| ||
| Well, my 2 cents about this. In fact it would be possible in some way. Think the way the Max2D or MaxAudio Modules are built into Blitzmax. I mean Driver vise. To have this working with the different 3D Engines you have to make a more or less lower level version of each engine which provides access to the renderpipeline in the same way the other engines do. After that you could create a main 3D core module which provides the highlevel functions in an abstract way and built easily a different '3DEngine Drivers'. But what do you benefit from this: I think nothing. You have to maintain a lot of different APIs most engines, they use different coord systems and the most annoying thing is that the developer has to know what is going on under the hood of all these drivers to provide good support to his customers. Also not every engine has the same feature set or handles features different then others so you have to keep all the extra things (mainly advantages) of an engine out of the drivers because you need the same functionality on each driver. Take the maxgui system: We have 3 Drivers providing nearly the same behaviour to us customers, but take a deeper look how difficult it is to provide the same functionality and look on each platform for BRL. Also we all want features like Tablelists and the like but they could only be built in when these features are available for each Driver everythingelse would collapse the Driverthingy. So in my opinion this is a no go, providing 2 different APIs like openGl/DX maybe possible but wrapping different engines to provide the same functionality is a work without light at the end of the tunnel. cheers klepto2 |
| ||
| Benjamin, these are the classical arguments against "standards" (difficult to realize, special advantages of a given "proprietary" solution get lost, development of new features is slowed down, etc.) And these arguments are mentioned regardless of the actual topic (I've been working in the area of (multimedia) telecommunications - and *their* (protocol) standards - since 1991) History has shown, that the result leads to s.th. like a 80%-20% solution: 80% standard, 20% proprietary. As a consequence, all participants have their benefits (well, and what would the world look like today without HTML and HTTP - regardless of their numerous(!) disadvanages - you could easily apply your arguments again!) Or, to give a positive argument: the fact that there are 3 drivers to render MaxGUI makes BlitzMAX interesting for cross-platform programmers (like me) I would never have invested a single second into BlitzMAX without that feature! Additionally, there already *are* some "3D engines" with a very similar set of functions under BlitzMAX - the final step to a common set is therefore quite natural (in my own opinion, of course) Why don't we make a "feature" out of the "problem" (of not having Max3D)? |
| ||
| In fact, both of them have been designed after Blitz3D which seems quite common. Exactly which definition of "common" are you using here? What if *all* "3D Engines" would share the same BlitzMAX function set? Yeah that's a brilliant idea. I mean who (the people who show up every other week whining about Max3D as the exception) could possibly want to do anything outside what the 6 year old Blitz3D Interface allows? I mean games these days don't have advanced shading and deformation, physics simulation and soft shadows! It's not like you actually need all that fancy stuff to make a match 3 game. History has shown, that the result leads to s.th. like a 80%-20% solution: 80% standard, 20% proprietary. What history? Name a single market leading software product that is even close to 80% standards compliant! Besides which in Blitz3Ds case it would be more like 20-80. Why don't we make a "feature" out of the "problem" (of not having Max3D)? How is not having Max3D a problem? |
| ||
| *reads tosh* What a load of... tosh. :P One of the things with 3D engines is that you chose what suits you best, as the programmer, based on your needs and target audience. If the programmer cannot make their mind up what engine to use then they are not going to be able to make similar decisions later- Which sound system do I use? How do I implement AI? Chose an engine with a flexible feature set, multiple pipelines if you will but merging engines into a "common" commandset is a bad idea. Doing it to get two render pipelines in is a *really* bad idea, and also, look at this: What if <x> engine is slow at <n> feature but good at <n2> but <y> engine is fast at <n> and slow at <n2>? There will be huge performance "issues" that will be hard to iron out, and you're likely going to get alot of bug reports regarding things you have no say over. |
   |