Project basics

[Thirlan Tyrandor]

The answer only depends on whether or not you want to work with the game industry. I say stick with windows for everything else unless GLT or GLUT. Obscure tools will not help you on the resume ;P

[Deran Malath]

actually, windows sockets aren't that hard to handle, not even the UDP. It is quite possibly the only thing they've done right, as it is practically the same syntax as in *nix.

That's simply because they copied it from *nix

[Angeleon Askaroth]

hmm, my damn ISP cut my internet yesterday, so I've not been able to do much... Having to move havn't been helping either, but I've done some work at least, even if it cant' be shared yet.

I've been studying GLUT and I find it to be a rather simple wrapper. It would do just fine and I think we should use it. The feeling of not having to bother with any of windows shit is just to great =)

It is, however, a event-based programming and does quite limit the main thread a bit in my opinion. It should be able to do everything, but I think two more threads should be useful. I.E. Three threads. One for player input (keyboard, mouse), one for network input and one to actually compute stuff. Pathing and other heavy things. Then the question is how to handle the communication between the threads.

Actually, it is maybe not much of a question as there aren't much of an option, is there? I can't really remember what they are in c++ either. We've got monitors and the lock-thingy, right? But then the lockthingy tends to be risky, right? We don't want a deadlock, now do we? I honestly need to refresh my memory as it was over a year ago I even touch these things. Normally I just try to avoid using threads if it can end up in a deadlock since that is usually the safer way, but now I think it would be better with threads and we will need some kind of safety-procedure for it.

[Thirlan Tyrandor]

You're talking about Mutexs (mutual exclusion). Dead locks only occur with poor design. Any of the theoretical based stuff you have problems with I can handle since that's what I'm good at. I've kept many "Operating systems and Architecture" notes that dealt with locks and how to do proper lock and step thread information sharing. For starters one often creates inbuilt locking data structures; one of which I will share in below.

The engine is where all the information resides and the threads take care of certain parts, often unique aspects so there wont be much need of locking information. For starters the network protocol thread can be kept in lock by creating a queue system. You get a message, you then parse it and lastly you dump it on a queue with two pointers. The back pointer where you insert new messages and the front pointer where you pop messages. When the two pointers are at the same position you can't pop the queue since it's empty. Once you enter a new message and are done you increment the pointer. Thus we have a mutual exclusion datastructure that will keep the system in step.

Anyway try not to code too much without me Angeleon. Pair programming helps in that two people understand the code so that when one is absent the other is at least present to explain. So before you go bananas we really need a CVS server up. I'm going to explore a CVS program I know right now and I'm going to bug either Fishbarrel to install it on his server or bug whoever manages the Duchy server. If we don't get this server up we can't easily keep track of who is doing what or the new changes that were made and I know you hate to make comments so we're going to minimize the risks here without imposing on you.

[Angeleon Askaroth]

That's what I'm talking about yes. =) I started to remember that stuff a little after the post and I too came to the conclusion that the one system you mentioned will probably do perfectly. Though I had nothing as concrete in my mind. =P

And yeah, I'm not doing anything advanced or so... I'm just setting up the startup functions and making simple (empty) functions so that we will have the ability to start a window and handle input through openGL. Basically doing things that one only have to use once. So don't worry, I'm basically just setting up so that I know how glut does things. If nothing else, I'll be able to do it correctly faster next time.

[Thirlan Tyrandor]

Ah okay... I'm just a little cautious. Last time I worked with a group and one guy suddenly started doing everything and before we knew what happened the entire engine was coded by him. Then he left for a bit and because he didn't bother to share or let anyone else do crap we spent just as much time trying to figure out his code as we would have if we created our own engine (couldn't tell that was the case at first). When he came back we had to hold the bugger down and extract information from him with a plier because only he knew how it worked and he was giving us a tough time because of his heroic attitude.

This is also a good time to tell everyone else something important... Heroics are a BAD SIGN because it implies things were allowed to get so out of hand in the first place that only monumental feats could save it. A well managed project has no opportunities for heroics. The same goes for wars and a passage from Sun Tzu neatly fits this,

"To see victory only when it is within the ken of the common herd is not the acme of excellence. Neither is it the acme of excellence if you fight and conquer and the whole Empire says, "Well done!" To lift an autumn hair is no sign of great strength; to see the sun and moon is no sign of sharp sight; to hear the noise of thunder is no sign of a quick ear. What the ancients called a clever fighter is one who not only wins, but excels in winning with ease. Hence his victories bring him neither reputation for wisdom nor credit for courage. He wins his battles by making no mistakes. Making no mistakes is what establishes the certainty of victory, for it means conquering an enemy that is already defeated. Hence the skillful fighter puts himself into a position which makes defeat impossible, and does not miss the moment for defeating the enemy. Thus it is that in war the victorious strategist only seeks battle after the victory has been won*, whereas he who is destined to defeat first fights and afterwards looks for victory."

*"He who seeks victory from battle is destined to defeat", familiar no?