map2dif related questions
by Injae Jeong · in Torque Game Engine · 04/18/2003 (11:41 am) · 4 replies
I have started to get a feel of Torque Engine capabilities by now after 2 weeks. :) which is definitely a good thing. But I am tormented by a zillion questions. I will post only a few of them (related to map2dif) for now. :) Any suggestions, hints and answers will be gr8ly appreciated.
I will explain what is my understanding (please correct me if I am wrong) and then pose questions.
A map file contains information about textures mapped to entities. The game definiton file is *.fgd. The engine reads the dif file, I suppose, to render the world created in WC.
My first question:
Q. Who writes a .fgd file? Is it the developer or is it a output of some utility. If I make any changes to the file entityTypes.cc in engine code, will I have to modify the .fgd file or will the compilation process take care of it? If I have to add, what exactly goes in there ?
Q2. Whats a dif file contain? Why is it written in an excel file?
Q3. Is there a guideline as to what goes as an entity and what should be added through a mission editor. For example, FXlights. Do I add an entity like corona_light (to be used in WC) or I add it as a mission object? Is the .dif file faster to be rendered than a object added through mission editor? How does it work?
Q4. How difficult is it to add an entity to map2dif project files? Can I find an example on garagegames?
I know these are a lot of questions but I am a newbie and having sleepless nights( ok exaggerated a bit :) ). Some of the questions might also seem stupid I guess. But please help. I can promise to share my to be gained knowledge with future newbies :)
thanks.
I will explain what is my understanding (please correct me if I am wrong) and then pose questions.
A map file contains information about textures mapped to entities. The game definiton file is *.fgd. The engine reads the dif file, I suppose, to render the world created in WC.
My first question:
Q. Who writes a .fgd file? Is it the developer or is it a output of some utility. If I make any changes to the file entityTypes.cc in engine code, will I have to modify the .fgd file or will the compilation process take care of it? If I have to add, what exactly goes in there ?
Q2. Whats a dif file contain? Why is it written in an excel file?
Q3. Is there a guideline as to what goes as an entity and what should be added through a mission editor. For example, FXlights. Do I add an entity like corona_light (to be used in WC) or I add it as a mission object? Is the .dif file faster to be rendered than a object added through mission editor? How does it work?
Q4. How difficult is it to add an entity to map2dif project files? Can I find an example on garagegames?
I know these are a lot of questions but I am a newbie and having sleepless nights( ok exaggerated a bit :) ). Some of the questions might also seem stupid I guess. But please help. I can promise to share my to be gained knowledge with future newbies :)
thanks.
#2
Thanks a lot for your detailed reply. It saved me ton of work. But I guess I will have to add entities anyways, entities like breakable glass. I dont see any workaround other than modifying map2dif. Is there some documentation about map2dif's design, dif format or any guidelines to get me started? Please help.
05/06/2003 (8:48 am)
hi Matthew,Thanks a lot for your detailed reply. It saved me ton of work. But I guess I will have to add entities anyways, entities like breakable glass. I dont see any workaround other than modifying map2dif. Is there some documentation about map2dif's design, dif format or any guidelines to get me started? Please help.
#3
map2dif has some very nice parts and some really horrible parts. I wouldn't worry overmuch about map2dif's overall design. The parts you are going to want to look are:
EditGeometry::Entity* EditGeometry::parseEntity(Tokenizer* pToker) in editGeometry.cc
entityTypes.h
EditGeometry::exportToRuntime(Interior* pRuntime, InteriorResource* pResource) in exportGeometry.cc
You will also need to edit:
Interior::read(Stream& stream) in interiorIO.cc
Interior::write(Stream& stream) in interiorIO.cc
Your rendering should be internal to your new entity but if you just want to stick some code in for the time being to get it on the screen, this is a good place to start:
Interior::render(const bool useAlarmLighting, MaterialList* pMaterials, const LM_HANDLE instanceHandle,
const Vector* normalVLights,
const Vector* alarmVLights)
in interiorRender.cc
Most modern video cards will end up calling:
Interior::renderARB_FC(const bool useAlarmLighting, MaterialList* pMaterials, const LM_HANDLE instanceHandle)
in interiorRender.cc
A good place to do some pre-processing is:
InteriorInstance::onAdd() in interiorInstance.cc
Beyond that, you are really going to have to dig through the engine to add custom behaviors for your entities. Try to find an entity that is similar to what you want and model yours after it. Like for breakable glass, I would take a look at the forcefield code since they exhibit similar behaviors and rendering.
You might want to look at www.garagegames.com/index.php?sec=mg&mod=forums&page=result.thread&qt=8911 for a work-around for breakable glass if that is all you are interested in.
As far as the .dif format goes, I would highly recommend that you don't worry about it and just rely on Interior::read and Interior::write. The format is huge. At first glance it seems fairly simple but there are layers and layers underneath this calm exterior. It adds up quickly. I've documented about 1/4th of it after three days of work and finally just gave up.
Honestly, I feel that the dif format is not the future of TGE. I am trying to add in some new features to make it easier for current mappers to work with but at some point this summer I am going to spec out a new format that I feel will meet the needs of TGE and its games better.
05/06/2003 (10:36 am)
map2dif's design:map2dif has some very nice parts and some really horrible parts. I wouldn't worry overmuch about map2dif's overall design. The parts you are going to want to look are:
EditGeometry::Entity* EditGeometry::parseEntity(Tokenizer* pToker) in editGeometry.cc
entityTypes.h
EditGeometry::exportToRuntime(Interior* pRuntime, InteriorResource* pResource) in exportGeometry.cc
You will also need to edit:
Interior::read(Stream& stream) in interiorIO.cc
Interior::write(Stream& stream) in interiorIO.cc
Your rendering should be internal to your new entity but if you just want to stick some code in for the time being to get it on the screen, this is a good place to start:
Interior::render(const bool useAlarmLighting, MaterialList* pMaterials, const LM_HANDLE instanceHandle,
const Vector
const Vector
in interiorRender.cc
Most modern video cards will end up calling:
Interior::renderARB_FC(const bool useAlarmLighting, MaterialList* pMaterials, const LM_HANDLE instanceHandle)
in interiorRender.cc
A good place to do some pre-processing is:
InteriorInstance::onAdd() in interiorInstance.cc
Beyond that, you are really going to have to dig through the engine to add custom behaviors for your entities. Try to find an entity that is similar to what you want and model yours after it. Like for breakable glass, I would take a look at the forcefield code since they exhibit similar behaviors and rendering.
You might want to look at www.garagegames.com/index.php?sec=mg&mod=forums&page=result.thread&qt=8911 for a work-around for breakable glass if that is all you are interested in.
As far as the .dif format goes, I would highly recommend that you don't worry about it and just rely on Interior::read and Interior::write. The format is huge. At first glance it seems fairly simple but there are layers and layers underneath this calm exterior. It adds up quickly. I've documented about 1/4th of it after three days of work and finally just gave up.
Honestly, I feel that the dif format is not the future of TGE. I am trying to add in some new features to make it easier for current mappers to work with but at some point this summer I am going to spec out a new format that I feel will meet the needs of TGE and its games better.
#4
thanks a ton for your detailed reply again! I tried using different entities in WC to get a idea about how they work. But the objects dont seem to respond. For example, I used a cylinder and tied it to forcefield but the object disappears in the game. When I tied it to collision, I fall through my mission area into te terrain. When I tied it to 'trans'( I used the resource to download the codes snippet) it appears with no difference. The mission area is an enclosed area and I add the object in an existing .map file. I read the tutorial on WC but no help there. What am I doing wrong?
05/06/2003 (1:36 pm)
Matthew,thanks a ton for your detailed reply again! I tried using different entities in WC to get a idea about how they work. But the objects dont seem to respond. For example, I used a cylinder and tied it to forcefield but the object disappears in the game. When I tied it to collision, I fall through my mission area into te terrain. When I tied it to 'trans'( I used the resource to download the codes snippet) it appears with no difference. The mission area is an enclosed area and I add the object in an existing .map file. I read the tutorial on WC but no help there. What am I doing wrong?
Associate Matt Fairfax
PopCap
The fgd is hand generated so if you add any new entities to TGE then you will have to add them by hand to the fgd file. This is a pretty straight-forward process if you look at how the current entities are implemented.
The hairy part though is adding the new entity to the dif file format. You will have to add read and write code as well as any code you need to render and/or handle the new entity at run time. You will also have to add support to the map2dif parsing process for the new entity (it is fairly infelxible and will often barf on unknown entities). Then you will have to add processing code for the new entity in map2dif. This can vary from simple data storage for later use up to complex interactions with the lightmap and collsion detection calculations.
In a nutshell dif files contain geometry (polys) information, texture information, collision information, portal/zone information, lighting information, and some special entity information. There is a lot more to these parts and how they work together. The Excel thing is just a misfortunate naming issue with a TGE .dif and some kind of file Excel can handle having the same file extension. You can't actually open a TGE dif in Excel and I would recommend against trying to since it might corrupt your data.
If you can add your "entity" through the mission editor then definitely go that route. It will likely go a lot easier on you. The dif format is fairly intense.