Engoo

[Spirit]

Also, holy crap marcher fortress in SOFTWARE?!

Kinn made sure it ran in winquake!

[qbism]

... IN DOS?!
Surprised due to DOS memory constraints.

Stainparticles is a fascinating concept. Is there a way to check particle collision while drawing surface blocks? Then stuff doesn't have to be precalculated and stored... as cached particle overlay surfaces?

The particles don't have to be precise, maybe a 'particlemap' modeled after lightmap could be used. Instead of blending, a discrete pixel would be written whenever a threshold is crossed, filtered through a dither lookup.

[leileilol]

The particles don't have to be precise, maybe a 'particlemap' modeled after lightmap could be used. Instead of blending, a discrete pixel would be written whenever a threshold is crossed, filtered through a dither lookup.

I don't think dithering would be necessary. I was thinking raw particles drawn on surfacecache texels *after* the surfaceblock functions so we don't push lights for every change (like stainmaps would require to do). IT would be called *before* the spans functions so we can have the stuff happen while keeping the asm. However, to 'clear' the particles, you would need a second surfacecache or run teh surfaceblocks again.

To 'blend' the particles in the map, they can use a lookup table, which would still be fast because particles are only 1pt texels in the surfacecache. Being in the surfacecache would also let them blend better through those crazy kernel filtering functions, fog and the like. We wouldn't even need to bother with any lightpoint calls!

The big problem is the mips. Do we require 4 near particles for mip1, 8 particles to draw on mip2, and 16 to draw on mip3?

[qbism]

OK, I've just got dithering on the brain.
So a particle hits a surface... does code delete the particle and run 'R_AddStainparticle' similar to FTE 'R_AddStain''? Or is the particle turned invisible, flagged, and scanned somehow for impact location after surfaceblocks?

[leileilol]

I'd want to skip drawing of the particle totally if it's within the wall.



Also , while trying to experiment to add echo to the sound system, I accidentally muffled sound effects however it's staticy. I might be able to utlilize this 'effect' for underwater...

[mankrip]

[...] make 3 separate colormaps - one for each of R, G and B, then output to 3 separate color buffers - one again for each of R, G and B. Mix them together at swapbuffers time to get the final image.

[...] the main advantages I see would be that you get to keep the original ASM code (with all of it's wacky Abrash optimizations)

I actually have the 3 blocks thing half-implemented (generating the 3 color maps as theorized even).

Interesting idea, but incompatible with my fast texture dithering approach. So, you may gain speed on the surface caching stage, but the cost will be a much slower texture filter in realtime, unless you figure out how to translate all of my surface cache padding code into Abrash's asm code.

[leileilol]

I would have a second 'mix' surfaceblock.

[mankrip]

Padding the surface cache at mix time after the R, G and B channels have been processed wouldn't allow this fix to be implemented, because it requires the texture and the lighting to be processed differently (wrapping the texture's edges, while expanding the lighting's edges), so you would still get visible seams in all surfaces.

Well, at least the speed gains would be retained.

[leileilol]

I'm not too concerned with fixing the kernel filtering at this point (especially when dealing with C spans contradicts the aim for performance, and i'm not sure if this rgb abrash surfblock theory is faster than my current c surfaceblocks yet (which I optimized quite a bit out of since to the point where I think something slow is happening in MarkLights)).

The strange waterwarp particles crash in Windows is more fatal, and now i'm starting to see a strange bug appear involving trail particles causing them to suddenly jump and make a long line. ugh

[mankrip]

i'm starting to see a strange bug appear involving trail particles causing them to suddenly jump and make a long line.

This happens when a missile travels through the map limits of the engine. It probably happens in vanilla Quake too. I still haven't tried to think about a proper solution for this.

[leileilol]

No that's not the same bug. Sometimes the particles THEMSELVES will suddenly move, not the same as calculating a trail from the new entities' now void origin.

This started happening after I installed VC6 SP5.... hmm!

At least I keep a public svn repository so I can go back and see what the hell I did wrong.

EDIT: Rolled back to VC6 and the bug went away. Hmm!

[leileilol]

Please, do not adjust your set...

[ceriux]

is that like a quad effect ?

[ceriux]

is that like a quad effect ?

[ceriux]

is that like a quad effect ?