Whelp, this'll be the dev thread for my project in orx.
I'm looking to build a 2D rts game with a gameplay that's inspired by the flash game flashtrek
and it's descendants. Long ago I've been meddling it's code with the same intention as I have now, but experience has taught me that I’ll be better off writing a new game from scratch in a new language (Which I’m still learning) than trying to sort out the mess another programmer made in a language which wasn't designed for that purpose in the first place. The extent of this game has long outgrown the interactive animation stage, and I only plan to add to that complexity.
Currently I have cannibalized the code from Grey's Tutorial 2 to provide a first working bare executable, and I'm slapping key imputs in my .ini.
I'm a bit confused about the Combinelist entry. What, and how does it do stuff?
For an example, I'm intending to have a selection behaviour. Lmouse = select, Lshift should be a modifier which allows me to select multiple things.
As for the CombineList, it defines which inputs are actually using all of the physical inputs of its list to get triggered. If an input isn't there, any of the physical input of the list will trigger it. As this is definitely not a clear explanation (morning, no caffein and all that), here's a small example:
Here Combined will be activated only if both KEL_LCTRL *and* KEY_C are pressed whereas Regular will be activated is any of KEY_R *or* KEL_RCTRL are pressed.
That's a bit limitating as you can't define two 2-key combos for the same input name for example, it's either 'or' or 'and' for all the elements of a list (up to 4 actually).
In your case, you can define MOUSE_LEFT = Select and KEY_LSHIFT = Modifier and in your code you can check any combination of these two inputs to do whichever logic you want.
The input module is simply an abstraction that helps you map any physical input (mouse, joystick, keyboard and single touch for now) to abstract input names.
Of course you can get info on the bindings, rebind any of them, create/delete new abstract inputs or even trigger them from code.
I use it as a generic interface between my UI and my logic code, allowing very easy expansion, often without having to change a single line of code (I can add buttons, key shortcuts and info text to any action of the ScrollEd editor by simply changing the config files without touching the code).
Btw, are you interested in trying Scroll?
Scroll is a thin wrapper written in C++ that sits on top of orx and adsd a couple of interesting features such as a built-in level editor (you can even run your game from it), C++ class/config name object binding (ie. everytime an orxobject is created based on config, the corresponding C++ user class, where your logic code resides, will be allocated in memory pools and linked to it; when the orx object is deleted, your C++ instance will be deinitialized and returned to the pool). Those custom C++ objects will then get notified for some events directly via virtual method calls rather than having to add event handlers. Same thing for update.
And a few other things. I actually use it for all my projects instead of orx directly but I haven't released it publicly as I have written any half-decent doc yet.
It's also licensed under zlib and is only a couple of .h/.inl files, so nothing precompiled, easy to integrate. The trade off would be that I'd be happy to get any comments about improvements or bugs so that I can make it better.
Currently on the to-do list:
- Update from eyecreate's 'nix 64 1.2 package to latest svn compile
- Check out, if the update didn't fix it, why my executable only takes viewport, camera and display from my .ini-s.
- Actually add something to execute. Menu items and a custom mouse would be nice for starters.
- Get some sleep. it's 0045 am already, for pete's sake!
So as to test if the actual config data in memory is correct, simple do this:
If it displays ShowFPS: true, it means that the actual FPS rendering is broken on linux64 (or maybe the internal font isn't working on linux64?). Still haven't any Linux64 around so it's hard for me to test.
G'night! (00:45 is often much before I start doing any coding on orx )
Yet this is what I still see. (warning big screen)
Here are the changes I had to make:
- I had to remove all the invalid calls in your Init() and only leave the valid one: orxViewport_CreateFromConfig() (the others don't exist at all)
- Linking the debug version against the debug lib and not the release (liborxd.so vs liborx.so).
Have you tried syncing the SVN? If so, after building the dependencies in /extern (you need: SOIL, glfw, Box2D and potentially libsndfile if your distro doesn't have it), build orx from /code/build/codelite.
If you start the orx binaries, it'll then come with my bounce test (which is also the playground where I test new features). The source's test is in /code/plugins/Demo/orxBounce.c
Just in case: are your video card drivers recent?
in order to get the FPS to be displayed.
Out of curiosity, have you tried recompiling the tutorials? Do they work?
So far I seem to have put out nothing but useless and non-functional code. Useless. Perhaps somebody could give me some hints to make it less useless?
You can change the current build target from within CodeLite (there's one for linux and one for windows).
And upon execution, this. It immediately opens and closes before I can do anything.
Are you using the precompiled lib that comes with the tutorial or the one you built yourself? The precompiled one is 32b and you're compiling for a 64b architecture, that won't work.
If you want it to work, there are two possible options:
- use precompiled libraries and compile 32b code (by simply adding -m 32 on the gcc command line (or is it -m32?)0
- recompile orx's dependencies + orx in 64b. In order to do so, you need to get the latest version from the SVN as otherwise it'll segfault.
(Including, but not limited to: two reinstalls, a whole day without any sound, spending an hour making compiz work properly without the right dependencies, spending another hour making xchat accept the servers i want it to connect to, and in general recreating a whole ^&$#load of settings)
Nothing beats AmigaOS in the end! ^^
I'll make bzip2 archives when I get something working here for linux64 but I'm sure Eyecreate or someone else will be able to make .deb/.rpm files from that.
I removed all the warnings I found but apparently there are a couple of bugs to fix on that platform: most tutorials run fine, for example, but a couple of them segfaults. I'll check that soon.
With the latest includes, everything all the tutorials compile *and* run just fine for linux x86_64. You can sync the SVN repo if you want to try by yourself.
I probably won't release any packages for linux64 before the next global release as the code base changed significantly since last release.