Doomworld Forums - Doom64EX Editing Support

Doomworld Forums : Powered by vBulletin version 2.2.5

Doomworld Forums > Classic Doom > Doom Editing > Doom64EX Editing Support - Need volunteers

Author

All times are GMT. The time now is 20:54.

Kaiser
Doom64 Guru

Posts: 2632
Registered: 08-00

With Doom Builder 2 already out and several plugins that are getting released, I am seeking volunteers to help get D64EX support for Doom Builder 2. Reason why I am asking is because that unfortunately, I do not have time to learn C# and learn the code structure in DB2 and my free time on Doom64EX itself is getting smaller and smaller, so rather I want the community to pitch in, assuming that they ARE interested in modding for Doom64. My hacked version of Doom Builder 1 is just causing so many frustrations to those who wants to make maps for it and I just want something that is stable and efficient.

While on the subject, this thread can also be used to discuss new editing features or editing improvements to help speed things up when editing levels for Doom64. Reason why I said that is because editing lights is VERY tedious and I know for certain that there were better and faster ways that the devs did when lighting the sectors.

So if anyone is interested, please post and I'll provide additional information on the requirements. Basically to briefly summarize to those that wants to know what they're getting themselves in to, here are the differences from Doom1/2:

* No Pnames/Textures lump

* Textures are all listed and stored in the T_START and T_END markers. Anything out of these markers is considered a simple gfx lump (for huds, skies etc).

* Sidedefs uses indexes instead of 8-char names. The indexes are based on the order the textures are listed in the T_* markers.

* All textures in Doom64EX are in 8-bit PNG format, which means that each texture uses its own palette. Same goes for sprites as well.

* Maps are stored as wads within the main iwad. So basically to edit a map, that wad needs to be extracted from the iwad to edit/view.

* Two new map lumps which are needed: LIGHTS and MACROS. The lights lump is basically a table that stores all the RGB information and macros contains info about the scripted stuff (similar to Doomsday's DED).

* I've already released a bsp compiler for Doom64ex, which Doom Builder 2 will need to be configured to use it.

* Vertices data are stored as ints instead of words.

* Linedef/sector format is different.

I am also working on a WIP technical document on Doom64, which can be read here: http://dl.getdropbox.com/u/18609/D64_EditingSpecs.txt

The doc is unfinished though, but I still work on it whenever free time is possible. There are also some things that needs better naming to better identify its use, like flags for example. So its available for improvement.

Feel free to ask any other questions as I am mostly visiting these boards..

10-04-09 05:10 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

InsanityBringer
Member

Posts: 385
Registered: 08-07

I could take a look at it. I'm not sure if I'll get anywhere though.

10-04-09 17:03 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Kaiser
Doom64 Guru

Posts: 2632
Registered: 08-00

InsanityBringer said:
I could take a look at it. I'm not sure if I'll get anywhere though.

Well, what do you think you can look into?

10-06-09 23:27 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

InsanityBringer
Member

Posts: 385
Registered: 08-07

I may be able to get things exporting into the new map format, and hopefully set up some system for creating macros. It looks like DB2 can handle the PNGs used for textures within the Doom 64EX IWAD file, so that's helpful.

The only thing I probably will not be able to do is the lighting in 3D mode. I know almost nothing about how to do it.

10-07-09 00:03 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Kaiser
Doom64 Guru

Posts: 2632
Registered: 08-00

InsanityBringer said:
I may be able to get things exporting into the new map format, and hopefully set up some system for creating macros. It looks like DB2 can handle the PNGs used for textures within the Doom 64EX IWAD file, so that's helpful.

The only thing I probably will not be able to do is the lighting in 3D mode. I know almost nothing about how to do it.

I would prefer we start with the basics, like map formats. The lights and macros lump can wait and during that time, people can use an external utility for compiling macro lumps (thanks to Quasar) but later down the road, I would prefer that this be handled in DB2 since macros aren't technically an optional map lump as well as the lights lump.

First thing first is to make sure that DB2 understands Doom64's 32bit vertex format and its indexed sidedefs lump (must understand that the index values in sidedef's mid/top/lower texture points to the lumps within the T_* markers).

10-07-09 22:19 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Kaiser
Doom64 Guru

Posts: 2632
Registered: 08-00

Well since no one is helping, I decided to struggle with this myself. As of now I got DB2 to read the map format without too much trouble, though need to add writing support afterwards. I am also VERY glad that I decided to use the PNG format for textures/sprites. This has made everything much easier..

Sneak preview here: http://img12.imageshack.us/img12/2/65668291.jpg

