Weird impy thing
Register | User Profile | Member List | F.A.Q | Privacy Policy | New Blog | Search Forums | Forums Home
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Classic Doom > Source Ports > Doom in true colour [ testers for exe welcome/src snapshot/links updated ]
Pages (7): « First ... « 3 4 5 [6] 7 »  
Author
All times are GMT. The time now is 08:46. Post New Thread    Post A Reply
Maes
I like big butts!


Posts: 12848
Registered: 07-06



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

Old Post 09-20-12 00:41 #
Maes is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit || Quote
_bruce_
Senior Member


Posts: 1330
Registered: 11-07



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

http://i.imgur.com/NzREl.png

Last edited by _bruce_ on 09-24-12 at 13:59

Old Post 09-24-12 00:56 #
_bruce_ is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit || Quote
Archy
Forum Regular


Posts: 672
Registered: 11-09



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

Old Post 03-16-13 00:47 #
Archy is offline Profile || Blog || PM || Search || Add Buddy IP || Edit || Quote
Marnetmar
Forum Staple


Posts: 2864
Registered: 09-10


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

Old Post 07-22-13 10:25 #
Marnetmar is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit || Quote
Vulture
Junior Member


Posts: 230
Registered: 01-07



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


You might be interested to know that Odamex has a truecolor renderer (that also uncaps the framerate) in development.

https://dl.dropboxusercontent.com/u/72213361/32vs8.png

It is not choco, but pretty close :)

Old Post 07-27-13 01:13 #
Vulture is offline Profile || Blog || PM || Search || Add Buddy IP || Edit || Quote
Memfis
Forum Spammer


Posts: 5888
Registered: 04-07


You're cheating, NUTS uses a new palette that makes things look more pale. :)

Old Post 07-27-13 03:16 #
Memfis is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit || Quote
Vulture
Junior Member


Posts: 230
Registered: 01-07



Memfis said:
You're cheating, NUTS uses a new palette that makes things look more pale. :)


Huh! I had no clue until you posted that and I opened it up in Slade to see for myself. Regardless, I think you get the point of the screenshot. But just in case you don't, have a few more: https://www.facebook.com/media/set/...38562007&type=1

Old Post 07-27-13 04:19 #
Vulture is offline Profile || Blog || PM || Search || Add Buddy IP || Edit || Quote
Marnetmar
Forum Staple


Posts: 2864
Registered: 09-10



Vulture said:


You might be interested to know that Odamex has a truecolor renderer (that also uncaps the framerate) in development.

https://dl.dropboxusercontent.com/u/72213361/32vs8.png

It is not choco, but pretty close :)



Awesome, but...

...Can you re-upload the exe pretty pretty please with cherries on top? :3

Old Post 07-31-13 07:50 #
Marnetmar is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit || Quote
Urban Space Cowboy
Junior Member


Posts: 180
Registered: 05-09



Marnetmar said:
...Can you re-upload the exe pretty pretty please with cherries on top?
Here's the source + binary package I saved: doomnx-20120912.tar.gz (5.45 MB)

Old Post 07-31-13 18:41 #
Urban Space Cowboy is offline Profile || Blog || PM || Search || Add Buddy IP || Edit || Quote
_bruce_
Senior Member


Posts: 1330
Registered: 11-07



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.

http://i.imgur.com/PXKtthL.png

http://i.imgur.com/0CTJyEm.png

http://i.imgur.com/hRWzMnr.png

http://i.imgur.com/gXo2xQq.png

Last edited by _bruce_ on 03-15-14 at 22:19

Old Post 08-13-13 15:09 #
_bruce_ is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit || Quote
NightFright
Junior Member


Posts: 235
Registered: 08-10


Mirror for both engine and source/dev kit.

Rapidshare mirror

*EDIT Oct 19, 2013*
Link updated.

Last edited by NightFright on 10-19-13 at 10:50

Old Post 10-10-13 15:30 #
NightFright is offline Profile || Blog || PM || Search || Add Buddy IP || Edit || Quote
Urban Space Cowboy
Junior Member


Posts: 180
Registered: 05-09



NightFright said:
I created a mirror for those who do not want to install TinyDM
You don't need to use that crap, just click the filename to the right of "Download:" at the top.

_bruce_ said:
[Source Link/Pass]
http://speedy.sh/C5Jrj/Doomtest.sou...5-08.13.2013.7z

Not found. Anyone have a mirror they could upload, please?

