|
|
|
Main |
|---|
|
[home] |
|
[me] |
|
[my links] |
|
Project pages |
|---|
|
[Luces] |
|
[Others] |
| Last update: |
|---|
|
March 19, 2005 |
|
Contact: |
| March 19, 2005 |
|---|
| Well, after ages... I have now completed my military service, worked for ISOFT (digital video, professional broadcast solutions) for 6 months, and then moved on to Nortel Networks NETAS. For the last year I have been working on Nortel's MMP project as a software design engineer. We code in PROTEL (Nortel's custom language), but I am still working at home (as long as I can find time from heavy work) trying to keep my C++ up. |
| November 7, 2002 |
|---|
| I redesigned the pages. This may not be obvious, but
many things changed. I used trial versions of Homesite and
DreamweaverMX, combined with old Frontpage documents, here it is.
The 'look' is not very different, but now it is much easer to maintain. Still, there may be broken links, please report them to [lucesferre at yahoo dot com]. |
| October 18 |
|---|
| Nowadays, I am mostly concerned in reading Marcel Proust...
When my eyes (and mind) tire down, I code. I finally have a very
nice resource manager: the "LCResource.DLL".
I like the 'DLL' approach - now I code in DLL's instead of classes :)) The data folder mess is now in a single, compressed file. I had to modify sooo much code to enable this - but it works. |
| September 19: |
|---|
| Finally, back to work (after months!). I am currenty
working on hacking for serial numbers/removing nag screens/etc. It
much more fun that I had ever expected. Being a newbie, I was able
to crack a few (namely, three) programs for their serial code. Those
were fairly easy ones, perfect for me (two games from www.shockwave.com,
and the babylon translator. I
am still working. BTW, I now use Setup2Go for the downloadables, this means that you may install/uninstall them. Still working. |
| September 19: |
|---|
| This is the new design of this page. Greatly inspired from the serialz2000 page. Nice design, simple, understandable, much more easily navigateable, whatever, it looks much better. The links are much better organized and the frames are totally removed. |
| June 21: |
| After ten days, here I am. I changed the page
design completely. I am rewriting many parts of the code, for the
sake of a cleaner interface, speed, etc. I started with the Maya
exporter. I had a problem with my right wrist, and it slows me
down a bit.
For the projective lights: just changed the blending to one to one, and now it works... |
| June 11: |
| Updated game_demo.zip. Now I have another weapon
(rocket-launcher style), point explosions, sounds are compressed,
and a few things more.
I had a problem with projective lights. After the multitextured diffuse/lightmap pass, I cannot just add light, or the shadowed areas of lightmap will be only black&white (or anly light color) after lighted by projected light. I cannot add a diffuse+light pass, because it causes color saturation. It is very late at night, so it will remain unresolved until next time. |
| June 7: |
| At last things are working fine. I rewrote the
whole octree code. Now, triangles are clipped to octree divisions,
and a triangle now appears in one node only (no duplications, as
it used to be). Weapon shading is per-pixel again. The code
is now much more stable, however sometime I may need to
write a new codebase.
I saw some screenshots from Doom 3. Stunning. It seems that the next thing to add will be realtime shadows. I will also have to buy a new video card, I cannot even imagine how fast my current one will suck on Doom (it is said that Doom will use up to 7 passes!). |
| May 30 : oct-tree and frustum culling |
|
I now use oct-tree for both collision detection and frustum culling. However, frustum culling introduced new problems. It sometimes slows down rendering speed! In the oct-tree nodes, I only store the indices to actual vertices. This lets me keep the vertex data in fast memory. The frustum test returns a set of oct-tree nodes, which contains indices. The problem is that, you either have to make many glDrawElements() calls, or you have to pack the indices into a large array. Both have problems. Calling glDrawElements() multiple times slows if there are a large number of nodes in frustum. In the case that there are few nodes in frustum, the packing slows things down. My final decision was to pack the indices into a large array. Nevertheless, I will need that array to sort indices for shader/state changes. |
| May 27: |
| I postponed the task of interleaving the vertex
structures. The growing number of visibility tests caused a
performance hit, so I rebuilt the collision code to use an
oct-tree. I provided quite helpful. I tested a world of about
80k triangles with no performance hit at all for collision
detection. Note that I use oct-tree structure just for collision
detection, and there is still no culling. |
| May 25: |
| I was able to render the scene with D3D (at last!)
. However, to be able to code easier with D3D, I have to
converting all my vertex data to interleaved formats. This may
take some time, because everything was using separate arrays
(easier with OpenGL).
Things are rather messed up now, may take a few days to work right. |
| May 24: |
| I just read an article from NVidia site, which helped me to find the 'weapon' bottleneck. It seems to be the low memory bandwidth of MX cards. I removed the ~500 triangle gun and replaced it with a ~10k triangle one, enabled four lights, and frame rate increased from ~70 to ~130 ! So, it is sometimes really better to have a high tessellation than using per-pixel lighting. I have to update the screenshots now. |
| May 23: |
| The weapon drops frame rate drastically. This is probably because it is rendered with multiple passes, one pass for per each light in range. I must find another way to render it efficiently. A better appoach may be using NV_register_combiners for multiple lights and reduce passes. However this extension is available only in GeForce class hardware. |
| May 23: |
| Using vertex shaders for dot3 lighting setup is very expensive on my machine. I have to track and see if I am doing something wrong, or it is just the incapabilities of GeForceII MX. |
| May 20: |
| I completely rewrote the part that handles the memory for the vertices. It now first looks for video ram, then AGP, if all fail, a standard malloc(). Sadly, obtaining a pointer of fast memory works only on GeForce class hardware. |