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

I am not very familiar with Boom's approach, although on paper it does sound like a better/simpler system. I don't know which of the two is safer if loaded in a non-compliant port, though. Sure, if you press/activate such a "special" wall and an unknown special value is propagated in the game code, it's tough shit in both cases, but surely if you use a specially formed texture name that is NOT to be interpreted as a normal texture, that will surely break a non-compliant port if it's encountered on a visible wall (again, not certain about that).

Share this post


Link to post

Update:
floor, ceiling, wall, object color and lightlevel can now be set independently ... Blood/Doom64 for the win.
Certain things won't take color values - all keys and maybe armor1/2... Doomguy may get the impression he's drunk standing in front of a purple door with a silver key in baby blue armor.
Additional color schemes for netplay.

Colorspace:
the conversion to HSV is costly, but can be eliminated by converting all rgb data to hsv at level/startup -
I always go for the simplest solution... so only minimal look up voodoo.
Conversion to hsv is now freed from any division + fixed point and conversion back to rgb is fixed point + some multiplies.

Framerates for Doom2/timedemo 3: fps
ChocoOriginal.........................- 1000+
Doom** - 32bit/lookup raw........- 240+
Doom** - 32bit/lookup fine........- 238+
Doom** - 32bit/calc+color float...- 48+
Doom** - 32bit/calc+color int......- 70+
Doom** - 32bit/calc+color intlut.- 104+

Using fixed gives error of +/-2 after converting to and from so your red 240 might turn into red 238 after the color space travel in worst case - good trade off regarding a 216% speed increase.

Gez - thx for the tip. Most likely I'll make the light lump compatible with Doom64's format. As for editing - I downloaded the source of Doombuilder2 and 64, but the C# is kinda a turnoff... totally lost in a jungle of classes and resource eating.
But I have to bite the sour apple and shot Kaiser a pm on where to begin searching in this monster.

Maes - thx for the info on sector/color stuff!

Maes/Wagi - always enjoy your tech talk... although I don't understand most of it O(m(y)god+1)!
it's always inspiring.

Current Column function - I try to keep it minimal and clean. Putting function pointers and parameters in a list could be a nice addition if some one wants to blow up functionality... as of now it's bare bones.

do
{
t = p32[ dc_source[ (frac>>FRACBITS)&127 ] ];

/* colorize before darken */
t = Shade2Op[1]( t, dc_color );
t = Shade2Op[0]( t, dc_light );

t = Shade1Op[0](t);

/* NX - write final pixel */
*dest32 = t;

dest32 += SCREENWIDTH; /* added by NX */
frac += fracstep;

} while (count--);
}

Release - after editor support and hsv level startup conversion materialized(1 - 4000 weeks) it will be alpha'd with a modified E1M1 'demonstration'map.

Just a random shot with random colour - mode will maybe left in as 'IDLSD'


MiniUpdate:
as always skip to pic or get coffee

-render mode 3 runs now in HSV mode, except for HUD stuff, and is nearly identical in speed to 32 bit via lookup modes
-mode 3 also also uses 32bit versions(well padded 24 bit actually) of the original artwork - having true color custom textures is now a possibility
-since all gfx has to be loaded and converted at starttime there's a delay of about 2 - 3 sec. and the memory usage is up to 85 MByte
-fps(C2D 3.2Ghz)
--DoomChoco 640x480 sw_scaled ~ 750fps
--Doom** WhateverResolution OpenGLscaled Mode1/2 ~570fps
--Doom** --------------------------------Mode3Hsv ~470fps

a 500Mhz cpu + OpenGL card could be playable... maybe I'll come across one and be able to test this
-demo sync is gone... hope I can fix that!
-Editor support now more needed than ever... no return mail from Kaiser... so I'll surf the code of DB64 for clues to hook in
-minibug:the last pixel in textures that are only 8 high is pixel number 0 instead of 7 -> came across this on 2 occasions in the game and my anal eyes are torturing my every time I step on those damn stairs... everything else looks 1 to 1 like it should be... strange.
-wandered around in Blewtonia and brown has never looked so good... I'll play a few rounds in final.
-LOTS of things to get right before first alpha but I'm positive about this ordeal.
-bad textures in TNT cause a crash when in render mode 3 -> textures of 2 crates with the blood patch offsets into y nirvana.




Share this post


Link to post

I'd like to see an IDLSD variant that used smooth gradients between random floor and ceiling colors (like the gradients in Doom 64) in every sector.

Share this post


Link to post

The question here is about how easy such gradients would be to code in the software renderer.

Share this post


Link to post
Gez said:

The question here is about how easy such gradients would be to code in the software renderer.


