Volca on 4/1/2010 at 11:46
Guys, sorry for the silence - my personal life interfered with the openDarkEngine efforts for the past few weeks. Others seem to be silent as well, I'm afraid. Hopefully I'll start working on this again in a few days.
@Yandros: It should not be a problem to render the sky properly. Actually it is a good idea for a subproject for anyone wanting to start helping with the project - not terribly difficult and rewarding.
Albert on 7/1/2010 at 02:24
Hm, the work Sio2 has done on the fog fix may be a little out of range for this project, but maybe Sio2 could share anything he has learned about the fog system with someone frisky enough to ever get to that part of the process.
Albert on 9/1/2010 at 06:48
Also, I must inquire something that piqued my curiosity a few minutes ago:
Considering that EAX has always been just a more Windows-specific feature of thief 2 (but of course), I looked into a more multi-os alternative: EFX, the openal equivalent to EAX. And though extensive work for sound is a bit out of the way for right now, I thought I'd just mention this so maybe it could be taken into consideration.
Also, I dunno if EFX is in working condition as of yet, I just found it on Google.
Albert on 25/1/2010 at 23:39
You mentioned some lightmap work your doing, Volca. How fast did it come to you to create the fix in the code as you did? (I'm not being sarcastic... much!) :p
Volca on 26/1/2010 at 07:07
I hope you mean this frankly - you have to understand the largest part of the effort does not lie in the coding itself but in the process of extracting tiny bits of knowledge from raw data or with the help of the reversing guys.
In this particular case (it took two days to come up with a solution) it was pretty well understood roughly what the data mean - we were able to apply texturing without glitches for a long time. It was understood for a long time as well that the lightmap positioning is in relation with the texturing, we knew what the fields in the structures of WR in the mission file are, their rough meaning. Still it resisted when it came to bulletproof lightmap UV calculation algorithms. The main reason here is that dark applies texturing coordinates based on the world position of the polygon and the UV shifts that should've moved the lightmap UV back to the range of the lightmap size in pixels were off. For a long time I resisted to do anything with it as the pseudo-working algorithm produced viable results but it nagged me enough to finally fix it.
Dark has a really old renderer. You could compare it somewhat with Quake 1 but there are big parts that are different. The data stored in WR are not really ready for any modern rendering. Texturing coordinates have to be calculated, lightmaps have to be stored in atlasses in order for the rendering to be a effective, etc. There are still other problems ahead of us regarding rendering - for example the fog you mention. We know how it is physically stored on disk but not yet how it is rendered. Then there is the dynamic lighting problem.
We'll see if the solution I came with can be made bulletproof yet, but it seems so, so far...
Albert on 27/1/2010 at 01:54
Yes, I do understand. I'm just as curious as anyone, I guessing is the case here, and not any impatience. Really, I think it couldn't go any faster now than if ever.
Though at the very least, when you make big steps in the coding process, be sure to post fancy pis to keep this project strong in the communities eyes.
Volca on 1/2/2010 at 12:17
Don't fear. If we'll manage to achieve anything visually appealing, I'll update this thread with a picture. So far it seems it will take a while, mainly non-visual work to follow (Camera handling, player handling, physics).
As a side note - the fix for the lightmap alignment is in SVN now, if anyone would like to try. It took a bit more time than previously expected, because contrary to my initial belief texture alignment was also wrong on some surfaces. It feels good to have this finally fixed, after all those years! :thumb:
jtr7 on 2/2/2010 at 00:51
Every victory is exciting!:D
MaxDZ8 on 2/2/2010 at 10:52
Good to know this is still moving. Maybe I'll be able to have OPDE before I change my computer, I am truly scared about dropping my current one because of the compatibility concerns.
To be completely honest, I am not well aware what's the current state of OPDE. I think my last message about that was posted in(
http://www.ttlg.com/forums/showthread.php?t=125524&page=10) 27th July. I know something has improved but I'm not sure of what. Could someone please sum up the overall evolution in the last few months? Is there a new demo to go?
Volca on 2/2/2010 at 12:49
Not much from the "awsome" standpoint - preparations for the simulation code, cleanup, completion of python bindings (still not entirely there), 2D rendering system for GUI and HUD, some resource management improvements (we still need a better system for this though - I'd love to add some threading at least to this part of the engine, we may be lucky as Ogre 1.7 introduces a generally usable worker thread and work queue concepts that may fit without us needing to add another library dependency).
Coming next - work on simulation... Sim, camera, physics services mainly. There are some large unknowns in the PHYS_SYSTEM tag still, mainly how contacts are stored. Some rough path ahead :)
