Upgraded 2 computers from 32 bit linux to 64 bit. Reason being that I had gotten to the point I had to build everything because of no packages available. Problem now is my 3d game engine is running at half speed. Not good! But, I'm moving forward now on ORX for 2d game play and have high hopes for good results. I look forward to discussing progress with you folks. You're a great community!!
I'm glad you made that choice, and, let me write it one more time: do not hesitate to ask anything on the forum. There's nothing worse than feeling frustrated when being stuck, especially when sometimes all it takes is a simple advice from other users.
Best of luck with your 3D engine optimization, I'm sure it'll be something trivial as I can't really think of any good reasons to lose half the performance when going from 32 bit to 64 bit.
However, as we speak, Knolan is working on one that looks rather promising. Maybe you can poke him directly if you want more info.
2D football game as in US football or soccer? At least, the term brings back sweet memories of Sensible Soccer and Kick Off.
I am using kivy for the UI interface. It uses python and my positive experience on python portability is probably the main reason for choosing it.
If you want to have a taste, here is what it looked like on april (really old stuff, it has multiple selection and undo/redo right now, for instance):
Here is a video of the collision edition (which right now would only be useful for top down games):
There is still quite a long way to go, I need to finish the sprite loader (probably next week or so) and then the layers module to get it ready for an alpha.
PS: If you want to create something with udp, take a look at enet, pretty good library.
Regarding the UI approach, there's a 4th solution which would be the one I'd take were I to work on orx full time one day: do it inside orx.
I actually took a quick stab at a somewhat functional level editor called ScrollEd that came with a convenience wrapper called Scroll that I use for all my own projects. Scroll is simply a few C++ include files, nothing pre-compiled, and the editor is optional.
What I enjoy the most with Scroll are shortcuts like easy C++-class-to-config-section binding and object-related events wrapped within virtual methods.
I posted a quick "doc" on this forum about Scroll but my search-fu is failing me at the moment, sorry. Maybe someone else will have the link handy.
Acksys also started a couple of tutorials on Scroll on the wiki:
The code itself is in its own repository: https://bitbucket.org/orx/scroll
More generally, there are also some good information on the orx-dev google group, mostly about new features that have been added recently and not yet documented on the wiki or enhancement proposals.
Here's some reasoning behind Seduce (the UI part of his tech): http://www.quelsolaar.com/technology/seduce.html
And here's an old video showcasing some of the principle behind it:
Right now the whole editor is sitting in about 5.4k lines of code (I am refactoring the resource module, which means some files are going to die soon and the count will drop), so it is a bit late for a restart.
Also, looking at the video, I have achiev this sync feature by using a file based communiction in the editor, in a very experimental effects editor. So you would have an orx application running in a window and the editor in the other window and the changes were live. It is a little resource consumer, but it ran fine in the core2duo 8400 that I have in my work.
I dream one day the editor may have live edit and debuging integration, but right now I think I should keep my feet in the ground and focus on releasing an useful tool for the community.
As for the debugging, we should be able to devise a way to do that if you want. Probably based on some remote procedure call, maybe based on commands? Commands can be executed from the console and timelines, it should be easy to execute them from a network connection. That could be a first step toward game introspection.
I could have used a socket based protocol, but it would be less portable, so I decided to try with files.
As for the current state of the project, I am finishing the resources module, which is meant to let you open sprite files (i. e.: http://opengameart.org/sites/default/files/wateranimate2.png) and mark the parts you want to load in the editor (think of a much simpler version of the darkFunction editor). I finished the UI today, so it probably won't take long to get it done.