Scroll / Orx and C++, a survey for all orx users

Hi everyone,

This post act as a survey about orx and a "hidden" functionnality. Actually Iarwain wrote something like a C++ wrapper for orx, but it's not released, because of the lack of documentation.

I discuss with him to release this code for you, and I suggest him to explain this wrapper in a post to get your feeling on it. So, you can reply to give us your opinion. Tell us if you want to try it, if you think this is useless, usefull or something else.

I said wrapper, but it's not really a C++ wrapper around orx. I'll try to explain.

First, the name of this project is Scroll.

So, I don't know if you prefer C programming or C++, in my case, I prefer C++ because I use it for a long time.

Scroll doesn't provide an COrxObject, COrxCamera, COrxSound, COrxViewport etc, it's not the kind of this project. It simply manage "object", called ScrollObject. To be simple, here is a description of what Scroll is doing :

- define a central part, called ScrollBase (derived in a class named GameEngine in my case). This is a "singleton" pattern, only one instance. This class manage some objects, called ScrollObject.

- ScrollObject define a lot of methods, for example : Update(), OnCollide(), OnSeparate(), OnCreate(), OnDelete, etc. It's very easy to get the orxOBJECT binded with a scrollobject, so you can use your favorite function on it.

Suppose you have a game, with an object that have a particular behaviour. For exemple, a ball. With Scroll, you just have to implement your CBall class, derived from ScrollObject and bind it with the name of the object in the config file. That's all. You just have to implement your ball in your .h/cpp.

Another big part of Scroll is an editor. You can run your game without the "main loop". You can change camera position/zoom, moving/scaling/creating objects (with a layer functionnality). All of those settings can be saved in a .ini file and can be used as a "level" in runtime. Scroll will load and create/delete those objects for you, so you didn't have to manage all of that by yourself.

For example again, ScrollBase provide some methods like OnMapLoad(), Pause(), and other stuff.

So, it's not really a C++ wrapper. When you implement your object, you have to use all of the orx functionnality. Each functionnality provided by Scroll have a real interest. For exemple, ScrollObject doesn't provide a SetPosition() method, there's no interest. To do that, you have to do something like : orxObject_SetPosition(GetOrxObject(),&vPos) (where GetOrxObject() is a method of ScrollObject)

I tried to do a summary here, it's an easy explanation. It not cover all the power of Scroll.

This post was just to have your feeling about this project. Do you prefer to use orx alone, or do you want to try Scroll ?

I know there're few users of Scroll, perhaps they can add some comments or corrections to my post ;)

And to finish, sorry for my poor english ^^
«1

