Engoo

[leileilol]

in colored lighting modes

However i've done the reverse, if anyone ever needed to to get that pre-1.00 or glquake look.

[qbism]

lookup table generation process..................................................................not unsetttling......rather soothing.......

The colored lighting has come a long way. It looks a lot like FTESW 24-bit lights. I used the saturated autogenerated lits from MH's lighting tool on start and e1m1 and the greens and reds are surprisingly smooth.

Framerate was jerky with dynamic lights (grinding through mips) at MAX_FPS 72 but smooth at MAX_FPS 24.

Video mode selections were good, 360x200 especially. Did MGL figure that out somehow with my 16:9 fullscreen DosBox?

Model lighting blended well with map lighting. Smoothing out transitions would be an improvement. Monsters and vweps flicker suddenly when moving over small dark patches. It's more noticeable now because otherwise it's so nice.

[leileilol]

DOS version doesn't use MGL, and Quake has always had those more unusual ModeX video modes like 360x200, 360x240, 320x480, etc


Also the reason why this is a dos build is because a win32 one would be more widespread. I'd like to fix some very annoying bugs regarding dynamic lights and the sprint function before release

[qbism]

CRDM2

[leileilol]

I have 16:9 support by startup parameter only (-169), and that's not perfect as it's just less vertical view.

[qbism]

[ceriux]

i think that looks great. esp. with that map.

[leileilol]

I've just implemented autosaving. It overrides the restart command if it knows it's autosaved, or if the user has saved, so there's more ease when restoring a saved game. Currently it only autosaves if you waste half the monsters on the level. Optional, and off by default. Just a little nicetie that I haven't seen often for Quake

Also


Not Super8 based - i figured this out on my own. The performance hit isn't so hard (though my spans aren't optimized in C to begin with)

Unfortunately i've hit a wall - crashes when a particle draws in waterwarp on Windows (not DOS) so there's probably a stack overflow somewhere... happens regardless of fog so I doubt the fog feature contributed to the crash. Perhaps it's time for me to clean out all unused variables and warnings

[leileilol]

Well um


I just beat my colored lighting functions to death


i mean optimized the hell out of them. Still no asm (yet *shudder*), it's in c


320x200, Dosbox 0.74 Pentium dynamic core @500,000 cycles, no sound, each benchmark ran three times and results averaged (yeah I should test on a real system but this will do for now):
Timedemo demo1
r228 : 70.6
r231 : 70.4
r233 : 74.4

Timedemo demo2
r228 : 80.4
r231 : 80.1
r233 : 84.4

Timedemo demo3
r228 : 65.9
r231 : 65.8
r233 : 70.0

Roughly a 10% gain, am I measuring that right?

[taniwha]

I get between 5% and 6% gain: 100 * (new - old)/old

Still, nothing to sneeze at, that's a very respectable gain.

[Spike]

percentages are cumulative.
A 6% boost can be quite significant really.

[leileilol]

I was almost thinking about surfacecache particles, like decals, writing single pixels to the surfacecache after the lighting so a red blood particle can splat flat on a wall, maybe even running down. The particle would still be there and processed by the wall, but just be turned invisible and written into the surfacecache instead, in which the spans afterward will keep drawing like normal.

like stainmaps, but with particles



And if anyone wants to, feel free to submit a patch to make Engoo work on a different platform (like Windows 3.1, Linux, Mac Classic, AROS, Wii, Gamecube, etc) I'll try my best to not regress them. I only debug in MSVC6, I compile in MSVC6 and DJGPP and getting from there to SDL+MinGW is a tad daunting to me.

Also, there's still a speed hit from colored dynamic lights with r_dynamic set to 0 so now i'm thinking it's something else causing a slowdown. RecursiveLightNodes?

Anyway, real P2 CPU tests:

DEMO1

r228- 41.8fps
r231- 41.6fps
r233- 42.7fps

DEMO2

r228- 47.2fps
r231- 47.0fps
r233- 48.2fps

DEMO3

r228- 41.0fps
r231- 40.9fps
r233- 42.1fps

[Irritant]

Wow, those screens look terrific. Very impressive.

[leileilol]

Fixed the dlight bug
Fixed the model interpolation unable to turn off bug
Fixed the fogged particles
Fixed the lit particles
Fixed the sticky particles (and made them sort of dissipate in the water, drip off ceilings (with SOUND), and run down walls)

Now i'm down to three annoying bugs:

- Numbers in notify area screw up in DOS
- Waterwarp crash in Windows
- Window stretch no work in Windows

also, I tried to recreate the lesser-known high-pressure blood spurt effect from Half-Life. Also in this screenshot is an additive blended muzzleflash hack.


This mess really calls for stainparticles, like stainmaps but writing particles to surfacecache instead of lightmap, probably before the lightmap to have lit particles, or after it to skip lightmap updates and use a multiply blend. Think the snow in Midtown Madness. Does anybody get this idea?


also, . Since this works in DOS now, it's safe to make QSB map limits (not protocol limits) build by default.


Also I think R_MarkLights can be made much faster.


There's a rare crash in Quake where a sprite gets too close to the screen. That's been dealt with now. It can be triggered by turning waterwarp off, playing in hi-res and trying to swim into your bubbles.

[Dr. Shadowborg]

Just checked out r_particleblood and now find myself wishing all engines had it. Its awesome.

Also, holy crap marcher fortress in SOFTWARE?!