May 24th, 2004: New release with improvements in the player collision code, bug fixes and more:

	a new MovementController, FlyController, a 'no-clip' mode (F4 switches MovementControllers)
	a 'no-clip' mode (F3)
	restart position key (R)
	collision with the sprites
	bug fixes

May 15th, 2004: Although it was a long break with no updates (mostly due very limited free time), I haven't completely ignored the  project. I've started a new subproject that is getting closer to a real game application. The main subproject was 3dMap.exe, which is just a 3d viewer for duke3d maps, and it served well for perfecting the 3d rendering. I feel that the rendering is capable enough at this point so I created this new 'game.exe' which models the real time as well, allowing for the next steps in the engine (animations, AI, physics, networking, ...). It is still a prototype (ie. don't expect me to polish it a little and release it as the next duke3d clone) but it adds some cool stuff: animated textures and player collision, in addition to a number of bug fixes. The player collision is by far the most important addition and it took me a considerable amount of effort to get it to the point where I decided to pack a new release. One of the reasons this release took so long (beside lacking free time) was that I experimented with a few different approaches to collision detection.

But enough with talking, go grab it and send me your feedback!

Dec 27th: a simple sound subsystem is functional. Much simpler than I was planning (the 3d positional part is laughable for example), but this way I made some progress. The initial plan was too ambitious, and it wasn't looking like I was making any progress, so I had to cut it down. I wrote some simple code to load .voc and .wave files, although I may use an open source library later. Now I'll take a quick take at parsing the .con files, as they tie much of the game together, including the definitions for actors/objects.

Oct 14th: The project is going to be moved (slowly) to SourceForge! This means CVS, forums, discussion lists, and more! Check out LDuke3D project's page.

Oct 5th: After some hard work the duke3d sprites are finally here! They look good (considering that they are 2d sprites :-) and I wanted to wait until all the obvious problems were fixed before releasing anything. Right now they look very close to the original engine rendering (with some minor 'improvements' :-) Bunch of new screen-shoots.

Sep 13: The website is back online after the old server machine broke down. Now I have a new and improved server :-) but it took almost 2 weeks to put everything back together.

August 16: I finally put together an implementation for mirrors. It took more effort than I originally anticipated, mostly because the limitations in the lfc3d and in the current engine design. But it's all good, as this version is just a prototype, at some point (soon I hope :-) I will throw most of the code and switch to a better foundation.

July 21: transparent walls are now sorted correctly (back to front) so that the resulting image looks fine

July 19: masking/one-way walls are now implemented. still have to work on the transparent masking walls (have to sort them correctly before I draw them). Also I fixed a small problem with textures with 'holes' (the annoying pink border around the 'alpha' border)

July 18: It took a long time from the last update, I've been quite busy for the last month, but I finally finished some the the basic things I had on the to-do list:
- correct 3d portal visibility determination
- fixed the 'parallax' rendering
- speed optimizations (now it should run at decent fps even on the most complex maps)

May 17: revised parts of the map geometry pre-calculation, collision detection and parallax rendering. Right now the engine supports only one parallax per scene, but this should not be a serious limitation. The new code deals correctly with the portal visibility and collision when we have parallax 'walls'. (note: even the original duke3d engine seems to have some problems in this area, although it computes the visibility correctly, the collision computation is off sometimes)

Overall, I'm trying to stabilize the rendering part and move to the next steps (collision/physics, AI, ...), but there is still work to be done on the rendering...

May 12: More performance improvements with (software) portals visibility. Also added portal 'rendering' to the wireframe rendering (screenshoots)

Played with the HW portal visibility using GL_NV_occlusion_query (btw, thanks to all who reply to my post on opengl.org) The results seem to indicate that the software visibility computation will result in better performance on maps with many sectors visible at the same time, at least on my video card (GeForce4 Ti 4200). But my implementation is somehow primitive (it doesn't try to take advantage of the gpu/cpu parallelism) so I think better performance using this approach may be possible.

May 10: I implemented an idea I had for a while: group the primitives by texture, so I can reduce the number of texture binding operations (which are expensive even with a good video card). For now I'm grouping only walls/floor/ceiling within a sector, and the results looks promising. Theoretically I should get even better performance by grouping across the map, but I have to look into it to see if it's worth it (it's slightly  more difficult than to do it within each sector because sectors have different 'palettes', shading/fog, ...)

May 5: experimenting with the portal visibility code. right now it can handle 'open area' with many visible sectors at the same time much better, but I still have a list with ideas for improvements