Doom in true colour [ testers for exe welcome/src snapshot/links updated ]

[entryway]

Intel(R) G33/G31 Express Chipset Family -> white screen.

[Gez]

YES! Chocolor Doom is cool.

[_bruce_]

entryway said:

Intel(R) G33/G31 Express Chipset Family -> white screen.

Link has been updated to archive containing both exes.

[Urban Space Cowboy]

_bruce_ said:

Link/Info on page one.

Took you long enough. Now where's the source code?

[LexiMax]

Urban Space Cowboy said:

Took you long enough. Now where's the source code?

Actually that's a good point.

Bruce, does anyone have a backup copy of your source tree, just in case you get hit by a bus or something?

[chungy]

More than that; the license for Chocolate Doom requires distribution of the source code. Technically nothing has been violated unless the source is refused after the request, but it's usually easiest to just provide it in the first place. Also the "where's the source code?" question certainly could have been less rude; just saying :)

Additionally, I don't use Windows so it'd be nice to be able to compile it myself =p

[Ralphis]

How do I go about enabling the smooth distance fade and crazy seizure colors? I tried IDLSD and it gives a comment like it is going to do something, but everything stays the same!

[Gez]

Ralphis said:

How do I go about enabling the smooth distance fade

Hit keypad + a few times to cycle through the different fading modes.

Rename the _map files to map files if you want to actually see colors.

Ralphis said:

and crazy seizure colors? I tried IDLSD and it gives a comment like it is going to do something, but everything stays the same!

idlsd is not implemented yet.

[bradharding]

Great work _bruce_! This makes DOOM look incredible, but still retaining enough "retroness".

But I'd also like to see the source code as well. Being that it was derived off of source released under the GPL, now that a binary has been let loose (even if it is only a "test"), the GPL requires the source code be made available as well.

[AkiraZXE]

Oh hey, cool to see this finally get a public release. Had no idea it was ready for a public test. Either way, haven't really played Doom in a month or two, now seems as good a time as any.

[bradharding]

Hi _bruce_. It's been several days since people have begun requesting for you to release the source code and you have yet to respond. You have since posted several times under other threads, so it would appear that you are ignoring these requests. I understand that you may not want to provide the source for something you've obviously worked so hard on, but this is the nature of open source, and you'd be doing a disservice to the DOOM community by not doing so. Please respond to this post.

[_bruce_]

Hi there,


I do understand the concerns regarding the source and I take them very seriously.
Initial date for the snapshot would have been 09/03/2012 but unfortunately my father passed away on this very day.
Due to this tragic event I had to step back from the stuff and couldn't tackle putting together this labor of love to present it in a somewhat edible form.

I'll upload the work in progress source tomorrow (09/11/2012) and hereby dedicate it to my father for once and all eternity.


Till then, take care.

[bradharding]

My sincere condolences, _bruce_. Obviously family comes first, and I'm sorry having pressured you. Take care of yourself.

[_bruce_]

Source snapshot released - have fun*

doomengine2012, thanks I really appreciate it.


*add editor support ^^

[Gez]

Condoleances, and thanks for sharing the source.

-DoomNX is not the official name of this project, to my surprise I learned that the Doom port for the Dreamcast bears this name... so please ignore it for now

"Chocolour Doom" is too perfect to pass.

_bruce_ said:

*add editor support ^^

What precisely is needed for editor support? Are there clear specifications for how color data is stored in a level? You mentioned that the *.lit files in the test distribution were an outdated method...

[_bruce_]

"E]Gez said:
Condoleances, and thanks for sharing the source.


"Chocolour Doom" is too perfect to pass.



What precisely is needed for editor support? Are there clear specifications for how color data is stored in a level? You mentioned that the *.lit files in the test distribution were an outdated method... [/quote]-Thanks for your support Gez!

-Yes, chocolo(u)r is so sticky that it hurts and seems heir apparent. ^^

-Well, a 'sector_t' carries additional fields now...
For light info...<skip this if not really interested!>
One 4 byte word where every byte represents a light value ranging from 0-255.
bit 24-31 : byte 3 - sprite/mobj
bit 16-23 : byte 2 - wall(upper/middle/lower)
bit 08-15 : byte 1 - ceiling
bit 00-07 : byte 0 - floor(same as original
'short lightlevel' found in 'sector_t')

For color info...
Six 4 byte words representing the HSV value
-> each word H(0-1535)/S(0-255)/V(0-255)
word 0 : floor
word 1 : ceiling
word 2 : wall upper
word 3 : wall middle
word 4 : wall lower
word 5 : sprite/mobj


-I chose a to unify the wall light values to stay within an integer.

-since this is a thing of change(the Value part of the hsv word should carry the lightlevel actually) I would keep the additional info in a text file generated by the editor and stored where your doom directory resides under 'wad/<iwad>/levelname.lit' -> for example '.../wad/doom2.wad/map01.lit'

-later when the definite format is agreed on one can store it at the end of a wad where its resides between 'NX_START/NX_END' along with other extra info

-basically a plugin that 'plugs' into Doombuilder2 and enables individual color/light picking in 2D/3D and writes a text file to the base/wad/<iwad>/... directory according to the map you're working on. After that's been implemented it's an easy ride and can be updated till nausea.

-a line in a -lit file is as simple as possible... [token]

[sector number] - 0-9999
[floor] - [1-1535,0-255,0-256]
[ceiling] - see above
[wallupper] - see above
[wallmiddle] - see above
[walllower] - see above
[sprite/mobj] - see above

