Stellar Planes (dev thread)

edited July 2011 in Projects - Tools
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.

Comments

  • edited July 2011
    First of all, looking forward to seeing Stellar Planes evolve, it sounds a promising project. :)

    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:
    [Input]
    Combined = KEY_LCTRL # KEY_C
    Regular = KEY_R # KEY_RCTRL
    CombineList = Combined
    

    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. :)
  • edited July 2011
    Thanks for the support both here and on the irc so far already, iarwain/kele!

    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!
  • edited July 2011
    Heh I wish sourceforge/freenode didn't already have a registered iarwain. :)

    So as to test if the actual config data in memory is correct, simple do this:
    orxConfig_PushSection("Render");
    orxLOG("ShowFPS: %s", orxConfig_GetBool("ShowFPS") ? "true" : "false");
    orxConfig_PopSection();
    

    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 ;))
  • edited July 2011
    hmmmh, this is what I got back:
    &"warning: GDB: Failed to set controlling terminal: Operation not permitted
    "
    [2011-07-23 13:15:20] <LOG> ShowFPS: true

    Yet this is what I still see. (warning big screen)
  • edited July 2011
    I tried your archive tonight, using codelite on Win7, and after a few changes, got it working as expected (ie. black screen + FPS displays correctly).
    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?
  • edited July 2011
    Also, I couldn't retrieve the MainMenu.ini from pastebin, so I got the other one and simply added:
    [Viewport]
    Camera = Camera
    
    [Camera]
    FrustumNear = 0
    FrustumFar = 2
    FrustumWidth = 800
    FrustumHeight = 600
    Position = (0, 0, -1)
    

    in order to get the FPS to be displayed.

    EDIT:

    Out of curiosity, have you tried recompiling the tutorials? Do they work?
  • edited July 2011
    I don't think it did. :/

    Build Started
    /bin/sh -c '"make" -j 2 -f "Tutorial_wsp.mk"none'
    Building project:[ 01_Object - Win32 Dynamic Release ]
    make[1]: Entering directory `/media/EXTDAT/arnoud meer/C++/ORX/orx-1.3rc0/tutorial/build/codelite/01_Object'
    gcc -c "/media/EXTDAT/arnoud meer/C++/ORX/orx-1.3rc0/tutorial/src/01_Object/01_Object.c" -O2 -o Win32_Dynamic_Release/01_Object_01_Object.o "-I." "-I../../../include"
    gcc -shared -fPIC -o ../../../bin/mingw/01_Object.dll Win32_Dynamic_Release/01_Object_01_Object.o "-L." "-L../../../lib/mingw" -lorx -fPIC -s
    /usr/bin/ld: Win32_Dynamic_Release/01_Object_01_Object.o: relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC
    Win32_Dynamic_Release/01_Object_01_Object.o: could not read symbols: Bad value
    collect2: ld returned 1 exit status
    make[1]: *** [../../../bin/mingw/01_Object.dll] Error 1
    make[1]: Leaving directory `/media/EXTDAT/arnoud meer/C++/ORX/orx-1.3rc0/tutorial/build/codelite/01_Object'
    make: *** [All] Error 2
    Build Ended
    0 errors, 0 warnings

    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?
  • edited July 2011
    By looking at the log, it looks like you're compiling the windows MinGW version instead of the linux one. :) (Win32... mingw...dll)

    You can change the current build target from within CodeLite (there's one for linux and one for windows).
  • edited July 2011
    Uh. Good point. Still gives me this, though.

    Build Started
    /bin/sh -c '"make" -j 2 -f "Tutorial_wsp.mk"none'
    Building project:[ 04_Anim - Linux Dynamic Release ]
    make[1]: Entering directory `/media/EXTDAT/arnoud meer/C++/ORX/orx-1.3rc0/tutorial/build/codelite/04_Anim'
    gcc -shared -fPIC -o ../../../bin/linux/04_Anim.so Linux_Dynamic_Release/04_Anim_04_Anim.o "-L." "-L../../../lib/linux" -lorx -fPIC -s
    /usr/bin/ld: skipping incompatible ../../../lib/linux/liborx.so when searching for -lorx
    make[1]: Leaving directory `/media/EXTDAT/arnoud meer/C++/ORX/orx-1.3rc0/tutorial/build/codelite/04_Anim'
    Build Ended
    0 errors, 0 warnings

    And upon execution, this. It immediately opens and closes before I can do anything.
    Using gdbinit file: /home/m/.gdbinit
    Current working dir: /media/EXTDAT/arnoud meer/C++/ORX/orx-1.3rc0/tutorial/build/codelite/04_Anim
    Launching gdb from : ../../../bin/linux
    Starting debugger : gdb --tty=/dev/pts/4 --interpreter=mi "orx"
    Debug session started successfully!
    Debuggee process ID: 5275
    GNU gdb (GDB) 7.2-ubuntu
    Copyright (C) 2010 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>;
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law. Type "show copying"none
    and "show warranty" for details.
    This GDB was configured as "x86_64-linux-gnu".
    For bug reporting instructions, please see:
    <http://www.gnu.org/software/gdb/bugs/>...
    Reading symbols from /media/EXTDAT/arnoud meer/C++/ORX/orx-1.3rc0/tutorial/bin/linux/orx...
    (no debugging symbols found)...done.
    Continuing...
    [Thread debugging using libthread_db enabled]
    [New Thread 0xf4f85b70 (LWP 5280)]
    [New Thread 0xf4f74b70 (LWP 5281)]
    [New Thread 0xf4bc3b70 (LWP 5282)]
    [Thread 0xf4bc3b70 (LWP 5282) exited]
    [Thread 0xf4f74b70 (LWP 5281) exited]
    [Thread 0xf4f85b70 (LWP 5280) exited]
    Program exited normally.
    Debug session ended
  • edited July 2011
    Yep, the plugin being not created, executing the launcher won't 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.
  • edited July 2011
    muh. I'm inclined to wait and laze around until there's a 64 bit .deb around, I’ve had enough fighting with my computer already this weekend
    (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)
  • edited July 2011
    Ah, the joy of linux! ;)
    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.
  • edited July 2011
    ok, the svn now has project files and precompiled external libs for linux64.
    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.
  • edited July 2011
    Erm, ok, I'm probably too tired, the segfaults were only me not updating the tutorial include folder. ^^

    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. :)
  • edited July 2011
    Yea, tired coding's probably not a good idea. I'll stay eagerly waiting, then. :D
  • edited July 2011
    Well, everything's ready for you to go on the svn. :)
    I probably won't release any packages for linux64 before the next global release as the code base changed significantly since last release.
Sign In or Register to comment.