Embarrassingly easy I'd say, seeing how the Doom renderer operates exactly on a pixel-by-pixel basis and at the column level, and it's thus easy to do something different with each pixel within a column, as long as one is willing to "take the hit", performance wise.

A linear gradient in particular is not only easy to do but also easy to encode: a sector with different colors for ceiling and floors could be treated specially, by applying a simple linear gradient between the two. Further effects like gradient periodicity/frequency or gradient offset could be made, which also would vary with time (e.g. a "barber pole" type white/red gradient with 5 periods per sector height).

That's where my proposed method of using dummy sectors also has another advantage: cDoom can have virtually infinite stacked Room Over Room effects, because all of the dummy sectors can reference the same actual playfield sector, and the extra properties (floors, ceilings) are simply stacked (though cDoom doesn't always do that cleanly).

Share this post


Link to post

Ok, upper, lower, middle walls also have their own color value now and I will expand this to light values - as of now a wall, no matter if upper/lower/middle depends on the same light value. This can be seen in the attached shot, where the upper part of the lit wall has correct color but incorrect light value.
This is, in reality, a few minutes change, but I always look at it from a level designers standpoint and try to verify it's use... "Do I need that? Ok, it looks nice, does it make a worth while addition to my sector battle? etc."

Colored mode is a 2 in one mode - it draws a colored version to a buffer and a normal one. Both are blended together in a final pass. I did this because I had trouble blending hue values and didn't want that blotched color look - like everything is soaked into color... nice but looks silly... unless you're an easter bunny.
So, if anyone knows how to blend hues fast - be my guest and help me improve upon my quite awkward solution.


Random - old approach, color soaking



Shot from a phase where I wanted to abuse OpenGL and it's alpha blending to fuse together my buffers - this would have been my color buffer.
fullbright gfx buffer + darkened buffer + color buffer -> blended via OpenGL into the final update. Skipped that approach because the surface to texture approach was awfully slow - especially for 3 surfaces per update.




This is the current look, colors full saturation, 48% color buffer to 52% original output - this color soaking percentage will be an options switch. Upper wall light will be fixed...

Share this post


Link to post

I'm hoping that number in the corner isn't the framerate!

Is the new renderer going to add any improvements besides colors? You could possibly fix tutti-frutti, fix the inaccurate flat-rendering code, or other things while you're at it.

Share this post


Link to post
Wagi said:

I'm hoping that number in the corner isn't the framerate!

Is the new renderer going to add any improvements besides colors? You could possibly fix tutti-frutti, fix the inaccurate flat-rendering code, or other things while you're at it.


Nope - vis plane counter.
Only color for now and somehow adding support for it in doombuilder/2 + wadbsp or zennode.
I'm back on my old training regime so time is sparse ... don't count on any thing besides getting this thing into appropriate functional state.
What 'other things' are you thinking about fixing?

Floor standard


Floor fixed


If I had known that it's changing a line of code and 2 variables I would have done it sooner. Jaguar Doom uses the more accurate version.

Share this post


Link to post
Wagi said:

Is the new renderer going to add any improvements besides colors? You could possibly fix tutti-frutti, fix the inaccurate flat-rendering code, or other things while you're at it.


Just a wild guess, but starting from Chocolate Doom as a base usually means having no intention to work towards Boom-like fixes or enhancements, which are already codified elsewhere. It would make more sense porting the renderer enhancements to prBoom or somesuch. That being said, an accurate flat rendering function can be added (using full 16.16 precision, rather than the half-assed 6.10 that vanilla Doom used). Chocolate Doom itself used the more accurate version in older releases, but it was ditched in the name of faithfulness (to the original fugly look, not to accuracy ;-)

Share this post


Link to post

Great to see another port with true color software renderer!

Maes said:

