It looks like you're new here. If you want to get involved, click one of these buttons!
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.
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).
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
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?
To me, most of the time, a pure 1:1 wrapping only implies syntactic differences, ie.
Well, hopefully you don't have to do that often, if at all, beside event payloads.
That's not a C/C++ issue there, enum are present in C as well.
Symmetry is most of the time a good practice, and symmetric code is much less prone to any memory leakage.
I'm curious about the portability statement here, I can understand the first two, but this one eludes me.
All those are probably fine when you work by yourself
I guess you meant windows by pc.
Currently supported platforms:
- iOS only
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, 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?
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 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!
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...
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.
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.
the use of functions such as orxStructure_IncreaseCounter are strictly for orx internals, not for external use.
I've seen so many horrors, once even forcing me to hex-edit binaries of precompiled libraries to patch some method calls
I wouldn't use smart pointers all over the place as they come with an overhead
Hi iarwain, thanks again for your comprehensive reply
What is the proper way of sharing ownership of a structure in Orx?
Or am I doing something wrong by needing it? I can give an example of when I needed this. In the game that I'm currently working on, the arrangement of objects on the screen aren't the same as their arrangement in the game world. This is basically because the view is not perpendicular to the game world. In summary, I need to keep my own data structure for arranging the game objects in the world, so I need to keep orxOBJECT references. The problem with simply keeping pointers is that the object that they point to can silently die. Isn't it natural at this point to wrap this pointer in my smart pointer that uses the increase/decrease reference count?
I feel for you...
It's funny how one moment you find yourself talking to someone saying that C++ lacks the advanced features of modern higher level languages, just for the sake of performance (well, people write 3D games in scripting languages nowadays), and the next moment you're told that smart pointers are bad for performance and somebody would rather not use them I guess everybody has a threshold for how much performance they can sacrifice for fancy features
The lesson I got from this entire discussion is that I should probably stop struggling with orx, and do things the orx way as much as possible.