Makaqu

For entities and textures I generally hack them in at load time, then #if 0 them out when done.

end.bsp has multilayered liquid; fall into the first pool and look up at the teleport you came from. Also e4m7 for liquids within liquids.

My http://www.quaddicted.com/files/engines ... spirit.zip testmap has a translucent brush. I hope I included the source. Would be great if those other test cases would simply be added to the map.
If I did not include a license, I hereby declare it public domain or WTFPL whatever suits you.

My http://www.quaddicted.com/files/engines ... spirit.zip testmap has a translucent brush. I hope I included the source. Would be great if those other test cases would simply be added to the map.
If I did not include a license, I hereby declare it public domain or WTFPL whatever suits you.

This is a great map for testing the basics, as well as making sure that you're doing this stuff in a way that's going to be compatible with other engines. Highly recommended.

Another favourite I use on occasion is LordHavoc's entitytest (it's on his downloads page) - there's nothing much special about it, but it does give your MDL drawing code a light-to-moderate workout and does include a moving sky brush, which tests how compatible you are with one example of the slightly weirder stuff.

Tried entitytest in some engines including quake.exe and winquake.exe, no problems whatsoever. Does it only get freaky if skyboxes are involved?

The standard id engines should work fine. Where an engine might go nuts is if it doesn't properly handle sky surfaces on brush models (skyboxes would be a good example here).

Try back2forwards. Multiple layers of transparency.

Thanks. Both entitytest and enginetest-spirit crashed my engine, but back2forwards worked.

backwforwards uses a BSP entity for the translucent floor and another for the translucent windows of the ship right below it, and thanks to that I found out that translucent BSP entities are affected by Makaqu's clipping bug also.

I noticed that with the directional lighting, you did not normalize the lighting vector after getting it from the dynamic light. You MUST do this, it will make it look much better.

I noticed that with the directional lighting, you did not normalize the lighting vector after getting it from the dynamic light. You MUST do this, it will make it look much better.

Thanks! This fixed the problem with multiple dynamic lights. I normalized it after all lights gets added.
The contrast in the shading doesn't look as extreme as before, but it does look a lot more accurate.

The 1.5 version is released. It only runs in windowed mode. I hated to release it with this bug, but despite that, I'm quite satisfied with it.

The particle lighting allows overbrighting, while the SPR model lighting doesn't. Maybe I'll change the particle lighting to behave like the SPR one, but opinions are welcome.

I was able to get it to run fullscreen mode. In fullscreen, FPS drops very low when the menu is down. The palette goes crazy until the next bonus or damage flash.

Transparency looks great. In back2forwards, was able to see entities and skies correctly rendered through 2 layers of glass (func_walls I think). mkqtest1 map from 1.4alpha rendered correctly, even through multiple layers of transparency.

overbright sprites could have a washed-out look. Instances like the explosion sprite.

In fullscreen, FPS drops very low when the menu is down.

I assume DirectDraw doesn't like the menu fade effect, it's much faster in -dibonly

The palette goes crazy until the next bonus or damage flash.

Windows 7 was my idea!

How could this "resolved"? Palette update per second (while not flashing) to squish the NT6 palette glitch?

I assume DirectDraw doesn't like the menu fade effect, it's much faster in -dibonly

Strange, yeah, it is much faster. But then palette mixed-up occurs on the back side instead, after closing menu.

Not sure why there's a speed difference. The fadescreen effect is applied to buffer upstream of vid blit. Could try ditching MGL for one of the MGL-less drivers posted by mh.

_never_ read from video memory.
if you need to read from video memory, use some other buffer somewhere (like quake's water warp buffer), a bit like you would an fbo in gl.

video memory is generally paged as uncached memory, so every single access results in stalling the cpu while waiting on the result, hence the slowness.

DIBs are blitted from system memory each time, hence why you'd want to use directdraw when you can.

The MGL-less drivers are immune to both read-from-vram and palette-craziness issues as they work on a system memory buffer for most of the frame but just expand that out to a 32-bit buffer at swap time. In practice this is just as fast as working in 8-bit (owing to some loop-unrolling), and may even be faster on some systems as writes to vram work best when you can feed it a lot of data in large chucks over a short period of time.