Comments

  • edited October 2011
    An interesting question and maybe it helps put in my 2 cents, having a reasonably large project in progress that is using orx with c++.

    I do a lot of non-standard things like implementing my own primitive collision detection, generating objects on the fly, using a custom "repaint tiles" method instead of screen scrolling.

    I have also been separating up many things into their own code files to keep things organised, while the main code file controls the updates in each. So the organised custom classes serve well.

    I don't think I would shift to Scroll for the current project. From the examples you mentioned above, I am not sure that it would save that much time. Perhaps for simpler stuff, I'm not sure.

    With all that said, my c++ is not overly strong. But it's from an active working perspective.
  • edited October 2011
    Interesting thread, thanks for starting it, faistoiplaisir.

    I just wanted to add some details:
    - Scroll is a thin layer, ie. it's only a bunch of non precompiled files so it's easily expandable by anyone and even more easy to integrate.
    - There's actually a SetPosition! ;) It's only a convenience wrapper that uses vector references instead of pointers and that allows to set the position locally or globally. So it wasn't probably the best example on that one. ;)

    As for me, I'm not using the editor part of it but I'm still using Scroll for all my projects because I'm lazy. Instead of listening for events and registering update callbacks, I'd rather simply override a method. That and the object management that allows easy linking between orx objects and my game classes. That's about it! =)

    Sausage, I'm also using a tiled rendering for a project I recently started so I guess it's not that uncommon for an orx use. ;) I couldn't find any other easy and efficient alternative that would allow me to emulate the ZX Spectrum color bleeding for people who don't have shader supports.
  • edited January 2012
    Guys, where can I get a copy of Scroll? I couldn't find it anywhere.
    I would love to try it out for my current game project.
    I actually was about to write my own C++ wrapper but if Scroll is already there then why would i bother? I could probably add something to Scroll underway..

    Thanks,
    Alex
  • edited January 2012
    Hi Alex and welcome here.

    You can get the most recent version here, including some instructions on how to use it in the forum thread. Let me know if you have any questions/suggestions.
  • edited January 2012
    Hi Iarwain!
    Thanks a lot :)
    I will try to combine Scroll and the iPhone demo.

    Cheers,
    Alex
  • edited January 2012
    My pleasure! Let me know if you encounter any issues with Scroll + Obj-C. Have yet to try the combination myself. ;)

    Cheers!
  • edited January 2012
    Iarwain, I ran into problems :)

    So i have a working iPhone demo without any objects but with Scroll. It just creates a viewport (had to rename Viewport to MainViewport in the config). Then it runs and calls the Run method all the time.

    I tried to add a "player" object:

    [Player]
    Graphic = FullGraphic
    AnimationSet = AnimSet
    ...

    and in code i have this:
    BindObjects:
    ScrollBindObject<player>("Player");
    OnStartGame:
    CreateObject<player>("Player");

    However, it fails inside the orxObject_GetName(const orxOBJECT *_pstObject) function.
    In particular this line fails with "_pstObject == NULL": orxSTRUCTURE_ASSERT(_pstObject);

    Any ideas?

    TIA,
    Alex
  • edited January 2012
    Hi Alex,

    Ah well, where would be the fun if you hadn't run into any problems? :)

    At first glance, I'd say it might be a debug/release mixup. That happens when defining __orxDEBUG__ and linking with the release lib or when not defining it and linking with the debug lib.
    Could it be what happened on your side?

    Another possible issue would be that your config wasn't loaded properly, either not loaded at all or inside a file saved with non UTF-8 unicode (in which case you'd get an error message in debug if you're using the SVN version of orx and not the 1.3rc0).
    Actually, I assume you're using the latest SVN as this version of Scroll is unlikely to work properly with 1.3rc0 which is over 9 months old now.

    Lemme know if you get more info.

    Cheers!
  • edited January 2012
    Oh actually, did you rebuild the iOS library with the SVN version? Any precompiled binaries you could get from any source would probably be outdated.
  • jimjim
    edited January 2012
    Hi,

    I am ready to give Scroll a try if it is recommended for beginners.
  • edited January 2012
    Iarwain,

    Thanks for your reply.

    Yes I rebuilt everything from subversion. Basically I took your iPhone demo from svn and stripped it down to an empty orx-on-iphone project. Then I added Scroll headers and created my simple game class and some ScrollObjects (character, player). I think you might be right that I have a situation with release game running debug library. I will check that tonight. However, would a debug build of orx library even show a coloured screen at all? I though it would crash at startup.. But I had a coloured viewport visible on iPhone! The problems started when I added the Player bit.

    Anyway I will check your assumptions tonight and report back.

    Cheers!
    Alex
  • edited January 2012
    For those of us wishing to experiment with Scroll (and understanding that documentation and support are limited for now) is there SVN access or should we just separate it from the MushroomStew solution posted above?

    Thanks.
  • edited January 2012
    Iarwain, your assumption was correct. Setting both orxLIB and orxTest to Release helped.
    I will try to code something meaningful and report back if anything goes wrong :)

    Thanks!
    Alex
  • edited January 2012
    @godexsoft, I'm glad that was it, easy fix! ;) As for why it wouldn't crash before, it only really matters for orxSTRUCTUREs as we do some *salted* type check using a magic number (0xDEFACED0) in Debug only whereas in Release we do the type check directly (saving the salting instructions) and assuming that any memory corruption would have been caught in Debug.
    When a Debug/Release mismatch happens, the grain of salt (huhu) breaks the whole thing. :)

    @acksys: I'll setup a temp Hg repository on Bitbucket for now as I still don't know if I want to host orx and scroll under the same roof.
    When I'm done with the 2D skeletal anim system (yes, I very recently started to work on it again after months), orx will probably turn 1.4 and get hosted with Hg either on Bitbucket or GoogleCode, haven't settled on which one yet. I'll then take the decision if I reunite orx/scroll in the same repo or not.
  • edited January 2012
    Iarwain,

    Now when i have a bunch of objects with animation working i have many more questions then i thought i would :(

    1) So i have my player object. In the config file, Player has some animations which I need to turn on/off at some point. The only way I found to do this is:
    orxObject_SetTargetAnim(player_->GetOrxObject(), "Walk");
    This looks like a really dirty hack to me. I would expect a way to inform the player that it should change animation. And indeed, there are a couple of virtual methods: OnNewAnim and OnAnimEvent. But how do I trigger them?

    2) Sound is not working. I couldn't find any sound code in Scroll so i did this in OnStartGame:
    bg_music_ = orxSound_CreateFromConfig(orxConfig_GetString("Music"));
    if(bg_music_)
    {
    orxSound_Play(bg_music_);
    }

    This code used to work without Scroll but with Scroll it won't work for some reason. Maybe this code belongs in Init though. Didn't check.

    3) How do I capture input?
    I don't mean keyboard because I'm on iPhone. I know that the MOUSE_LEFT event works as a touch but how do I actually detect a tap on some orxObject (or better my ScrollObject subclass). I have an onscreen "pad" with two buttons. For each button I have a ScrollObject. All I want is some way to get notified inside the button class that a touch happened.

    Thanks for your time :)

    Cheers,
    Alex
  • edited January 2012
    godexsoft wrote:
    Iarwain,

    Now when i have a bunch of objects with animation working i have many more questions then i thought i would :(
    Happens! :)
    1) So i have my player object. In the config file, Player has some animations which I need to turn on/off at some point. The only way I found to do this is:
    orxObject_SetTargetAnim(player_->GetOrxObject(), "Walk");
    This looks like a really dirty hack to me. I would expect a way to inform the player that it should change animation. And indeed, there are a couple of virtual methods: OnNewAnim and OnAnimEvent. But how do I trigger them?

    There's currently no wrapper for accessing anims on a ScrollObject but they're easy to add.

    OnNewAnim is where you get notified when your ScrollObject is playing a new animation, letting you know if the previous anim was cut or not.
    OnAnimEvent is where you'll get notified of encountered custom event (ie. the ones defined in config).
    2) Sound is not working. I couldn't find any sound code in Scroll so i did this in OnStartGame:
    bg_music_ = orxSound_CreateFromConfig(orxConfig_GetString("Music"));
    if(bg_music_)
    {
    orxSound_Play(bg_music_);
    }

    This code used to work without Scroll but with Scroll it won't work for some reason. Maybe this code belongs in Init though. Didn't check.

    Scroll doesn't wrap any sound code as they'd be the same as orx. I've only done convenience wrapping or added new features in Scroll but I'm still using calls to the underlying orx API as I didn't want to clutter too much Scroll's API. That being said, it's totally possible to entirely wrap orx in Scroll if someone has the patience to do so. :)

    OnStartGame should be called after the init phase, so I'm not sure why it's not working in your case. Are you in the correct config section, just in case?

    Also, I personally avoid doing calls to the sound API when I can. For music playing I simply define in config a BackgroundMusic object that will play the music for me when created. I usually then add this object as a child of my scene, add it using the level editor or create it programmatically when loading the level.
    However it's simply a matter of taste, there's nothing wrong with using the sound API, it's just that I like to use the object as wrappers as much as I can.
    3) How do I capture input?
    I don't mean keyboard because I'm on iPhone. I know that the MOUSE_LEFT event works as a touch but how do I actually detect a tap on some orxObject (or better my ScrollObject subclass). I have an onscreen "pad" with two buttons. For each button I have a ScrollObject. All I want is some way to get notified inside the button class that a touch happened.

    I usually call Scroll::PickObject in my game loop and then forward call a method of the class Button if the ScrollObject is of the right class (or you can extend the ScrollObject interface with a virtual method if you'd rather).
    Lately I've bypassed this by simply using the config and input modules:
    - I pick the object using the mouse's world position
    - I push its section and look for an Action attribute
    - if found, I'll then activate the matching input with orxInput_SetValue(orxConfig_GetString("Action"), orxFLOAT_1);
    - I simply handle the input within an event handler, that allows me to easily add other way of activating a button (like keyboard shortcuts when debugging on PC) by simply modifying the config and not touching the code.
    Thanks for your time :)

    Cheers,
    Alex

    My pleasure! Let me know if some of my answers weren't very clear. :)

    Cheers!
  • edited January 2012
    iarwain, thanks, it'll be great to be able to check it out.
  • edited January 2012
    Iarwain,

    Thanks for your detailed explanation. I got most if it working and even extended Scroll to support SetTargetAnim and OnInput. I also fixed my sound problems.

    Now I need to know how to handle multitouch input. Is there a way? I thought MOUSE_RIGHT would do the trick but no luck :-)

    Cheers,
    Alex
  • edited January 2012
    Hi Alex,

    Yeah, I only plugged MOUSE_LEFT for single touches, but I could potentially plug all the other touches on MOUSE_RIGHT, MOUSE_MIDDLE, etc... even though they won't cover all the touches.

    As for getting the multitouch info, it's not yet completely unified, so it's a bit different on Android and on iOS. Both will send you the same events (orxSYSTEM_EVENT_TOUCH_BEGIN/_MOVE/_END) but the payload will be different. On Android it'll be orx-defined values whereas on iOS it'll be directly the NSSet containing all the touches.

    I'll try to unify that soon-ish, probably within a week or two.

    You can find all those info in code/include/core/orxSystem.h
  • edited January 2012
    Hi Iarwain,

    Oh wow it's good to know that touch_begin/end events are available! At this moment I'm trying to compile my stuff for android so it's really good timing to know about this differences now :-)

    As you are yet to unify stuff I will add my 50c with a small request: When you will have unified structures to transfer touches into orx, don't forget to add the timestamp (hardware touch timestamp) to that structure as in some games (rhythm games for sure) it's crucial to get the real timestamp of the event even though the actual event may occur with a delay (milliseconds are important!).

    Thanks,
    Alex
  • edited January 2012
    @godexoft, see related thread: https://forum.orx-project.org/discussion/2488#Comment_2850

    I have an interest in this also and faistoiplaisir was a good help in the other thread.

    My designers have said we don't need multitouch for the current project, but I have a suspicion I may be required to implement it before release :D
  • edited January 2012
    Thanks for the suggestion, Alex. I don't know what's available on the Android side but I'll check with faistoiplaisir. I know there's a pressure param on Android but there's no pressure afaik on iOS, so it'll me maxed out all the time.

    Also, I'll need someone to test the modifications for me as I can't test on iOS devices right now.
  • edited January 2012
    Iarwain, I can help you test. Just shout when code is ready. Add me on skype for better communication speed: godexsoft

    Cheers,
    Alex
  • edited January 2012
    Thanks for your help. I don't use skype though, but I'm on gtalk most of the time if that can help.
  • edited January 2012
    Hi again!

    Well, so I wasn't really awake 2 days ago. There's a good reason why only MOUSE_LEFT is plugged on the touch event right now: a mouse can only have one position whereas each touch has its own position. The workaround this would be to support more than one mouse, in the same way we support more than one joystick.
    It can be done but it's not on my short term todo list.

    That being said, I'm on my way to the touch event payload uniformization. :)
  • edited January 2012
    Ok, the new unified payload for touch/acceleromer events has been added + iOS implementation.
    NB: for now it won't compile on Android till faistoiplaisir has the opportunity of updating that version.

    That should probably be resolved before a day or two. No pressure, faistoiplaisir! ;)
  • edited January 2012
    Ok Iarwain, it's done :)

    But the work is only done for android 'non-native' (the one that use the NvEvent framework).

    For now, if you want to compare the timestamp provided by the payload, you have to compare it with orxSystem_GetTime().

    In another post, about the multitouch, I sent a Multitouch.zip file including a TouchManager class. I use it in my actual game. This manager provide a "bIsActive" and "bStatusChanged" member for each touch. In addition, you can now check the pressure and the timestamp.

    So, in case of you use this touch manager, you can get the new version here (supporting the new payload). https://forum.orx-project.org/uploads/legacy/fbfiles/files/TouchManager.zip
  • edited January 2012
    Thanks!

    Do you think you could have a look at the native part at some point? No rush though. :)
  • edited January 2012
    Hi,

    I took a look at the native version. I think it's easy to do. Similar methods are available in Java and Native API.

    But, since I never compile myself the native version, and because I don't use it, I think I don't do that quickly.

    But If someone need that immediatly, I can do an effort :)
    If no one need it immediatly, it can wait ^^

    In the futur (probably my next game) I will use the native version. In this case, I will change that to support more than one touch (for now, I confirm, the native version manage only one touch).

    So, just be patient ^^
  • edited May 2012
    For everyone who interested in Scroll, I am working a series of tutorials on getting started. The first one (basic setup) is finished and is available here: http://orx-project.org/wiki/en/orx/tutorials/community/acksys/scroll0

    The second tutorial (object binding) is in progress and should be finished soon.
  • edited May 2012
    I think I might actually use this. I started a new project in C++ using vanilla orx but that object binding thing and the map editor sound good enough to give it a try.
  • edited May 2012
    Just reading this, it may be useful to make an ini editor in general of sorts, where you can determine and see in real time the original image and animations, then it just poops out ini files...

    I may try this after i've ported B0UNCE.
  • edited May 2012
    My first two Scroll tutorials are now available on the wiki:

    http://orx-project.org/wiki/en/orx/tutorials/community/acksys
  • edited June 2012
    Never mind.

    [Iarwain edit - The question was: where could one find the latest version of Scroll?]
  • edited August 2012
    In case others have the same question, here's the link to the bitbucket repo which will always have the latest version of Scroll: https://bitbucket.org/orx/scroll
  • edited September 2012
    Dear nice Orx community!

    (Note: The following is not a criticism of Orx itself at all, but rather a discussion of the limitations of C. I'm actually amazed (again and again) by how iarwain managed to build such a nice architecture on top of pure C!)

    I would also want to express my deep interest in Scroll. I naturally wrap every C function with a C++ mindset before I use them. I feel like cleaning a toilet with bare hands whenever I type cast a void pointer, or check an "int" property against a set of "int" constants (instead of using enumerations, which eliminates the risk of comparing apples and oranges). There's also the whole story of having to remember to undo something at the end of a function that you've done in the beginning (push/pop section f.x.), so anything that's already in Scroll is less code (and less checking documentation) for me.

    I hope one day we get to wrap all of Orx in Scroll. I really like how ScrollObject works, and I wish we had similar wrappers for everything.

    I'm sure C++ lovers like myself are already doing a lot of wrapping on top of Scroll and it'd be great if we shared the effort. This way, we'll have less bugs, less boilerplate code and more portability.

    Cheers!
  • edited September 2012
    Hi enobayram,

    I was playing around with Scroll and Orx quite a bit and I really liked the ideas behind the engine and how you could bind config types to custom objects with Scroll. I didn't like the need to fallback to plain C often though so after fighting myself for some time I couldn't take it and wrote my own version of orx from scratch and in modern c++. It's opensource and though still in development it provides quite a bit of tools (basics, xml-based configuration, box2d physics, lua/luabind integration and object scripting, events and listeners, zones/contexts and triggers, animation system, fonts, prototypes, etc.). I really love orx but I just can't live with a constant need to fallback to plain C code in a nice C++ environment (hi Iarwain).
    At the moment I'm crosscompiling my stuff to android (already have basic physics/lua demo working on my htc). If you want to check it out (you too, Iarwain ;) ) feel free to visit the outdated doc (http://x2d.7bit.co) or the github project (https://github.com/godexsoft/x2d).

    Cheers!
    Alex
  • edited September 2012
    This is blasphemy!!!

    :) Just kidding obviously. That's an amazing undertaking. I'm really curious as to why you've gone as far as developing orx from scratch. Did you try wrapping it first? What was the problem with wrapping it(I'm asking because that what I would/will do and would like to know the problems ahead).

    I'm looking forward to taking a look at what you have there, as soon as I have the time, but I must say I'm a bit skeptical about just throwing away all that's built around orx (and orx itself).

    Cheers!
    Enis
  • edited September 2012
    Oh I'm not suggesting to throw away orx and use my engine! Orx is great and if you already got it working then you definitely should stick to it :)

    As for my effort and decision there are several things I had in mind when starting x2d late january:
    1) Orx didn't work right for me. It gave me tops 30fps on an iPhone4 with a very simple game mockup (20 sprites on the screen). Me and Iarwain were looking into it and both couldn't find why it was happening. As I understand now it had to do with retina support and downscaling to older iPhone screen size (320x480) using the retina screen size as the physical one. Basically, I guess that orx was doing what should be done by iOS itself and was doing it wrong somehow.
    2) I really like to gain deep understanding of everything I try to learn. Writing my own engine was the best way to understand how stuff works in orx. For the same reason I wrote my own cross-platform boost::asio several years ago :)
    3) No fear. Its been ~8 months since I started x2d and most of the time I was busy with my daily work in my startup. Unfortunately we don't develop games and don't develop game engines in my startup.. however my real passion is in gamedev.

    And I didn't really try to wrap orx myself. I used Scroll from the start and I simply didn't like some stuff in it and how it's done. I don't say my engine is better though.. just it's mine and I know exactly where, what and how is happening. Also my memory management is based on boost::shared_ptr and RAII where possible.. i can't live without it :)

    No matter if you like or hate x2d, C+C is really welcome! :)
    Thanks in advance.
    Alex
  • edited September 2012
    And sorry, I forgot to mention. Obviously it's been a long while since january and I can't remember everything but here are some key differences:

    1) Config system is XML vs. INI. This allows nesting and hierarchy. Apart from nesting x2d provides namespaces in XML configs.
    2) x2d uses a virtual filesystem (zip with 0 compression) and all resources live inside one or more archives which you mount to a path: lvp_man.mount("resources.zip", "res") for example will open a 'filesystem' archive and mount onto a virtual 'res' drive. in the config system you can access stuff like this: path = "res/graphics/spritesheet.png" etc. This allows for really easy skin/theme support oob. as you can mount and unmount in runtime :)
    3) A plugin system (WIP) allows you to extend configurations (xml) with custom stuff. Note that these are compile time plugins, not shared libraries. For example there is a (mockup) plugin called x2d_ui which adds labels, buttons etc. into the mix.

    There is probably more but I can't remember :)
    Cheers
  • edited September 2012
    x2d looks/sounds really nice, you've got me even more interested. As a side note, I'm also experiencing performance issues on Android with Orx, but until now, I've assumed that it's something wrong that I'm doing. I'm curious whether the iphone performance issue is solved on Orx in the last 9 months since you've tried, or whether what I'm experiencing on Android is the same. Do you plan to ever support PC with x2d?
  • edited September 2012
    At the very begining of x2d i had xcode compiling and running stuff on my desktop mac but i guess you meant windows by pc. For windows support i think i would need to implement a directx driver and use proxies everywhere. I'm sure orx does a great job there.
    Originally i wanted to support multitouch input at the core of the engine and thats what i have now. So instead of simulating multitouch thru mouse input i can emailate/support mouse input thru the multitouch core:)
    I'm mainly interested in mobile gamedev though so unless someone will help me to build the pc framework i doubt i will spend time on that..
    Obviously orx is much more mature and i suggest you stick with it unless you really want to target mobile only with the benefit of modern c++ all around the place:)
    I guess i should open a forum for x2d where people could post their ideas and suggestions...:)

    Cheers!
    Alex
  • edited September 2012
    enobayram wrote:
    I would also want to express my deep interest in Scroll. I naturally wrap every C function with a C++ mindset before I use them.

    That's an interesting topic! To me, most of the time, a pure 1:1 wrapping only implies syntactic differences, ie.
    orxObject_GetName(MyObject);
    
    vs
    MyObject->GetName();
    

    The C++ one has the advantage to be shorter, while the C one has the advantage to explicitly reference the interface. I guess it boils down to a matter of preference in this case.

    However I wrote Scroll in C++ for a couple of very simple reasons:
    - I needed template meta-programming as macros where not powerful enough to embed the editor in any game with the ability to run the game from inside the editor.
    - Needed templates for managing objects via the factory in a cleaner way than C would have allowed me to.
    - I needed inheritance for objects as handling events is definitely verbose and annoying, while still keeping the overhead as small as possible.

    That's about it.
    I feel like cleaning a toilet with bare hands whenever I type cast a void pointer
    .

    Well, hopefully you don't have to do that often, if at all, beside event payloads. :)
    , or check an "int" property against a set of "int" constants (instead of using enumerations, which eliminates the risk of comparing apples and oranges).

    That's not a C/C++ issue there, enum are present in C as well. They're actually extensively used in orx except for flags which is probably the cases you reference, isn't it?
    The issue with enums is that their definition in C/C++ can't be partial. That means if you want to keep a set of flags private and a set of flags public, you can't do it cleanly.
    Hence the use of plain old un-typed numerical values.
    There's also the whole story of having to remember to undo something at the end of a function that you've done in the beginning (push/pop section f.x.), so anything that's already in Scroll is less code (and less checking documentation) for me.

    Well, Scroll does it behind the scene. It's more convenient but it's also more costly as you might not have needed to push/pop a config section in the first place.
    But even in a wider context, such as C++ RAII, symmetry is most of the time a good practice, and symmetric code is much less prone to any memory leakage, for example.
    I hope one day we get to wrap all of Orx in Scroll. I really like how ScrollObject works, and I wish we had similar wrappers for everything.

    This is going to be a daunting task, I think, but why not! :)
    I'm sure C++ lovers like myself are already doing a lot of wrapping on top of Scroll and it'd be great if we shared the effort. This way, we'll have less bugs, less boilerplate code and more portability.

    I'm curious about the portability statement here, I can understand the first two, but this one eludes me.

    And now a quick reason why I think wrapping is a good idea but rewriting isn't. C++ has many many more caveats than C, and some of them are pretty subtle (scope resolution not using mangled symbol name, sneaky operator overloads can lead to disastrous results (operator->, operator(), operator[], operator,, operator!, operator~, ...), virtual methods called from within a ctor or dtor are not going to yield the expected result, they'll crash for pure virtual methods but not for regular virtual ones, which is very sneaky and hard to track, variables declared in a for statement has a different scope depending on which C++ standard you're using, ...).

    Bugs created by such issues are usually very hard to track and I think that's a big reason why a lot of low level libraries/middleware are still sticking with C.

    All those are probably fine when you work by yourself, but for a project where you expect other developers from different level of knowledge of C++ to contribute, this can be very time consuming and aggravating (speaking of 11 years of experience in the video game industry with C++ there).
    Cheers!

    Cheers! :)
  • edited September 2012
    godexsoft wrote:
    Hi enobayram,

    I was playing around with Scroll and Orx quite a bit and I really liked the ideas behind the engine and how you could bind config types to custom objects with Scroll. I didn't like the need to fallback to plain C often though so after fighting myself for some time I couldn't take it and wrote my own version of orx from scratch and in modern c++. It's opensource and though still in development it provides quite a bit of tools (basics, xml-based configuration, box2d physics, lua/luabind integration and object scripting, events and listeners, zones/contexts and triggers, animation system, fonts, prototypes, etc.). I really love orx but I just can't live with a constant need to fallback to plain C code in a nice C++ environment (hi Iarwain).
    At the moment I'm crosscompiling my stuff to android (already have basic physics/lua demo working on my htc). If you want to check it out (you too, Iarwain ;) ) feel free to visit the outdated doc (http://x2d.7bit.co) or the github project (https://github.com/godexsoft/x2d).

    Cheers!
    Alex

    Hey Alex, long time no see! :)

    Congrats for x2d and best of luck with that. It's definitely the best way of learning than doing things oneself.

    I checked it out a bit, I'm no big fan of the syntax choices (or the lack of consistency in some cases), but beside that that looks fine.

    I'd advise using a component approach instead of aggregating things in your object as you're currently doing.
    A Data-Oriented Design (DOD) usually yields much better performances and a pure traditional Object-Oriented (OO) one.
    There are countless articles online on the matter and I think you can find some on http://www.altdevblogaday.com.

    There still a long road to go to get to a mature state but I'm sure you have the motivation so that shouldn't be a problem! I sure will check your work from time to time.

    Cheers!
  • edited September 2012
    godexsoft wrote:
    2) x2d uses a virtual filesystem (zip with 0 compression) and all resources live inside one or more archives which you mount to a path: lvp_man.mount("resources.zip", "res") for example will open a 'filesystem' archive and mount onto a virtual 'res' drive. in the config system you can access stuff like this: path = "res/graphics/spritesheet.png" etc. This allows for really easy skin/theme support oob. as you can mount and unmount in runtime :)

    Mmh, I never heard of lvp_man before. How does it compare to PhysicsFS?

    I considered integrating PhysicsFS a long time ago but in the current state it's not really worth it as it's very easy to handle it on the game-side (or even better by using encrypted archives) and spoon-feeding orx when it needs resources as they can now all be created at runtime from memory accesses (or memory-mapped files).
  • edited September 2012
    enobayram wrote:
    x2d looks/sounds really nice, you've got me even more interested. As a side note, I'm also experiencing performance issues on Android with Orx, but until now, I've assumed that it's something wrong that I'm doing. I'm curious whether the iphone performance issue is solved on Orx in the last 9 months since you've tried, or whether what I'm experiencing on Android is the same. Do you plan to ever support PC with x2d?

    Alex's issue are explained in this thread: https://forum.orx-project.org/discussion/3235

    Which still puzzles me as of today. I've never experienced it myself and I since then have had access to retina devices.
    I never was able to reproduce that issue, but, to be honest, the code might have changed quite a lot since January, including native orientation support on iOS (both portrait and landscape, no more double camera trick needed there).

    To be a bit more precise, using glOrtho for the transformation or pre-multiplying the coordinates yields the exact results/UVs, one simply does the multiply on the CPU side and I'm pretty sure that 20 multiplications is not going to make any difference within a frame (especially knowing that when having a straight 1:1 ratio is still using the same number of multiplies, except using 1 as an operand).

    Considering your performances issues on Android, have you tried the profiler to try to narrowing down the sources?
    Most of the time on handheld PowerVR-based devices, 2D performances are mostly affected by the use of alpha-blended pixels (alpha-tested is even worse).
    The more of them you have, the worst the performances are. Drastically.
    That being said, in your case, it might be different and the profiler is there to help you finding the root of the issue.
    Don't hesitate to open a thread if you need help on that topic! :)
  • edited September 2012
    Hi Iarwain!

    Thanks for your comments. I sure will read more on DOD and think what I can do. The object is currently a massive collection of "components" which are mostly flagged by a boolean or wrapped with a shared_ptr so it's almost free to check whether we are using one of them or not. also most of it happens at parse time (only once). However I really need to split up the code quite a bit coz currently object.cpp is an ugly monster :D

    lvp_man stands for liverpool manager which is a manager class built on top of the liverpool library. The liverpool library itself is a very simple wrapper for uncompressed zip files. It can read a directory structure and access individual files from it. The liverpool lib was written by me long time before x2d so I doubt you could have met it before :) I don't remember wether I looked into PhysicsFS but I definitely researched a little before implementing my own. I think most of these libs provide read/write access which i don't need. Supporting compressed zip archives, however, is a good idea. Even better - supporting encrypted zip archives.

    Why zip format was chosen? It's simple for designers to work with.. they can use their archiver tool to create it and they don't have to worry about custom tools. Especially helpful when you can easily separate your assets from your configurations (res -> resources.zip (only sprites, music, etc.), cfg -> configuration.zip).

    Cheers!
    Alex
  • edited September 2012
    Hi iarwain, thanks for your long and insightful comments! I finally have the time to reply appropriately.
    To me, most of the time, a pure 1:1 wrapping only implies syntactic differences, ie.

    I agree, percentage-of-code wise most differences are as shallow as this. However, some features of C++ can not be reproduced with C code without changing the code structure significantly. I'm not really armed for an all-out C versus C++ flamewar :) but I can try to give some examples. As godexsoft already mentioned, smart pointers are a very important feature. I've noticed that you're already reference counting all orxSTRUCTUREs, but that's not evident when you look at an orxOBJECT *. Further, without checking the documentation, (and note that, the orxOBJECT documentation has no mention of this, so you need to check the documentation exhaustively to notice the relevant section of orxSTRUCTURE!), I wouldn't know how to properly handle an orxOBJECT * appropriately. In a modern C++ library, you'd never have to worry about such low-level concerns. Everywhere that you see an orxOBJECT *, you'd see a shared_ptr<orxOBJECT>. This isn't important only when you're receiving something BTW. As we've discussed before, when I see orxDisplay_SetBitmapData, I can't know (without asking) whether this function copies my data, takes ownership of it or just references it, leaving the lifetime management to me entirely. Imagine that, before using ANY function that takes or returns a raw pointer, you have to ask about its memory management...

    This example actually brings us to another issue. Even though orxObject_GetName(MyObject); vs. MyObject->GetName(); seems trivial, if orxObject inherits from orxStructure in C++, you'd be able to say MyObject->IncreaseCounter(); -assuming you'd even need to know about the implementation of the shared semantics- and your IDE's content assist would probably inform you about this when you pressed ctrl+space.
    Well, hopefully you don't have to do that often, if at all, beside event payloads. :)

    Well, you can find void * in many many more places. Going back to the orxStructure_IncreaseCounter example, that function accepts a void *. Now, looking at just this, can you tell what exactly it expects? Does it expect my orxOBJECT pointer? or will I have to extract an internal pointer of my orxOBJECT using a macro?
    That's not a C/C++ issue there, enum are present in C as well.

    Well, my problem with C enums is that they allow comparing apples and oranges, though what I missed is that C++ allows that as well. My mind was at Java enums (Oh my god I'm about to say something good about java) which do not allow comparing enums of different types. Now in C++11 you have strongly typed enums that bring the same functionality.
    Symmetry is most of the time a good practice, and symmetric code is much less prone to any memory leakage.

    Symmetry is not the answer to all problems, even if you have the discipline to follow it. For example, what happens if someone else does not realize the symmetry in your code, and returns in the middle? Even worse, what if an exception is thrown? (I know using exceptions is a personal preference) I feel much more safe, when I can look at a small segment of code, and tell that it's not doing something wrong. In C, you often have to remember to clean-up very far away from where you start doing the dirty thing.

    But I really don't want to start a flamewar :), if you like C, I'm sure you're using it in a way that eliminates the problems I encounter using it. Just like I'm using C++ in a way that I never run into the problems that C++ haters love to mention. So, the important point is, we all have strong personal reasons to choose our programming environments.

    I would like to mention again, that even though I don't like using C libraries, I don't mind wrapping them. Especially in the case of Orx, which is very well designed around an OOP architecture. You just check the documentation once, wrap what you need to use before you use it, and sleep tight at night. So, even though I seem to have strong opinions against C, I really (Really) like Orx. There's so much good in it that makes the task of wrapping stuff insignificant.

    This brings us back to our real topic, let's do the wrapping as a collective effort! :)
    I'm curious about the portability statement here, I can understand the first two, but this one eludes me.

    Well, C++ compilers don't play along well with each other. Especially when you start doing advanced things like template-metaprogramming, there are certain cases where you need to go as far as writing preprocessor ifs for each compiler. I have some C++ programs compiled successfully with GCC on both Linux and Windows (MinGW), but I get a 100 distinct compiler errors when I try to compile it with MSVC. Have you noticed how far the boost people have gone to make sure that you can use boost on those supported compilers...
    All those are probably fine when you work by yourself

    You're right about this in both directions. It IS fine when you work by yourself and I believe you when you say it isn't when you collaborate with C++ programmers of various skill. Though I would still prefer to set-up the architecture in C++, and let the others program purely C-like. As a small example, imagine using smart pointers all around Orx, but keeping everything else the same otherwise.

    About the performance issues, I haven't done anything about them yet. They're most probably about alpha-blended pixels as you've said, because I've been using them ad-libitum :) I was planning to start a topic about it once I focus on the performance aspect.
    Cheers! :)
    Cheers! :) :)
  • edited September 2012
    godexsoft wrote:
    I guess you meant windows by pc.
    I actually meant the significant three (Linux, Windows, Mac). The reason why I asked it as "PC" is that in the github project page, you state
    Currently supported platforms:

    - iOS only :D

    BTW, why wouldn't you use OpenGL on windows as well? Valve people say in this blog that OpenGL is even faster on Windows as well.

    I'd love to collaborate with you on x2d, but I'm really overloaded these days. When I'm more free in a few months time, I'll try to see if/how I can help. The forum is still a good idea though :)

    Cheers!
  • edited September 2012
    I plusone enobayram. Your understanding of the C vs. C++ problem is very similar to mine :)
    Furthermore, I can't agree with Iarwain that hardcore C++ is only good when you work alone and/or don't have other developers of "various skill". I think there is a good reason people invented lead developers, senior developers and other names which usually represent the length of someone's dick in software companies :) In my opinion the core/engine of any application can be any level of hardcore meta-programming as long as it exposes a simple, intuitive, yet well-documented interface for "various skill" developers to use.
    Also, i never give jobs to people who i interview if they don't meet a certain level of expected knowledge. Many developers with _years_ of experience in C++ (some over 10 years in Symbian for example) don't know the basics. I wrote a blog post on this matter a while ago.

    Enobayram, thanks for your interest and will to help :) I will create a forum and post back here. Thanks!

    Cheers guys! :)
    Alex
Sign In or Register to comment.