11-08-09 23:54 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Mechadon
Senior Member

Posts: 1753
Registered: 12-06

So awesome :D. I eagerly await being able to make Doom 64 maps. Thanks for that update Kaiser.

11-09-09 01:42 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

InsanityBringer
Member

Posts: 385
Registered: 08-07

Crap, I'm sorry I didn't get anything done. School happened

11-09-09 03:13 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Dragonsbrethren
Member

Posts: 567
Registered: 03-09

Yeah, Kaiser, looking good.

11-09-09 04:14 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

CodeImp
Moderator

Posts: 1441
Registered: 12-03

Oh shit, why haven't I seen this topic earlier... I am currently in the process of moving (painting the walls now) and writing software for a central computer in my house, so that is why development on DB2 is currently on hold. But I am willing to help you out on this project where I can!

Most of the changes you need can probably be made with a plugin if I add support for it, but I doubt some changes (such as Linedef & Sector properties) can be made to work nicely with plugins (unless you are willing to use the Custom Fields for your custom properties, which is now only used by UDMF).

Would you like an SVN branch in the DB2 repository to work in so that you can later merge in any future fixes/changes more easily?

About the texture indices instead of names; I think you should just lookup the correct indices in your MapSetIO class and just stick to names in all the other code. I make this suggestion because it is harder to accept future changes from the main branch if the entire source code is turned upside down.

If you have any technical questions, please use the dev forums: http://www.doombuilder.com/forums/ If there is a feature you need to add, but can't be added nicely into the code as it currently is, please ask me so we can come up with a clean solution. It would be best if everything could be done through a plugin, but I am not sure all that you need could work that way.

EDIT: Oh and the current version in the SVN is not entirely stable. Its a work in progress I currently don't have time for to finish :(

11-09-09 06:56 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Kaiser
Doom64 Guru

Posts: 2632
Registered: 08-00

CodeImp said:

Most of the changes you need can probably be made with a plugin if I add support for it, but I doubt some changes (such as Linedef & Sector properties) can be made to work nicely with plugins (unless you are willing to use the Custom Fields for your custom properties, which is now only used by UDMF).

Yeah I was trying to avoid tampering with the actual code as much as possible and separate all of my additional code in a plugin, but thats not going to happen.

So far I created a new format in addition to Doom/Hexen MapIO and I got the editor to read and write out Doom64 maps with little effort.

CodeImp said:

Would you like an SVN branch in the DB2 repository to work in so that you can later merge in any future fixes/changes more easily?

I already got access to the SVN :)
Though I may hold on to my changes for you to review before I submit them to the SVN. I also have a few solutions and ideas that I've been toying around like linedef flag colorization through configs.

CodeImp said:

About the texture indices instead of names; I think you should just lookup the correct indices in your MapSetIO class and just stick to names in all the other code. I make this suggestion because it is harder to accept future changes from the main branch if the entire source code is turned upside down.

I basically had to do what I did with my hacked DB1. I had to add a new config property that defines a index for all d64 texture names and have DB2 look up that list when reading from sidedefs. Its able to read walls/flats now with little code change.

CodeImp said:

If you have any technical questions, please use the dev forums: http://www.doombuilder.com/forums/ If there is a feature you need to add, but can't be added nicely into the code as it currently is, please ask me so we can come up with a clean solution. It would be best if everything could be done through a plugin, but I am not sure all that you need could work that way.

EDIT: Oh and the current version in the SVN is not entirely stable. Its a work in progress I currently don't have time for to finish :(

I believe I registered already. I plan on posting soon once I have some questions gathered. I've also been looking into new config properties that would otherwise help out for plugins.

The biggest change that will have to be done is the new sector properties, colored lighting, and macros. I actually imagine the sector property window taking up most of the time. There's also going to have to be a few things that will need to be hidden or disabled like sector brightness.

Macros can probably be treated as 'scripts' in DB2 but I would rather prefer to how I have them setup in my hacked DB1.

Lighting is going to be a pain in the ass because its a completely separate map lump that the sector references. Though, rendering the lighting in 3D mode shouldn't be a problem but I am planning on allowing the user to edit the lights while in 3D mode.

I still have the hacked DB1 if you're interested in seeing how I have things setup but anyways, I am trying to avoid as much extra code as possible.

Last edited by Kaiser on 11-09-09 at 16:24

11-09-09 16:14 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

CodeImp
Moderator

Posts: 1441
Registered: 12-03

Yea, please email/upload me a copy. I thought I still had it laying around somewhere, but I can't find it.

