[Jan Satcitananda]

Mblackwell, on Oct 26 2009, 06:10 PM, said:

Rendering is processed on the GPU. Also splitting threads isn't exactly an easy task. Any time you split a task to another CPU you create room for more bugs to creep up due to an increase in code complexity (and race conditions but let's not go there).

I'm talking about software (8-bit) rendering. And thread managing isn't so difficult for an experienced programmer. I did some split-screen routines myself and they work fine.

[Jan Satcitananda]

I've discovered a real-time screen bending effect. Real powerful thing capable to beat shader processing because every screen line may have its own camera coordinates. The effect is very slow though: there are 199 showviews per frame! It's like playing Duke on a 486. Still I think it may be used in some short-term FX like teleporting. To increase performance, the thing may be undersampled to 100 or 50 bands.

This is how it looks:



And lol, I have slightly above 1 fps in the LPT's hall.

[Danukem]

CraigFatman, on Nov 2 2009, 07:41 PM, said:

there are 199 showviews per frame!

[Stabs]

good stuff, surely the bands could be brought down enough to have a nice subtle underwater effect

[zykov eddy]

Looks just great. Nice work Craig! Hope Eduke 32 programmers will include your work in next Eduke 32 release.

[Jimmy]

Interesting idea.

[KillerBudgie]

This TC might be worth looking at.

[Danukem]

DanM, on Nov 2 2009, 10:34 PM, said:

good stuff, surely the bands could be brought down enough to have a nice subtle underwater effect

I don't think that's practical. Even if there were only 20 different bands, that's rendering 20 scenes on every screen. I'll bet the framerate would be unplayably low for all but the fastest computers just to have the underwater effect.

Like he was saying, it could be useful in a special situation such as a teleporter effect. And even then, it should be done in a simple area of a map, because if it's a complex scene then the game will come to a stop.

[Sangman]

