The followup(1)
Nice to see that Radupvr is not going to leave right now, and will continue to update his journal. But it doesn't change anything to the behavior of those who bashed him. Believe it or not but I find user-bashing rather imature and childish. User bashers tend to think that they are the only ones who are right in the entire universe, and that their way of thinking is the best one can possibly have. They deny you the right to be wrong - in their opinion, but since their opinion should be Teh Opini0n... - or to think differently than they are - omg! j00 r not fol0win Teh Opini0n!!!!11.
They are responsible for a number of departure - or visible dismiss - here. Remember the dismiss of S1CA? Even if he came back, who can say that bashing S1CA was a good thing? Wasn't he helpfull?
I happen to believe that Radupvr, S1CA and a lot of others are far more important for this board than any lounge lizard user basher.
The more technical stuff
I nearly finished the SQLite driver code - it is not so bad, but I had a number of problems and it not completely tested (for example, I didn't test the transaction mode). Anyway, it is cool because I can now continue to program on my laptop or on my main PC. I must now do the PostgreSQL code - it will probably be easy too, since libpq is rather easy to use. I may give you the code once it will be ok (and if you want it, of course).
Now, I have to create my tables - they have to be simple enough to be understood by both SQLite and PostgreSQL.
I am not happy at all with my network code - maybe you can help me, guys - actually, I have two problems:
- when I run my code in the vc++ debugger, the socket I creates have socket descriptor > 4096, while FDSET_SIZE is defined to 64. You have to change the definition of FDSET_SIZE (this is legal, so there is no real problem here... except that your fdsets are now very big and that select() performs poorly). I believe that this is a Microsoft trick to enforce the use of these asynchronous sockets in their Winsock API but this is something I can't do, because my network code has to be (nearly) portable - my server will run on a linux box.
- I may have to manage a large number of connections anyway (I still don't know exactly, but it would not be a bad idea to target more than 1000 tcp/ip connections). I still don't know whether it is a good idea to use tcp/ip or not, because I don't know how an ip stack will peform with such a high number of incomming, permanent connections. I may be able to redesign the communication process to use udp/ip - maybe... :S
If you, guys, have some ideas about this subjects, let me know! I guess I have to visit the Multiplayer and Network Programming forum ^_^.
Other project, other thoughts: I reread [SB-1](2) and I though to their terrain engine, and more precisely to their LOD system. In Scott Bilas's paper, no indication is given concerning the terrain LOD system they use, and maybe the reason is that they don't use a terrain LOD system. Tis would be crazy, but in fact most of time you don't see much of the terrain - because the view is centered on the player - so a brute force algorithm should be possible. If a LOD system is implemented, it has probably to do with the terrain node system - since the terrain is splitted in nodes, once can use a method similar to GeoMipMap to LOD far nodes.
So: brute force or LOD? I guess both have to be tried... :)
Update!H_o_p_s right side notes are finnaly nearly working! (1) edit: I tried to use H_o_p_s side notes, but was unable to use them. My HTML r the sukz0r.
(2) references are now put in the small references collection on the left of the journal entries.
