|MarekKnows Discussion Forum
|Using a differant level editor
|Page 1 of 1|
|Author:||Bukaroo7000 [ Fri Feb 06, 2009 11:14 pm ]|
|Post subject:||Using a differant level editor|
Is it possible that you can re-work the Game Engine to use a more popular editor like the Tomb raider level editor or Sandbox?
These are already avalable set-up kits you can start upgrading the game engine to something viable.
|Author:||codeslasher [ Sat Feb 07, 2009 5:20 am ]|
Your missing the point to these VMKs. Its about learning how to develop the tools not using an existing one.
If you want to use the other editors, you can go ahead.
But what happens when a new editor X comes out which you want to use?
If you don't understand the principles of what Marek is showing you, you will not be able to do so without someone showing you all over again! (Which is what Marek is doing with these videos.)
Gain the knowledge then strike out on your own.
|Author:||ajm113 [ Mon Feb 09, 2009 2:34 pm ]|
Uh, you do realize that Marek Already did create several tutorials that show to to parse files, right?
That include 3D Model Loading and simple level Script File Parsing.. :roll:
There are tons of resources on File Loading! Look at Mareks VMKs and study others model loaders or level loaders source codes.
Look at them and see how they work and then look at whats inside the Tomb Raider level script or what ever and see how its set up and mod your file loader to read it correctly.
|Author:||Bukaroo7000 [ Tue Feb 10, 2009 10:01 pm ]|
|Post subject:||Such Hostility|
First off, I have every video pretty much on this website. I have purchaced the DVD with the thought that it was a complete and viable engine and not just some picture of a dude going foward/backwards and side to side.
Not being the case my suggestion was to use a third party engine so the focus would be on the engine alone and possible getting to porting to direct X, adding collision, sound, ect...
As well, I don't believe that anyone who purchaced the DVD should have to continue purchasing the rest of the program that was absent such as collision and sound. It's like buying a book, reading it all the way through and find out if you want the ending you have to buy part two. I did that with Star Wars.
I haven't been on the site lately so I've only updated recently by D/L parts of Ghost Toast. Time permiting I will finish the initial video's, like everyone else real life interferes with my hobbies.
|Author:||BugHunter [ Wed Feb 11, 2009 7:34 am ]|
|Post subject:||Devil in the Details|
Cheer up, old fellow! Least of all hostility was intended or implied. I believe it was just awkward prose style or unpremeditated side effect. ;)
I understand my colleagues in the way that first reaction on your proposal is to say that GE intentionally avoids third party libraries, except OpenGL on its own, because the main goal is to acquire generic knowledge, not to get buy-and-plug-in appliance (excuse the reiteration).
However you are absolutely right that in real life it would be too impractical to use only hand-made stuff, since it is too time-consuming, apart from the necessity to be an expert in quite different domains at the same time, say sound processing, networking, packing, cryptography, compilation theory, 3D, AI, physics, math, etc, etc.
As to the subject, I find your request quite reasonable. In particular I do agree that GE should have some means to expose its containers to allow them be filled with the stuff which is read from external sources.
In short, I would propose following scheme. But devil in the details.
Class SceneBuilder has an access to the internals of the class Scene (either as a friend or receiving the references to the containers of the Scene during initialization). Alternatively, all containers might be defined as global objects (this is considered as not to be very good practice in general purpose programming but gamedev is another story, i.e. Andre Lamothe is not ashamed to use globals). Anyway, SceneBuilder should have the ability to fill materials, lights, textures, etc containers in and to grow the Scene Graph.
Then SceneBuilder exposes public interface using which its external clients (proxies) can add stuff to the scene. A tiny part of such interface might be like this:
Code: Select all
To add the support of a new format the developer may use 3rd party libraries and/or write handmade parsers. The parser, i.e. COB-bin parser, LVL-parser etc supplies the special proxy class with the data in the native (for the parser) format. Proxy class behaves like glue between the parser and the SceneBuilder converting the data from the parser's output to the calls of the SceneBulder's methods.
The bright side of this approach is that you do not have to rewrite the code, which adds the stuff to the scene every time you add new format.
I understand that this scheme is pretty rough, too general, too obvious and as such almost useless; the main work is in developing good interface and in organizing smooth process flow.
Vanquish the Beelzebub!
|Author:||Bukaroo7000 [ Thu Feb 12, 2009 2:30 am ]|
|Post subject:||If I understood Greek|
I would know exactly what you just said but the closest I've got was a visit to Italy 10 years ago :?: .
|Author:||BugHunter [ Fri Feb 13, 2009 5:04 am ]|
|Post subject:||Beelzebub is not to be a friend of Zeus|
... a visit to Italy 10 years ago
Good for you. :) However you may "google" the Beelzebub to find this
|Page 1 of 1||All times are UTC - 5 hours|
|Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group