Either way my mind is blown by all of this, I find it odd how some of you react so calmly (except for DT of course, he's always a sober man)

[Jan Satcitananda]

Sangman, on Nov 4 2009, 02:06 AM, said:

Either way my mind is blown by all of this, I find it odd how some of you react so calmly (except for DT of course, he's always a sober man)

Sometimes this makes me feel damned...

[Plagman]

I don't know if it does beat shader processing, but it sure does comes out nicely. Too bad the implementation isn't really suited to interactive framerates. Anyway, such screen distortions is a post-processing effect that's on my Polymer to-do list, so you might see direct CON access for it someday.

[XThX2]

I've read the source code of doom, it has a nice screen melting algorithm that doesn't really kill framerate. (or it feels like it doesn't on my machine, I remember the first few seconds of the game being really slow on an old machine with DOS ) So I guess it's doable :/ (I've always wanted to have the screen blow up and then come back with some CON commands; could be really interesting... like you kill the boss and the screen blows into pieces then comes back to it's place after some time with a lightning bolt painting the whole screen to white!!!!)

By the way, don't feel damned I'm absolutely amazed with those It's great to see that CON is indeed capable of LOTS of things :cool: It's just a matter of how you think about things and how you do things.

[Sebastian]

Nice effect, Graigfatman!
Can this trick be used to simulate heat stemming from valves or fires?

[Jan Satcitananda]

XThX2, on Nov 4 2009, 09:59 PM, said:

I've read the source code of doom, it has a nice screen melting algorithm that doesn't really kill framerate. (or it feels like it doesn't on my machine, I remember the first few seconds of the game being really slow on an old machine with DOS :P ) So I guess it's doable :/ (I've always wanted to have the screen blow up and then come back with some CON commands; could be really interesting... like you kill the boss and the screen blows into pieces then comes back to it's place after some time with a lightning bolt painting the whole screen to white!!!!)

In the source code, it's easy to distort the screen in any way. Duke has a screen tilting feature when the scene is rendered to the intermediate buffer and then shown rotated. We can produce a fast bending effect as well.

Rusty Nails, on Nov 5 2009, 12:32 AM, said:

Can this trick be used to simulate heat stemming from valves or fires?

This is difficult, but not for me. :P Since I got WoW effectors showing certain parts of the screen separately, splitting it into several bands will make a slight tremble with appropriate framerate. I'll try to do it today.

[Jan Satcitananda]

I've made a simple heat haze box. So far it needs a bit of troubleshooting to make a proper look when you step onto the box, as well as to let Duke go through it. Here are up to 50 bands distorted randomly, the haze looks very realistic ingame and my framerate is high enough. However, this effect doesn't look that good on a static screenshot, so here I combined four frames into one to simulate persistence of vision.



I think, a nice wavy distortion may be applied to a view through a water surface. I can even try to simulate light refraction including the total internal reflection. This may be a way to immerse the player truly and properly. Now I need to revise my code to make a support for rendering without the auxiliary sector, like the common sector-over-sector effect. This will make possible translucent water shown by a multi-pass effector even when the camera is situated right above the water surface (so far such situations result in HoM).

[Ryan Cordell]

All I can say is dang you and your inventive, software abusing ways.
This looks all pretty dang sweet, considering we know which kind of renderer this is on. Keep it up, yo. \o/

[Jan Satcitananda]

Very funny, Ryan.

Btw, Software mode can render a sort of parallax mapping:





I had to write a generator program for creating a series of lit slices from a height map and a diffuse color map. Another tricky texturing techniques I'm going to mess around with include fake bump, volume lights and fresnel reflections (utilizing the HDR exposure trick).

[XThX2]

That looks like a wall made of voxels. Certainly interesting to look at!

[Headless_Horseman]

This whole mod seems simply amazing : I hope it will run on my old PC...
CraigFatman, what are your actual spec's ?

[Jan Satcitananda]

XThX2, on Nov 26 2009, 06:44 PM, said:

That looks like a wall made of voxels. Certainly interesting to look at!

Looks quite similar. Nevertheless, there are no voxels. I bent the wall in the second shot into a curve to show that various deformations may be applied to it which would be impossible with voxels. Also, clipping is a lot better.

One more sample:

Headless_Horseman, on Nov 26 2009, 06:57 PM, said:

This whole mod seems simply amazing : I hope it will run on my old PC...
CraigFatman, what are your actual spec's ?

Read post #26 I think nothing but having relatively fast CPU will be important for the mod.

[Jimmy]

This is some awesome shit.

[zykov eddy]

Looks great, Craig.

[Jan Satcitananda]

My TC is about to have its own GUI. It's intended for accessing a bunch of extra options, Duke's inventory and the built-in glossary. The widgets were drawn in a pixel art fashion.

[Geoffrey]

Hah - cool

[m210®]

That is great

[Simon_Croes]

Wow thats just insane dude =D

[Daedolon]

Assuming the checkboxes do something and the scrolling works -- that's some mighty fine coding there.

[Jan Satcitananda]

So far the GUI is incomplete, the controls show no interactivity. I'm going to use only six types of controls: windows, command buttons, checkboxes, option buttons, vertical scrollbars and shapes (decorative elements being shown either as labels, lines, frames or sprites). The most difficult thing here is coding a proper container hierarchy. In my implementation, any control can become a container for another ones.

[Danukem]

It's really great, but I wonder why you are putting so much effort into a menu system for a Duke 3D mod. I guess you must be planning to have a huge number of options.

[Jan Satcitananda]

I think it's necessary. I have already sketched what options I'll add. Here's an approximate list:

LNGA Exposure Setup
  AE Metering Spot
	( ) Very Narrow
	(*) Narrow
	( ) Broad
  AE Threshold
	( ) Low
	(*) High
  Exposure Compensation
	<-> -2, -1.5, -1, -0.5, 0, +0.5, +1, +1.5, +2 EV
  [x] Limit Sensitivity To Monitor Brightness:
	<-> ..., 256, 362, 512, ... cd/sq. m
LNGA Acoustics Setup
  Speaker Configuration
	( ) Loudspeakers
	(*) Headphones
  Echo Sampling Quality
	( ) Low (Troubleshooting)
	(*) High
  Master Gain
	( ) 0 dB
	(*) 20 dB
	( ) 40 dB
  Dynamic Range Compression
	(*) 0 dB (Realistic)
	( ) 20 dB
	( ) 40 dB
  [x] Allow Sample Duplicating
Visuals Setup
  [x] Animated Messages
  [x] Light Emitters Motion Blur
  [x] Actors Motion Blur
  [x] HUD Graphics Motion Blur
  Facing Sprites Style
	( ) Classic (For Non-LNGA Maps)
	( ) Camera Plane Aligned
	(*) True Facing (Recommended)
  Particle Effects
	( ) Low
	(*) Normal
	( ) Overkill
  Parallax Mapping Quality
	( ) Off
	( ) Low
	(*) High
  Mip Bias (Affects Some Actors)
	(*) 640 px
	( ) 800 px
	( ) 1024 px
  Dynamic Light Resampling Frequency
	( ) Low
	(*) Medium
	( ) High
  Indirect Lighting Quality
	( ) Low
	(*) High
	( ) Extra High
  HUD Acceleration Feedback
	( ) Off
	(*) On
  Stereopair Rendering (Experimental)
	(*) Monocular (Default)
	( ) Cross-eyed
	( ) Parallel
Reflections/Refractions
  Fresnel Falloff Sampling
	( ) Off
	( ) Low
	(*) High
  Volume Refractions
	( ) Low
	(*) High
  Water Reflections
	( ) Off
	( ) Refmap Only
	(*) Refmap + Reflection Pass
  Water Refractions
	( ) Off
	( ) Low
	(*) High
	( ) Extra High
  [ ] Enable Alternate-Frame Partial Reflections (Experimental)

I think I have a clue for getting these features to work.