Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
_bruce_

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

Recommended Posts

kb1 said:

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.


I will attempt an explanation first...the benefits of HSV are that it's easier to produce luminosity, hue and color saturation effects by changing only one component instead of 3.

On the other hand, it's harder to do certain effects like color mixing and transparency in HSV (it's easier in RGB). Every color space is good at some tasks and poor at others.

I'm not sure if the sprites & textures are all in HSV mode, however the final rendering to the user's screen must be in RGB as this is what video cards undertand, so in the end any processing advantages in HSV space are nullified. Also, for certain effects, there are HSV -> RGB -> HSV conversions going on. Correct so far, _bruce_ ?

Share this post


Link to post
kb1 said:

_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.


Thx.
Well, basically I had to use HSV for reasons Maes summed up nicely. I have to chuckle on how naive I was when trying to "colorize" the stuff on screen.
I remember, shortly after having mode 3 running in HSV, sadly realizing that it was
1. too slow
2. the colorization was perfect BUT the original colors got lost so something that got blue-ified was then blue to the core.

-So to get rid of slowdown I'm converting all artwork to HSV on startup(doesn't even take long on a Celeron366) and keeping it in memory - so we have the 8bit palettized stuff hollering to the neighboring memblocks were the HSV high flyers are residing.
Additionally I tweaked the conversion from HSV to RGB as much as I could via fixed point and look up tables for divisions.

-To remedy the color issue I just blend a colorized version with an original one - which yields the highest quality output.
The only visual thing I have to re/add is transparent 2sided linedefs. They're disabled because of speed - this one needs a different approach.

-Momentarily I'm working on the mini editor so that one can add color info via a visual interface and that's a tough cookie with my caveman math senses, though I'll get it done so that all this stuff has a little bit of real world value.


Take care and inhale the Hue

Share this post


Link to post
_bruce_ said:

[Limits]
All render limits have been increased partially due to increase of visplane usage in extended mode.

What limits exactly and to what have they been increased to? Obviously visplanes have been increased but how about, drawsegs, vissprites, ect?

Share this post


Link to post
Marnetmar said:

Sorry for the bump, but has any progress been made on this? The link in the OP is also dead.


[ Links updated ]

Marnetmar - thanks for reminding me... these things tend to rot.
Usc - thanks for providing a link

This has been on halt for quite a long time but will be finished... though it could take quite some time.
I've yet to finish the 15bpp/555 version and then re approach my take on this whole thing in a slightly more efficient way.


Concerning the source...
-VS2005 + YASM required(MASM purged since YASM supports higher SIMD versions)
-the open GL scaler works but is severly outdated and unnecessarily complicated/the version I did for Choco+ is way more elegant
-determining compilation of sw/gl .exe is dependent on 'config.h/#undef GL_BACKEND'... this has also been resolved in Choco+
-transparency is disabled by default due to slowdown in colored mode
-close but no cigar

-reupload tomorrow on another host/THX for reminding me

-trying the HSL instead of the HSV color model... I'm fighting a little bit with accuracy I think +4 error per color per RGB->HSL->RGB conversion is still negligible as long as the result is worth it. The HSL color model kinda supports "overbrighting" which I'm trying to use for enhancing the color range. Though you can't go too far or your colors wash out since full "lightness" means all white - imagine a fog type situation. Currently there's a slight grey'd out effect going on which I'll have to look into. On the "brighter" side the range from dark to light is even more dynamic than before.







Share this post


Link to post
VGA said:

Does this get rid of color banding?


Yup. All truecolor Doom projects do that, whether OpenGL or software-based. Banding ceases being noticeable if at least 64 light levels (rather than 32) are used, which in turn makes sense to have only with an effective bit depth of 18 bits or more (HiColor modes are possible, but still exhibit banding).

Share this post


Link to post

@Evolution
YES. But do not expect anything before summer 2015. This whole thing needs to be converted from a hack to something more robust and structured - also Fraggle's Choco 2.1.0 base seems to be promising. There should be a good bunch of features which serve the niche this port is targeting.

@VGA:
Minimal banding will always be there.







@Maes:
Have you got my pm?

Share this post


Link to post

@ _bruce_: You got us jonesin! (How TF do you spell it?) Are you going to set it up with something like special linedef types and control sectors? I know it makes it a bit tedious to edit, but that's what Boom, and then everyone else did, for editor compatibility.

