Doom level...

[Sir Seizhak]

It looks pretty good. Keep on working man .

[Bruce777999]

Been a long time. This whole thing is a pain in the ass, but somehow I will push through. As I was browsing through the maps it hit me that I lost one... maybe I overwrote it by accident.
Well, don't hold your breath as I'm currently totally not into anything game related.

Map19






Map23






Map25

[Bruce777999]

Found my lost map... now at 32 + 2 DM maps.





Tried a more fancy method of lighting... but what seemed good in the editor and preview seems to have no payoff in the actual game - due to palette/color restrictions.





I'm out.

[Drakan]

Bummer. Doom has it's limits these days. Have you thought of maybe using a tailored engine?m If you already have, my bad.

[Blood of Nightmares]

Bummer. Doom has it's limits these days. Have you thought of maybe using a tailored engine?m If you already have, my bad.

Well the Eternity Engine supports Room above another Room and also the closest that ZDoom has is GZDoom's 3D Floors.

[Krypto]

What map editing format did you utilise when commencing this project? Vanilla is certain to run into limitations in size and detail, Boom would offer a greater capacity for more elaborate and rare features, but oweing to it's retention with classic Doom it lacks the ability to utilise mirrors, slopes and other gameplay altering mechanics as is Zdoom's definitive highlight. It seems perculiar to come into conflict with a colour palette restriction, and consider the engine format may be at alone at fault, perhaps a number of colluding factors are the source of this mystery.

[Bruce777999]

Folks of Postmortem - thx for your input!

The palette restriction won't go away in a sourceport unless it internally calculates the "lighting" in true 16/32 bit color. This is also a fact that really pissed me off in Blood - due to it's pretty nifty lighting of each surface a very delicate mood could be set enabling cool effects. But the palette plague prevented this to a large degree - most scenery blurred into a gray mess. I hope that the XLEngine will put a halt to this and enable Blood to shine like it should.
Seems that both Doom and Blood need a minimum difference of 16 between shades and feature 16 levels... 256 something... VGA something.


Regarding source ports...
Chocolate Doom
...many hot kisses.

JDoom
...may be the only sourceport for Doom that has "real" 32 bit color resolution.
...features now some cute object based lighting interacting with sectors additional to the one defined by the mapper.
...odd player movement - not Doom
...no diminishing light window

DelphiDoom
...touts 32 bit rendering though I'm missing the diminishing light window... looks flat and washed out.

PRBoom+
...cool port - Doom on steroids.

The rest
...seems feature hogged and overblown + strange player movement
...though very interesting for TC's(like ZBlood)


Worked a little bit on Map10/11 and 12.
Here's a random shot of ...

Map10



Map12

[Umnir]

Fantastic as always

[Drakan]

Seconded.

[Krypto]

May I request a progress update, if you haven't abandoned this project elusive Bruce?

[Fuzzyfireball]

Looking great.

I'm always mapping for DOOM, we should chat sometime.

[Bruce777999]

Hi brothers of Blood - the whole thing is still going.

Modifying ChocolateDoom to work in true color took me a while - works, but there's a lot to do to make it worthwhile... doing the color blending via MMX, editor support for colored sectors, teleporting keys, and many odds and ends... I'm somewhat of a slug when it comes to analytical things... we'll see.
So far - red is red, blue is blue... no more greying out or color bleeding.
I couldn't stand to see the awesome artwork being further abused by a 256 color palette.

Light values are now per wall, floor, ceiling - like in Blood.
Color values are per upper wall, middle wall, lower wall, floor and ceiling.

Needs editor support -> aim is Doombuilder1. Don't like part 2 - C# sucks.

Ok, here's E1M1 - smooth


Map23



Map23



Map28



Map28


Next one is colored - fully. I tried blending colors in HSV space... to no avail. Let's keep it nice and say it looks strange.


Then it dawned on me... I needed to render a normal image(RGB) and a fully colored one(HSV), later converted to RGB, which would be blended together as a final pass. Slower but that was the look that I had in mind.


I checked to see how DoomPSX and Doom64 looked colorwise and I was rather disappointed... pretty blotchy...
So much for the memories.

Blood related: I also want to finish this badly, but I ran out of sectors... some years ago.




Input is always welcome!

Take care

[Krypto]

What a wonderful treat to return home to after my Art class

This talk of modifying the colour palette intrigues me, did you create a seperate palette in the form of a (Dehacked .deh) file to be loaded seperately with your mod, or is it integrated within an edited Chocolate Doom executable? I've only come across other wad authors using the former method, as your modifications to the manner in which light and colour values affect each seperate flat/texture is very interesting. The RGB experiment looks rather evocative, although I agree with your sentiment as the shade of magenta appears too vivid, nonetheless working with colours proves to manifest intriguing diversities of light.

Your Blood map looks like a mix of E2M3 - No Rest For the Wicked and a BloodBath map which has a similiar architectural layout, it's appears authentic and nostalgic in it's current state, good work

[Bruce777999]

Krypto, thought I put an answer here looong ago.

No hacking, just an update to the source code which is still going another taste variant of the original Vanilla so to speak - all hail Fraggle(ChocoBoss) who laid this wonderful groundwork.
Every pixel can now be manipulated by RGB component -> blending/inverting/whatever...
In colored mode you have an additional buffer in HSV format which is later converted to RGB and blended with the original buffer to enable a blend of colorization and original artwork hue.

So much to do... plus I'm back at working on my megawad.



-blending via SSE is now faster -> roughly 1.5 times(800 vs. 1200 kilocycles) when working on 2 320x200 screens in 32bit color.
-tried the upscaling via SSE 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
-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.

[Bruce777999]

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