With traditional 256 fixed color renderers, sure, you can make a 256 * 256 translucency or other such table which maps pairs of colors to another color, but determining which one in particular in order to obtain a particular effect is not really trivial: Boom derivatives have a whole function dedicated to pre-computing this table (or pre-load it, since it's really time consuming), and it involves taking any two palette colors, converting them to RGB, mixing them in RGB, and then checking which one of the EXISTING palette colors better matches their mixture. And then again the table will only be 100% valid for only one palette (e.g. the green radsuit palette would need its own table, but this is often not done).

And you have to do this 65K times (or 65K/2, at least), with a running time of O(n^3) where n is the number of colors, and a space requirement of O(n^2).


Something similar I had implemented in DelphiDoom using 65K precaclulated tables (2 dimintioned - 256X256) to handle transparency in 8 bit software modes. Each table item at (x,y) position stores the palette index closest to the RGB blend value of x and y palette indexes. 8 different blending factors are present for 0 to 7 where 0 gives the x palette index and 7 gives the y palette index.

Maes said:

Stuff like Delphidoom or _bruce_'s port just do those operations in real-time in non-indexed color spaces. Once you deem the performance overhead as "acceptable", sure, you no longer have to use palettes or LUTs for everything (though a mixed mode is possible, e.g. apply colorization/transparency in "full processing mode" but still use LUTs for certain things)


In fact DelphiDoom precalculates as much as possible: Each wall's column prossesed in 32 bit color values. Each column is calculated either by the wad lumps or an external hi-res texture and the RGB color values are pre-prossesed to fit the current palette and current gamma correction (initially that was a problem with external hi-resolution textures).
Then the column is stored in a 16K table using hash indexing. When the column is needed with the same colorization parameters is already precalced and easily retrieved from the table with non time-consuming calculations. When another column that is needed by the renderer happens to have the same hash value with an occupied item of the 16K table it is caclulated again and occupy the same table item (overwrite it). This happens rarely (when playing the game there is a 98% "cache" hit and only about 2% recalc). After that precalc the only thing left was to apply a smooth colomap (not the ugly transactions of the original 8 bit renderer).
I came up to this solution because it was not possible to precalc all the columns of all textures with all the possible colorization parameters (possibly a few GB of RAM :( ).
A simmilar (but more simple) tecnique was used for the flats.

Share this post


Link to post

Well, now even Mocha Doom is in the "club" of extended color software-rendered ports: I was skeptical of whether to release v1.6 in its "plain" 8-bit form, but now that I started a HiColor branch of it (aimed at emulating id's HiColor mode that never made it past the Alphas, and using the COLORS15 and COLORS12 lumps, details here), coupled with all the other neat features I have been adding, that's a much more worthwhile enterprise.

So now there will be a whooping total of at least three ports with an "enhanced software renderer" to choose from, each with its own features and capabilities that help stimulate the source port community. It's no longer a pipe dream to play pure software mode with an enhanced/special experience that is closer to vanilla than any OpenGL mode could ever be.

Share this post


Link to post

Not wishing to detract from the work being done here, I just want to point out that you cannot categorically rule out hardware accelerated renderers (e.g., those using OpenGL) from being able to accurately emulate the vanilla software renderer. If one considers a renderer that forgoes using the hardware for depth projection purposes, instead compositing the view in much the same way as the software renderer, it can in fact be emulated precisely.

Furthermore, it is actually possible to replicate many of the effects of software renderer, while rendering the world in "real 3D" using a hardware accelerated renderer. However to date, the only port which has really attempted this has been the early ZDoomGL 2.0 alphas (which never went anywhere).

Share this post


Link to post
Maes said:

Well, now even Mocha Doom is in the "club" of extended color software-rendered ports


Speaking of that "club"...

Anybody feels like giving some pointers on what to change when updating the software renderer from 8-bit paletted to 24-bit direct color? Which functions need to be updated, which don't?

Share this post


Link to post

Mostly, it depends on the port, but for Chocolate Doom:

- Make sure that (SDL_Surface*) screen is a 32-bit image
- screens[4] should have it's type changed to SDL_Color or some other sort of 32-bit type.
- The lighting LUTs (like scalelight[] and zlight[]) should be replaced by functions that calculate the lighting.
- In addition, bit shifters like LIGHTSEGSHIFT should be reduced or removed to provide smooth lighting.
- The screen wipe code needs to be completely redone, at least from my experience. The code is such a mess and it completely depends on the size of a pixel being one byte.
- References where you're writing a palette entry to the screen (like in the automap code, the -devparm FPS counter, R_DrawSpan/R_DrawColumn/V_DrawPatch) need to actually draw the color that the palette entry points to.
- When it tries to memcpy/memset to the screen, you need to make sure that it's multiplying the size argument by four (or whatever your color size is), and that the types match up. The code that draws the border needs to be improvised, becausue you can't really memcpy a series of bytes directly to the screen anymore at that point.
- There's also some fudging to go in I_Scale.c, especially in the stretch/squash code.

Most of what you'll be changing will be in the R_* files, V_* files, and some other tidbits here and there like the Automap code.

Share this post


Link to post

In general, you need to change whatever assumes that the display is 8-bits wide. This includes colfuncs/spanfuncs, block copy/column drawing functions, memcpys from/to the screen, single-pixel indexed color writes (such as those in the Automap) etc.

All palette/gamma tricks are also off, and you have to work out alternatives.

In general, there are two approaches:

You can use the extra colors simply as COLORMAP extensions (like Mocha HiColor and the Doom Alpha probably does) or you can do full-pixel processing (like _bruce_'s port does). Both approaches have advantages and disadvantages.

In the first case you can leave most of the R_ code intact (except for the colfuncs/spanfuncs ofc), and use the colormaps as "extended palettes" that act as RGB LUTs. This is quite fast, and still gives an extended color depth. You can even use some palette-like tricks like e.g. modifying the colormaps on the fly in RGB space and recoup the lost palette/gamma effects relatively easily and even create new ones as if you did full RGB processing. In essence, it's like a "superindexed" mode where you can use some of the old palette tricks plus apply pixel-based post-processing, if you want. The drawback is that you're still treating image data as 8-bit indexed, and you're still limited by the depth of the colormaps (however they can be extended to 64, 128 and 256 if you use RGB888 modes).

With the second approach you throw all indexes and colormaps out of the window, so to speak (if I understood correctly. _bruce_?). This theeoretically gives you more flexibility (e.g. depending on the implementation graphics can be pre-converted to hsv truecolor and you could have really truecolor sprites) and you can do a lot of neat effects at the pixel level, but it has far more processing overhead.

Personally, I'd prefer a combination of both: use a "superindexed" approach for gameplay, and only use costly RGB/HSV processing for a few select effects (e.g. the spectre invisibility effect in Mocha HiColor is done via RGB processing because the old colormap trick is not applicable)

Share this post


Link to post

Sorry for the bump, but what's up with this? This is the only Doom thing I've ever looked forward to. I understand it's coming out with your megawad, but I haven't heard anything about that either. I don't even see a WADs n' Mods started by you.

Share this post


Link to post

You could always fuck around with my HiColor Mocha Doom branch, for now. It's fully functional, at least as much as the regular one. Not that I have updated much, either. I'm currently looking for a way to keep the logic of all three branches (normal, HiColor and a future TrueColor branch) unified, possibly within a single branch. But RL has other plans...I guess that's what is happening to _bruce_ too.

Share this post


Link to post

I really hope Eternity will have something like this! Considering its current development, a true-colour mode that isn't hardware is just right.

Share this post


Link to post

On the question, what to change to go to 24bit direct draw.
Just did this in DoomLegacy. It is not in the beta or alpha releases but is in the latest SVN system.

You have to finish all the draw routines in r_draw16.c and then make an r_draw24.c and an r_draw32.c. The fuzz draw was not finished in r_draw16.c so that has to be finished. You should also do 32bit draw, because most hardware is going to choose that as native (mine did). The 24 bit draw is slower.

Have to make a generic pixel draw and line draw that can draw in all bpp modes (8bitPAL, 16bpp, 24bpp, and 32bpp).

Have to fix the 16bpp, 24bpp, and 32bpp palettes.
The palette setup call has to be moved because it setup at the wrong time. It should be called after changing video modes.

Must setup a full set of draw routines. The original set for 16bpp does not cover all draw situations like the 8bpp does (the 16bpp draw was not finished, nor was its support).

Have to fix all secondary draws (non-play) to use the generic pixel draw as they are all 8bpp palette based. These are status bar draw, background draw, all v_video.c draw routines, title page and other picture draws, border draw, the fade and falling columns transition draws, and the auto map draw.

The fade draws can only work in 8bpp, and are unnecessarily complicated. Must totally replace with new routines.

Have to add a selection mechanism for the bpp. I have "-bpp n" "-truecolor" "-highcolor" and "-native".

The advantage is that the transparency based draws look much better, as they are done by fast RGB math.
Whenever possible it uses the approach of masking off some low order bits, shifting operands down, and then doing the add.
Anything except averaging of RGB pixel values did not work well.
Even the fog effects are done by picking a fog color and then averaging with it (50%, 50%) (75%,25%) or (87%, 13%).

Also consider that some memcpy (like border draw) assume that the video buffer wraps around from the right edge to the left edge (the copy both right border and left border in one operation). This is not true for some video (like on a Mac), as some video pads the video scan line out to a power of 2 to make the video hardware simpler.
Some cards were known to use the pad space for video card internal variables (so it is a do-not-touch area).
I fixed DoomLegacy to handle such padded buffers, but that is really complicated to describe. One thing it provides is separate variables, vid.width (draw width), vid.bitpp (bits per pixel), vid.bytepp (bytes per pixel) and vid.ybytes (increment to next y line), and a enum based draw mode variable to make bpp draw select statements fast.

Share this post


Link to post

On the extended palette discussion. I favor the idea of a 14 bit palette selection, where the normal palette colors are arranged into stripes of intensity. Then all intensity effects can be done by additions to the index, instead of using separate colormaps for each intensity level. The worst problem is having to check for intensity overflow, which might force the intensity addition to be a LUT (which might work well because the intensity range is so small). Shifts in color space (such as a Boom colormap) would use a small LUT to do the color shift, but then use the 14 bit table to do the light intensity. This could still use the max intensity of a arbitrary Boom colormap as the color shift LUT.
Transparency would either need to use the existing transparency LUT or RGB math.

Share this post


Link to post

People of Doom,

this port will be completed - at all cost.
I've been up to other things, including working on the mega wad, and have started to re/open the project yesterday.
I have to iron out a lot of things to make this a solid base from which someone can expand their vision of Doom.
Finally got around to properly implement the calculated light falloff stuff(planes/segs) to look good and run fast - thx to WAGI for the original idea.
To keep this thread lively I'll pop in some updates related to the megawad.

Take care





-tested an MMX implementation of the simple weighted blending( of 2 rgb dwords) and it was 8 times slower(~40000+ cycles vs 5200+ cycles) than the standard version on a Core2Duo.
Maybe on a slow machine, 500Mhz or less, the MMX stuff would be feasible?
Will try if memcpy is faster via MMX though I doubt it.
Testing the SSE2 routine to do the blending...
-all of this is of course WIntel only
-little changes here and there taking into account this should also compile on a "MacIntel"
-working on Map06 of the megawad.
-blending via SSE2 is now faster -> roughly 1.5 times(800 vs. 1200 kilocycles) when working on 2 320x200 screens in 32bit color.
-bug'gered Fraggle because of a bug that wasn't one
-maybe the upscaling in software can benefit...



-tried the upscaling via SSE2 and this is the first thing that is somewhat faster at 1280x800(originalx4) -> it gave +8% performance.
This seems rather tame but the higher the resolution - the bigger the difference. I have to test 1920x1200(originalx6), 2560x1600(originalx8) and improve the way memory is handled. Windows/Intel only.
-using SSE for moving mem is limited by the width of the cpu's bus(duh).
On PentiumM/Core 16bytes per cycle.
On Core2 32 bytes per cycle thus(200%) speed increase when using SSE to generally copy mem > 1Mbyte as e.g. in
movdq xmm0, [esi]
movdq xmm1, [esi+16]
movdq [edi], xmm0
movdq [edi+16], xmm1
...further unrolling is of no real benefit as 32 byte(mem 2 xmm registers can hold) per cycle is max.
-SDL seems to be the weak spot here... blitting the buffer to the screen is the real bottleneck. What a waste.
-settled for a blend of C and SSE in the enhanced routines. The SSE part will have to be moved into an external assembler file because code containing inline assembler won't compile on Win64.
-fixed aspect ratio in GL scale mode(finally!)
-made a version for blending the combined palette values that uses SSE -> 1390 % faster than the standard one.
This is important if one adds high res because blending the palette over a huge mem area needs lots of cycles.

-hit the 500+ fps on a 2.28 Ghz C2D
-"added" transparency for 2 sided middle patches/textures
-any additional functionality(which will be kept minimally) will be stored in a separate wad -> e.g. yourwad.wad has a yourwad.wad32 companion from which it reads the extra info -> light, color, transparency for sidedefs, extra RGB textures in bmp format. This way should keep compatibility witch choco to a max. For now only folders with ASCII files





-due to transparency, the rendering process in the color enabled render mode is kind of 'spread out' into a separate way of rendering segs/planes and masked segs and sprites and later combining them... a somewhat layered approach
-overall I'm glad that it works(~250+ fps) in 'timedemo 3' on a C2D 2.28Ghz.



-preliminary color config file support(later wad also) - associative per pwad/iwad per map name -> e.g. doom2/map01.xxx
-transparency is currently disabled because I have to come up with a more appropriate solution

Test shot of Map02(my fav)
raw


fine


fine color


-added a visual cue on how the zone mem changes during game play... funny to watch -> white/header, green/free, red/static, dark red/level, grey/cache, white underline/rover...

Share this post


Link to post

I'm dying to try this out, absolutely stunning work!

I'm, however, wondering if my venerable Prescott 670 3.8ghz will be up to the task? I'm talking fullspeed at 320x200, nothing really higher than that.

Share this post


Link to post

I don't like it. I like the "before" shots better.

I also don't like opengl. I prefer software(pixel) rendering. In a way, software(pixel) rendering is sharper and will always give me the true feeling of the original classic doom that I played when I was young.

I don't know why you guys keep changing stuff like this. You're taking away the vanilla feel of doom...

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
×