Anyway, my REAL question is: If you are going to use special linedefs:

1. Can you choose numbers that no one else uses? The 290 thru 350 range means different things to different ports, which sucks for compatibility :)

2. Can you post what your linedef numbers will be, before Summer 2015? (Maybe you need to write the code, first though, huh? :)

I would like to try my hand at adding true-color to my port, and I would love to make it linedef-type, and visually compatible with your code. It's a BIG feature, a NEW feature (sort of), and you are kinda the pioneer, which means that you have a unique chance to choose the standard that other ports will follow (if they are smart, and care about level/feature compatibility, that is.) Maybe somthing as simple as reserving a range of linedef types for your future use.

As a suggestion, maybe check out Legacy editing docs. One feature lets you set sector color by entering an 8-digit hex value into a sidedef name - something like AARRGGBB, for alpha, red, green, blue. Just an idea...

By the way, your demo is awesome! Good job!

Share this post


Link to post

I'm glad you're still working on this thing.

Do you still use that color blending system where the original images are being mixed with fully colored ones?

Share this post


Link to post
kb1 said:

1. Can you choose numbers that no one else uses? The 290 thru 350 range means different things to different ports, which sucks for compatibility :)

We really need a page that centralizes line types. EDGE uses the 400, 500, and 800 ranges.

Share this post


Link to post

I'm not saying to do that as a project for standardization (it's kinda too late anyway) but as a project for documentation.

It's pretty hard to find documentation on line types for, say, Legacy, what with the Legacy wiki being dead (and judging from the XML dump from 2012, it wasn't very thorough anyway).

Share this post


Link to post
Linguica said:

Wasn't there a project at one point to do exactly this?

fake edit: right I should always check http://www.doomworld.com/10years/ports/ports01_2.php about these sorts of things. The Joint Doom Standards group it was called.

"Fake edit" <- I got a kick out of that :) Yep, I do 'em too (but don't admit it :)

Gez said:

I'm not saying to do that as a project for standardization (it's kinda too late anyway) but as a project for documentation.

It's pretty hard to find documentation on line types for, say, Legacy, what with the Legacy wiki being dead (and judging from the XML dump from 2012, it wasn't very thorough anyway).

It's late, but could still be used for standardization, with the caveat that some linedef types suck, and need to be distinguished. I imagine that a clever algorithm could be used to glean something specific about a map, to determine which type it is, and, therefore, what these "multi-linked" linedef types are.

The best thing would be a map identifier: "I am a map that conforms to 1.0 standards for linetypes". Of course, that's another old argument: Should we use a lump? MAPINFO, MAPDATA, GAMEINFO? Add text to the MAPxx lump, like Legacy did? I'd love to get some support for this sort of thing, in the popular map editors. Otherwise, we'd have to use an algorithm, which would probably not be adopted by all ports. But, I have to say it again: TrueColor could be the thing that entices map editor and source port devs to agree on a simple standardization spec. It's easy to support. ZDoom already remaps linedef types.

First, we need a definitive list of linedef types (and things, sector types, etc), and just see how big the problem is.

Of course, as with all of these attempts, there must be cooperation. Maybe, when true-color projects start appearing, other ports will want to support true-color, and will be able to agree, at least on the linedef types used. That could revitalize the argument.

Anyway, I've deviated from the original thread enough. Good luck _bruce_!

Share this post


Link to post

@kb1:
Thanks!
Though I have to admit that the changes I made are on the simpler side and the transition to more colors was an obvious step. Nonetheless the "old" palette based look will never be phased out as it adds to Doom's unique character.
The only interesting code that has been produced is the screen scaling/stretching code in SSE which is unfinished as of yet.

The linedef actions are a bit of a plague... only bothered with them when editing thus far.
If the 351 to 399 region is free then that would be a start - otherwise start at 900.
2 bytes leave a lot of headroom.

My new line actions would be very few - actually a
"xxx - change sector color properties to color properties x at speed y"
In hsv/hsl format -> combines change of hue/saturation/light in an intuitive way when the user interface dissects it in an appropriate way.
"xxx - change sector color prop. to that of sector y"

Another one, if not already done...
Change 2s linedef transparency to x at speed y.
Change sector height by +/- x at speed y.

