On Jan 4, 2008 9:19 PM, Tyler Nielsen <[EMAIL PROTECTED]> wrote: > Well I missed the e-mail on the 29th. But I finally got around to looking > to it, and as you said, you fixed it. That said, there are a couple things > I noticed. Is cmake the 'supported' way to build? If so, I had to add > libpthread and libutil to worldtest to build it. I'm not sure the correct > way to add this, so I didn't commit anything.
I'm not so sure about the CMake build ... I only really use it on the windows box (which is broken right now, although I still have a working setup on my work laptop. However, since I'm back in Germany, I usually leave that in the office.) That said, I didn't use CMake much for a while, so it might well be missing some libs. Possibly these are dependencies of other libs, like SDL, as we don't use pthreads directly. I did use CMake to create project files for XCode a while ago, and those required manual tweaking too. So for now, CMake is mostly useful to produce windows binaries (where I had troubles getting autotools working), but its not the recommended build tool on other platforms. Maybe Joel or Alex can have a look at that some time. Also, with autotools I can run make dist and get a working tarball for distributing the source code. The CMake build doesn't have that functionality yet. > I tried to run gfxtest and I'm missing crono.png. Not sure what the state > of this is, so it may be known, or may be obsolete. gfxtest hasn't been touched in ages, so that's to be expected. I imagine it would need some of Alex' data files. Nothing to worry too much about right now, however. > If there are any other tasks that you want done, I should have some time > this weekend. i'm not sure what the next few steps are/should be. Depending on how much time there is, maybe you could improve the animation/image cache. I.e. move it to its own class, implement reference counting and some way of cleaning unused images (either automatically, or when calling a clean method). This will be something we'll definitely need once we start having bigger maps with many different objects. If you are looking for something that is more visible to users (and possibly also needed earlier than the improved caching), I'd suggest the GUI/Widget module (http://adonthell.berlios.de/doc/index.php/Tasks:Widget_Set). Although that's certainly a long-term task and not done on a weekend. Here I basically see two possibilities: 1) continue with what Joel has started (src/gui/), maybe reusing some of v0.3s GUI code too. 2) integrate an existing GUI library. A possible candidate might be CEGui (http://www.cegui.org.uk/wiki/index.php/Main_Page). I haven't evaluated it very thoroughly yet (so that would be the first step), but the big benefit I see with that one is that is does not depend on a specific media library. Instead, it provides a couple interfaces for the actual rendering that could be implemented in terms of Adonthell's gfx module. (There are also some default implementations for OpenGL or CrystalSpace, etc.). I see this as a big plus over similar GUI libraries (which are implemented on top of SDL, for example). Those would not integrate very well with our abstraction layer on top of the actual media library. Moreover, CEGui is customizable using XML files (although to me that looked like a major undertaking). Not sure what to make of the fact that CE stands for "Crazy Eddie" though ;-). If all that is not to your liking, just have a look at the task list (http://adonthell.berlios.de/doc/index.php/Tasks:Contents) or road map (http://adonthell.berlios.de/doc/index.php/Tasks:Road_Map). There are tasks with dependencies on stuff like the collision (or the GUI), but others could be implemented now as well as later. Let me know if there are questions regarding a specific task. Kai _______________________________________________ Adonthell-devel mailing list Adonthell-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/adonthell-devel