Makaqu
Re: 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.
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.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for
Re: Makaqu
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.
If I did not include a license, I hereby declare it public domain or WTFPL whatever suits you.
Improve Quaddicted, send me a pull request: https://github.com/SpiritQuaddicted/Quaddicted-reviews
Re: Makaqu
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.Spirit wrote: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.
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.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for
Re: Makaqu
Tried entitytest in some engines including quake.exe and winquake.exe, no problems whatsoever. Does it only get freaky if skyboxes are involved?
Improve Quaddicted, send me a pull request: https://github.com/SpiritQuaddicted/Quaddicted-reviews
Re: Makaqu
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).
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for
Re: Makaqu
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.
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.
Re: Makaqu
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.
Re: Makaqu
Thanks! This fixed the problem with multiple dynamic lights. I normalized it after all lights gets added.Revanic45 wrote: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.
The contrast in the shading doesn't look as extreme as before, but it does look a lot more accurate.
Re: Makaqu
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.
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.
Re: Makaqu
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.
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.
Re: Makaqu
I assume DirectDraw doesn't like the menu fade effect, it's much faster in -dibonlyqbism wrote:In fullscreen, FPS drops very low when the menu is down.
Windows 7 was my idea!qbism wrote:The palette goes crazy until the next bonus or damage flash.
How could this "resolved"? Palette update per second (while not flashing) to squish the NT6 palette glitch?
i should not be here
Re: Makaqu
Strange, yeah, it is much faster. But then palette mixed-up occurs on the back side instead, after closing menu.leileilol wrote:I assume DirectDraw doesn't like the menu fade effect, it's much faster in -dibonly
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.
Re: Makaqu
_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.
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.
Re: Makaqu
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.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for