guyver6

Then you have to tell me how did you managed to compile CEGUIPython . And I have to look at Ogre a lil closer, since there were some changes to things we do with RenderWindow in OgreSystem...

I hope so too . We'll see in coming months Az: I was the one responsible for washing dishes. Nothing important

Last week I've spend updating dependencies in C++ branch (trunk actually). First of all, I've added all needed libraries so you don't have to download 3rd party package to get up to speed. That is, dependencies directory contains: - Log4cxx, SVN head - Xerces-C, 2.7.0 - FMOD, latest one - DirectX9, only needed stuff to compile Ogre, February 2007 Update - ZLib (DLL version, official one) - ZZipLib, 0.38.something - FreeType, latest version - FreeImage, latest version - SigC++, latest version These makes it easy to compile all dependencies out-of-the-box (the dependencies solution). There's still one thing missing, Boost 1.34.0, but I don't think adding it to the SVN is that good idea. Before I started the packages update, I looked at which Boost libs we're actually using, to try to strip it, but from 35 MB of header files I was able to cut it to 32MB... then I decided to pack it with 7z and that's how it's gonna be uploaded to SVN. But I'll do it tomorrow evening cuz I'm not at home till then. Oh, one more thing. Due to unknown changes to CEGUI, CEGUIPython no longer compiles, hence Xenocide no longer works (I removed ScriptModule creation from code). I thing Xenocide will only benifit from the CEGUIPython removal.

Hi all, First of all sorry for letting you all down with my departure, but back then I thought it's "the next step" (getting a job and moving on). I was wrong as I know it now (The Job for which I left you all is going to change veeeeery soon, like at the end of June), and now I know how much I've lost not being with Xenocide for so long. Anyway, my bad, I'll try to fix as much as I can. The good thing is I now have the needed experience to see what I did wrong with "the Stackless branch" (and no, there ARE some good things I did with that branch ). What I'd like to do, you may ask. Well, I'd like a task from Dteviot. But not an ordinary one, my leader . But let me explain some things first. I've seen XNA branch, I compiled it, got it to work and well... Well, it rox in few fields, like I can build up a base, I can place facilities, I can smash them if I don't need them, I can call an interceptor to kill that nasty UFO, etc. And I was disappointed about the looks. I'm half-an-artist (playing guitar, knowing how to model simple things in XSI, photography, singing), and my artistic part of soul screamed at what I've seen. Then I decided "heck, I'm a coder too so I could go and do something about it, make a nice earth, etc."... So I started to go deeper into codes of XNA and what I see is bearly a Framework, a "Game Software Factory" as MS should call it, that for sure provides basic mechanisms to go on with creating Tetris clone and makes it easy to use IoC concepts (which in turn makes code look sleek and shiny and easy to understand), thou it does not provide any eye-candyness out-of-the-box. More over, there's no Linux nor Mac support. No MAC? (as an explanation: I've bought myself a MacBook Pro and one of the things I'm gonna try to accomplish this weekend is running C++ xenocide on it ). But there is so much good things about XNA! Gosh, working bases, working crafts, actually you can feel the UFO: Enemy Unknown gameplay! And is blazingly fast to code C#. I know something about it. I did C# for the last 8 months. That's amazing language. So, the conclusion of all of this is I want to resurrect C++ code if Dteviot agrees, forget python for a while and build a framework XNA-alike. Here's my proposal: XNA branch implements models and logic, while I'm getting up to speed with C++. What that means? My feelings: 1. Rip out CEGUI Python, since it won't work the Model-View-Controller way (actually what I've learned about MVC and Model-View-Presenter is that the Controller/Presenter part is highest in the hierarchy, which means that's the part that could be easily done in Python, not the UI - View, nor Model) 2. Redesign the Graphics module again, to meet the new requirements (I'm working on them ATM). 3. Isolate MVC parts as they should be. 4. Check if we can do logic/controller part in python, if not, make a framework for it in C++. 5. Check if we can do AI in python, if not, leave python only as a Console commands interpreter. Oh, and I want Xenocide on Mac soon . More to come soon... Stay tuned (and rant me below). Guyver PS. I see XNA as a prototyping project for Model and game logic. Resharper makes refactoring a breeze, while refactoring C++ can be cumbersome, so if XNA prototype is working and looking good then it can be moved to C++. The good side of this is not having to work heavily on graphics part and engine part of XNA branch, that frees Human Capital of Project Xenocide to design and test gameplay solutions before they get dressed in C++ + Ogre + CEGUI. That's my view of the thing.