What I meant by SVN access is your own branch from the main repository in which you can commit your work. If we can't find a way to make everything work through a plugin then it is better to branch the source and make a separate release. But I am willing to make changes in the core to support whatever you need to make it work through a plugin.

For example; I can have the DataManager keep a list of indices for the loaded textures and provide those to a plugin and make it possible for plugins to provide their own MapSetIO. That way you can write your own MapSetIO in a plugin that uses the indices lookup table to read/write the textures indices.

The lighting colors in Visual Mode are very easy to add; you first have to copy the Visual Mode classes from the BuilderModes project into your own plugin so that you have the same Visual Mode features that the original mode provides, then add your own code in.

I'm not sure about the interface changes you need. Maybe I can have plugins provide their own tab pages for the property dialogs (and allow plugins to hide existing tabs)... or you can use the Custom Fields (see the UDMF format how it dynamically creates custom properties and how they are presented on the property dialogs). Those Custom Fields are defines in a game configuration and you can easily read/set them on the map geometry classes (which means you can do whatever you want with them in your MapSetIO).

11-09-09 18:18 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Kaiser
Doom64 Guru

Posts: 2632
Registered: 08-00

I pm'ed you a message about the hacked DB1. As for DB2 goes, I may just end up creating my own branch/version. Maybe call it DB2-Plus or something :P

11-14-09 20:23 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Gez
Why don't I have a custom title by now?!

Posts: 6458
Registered: 07-07

DB 64.

11-14-09 20:38 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Kaiser
Doom64 Guru

Posts: 2632
Registered: 08-00

Update time

http://img692.imageshack.us/img692/2364/80012263.th.jpg

There is only one problem I am running into at the moment. Masked transparency - Its really difficult to figure out how DB2 knows what color pixels to mask out on either textures or sprites. Since all images are loaded as 32 bit ARGB format, I can't just easily say that the first color data in the palette is used for transparency since all images are stripped of their palettes when loaded into DB2.

Last edited by Kaiser on 11-23-09 at 00:52

11-22-09 22:51 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Mechadon
Senior Member

Posts: 1753
Registered: 12-06

Niiice :D

11-22-09 23:00 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

esselfortium
Cumulonimbus Antagonistic Posting

Posts: 5153
Registered: 01-02

Omg Kaiser YES :D

11-22-09 23:31 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Dragonsbrethren
Member

Posts: 567
Registered: 03-09

I can't wait to give mapping for this game a try. I could never get my maps made with the DB1-based editor to run for some reason.

11-23-09 00:16 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Kaiser
Doom64 Guru

Posts: 2632
Registered: 08-00

Yet another progress screenshot

http://img28.imageshack.us/img28/7527/11444379.th.jpg

I am getting satisfied enough to calling it done for now unless people who will actually use it requests for improving editing and whatnot. Because of the ridiculous amount of changes done to DB2, I have no choice but to make it a separate/standalone editor. Though I don't plan on supporting it after its done due to other overwhelming stuff thats going on.

11-30-09 01:18 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Fisk
Forum Regular

Posts: 821
Registered: 02-07

Dang. Fiskmaps 64 to hit store shelves soon.

Out of curiosity, "limitations" are mentioned in the tech document table of contents, but obviously are not present in the document body. Would you be willing to give some numbers in this regard?

11-30-09 19:37 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Kaiser
Doom64 Guru

Posts: 2632
Registered: 08-00

Fisk said:
Dang. Fiskmaps 64 to hit store shelves soon.

Out of curiosity, "limitations" are mentioned in the tech document table of contents, but obviously are not present in the document body. Would you be willing to give some numbers in this regard?

Well for one there aren't any vis/seg limits so no need to worry about that. The limitations that I am concerned about is mostly related to the d64ex engine. D64ex is a tad bit more sensitive than prboom/zdoom in terms of how many sectors/linedefs it can push at one given scene. However this isn't a problem if the number of texture variations is kept to a minimum, so a bad example would be rendering 500 sectors in one scene, each with having a unique ceiling/floor texture. D64ex also has several dev features that tells you when you're pushing too many polygons or making too many texture binding calls.

Don't get me wrong, D64ex is capable if handling fairly large maps, just don't expect it to run something like the Vrack series.

On a side note, the mobj(thing) loop code has been optimized and redesigned somewhat, allowing fewer calls to P_CheckSight. Now I still don't know if something like Nuts.wad would run faster but it would be interesting to see how much of a difference it made.

Last edited by Kaiser on 12-01-09 at 01:25

12-01-09 01:20 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

CodeImp
Moderator

Posts: 1441
Registered: 12-03

Good to see this Kaiser! Couple questions, if you don't mind:

