What are you working on?

[r00k]

airshotmap : Airshot02

[qbism]

I know it is nothing special, but I just finished to add the Hexen monster: Afrit into Quake and wanted to mention it.
I used John "Psychikon" Jensen´s wonderful gpl model for it.
Using the Darkplaces engine I also made some fire particle effects for him.
If you are interested you can download him at quakeone.com

I like to see creatures that blend well into the environment in terms of lighting, style, and effects. The ablilty to do so is a talent in itself.

[qbism]

Implemented true hi-res screen waterwarping in Makaqu. My previous hi-res waterwarp code did render the scene in hi-res, but the waves of the warping effect weren't scaled up. Haven't posted about it in the blog yet because I still have to take some screenshots for comparison.

Sorry, digging way back...
I'm working on removing the warpbuffer and rendering straight to the vid buffer. It would save the time it takes to transfer from on to the other. We can do this because in Windows it's not 'really' the vid buffer, it gets transferred to the "real" buffer later, 32-bit ddraw for example (depending on version of vid_win.c used). I've got regular rendering and fog working. But the catch with underwater warp is that it's destrucive/ overwrites original pixels (will post a screenie when I fix screenshot code...) so it really needs those two buffers. Or is there another way?

[mankrip]

I've got regular rendering and fog working. But the catch with underwater warp is that it's destrucive/ overwrites original pixels (will post a screenie when I fix screenshot code...) so it really needs those two buffers. Or is there another way?

I guess I know what you mean. Fog must be calculated before the underwater warp, because the underwater warp doesn't change the Z buffer to match the resulting image.

You could probably make a copy of the D_WarpScreen function, call it D_FoggedWarpScreen or something, and modify it to do both things at once, while also writing directly to the system's video RAM.

And I guess there's a slight error in the case numbers of the unrolled loop of the tutorial I've posted a few days ago. It should go from 31 to zero, not from 32 to 1.

[jitspoe]

Experimenting with various optimizations. Brought over the DarkPlaces point lighting to Quake2 and fixed some bugs with it.

[qbism]

I guess I know what you mean. Fog must be calculated before the underwater warp, because the underwater warp doesn't change the Z buffer to match the resulting image.

You could probably make a copy of the D_WarpScreen function, call it D_FoggedWarpScreen or something, and modify it to do both things at once, while also writing directly to the system's video RAM.

And I guess there's a slight error in the case numbers of the unrolled loop of the tutorial I've posted a few days ago. It should go from 31 to zero, not from 32 to 1.

Thanks for the tutorial, I've just finished implementing it (5 minutes ago) and enjoying the bigger warp. I don't know if it would be slower to warp the Z as well, or move fog calc back before warp. The issue with doing both at once (D_FoggedWarpScreen) is that warp will pull from pixels without fog calculation yet.

[mankrip]

I don't know if it would be slower to warp the Z as well

It would, because you'd need to have a secondary Z buffer, and write the warped results into it.

The issue with doing both at once (D_FoggedWarpScreen) is that warp will pull from pixels without fog calculation yet.

Make a turbzsrc variable, following how the turbsrc variable is implemented. You'll also need to make a local zsrc in D_WarpScreen. Then it will be just a matter of turning this:

Code: Select all

         tempdest[31] = src[row[turb_x_temp[31]] + col[31]];

Into something like this:

Code: Select all

         srcindex = row[turb_x_temp[31]] + col[31];
         depth = zsrc[srcindex];
         pixelcolor = src[srcindex];
         // apply fog and write to the screen
         tempdest[31] = fog (pixelcolor, depth)

Of course, zsrc and src can be read directly by the fog algorithm, to make it faster. And you can change tempdest to point to the system's video buffer instead.

[qbism]

Of course, zsrc and src can be read directly by the fog algorithm, to make it faster. And you can change tempdest to point to the system's video buffer instead.

I began to implement this. It would work, but requires flagging of hud pixels, possibly by using z buffer. I was too lazy to take it that far, but not too lazy to justify myself I found that in a particular underwater view, frames took 20ms to render and took 0.18ms to copy the warpbuffer, less than 1% overhead. The flagging of hud pixels and the extra conditional in post-process would eat into that small potential savings.

Here's waterwarp into it's own buffer as promised, showing soon at your local modern art gallery:

[Ghost_Fang]

Been learning a bit of C lately and having fun with it.
Added basic achievements to the PSP (L4Q).
It plays a sound, slides down, pauses for 3 seconds, and slides back up.

[Spike]

qbism, surely the hud is drawn after fog, thus the fog code doesn't need to care about any 2d stuff (also, drawing the hud is very likely to not affect the depth of those overlay pixels).

any luck with using threads to offload parts of the rendering? might help achive 60fps+vsync, to make things smoother. most aproaches buffer the result of one thread for use by the second thread the following frame, rendering an extra frame behind. not sure what you can easily chuck on to such a worker thread. fog, I suppose, though that does make the hud awkward unless its drawn by the worker thread too (which likely requires more sync points).

[ceriux]

cool stuff ghost_fang.

[qbism]

@Spike: putting fog at the very end (vid_win flipscreen) is a performance boost but means zeroing out z at each hud pixel or just letting the hud be a little foggy. Plus there are other gotchas that eat into the initial boost. Would be great to at least thread the fog loop. Likewise warp.

@ Ghost_Fang: A great idea. Achievements add fun and even replay value to levels if done well. Modern Warfare 2 is an example.

[mankrip]

[...] you can change tempdest to point to the system's video buffer instead.

[...] It would work, but requires flagging of hud pixels, possibly by using z buffer. [...] The flagging of hud pixels and the extra conditional in post-process would eat into that small potential savings.

Actually, I've thought about this for a while, and there's no good way to write the warped image directly into the system's video buffer without also warping the HUD, menus and all other 2D elements. It's better to only copy the engine's video buffer to the system's video buffer after everything has been drawn into it.

About threading, it would be interesting to make the whole server side of the engine run in a separated thread.

[ajay]

After doom and gloom, I've finally got my hands on a new pc. Alls working well. Anyway, I reviewed the brightness, or lack of it, debate I was struggling with, where some would see it how I did and others would see it as too dark. ON my my new pc, it looked.... too dark! Some adjustments (not subtle, just to raise the overall light values, still work in progress) later, and the result can be seen here: http://wp.me/a1NjfD-8Q
It still needs work, but I hope it looks to others how I've always seen it.

[goldenboy]

w00t, a new post!

Yeah, that looks a lot more sane Ajay.

Something else: Your curbs are too high. Imagine driving that bicycle up that curb. Ouch!! Your street is also a little flat.