Just wanted to say I'm trying to get back on board. I should post something meaningful today on PRG forums. Till then check SVN

And why we're not using that already? Cuz I can't remember any discussion about that we should use Listbox instead of ItemListBox... I know ItemListBox is a lot better so use that one.

Put #include at the end of "Dependencies Headers" section in xenocide/base/baserequisites.h. You can then also add that forward declaration in xenocide/base/types.h, with other forward declarations from Xerces. Or maybe there's a .h file in Xerces that has forward declarations already (Ogre has one in example)?

We could take make a use of background loader that comes with Ogre Eihort and loads stuff in another thread, that could show XNet window in a matter of a blink of an eye (just loading the layout), and then, the rest could be done in background (reading xml entries and creating menu, then show it when it's ready and leave it in Ogre's memory manager until there's not enough mem for other things). Just a thought. Needs researching (as everything)

To tell you the truth I'm researching for some time ways to do such prototyping in Python. That is the best way to do things right in Xenocide code. Yes, the reason is to make it easy to build Python extensions. Remember we're not a Python extension. We embed Python to do some work for us and that's a higher level of Python usage. Python is designed to be a stand-alone language, while ie. Lua or ActionScript are designed to be embedded. We're doing advanced stuff with Python right now, lots of code there is was really hard to come up with and some of it isn't even documented in Python APIs. I think that qualifies us a little higher than a simple extension that can use SWIG or boost to quickly expose some C/C++ functionality to Python. Anyway, since I really like researching these days, I'm almost certain that we could come up with some macros + templates magic that could help with advanced exposing capabilities easily enough (== easy templates and not much work). That would eliminate lots of hacks and workarounds there are now in boost::python binding (in example singletons... now you have to write SingletonClassName() to get it... very inconvinient, or that auto-completion, which could work a lot better with properly constructed new python types).

Just as Reist said, we're surely not interested in PyOgre, I actually used PyOgre as a base for creating CEGUIPython (PyOgre has CEGUI exposed, but very clumsy and it's more of creating an environment to build UI in PyOgre, not to script UI, that's why CEGUIPython uses only a small subset of PyOgre; anyway we're more up-to-date than PyOgre), but I don't see much of use for PyOgre. After we introduce the changes we want, usage of graphics module from inside python will be more or less like showScreen('Planetview') addScene('Earth', Viewport(0,0,1,1), -1) so very high level. Just a subset of functionality we'll want to control with UI.

Let me put here some thoughts from todays chat with Reist. <guyver6> The Bad Thing about Boost.Python and SWIG is that each C++ object is wrapped in SwigObject or BoostPythonObject types <guyver6> this makes all SWIG exposed objects look the same <guyver6> as well as all boost objects <guyver6> while The Good Practice should be to create new Python type for each C++ class <reist> does cxx do that? <guyver6> yep <guyver6> but exposing classes with PyCXX is a lot harder <reist> so...is the level of difficulty something like boost < SWIG < PyCXX < Python API? <reist> or am i totally wrong? <guyver6> yes <guyver6> something like that <guyver6> boost is the least flexible <reist> but the easiest to write, unless you start doing more advanced stuff :p <guyver6> yes <guyver6> :) <guyver6> we're surely doing Advanced Stuff kind of things from the very beginning, and I wonder if we've choosen the best tools <guyver6> we're having problems with python all the time <guyver6> first Stackless <guyver6> great thing, coroutines and stuff, awesome at first, but try to debug Xenocide, while main loop is running in the Stackless tasklet context <guyver6> then SWIG for CEGUI, so easy to write, only #include and %include and we're done <guyver6> and since now we have loads of code that goes between those includes in lots of classes and it isn't said that we won't have more of that later <guyver6> boost.python <guyver6> it was a Real Pain to integrate it like it is to Xenocide, just because (nb just like SWIG) it's purpose is to write Python Extensions, not embedd python <reist> i see <guyver6> the truth is that those that integrated deeply with Stackless (I'm thinking Eve right now) did it through their own layer and have prepared ALL objects and classes to use python <guyver6> their method signatures look just like that: PyObject* Object::something(PyObject* self, PyObject* args) <guyver6> in ALL classes that they expose to Python <reist> wow <guyver6> I think we did 2 mistakes: first of all we wanted to "try" stackless when we should decide to "use it" or "not use it", the second mistake is we glued our bindings to our classes, while we should go on and make them Python aware from the very beginning <guyver6> that's why the solution to get out of this "in between c++ and python world" is to clearly say what goes to python and what stays in C++, on the modules level <guyver6> now graphics is in python and in C++, the same model, game and snake <reist> hmm <reist> yeah, seems like that's exactly what we did :/ <guyver6> my proposition is to leave graphics, model, game, snake, base in C++, while put AI and UI and PYOS in python <guyver6> reduce the number of exposed objects by orders of magnitude leaving only needed stuff <reist> sounds like the best idea really <reist> but <reist> what do UI and AI do? what does game do? <guyver6> and create a communication layer, like events queue, to be able to control game from UI and AI <guyver6> UI lets user control a game <guyver6> AI controls model <guyver6> game controls model and graphics <reist> what, audio just sits in a corner and waits for someone to remember it? :P <guyver6> :P <guyver6> hehehe <guyver6> no, Audio is very important <guyver6> but it's easiest to integrate <guyver6> it already can react on events