Last edited by Urban Space Cowboy on 10-14-13 at 21:05

Old Post 10-14-13 19:39 #
Urban Space Cowboy is offline Profile || Blog || PM || Search || Add Buddy IP || Edit || Quote
NightFright
Junior Member


Posts: 235
Registered: 08-10


My link above has been updated. _bruce_ has also reuploaded all files in the meantime, so enjoy. ^^

Old Post 10-19-13 10:50 #
NightFright is offline Profile || Blog || PM || Search || Add Buddy IP || Edit || Quote
Evolution
Junior Member


Posts: 233
Registered: 09-10


Hey _bruce_, are you still working on this project?

Old Post 10-26-14 10:30 #
Evolution is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit || Quote
VGA
Member


Posts: 310
Registered: 05-14


Does this get rid of color banding?

Old Post 10-27-14 03:08 #
VGA is offline Profile || Blog || PM || Search || Add Buddy IP || Edit || Quote
Maes
I like big butts!


Posts: 12848
Registered: 07-06



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

Old Post 10-28-14 14:21 #
Maes is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit || Quote
_bruce_
Senior Member


Posts: 1330
Registered: 11-07


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

http://i.imgur.com/TcglN6p.png

http://i.imgur.com/HZAsEQO.png



@Maes:
Have you got my pm?

Old Post 10-29-14 20:59 #
_bruce_ is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit || Quote
kb1
Member


Posts: 453
Registered: 11-06


@ _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!

Old Post 10-31-14 02:55 #
kb1 is offline Profile || Blog || PM || Search || Add Buddy IP || Edit || Quote
Da Werecat
Senior Member


Posts: 1478
Registered: 11-09


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?

Old Post 10-31-14 12:24 #
Da Werecat is offline Profile || Blog || PM || Search || Add Buddy IP || Edit || Quote
Gez
Why don't I have a custom title by now?!


Posts: 11544
Registered: 07-07



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.

Old Post 10-31-14 13:26 #
Gez is online now Profile || Blog || PM || Search || Add Buddy IP || Edit || Quote
Linguica


Posts: 4078
Registered: 05-00



Gez said:

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

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.

Old Post 10-31-14 18:01 #
Linguica is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit || Quote
Gez
Why don't I have a custom title by now?!


Posts: 11544
Registered: 07-07


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

Old Post 10-31-14 19:33 #
Gez is online now Profile || Blog || PM || Search || Add Buddy IP || Edit || Quote
kb1
Member


Posts: 453
Registered: 11-06



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

Old Post 10-31-14 22:05 #
kb1 is offline Profile || Blog || PM || Search || Add Buddy IP || Edit || Quote
_bruce_
Senior Member


Posts: 1330
Registered: 11-07


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

Old Post 11-04-14 21:38 #
_bruce_ is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit || Quote
Kaiser
Doom64 Guru


Posts: 2876
Registered: 08-00


This is really awesome. I can't wait to see more progression on this :)

Old Post 11-04-14 21:55 #
Kaiser is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit || Quote
Gez
Why don't I have a custom title by now?!


Posts: 11544
Registered: 07-07



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

Last edited by Gez on 11-04-14 at 22:11

Old Post 11-04-14 22:06 #
Gez is online now Profile || Blog || PM || Search || Add Buddy IP || Edit || Quote
Da Werecat
Senior Member


Posts: 1478
Registered: 11-09



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

Old Post 11-04-14 22:27 #
Da Werecat is offline Profile || Blog || PM || Search || Add Buddy IP || Edit || Quote
Kaiser
Doom64 Guru


Posts: 2876
Registered: 08-00



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.

Old Post 11-04-14 22:45 #
Kaiser is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit || Quote
Breezeep
Member


Posts: 397
Registered: 04-14


anyone have a working link for this engine. it looks neat and I'd like to try it out.

Old Post 11-05-14 02:08 #
Breezeep is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit || Quote
kb1
Member


Posts: 453
Registered: 11-06



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! :)

Old Post 11-05-14 04:44 #
kb1 is offline Profile || Blog || PM || Search || Add Buddy IP || Edit || Quote
All times are GMT. The time now is 08:46. Post New Thread    Post A Reply
Pages (7): « First ... « 3 4 5 [6] 7 »  
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Classic Doom > Source Ports > Doom in true colour [ testers for exe welcome/src snapshot/links updated ]

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 >

Powered by: vBulletin Version 2.2.5
Copyright ©2000, 2001, Jelsoft Enterprises Limited.