A color lump per map would be nice, maybe add an 11th entry to every map entry for new maps -> COLOR after BLOCKMAP.
And/Or go the addendum routine, when adding color to old i/wads, of having a "COL_START, COL_END" section where "MAPXX_C/EXMX_C" lumps reside which carry all the extra data for color.

As of now I use a simple text file(identified per folder/file name) which I will keep as an additional easy access option to hack in some values.

@Da Werecat - yes. Although the blend factor will be determined in the options menu... so you can go for a full soak or a more tasteful mix.

There are nifty little things I will hopefully be able to implement to solidify the niche aspect of my port.

Let's see.

Share this post


Link to post
_bruce_ said:

The linedef actions are a bit of a plague... only bothered with them when editing thus far.
If the 351 to 399 region is free then that would be a start - otherwise start at 900.
2 bytes leave a lot of headroom.

That region isn't free. I've built this table. The 600-799 range is free, though sandwiched between EDGE types. 900+ range is free.

While doing this, I've discovered that Doom Legacy uses 272 for a FraggleScript starter (inherited from SMMU) and for a sky transfer (inherited from MBF). Both effects are there simultaneously.

_bruce_ said:

A color lump per map would be nice, maybe add an 11th entry to every map entry for new maps -> COLOR after BLOCKMAP.
And/Or go the addendum routine, when adding color to old i/wads, of having a "COL_START, COL_END" section where "MAPXX_C/EXMX_C" lumps reside which carry all the extra data for color.


I'd recommend using a MAPCOLOR lump grouped with the map lumps, personally. (Also, "COL_START" is nine characters. :p)

Share this post


Link to post
_bruce_ said:

@Da Werecat - yes. Although the blend factor will be determined in the options menu... so you can go for a full soak or a more tasteful mix.

I see.

I've tried to map for your test exe, and I think that this approach has its limitations. Mainly, the art assets themselves are losing their colors, and at the same time you can't have very saturated colored lights. Changing the blend factor globally would fix one problem at the expence of making the other worse.

Personally, I would make the saturation value affect the blend factor for a given colored light instead of color's saturation. Or add another field for that. It would make the system more versatile and intuitive. Smooth gradients between colored and non-colored surfaces would be possible.

But I have no idea how hard it would be to actually implement.

Share this post


Link to post
Gez said:

I'd recommend using a MAPCOLOR lump grouped with the map lumps, personally. (Also, "COL_START" is nine characters. :p)


Could also borrow Doom64's idea of a 'LIGHTS' lump which consists only of RGBA values plus a 2-byte value for tags.

Share this post


Link to post
Gez said:

That region isn't free. I've built this table. The 600-799 range is free, though sandwiched between EDGE types. 900+ range is free.

While doing this, I've discovered that Doom Legacy uses 272 for a FraggleScript starter (inherited from SMMU) and for a sky transfer (inherited from MBF). Both effects are there simultaneously.

I'd recommend using a MAPCOLOR lump grouped with the map lumps, personally. (Also, "COL_START" is nine characters. :p)

Nice - a table! I was considering doing that. Good job! @272 issue: ugh. Yeah, I was concerned with compatibility across ports, not within them :)

_bruce_ said:

@kb1:
Thanks!
Though I have to admit that the changes I made are on the simpler side and the transition to more colors was an obvious step. Nonetheless the "old" palette based look will never be phased out as it adds to Doom's unique character.
The only interesting code that has been produced is the screen scaling/stretching code in SSE which is unfinished as of yet.

Oops. I really didn't intend to initiate a dialog of people telling you how to build your port...sorry about that. However, I'm not sure were we're meeting eye-to-eye, in reference to your comment. The transition to 32-bit color might be obvious, but don't short-change yourself on the importance of it, or, rather the impact. Your implementation is not specifically "the first", but I am believing that it is the most sought-after, if you know what I mean. That gives you a bit of "power", so to speak. The power to basically dictate how 32-bit color will be setup and configured, and used, in all other ports from now on.

I am asking you to use that power, to build it in a good, compatible, straight-forward way. And that suggests: Unique linedefs, and control sectors - the Boom way. Special map lumps, and the like, require special map editor support, which would be nice...but not as readily adopted.

At any rate, I put that out there, for you, but, again, I do not want to control your port either. But, please do recognize that there's a lot at stake. It's that important. Do it right, man! :)

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×