I'm lacking historical knowledge of this project, that's why I opening this:
- threads:
I don't want to start a flamewar on whether this project should or shouldn't use threads, yet the question remains:
Atm, pthreads are used sparsely all over the project code, mainly to separate different up keep functions in different threads
and overall, handle networing and try to win some speed, I guess.
I won't say "threads are evil" (common dev sentence), but yeah, they are dangerous.
That's why I wanted to ask: Why were they desired in the first place? What is the historical reason?
As for a point of situation about this:
It seems the threads implementation was never actually finished (because the code was tangled enough to prevent this, but also because the effort was stopped in the middle of it.)
and actually, they are functioning only to provide one working client thread, one server thread, one AI thread and one creature up keep thread. One thread per creature and per AI was desired but doesn't work and was disabled in the code for both AI and creatures management. (This means not a lot is threaded finally AFAIK. ODServer::startServer() makes two or three functions be called in separate threads. Functions that could be, IMHO, sequential.)
There is also a few bad things happening because of threads atm:
- The GL renderer plugin for Ogre is crashing at app exit because it is functioning in a threaded environment, from what I could see.
http://www.ogre3d.org/forums/viewtopic.php?f=2&t=65997
Might be related to bug #5 in the bug tracker and maybe we can fix this with what is proposed there but I'm not sure.
http://sourceforge.net/apps/trac/opendungeons/ticket/5
- There is a race condition present atm in the creature spawning code, making the game stop in the middle of that sometimes. It is fortunately rare enough.
- The thread management is atm tangled within the components code. I mean we have plenty of semaphore along entities code for instance, and it's hard to be sure when one can access/write some data with or without a semaphore, and without adding a new potential crash within game. I've been lucky so far because I've never pushed things that looks right but breaks the game.
All that is making me think we don't need them, and could easily replace the network part with SFML or SDL, for instance, hiding the network threaded part from us. The rest can be sequential since it is already most of the time.
I don't claim I'm totally right here, and maybe there are things I still don't know that makes the game needs absolutely threads. Yet, I'd like to know whether it would be possible to slowly switch to a client/service based code, and limit the tread use only to the minimum if we can't drop this. what do you think? Feel free to comment!
- Flood filling:
I've noticed that in the game map code, there is a flood filling algorithm. An algorithm which "paints" AFAIK tiles of the same type.
My question is what is that needed for? The editor?
- PrefixtreeLL:
The prefixtree class is from what I understood, something that permits to retrieve a word from a dictionnary when you give it only the beginning. Like when pushing the tab in bash commands.
I've got nothing against that. The problem is that the class is not gpled according to the copyright header.
Thus, are the files gpl compatible and how can we prove that? Or can I remove the use of this as it isn't vital?
- Group code source in sub-folder:
Atm, the source code is in the same folder source/ and there is a lot of files there. I wondered whether we could move files used together in the same subfolder. e.g: Move all the entities speaking files into a Entities/ sub-folder.
Move the game map related files into a GameMap/ subfolder, ...
Of course, certain files would remain in source/ but I think it could help making links between files when coding.
What do you think?