Fixed in SVN. CEGUIPython had a Bug. Nasty one NOTE: Seems there's another bug in there, try "saving" more than twice without closing dialog. It might be a CEGUI bug though.

Hi, I've got some more thoughts on the GameTime feature. First of all I'd like to isolate some entities that take part in GameTime workings: 1. Update-able objects - this get Update event every frame with real time changed since last frame: onUpdate(Real secs) 2. Tick-able objects - those get Tick event every given game time passes, we need to determine the minimal tick time with which we'll update game objects. NOTE: the Tick concept is in use in strategy games for over an decade, so I guess it's best approach to use known-and-tested technique, this one is also pretty fast and simple to implement. 3. Mixed objects - Crafts belong here, since while flying they need real-time updates which are dependent on game-time updates (the faster we have game time clock set, the faster Craft moves), also we need this one to be pretty accurate for larger game time speeds When I wrote the above it got me thinking and, you guessed it, I'm gonna share with you what I discovered. First of all Object-Oriented concepts doesn't like Mixed things. If something is Mixed, means it's complex, and if it's complex, it can be decomposed into smaller elements. So let's start (I'm doing it while I'm writing, so don't be too picky ). * Craft is the entity and has properties like Fuel, Capacities (soldiers, equipment, weapon slots, max fly height, max velocity, acceleration), HomeBase, Target (can be null), Stuff (items that are in it, soldiers that ride in it, etc.), Damage * Craft can be safely ticked every the smallest tick speed available (that one we'll have to determine, but I guess it'll be like 1 sec or 5 sec, game time of course) while on fly to update Fuel (we don't have to update every 60 ms - that's the longest frame time we'd like to have, if someone thinks we have to then I'd like to hear why) and maybe other properties like max velocity, or acceleration based on Damage, but that's not in our features list - just a proposition * Craft can be safely ticked every game day to update Damage (while repairing in Base) * Craft, when in flight, additionally has: Position, Velocity, Azimuth, anything more? Huh? That's all. Why no destination? Because that's dependent on Target. Position have to be updated on per-frame basis, as well as Velocity and Azimuth. So what's wrong with that? Can you see it? C'mon, Craft needs Position, Velocity and Azimuth only when is flying, and only those need to be updated per-frame. I don't know how for you, but that asks itself to be decoupled into CraftPosition or even ObjectPosition class and connect them 1-1. Wait... We have Geoposition, right? That position of craft doesn't have to do anything special, so Geoposition is enough. Actually Bases need Geoposition also... As well as Sites... Any more ideas? I've run out of mine...

The last step isn't required, we can do the .this programmaticaly in extract_cegui_object(). Also, we need to check in there for errors, ie. check if given PyObject has .this attribute, then if .this is PySwigObject and then return the ptr to CEGUI object. Except for that the name setSWIGWindow looks ugly ;P Make it setCEGUIWindow or setwindow. That should be enough.

A quick'n'dirty reply (I'm at work) Could you write what was the problem with SWIG - Boost.Python you encountered? As to the structure of current usage of Actors and channels and tasklets... We'll need sort of AI framework to build anyway, the Python tasklets is just a way to get nice AI without much work... once the framework is established. UI can also be a lot simplified using reflection abilities of loosely typed language like python. Thou no one has worked on it to simplify that with some form of UI framework. There shouldn't be a need to pass anything from Boost.Python to SWIG, since all SWIG exposes is CEGUI so we can access CEGUI from Python, nothing more.