
Doom level...
- Sir Seizhak
- Pink on the Inside
- Posts: 348
- Joined: Nov 14th, 2006, 22:33
- Location: Castilla La-Mancha. Spain.
- Contact:
Re: Doom level...
It looks pretty good. Keep on working man
.

Cabal's Return Add-On. Wait for it.
BloodHispano. The best Spanish Blood website!
BloodHispano. The best Spanish Blood website!
- Bruce777999
- Pink on the Inside
- Posts: 365
- Joined: Jan 21st, 2008, 17:10
- Bruce777999
- Pink on the Inside
- Posts: 365
- Joined: Jan 21st, 2008, 17:10
Re: Doom level...
Bummer. Doom has it's limits these days. Have you thought of maybe using a tailored engine?m If you already have, my bad.
Life is a privilege...Death is a promise...
- Blood of Nightmares
- Well Done
- Posts: 1675
- Joined: May 10th, 2005, 23:17
- Location: The Accurate Hall of Epiphany
Re: Doom level...
Well the Eternity Engine supports Room above another Room and also the closest that ZDoom has is GZDoom's 3D Floors.Drakan wrote:Bummer. Doom has it's limits these days. Have you thought of maybe using a tailored engine?m If you already have, my bad.
Re: Doom level...
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
- Pink on the Inside
- Posts: 365
- Joined: Jan 21st, 2008, 17:10
Re: Doom level...
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

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

Re: Doom level...
May I request a progress update, if you haven't abandoned this project elusive Bruce? 

-
- VIP
- Posts: 25
- Joined: May 2nd, 2011, 06:25
- Location: The Dirt Ball
Re: Doom level...
Looking great.
I'm always mapping for DOOM, we should chat sometime.
I'm always mapping for DOOM, we should chat sometime.
"People don't change that much. Some are born wolves, some are sheep. You might be wearing sheep's clothing but your fangs are showing through." - Rhinehart
- Bruce777999
- Pink on the Inside
- Posts: 365
- Joined: Jan 21st, 2008, 17:10
Re: Doom level...
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
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
Re: Doom level...
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

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
- Pink on the Inside
- Posts: 365
- Joined: Jan 21st, 2008, 17:10
Re: Doom level...
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.
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
- Pink on the Inside
- Posts: 365
- Joined: Jan 21st, 2008, 17:10
Re: Doom level...
-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.

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