- Are there any questions still unanswered that you would still like to know to continue your work? For example; Did you figure out that transparency part about which you wrote here?

- I see you are using the latest, unstable SVN version to build your branch from (instead of the latest official release). Are you willing to update and merge any changes we make to DB and release new versions of this editor that include the base DB changes/additions?

- How did the overall implementation go? Are there parts of the source code poorly documented? Was the object oriented structure flexible enough to let you make your implementations?

EDIT: Also, where is the download? :P

Last edited by CodeImp on 02-03-10 at 15:00

02-03-10 14:48 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Kaiser
Doom64 Guru

Posts: 2632
Registered: 08-00

CodeImp said:

- Are there any questions still unanswered that you would still like to know to continue your work? For example; Did you figure out that transparency part about which you wrote here?

Yeah I did, but I had to sorta hack things in to get it working right. Doom64's graphics indicate that a pixel is transparent if the pixel points to the first index in the palette. It was sorta hackish, but trivial to implement.

CodeImp said:

- I see you are using the latest, unstable SVN version to build your branch from (instead of the latest official release). Are you willing to update and merge any changes we make to DB and release new versions of this editor that include the base DB changes/additions?

I am hoping to do that once I get everything up on my SVN.

CodeImp said:

- How did the overall implementation go? Are there parts of the source code poorly documented? Was the object oriented structure flexible enough to let you make your implementations?

There was some parts that I kinda got confused on, but I managed to figure things out fairly quickly. Though I can't remember what were the things I struggled with right now. For one, I know that I had a hard time understanding the 3D rendering process in the editor.

CodeImp said:

EDIT: Also, where is the download? :P

Right here: http://dl.dropbox.com/u/18609/Builder64.zip
Source: http://dl.dropbox.com/u/18609/Builder64_src.7z

EDIT: Crap, the source may be outdated...

Also, I don't know much about memory management in C# and the Dispose method, so I may have introduced some memory leaks with the new code I added. Also everything that I added has been commented with //villsa

Last edited by Kaiser on 02-03-10 at 15:51

02-03-10 15:46 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

CodeImp
Moderator

Posts: 1441
Registered: 12-03

Thanks! Yea the Visual Modes code design is a bit complicated. The idea is that the Renderer3D does the actual rendering, once you finish telling it what to draw. The DB core provides the Visual**** classes as a basic framework of elements that can be drawn. The BuilderModes plugin overrides these classes and their methods to provide the behavior and create the actual geometry.

Kaiser said:
Also, I don't know much about memory management in C# and the Dispose method, so I may have introduced some memory leaks with the new code I added.

Generally the rule of thumb is; When a class has a Dispose method, you MUST call it when you're done with the object. This is because .NET can manage the memory of the .NET code, but when you use unsafe or other non-.NET code you could be doing things that require explicit clean up and you can't trust the timing of the destructor, because it's called when the garbage collector cleans up your class from memory. As you may have noticed, a lot of my classes also have a Dispose method, because I don't like relying on the garbage collector.

02-03-10 21:05 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

RDMonkey
Green Marine

Posts: 38
Registered: 06-09

Hey i had an idea for an update on Builder 64.

What if instead u insert like a button or action to things and linedefs called "Assign Macro". Example, you type in "256" and hit assign macro to make that line or thind do what the specified line macro does. Just an idea. Im making a map and i just cant get this Macro stuff down.

Last edited by RDMonkey on 02-19-10 at 20:14

02-14-10 23:43 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Gez
Why don't I have a custom title by now?!

Posts: 6458
Registered: 07-07

Sorry for the bump, though I figure this thread is just slow rather than really dead.

Kaiser said:
I am also working on a WIP technical document on Doom64, which can be read here: http://dl.getdropbox.com/u/18609/D64_EditingSpecs.txt

About specs. I was looking at this old thread and all the rr.com links there are dead; and archive.org only archives D64lumplist.txt. Now the info in the post itself is mostly sufficient anyway, and the Jaguar Doom source code as well as D64EX can serve as reference, so it's not too bad if most of these things have disappeared from the Internet. But it would be nice if the LIGHTS lump chart and the various tools were uploaded somewhere again.

02-23-10 10:52 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

All times are GMT. The time now is 20:54.

Doomworld Forums > Classic Doom > Doom Editing > Doom64EX Editing Support - Need volunteers

Show Printable Version |

Email this Page |

Subscribe to this Thread

Forum Rules:

You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

HTML code is OFF
vB code is ON
Smilies are OFF
[IMG] code is ON

< Contact Us - Doomworld >