Maes Posted September 19, 2012 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_ ? 0 Share this post Link to post
_bruce_ Posted September 23, 2012 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 0 Share this post Link to post
Archy Posted March 15, 2013 _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? 0 Share this post Link to post
Marnetmar Posted July 22, 2013 Sorry for the bump, but has any progress been made on this? The link in the OP is also dead. 0 Share this post Link to post
Hekksy Posted July 27, 2013 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 :) 0 Share this post Link to post
Memfis Posted July 27, 2013 You're cheating, NUTS uses a new palette that makes things look more pale. :) 0 Share this post Link to post
Hekksy Posted July 27, 2013 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/?set=oa.10151156938562007&type=1 0 Share this post Link to post
Marnetmar Posted July 31, 2013 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 0 Share this post Link to post
Urban Space Cowboy Posted July 31, 2013 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) 0 Share this post Link to post
_bruce_ Posted August 13, 2013 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. 0 Share this post Link to post
NightFright Posted October 10, 2013 Mirror for both engine and source/dev kit. Rapidshare mirror *EDIT Oct 19, 2013* Link updated. 0 Share this post Link to post
Urban Space Cowboy Posted October 14, 2013 NightFright said:I created a mirror for those who do not want to install TinyDMYou 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.source.msvc2005-08.13.2013.7zNot found. Anyone have a mirror they could upload, please? 0 Share this post Link to post
NightFright Posted October 19, 2013 My link above has been updated. _bruce_ has also reuploaded all files in the meantime, so enjoy. ^^ 0 Share this post Link to post
Evolution Posted October 26, 2014 Hey _bruce_, are you still working on this project? 0 Share this post Link to post
Maes Posted October 28, 2014 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). 0 Share this post Link to post
_bruce_ Posted October 29, 2014 @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? 0 Share this post Link to post
kb1 Posted October 31, 2014 @ _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! 0 Share this post Link to post
Da Werecat Posted October 31, 2014 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? 0 Share this post Link to post
Gez Posted October 31, 2014 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. 0 Share this post Link to post
Linguica Posted October 31, 2014 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. 0 Share this post Link to post
Gez Posted October 31, 2014 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). 0 Share this post Link to post
kb1 Posted October 31, 2014 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_! 0 Share this post Link to post
_bruce_ Posted November 4, 2014 @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. 0 Share this post Link to post
Kaiser Posted November 4, 2014 This is really awesome. I can't wait to see more progression on this :) 0 Share this post Link to post
Gez Posted November 4, 2014 _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) 0 Share this post Link to post
Da Werecat Posted November 4, 2014 _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. 0 Share this post Link to post
Kaiser Posted November 4, 2014 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. 0 Share this post Link to post
Breezeep Posted November 5, 2014 anyone have a working link for this engine. it looks neat and I'd like to try it out. 0 Share this post Link to post
kb1 Posted November 5, 2014 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! :) 0 Share this post Link to post