->hue being '0' means hue and saturation get ignored
->value being 256 means take original sector lightlevel and apply it to ceiling/wall(upper/middle/lower)/floor giving the original look.
-> each .lit file carries an accurate description/rules


Quite the wall of text.

[Gez]

I think it'd be easier to handle for both DB 2 and SLADE 3 if the info lump was directly following the level lumps (like SCRIPTS often does in the Hexen map format). They've been designed to manage maps as a collection of sequential lumps and having to write it in two different places would make it more complicated. Other engines would just ignore them anyway, so no harm is done.

[_bruce_]

Gez said:

I think it'd be easier to handle for both DB 2 and SLADE 3 if the info lump was directly following the level lumps (like SCRIPTS often does in the Hexen map format). They've been designed to manage maps as a collection of sequential lumps and having to write it in two different places. Other engines would just ignore them anyway, so no harm is done.

Took a look at a hexen wad and this sounds reasonable. The problem ain't where to put it, meaning the extra data ^^, but how to create the plugin for DB2.
Doombuilder2 is an elaborate beast of a program and I've found no specs besides the plugin source examples which are nice but this feels like another job of "reverse engineering".
If I wasn't such a lousy programmer I would write an editor myself, though DB2 is quite rightfully the standard and one has to deal with it.

[bradharding]

Thanks for sharing the source! Now, to use my limited programming experience to work out how all this works...

[Siggi]

It's awesome to see a release for this along with the source. :)

A couple of hours before your release I managed a similar 32bit conversion of a software renderer. It's not done in the same style as this, nor does it provide the same features, but your work was definitely an inspiration.

I shall be looking through your sources at some point. Keep up the good work.

Condolences for your loss.

[chungy]

Great work; I'm wondering what version (svn revision?) of Chocolate Doom your work is based off of?

[boris]

Writing such a plugin for DB2 would be pretty trivial. The tricky part is to keep the data over modifications of the geometry, and I don't think that's possible without changing the base source.

[Gez]

boris said:

Writing such a plugin for DB2 would be pretty trivial. The tricky part is to keep the data over modifications of the geometry, and I don't think that's possible without changing the base source.

How does DB2 internally handle UDMF props? Are UDMF sectors, linedefs, etc. represented by different structures than binary format sectors, linedefs, etc.? Because if not, then the best way is to represent the light data as UDMF properties tacked on, and have the plugin write them in the dedicated lump.

[DaniJ]

That would make the maps incompatible with Chocolourdoom - it doesn't support UDMF format maps.

[boris]

Checked it out, and apparently you can access the data structures that are supposed to contain UDFM custom fields with a plugin in any map format. That'd leave reading and writing. That's controlled through some classes, in the config files you'll see something like 'formatinterface = "DoomMapSetIO";'. But it looks like you can't inherit from those classes in a plugin.

[edit] If going for a .lit file approch the info could be saved in the .dbs file while editing and a "export" button could be supplied by the plugin that would write the .lit file.

[Gez]

DaniJ said:

That would make the maps incompatible with Chocolourdoom - it doesn't support UDMF format maps.

I'm talking about the internal representation in the editor, not the way it's written out when saving. For example, SLADE 3 uses UDMF-style internally, so that any arbitrary amount of new properties can be added to the basic elements without having to update the data structures themselves.

DB2 supports UDMF, which means it supports having potentially hundreds of custom properties added to any vertex, linedef, sidedef, sector, or thing; and can keep track of them so as not to be confused after elements are deleted or inserted.

[_bruce_]

@Chungy
it's based on Choco 1.6.0. There's been an update to 1.7.0 from what I've seen and the most notable change, for me, was the change from RGB888 palette granularity to the VGA's original RGB666 one.
Since this source ain't properly forked off, it's a little bit of the hassle to keep up to date though. At the time I started this chocolor baby I had no idea how to properly keep a source base and always wondered about these strange svn, git, etc. people.

@Siggi
thx and pm me if there's anything unclear in the source.

The idea with the .dbs file is a very nice one. Never payed attention to these when editing.
The IOstuff seems to be the make/break point since Builder64 changed this and it now only supports D64 stuff which seemed kinda baffling because I thought the very idea of these complicated interface/class stuff is to be able to transparently create your own slice of the pie without problems.

I totally overlooked that Gez is the author of Slade(props to you), and there will be map editing functionality - well Goodbye DB2, C ass and .lag ^^

In the meantime I'll be "developing" my own little editing tool(C + Allegro5) which has always been a dream of mine. It's a quasi crutch till the baby format is final and I'll burden Slade with it.

Take care

Baby stage... looks funky.

[Gez]

The author is Simon Judd (SlayeR on this forum); I'm just a code contributor. :)

[Dragonsbrethren]

It just hit me the other night how cool it's going to be making vanilla-compatible maps that can be loaded into this and played with colored lighting (not to mention the true color graphics and smooth shading). I've always wanted to make PSX-inspired maps, but the idea of limiting people to GZDoom for playing very vanilla-like maps has never sat well with me. This port looks like it'll be a great solution once it's released.

[kb1]

_bruce_ said:
For color info...
Six 4 byte words representing the HSV value
-> each word H(0-1535)/S(0-255)/V(0-255)

_bruce_, I'm sorry to hear about your dad, man - that's a shame.
I had a question for you: Why did you choose HSV instead of, say, RGB? I'm not critisizing, it seems to work really well, and it looks great! I'm just not familiar enough with HSV to understand it's benefits over RGB, which, would seem to me to be easier to code (but I have no idea what it would look like.) Can you explain the difference in terms of drawbacks/benefits? Thanks.