Hey guys. I haven't posted in a long time; I've been busy with classes. And trying to make a Windows 8 app. Which I can't even finish until the full version of Visual Studio comes out.
Anyway...
I want to make another top-down shooter, but this one is going to be of my own doing, will have a story and tie in to the next game I want to make (an RPG, which I will explain to you later when I'm ready to start work on it), and will be fully featured, unlike the one my friends and I made for my senior project. (I was told I have permission to share it, but I want to make sure before I do.)
We coded our senior project game in C, so I wanted to try C++ with scroll for this one. I love the looks of scroll, but with no complete tutorial I have a few questions to ask (and I'll only have more as I continue to work with it)!
So, firstly, if I want to create an object, how do I do it outside of the OrxScroll class? I'm assuming I call OrxScroll::GetInstance().CreateObject([name]), but I want to make sure.
Secondly, can I call the normal orx object functions (specifically GetName) on scroll objects?
Also, what functions are exclusive for scroll that are not in or do not have parallels to vanilla orx functions?
Finally, what specific scroll functions are to be used in place of the regular orx object functions?
These are just a few questions I have. There's no need to go super in-depth or anything. Anyway, have fun and happy programming!
Comments
Welcome back!
Still looking forward to seeing your senior project.
Sounds like a good idea, that should make a bunch of things easier.
Yep, that's good. You can even use the CreateObject<MyObjectClass>("MyObject") version if you know which class it is and don't want to do any casting yourself (plus this version will check that you actually get the right class and that there's no mismatch).
Not directly but you can call all of them of the orxOBJECT stored inside your ScrollObject:
Mmh, it's more about the virtual callbacks you can override (check ScrollObject.h), such as an Update() method that will get called for all ScrollObject, giving a good place where to put your object logic.
Or the fact you can bind a C++ class, deriving from ScrollObject, to a config section of an orxOBJECT. You can also iterate through the collection of ScrollObjects with Scroll::GetNextObject() or the typed version Scroll::GetNextObject<MyObjectClass>() that will only go through the collection of those objects in an efficient way.
Most of them are convenience wrappers and they're all defined in ScrollObject.h. You can of course add your own and submit a pull request on bitbucket if you think other users might use them too.
Well, don't hesitate if you have any other questions!
The scroll expects orx to be in a folder; the orx libraries it references expects orx not to be in a folder.
So, if I have everything in a top-level directory, scroll complains about not being able to find orx because it's looking for the include path "orx/orxWhatever.h" but orxWhatever.h is looking for orxBase in "orxBase.h". So, everything goes to crap.
What I end up doing is putting orx in a folder in my include directory and softlinking everything to the root of that include directory. It's butt-ugly, garish, and is probably not how this is supposed to work. So, how is it supposed to work then? Do I just delete or ignore the included orx folder and download the latest svn copy? or do I have to use the included orx folder? If I have to use the included orx folder, do I have to build orx? because there's no build folder. How do I fix the path issues?
I think this might be the cause of some of the issues I'm having with Scroll right now. Once this is fixed, if I'm still having problems, I can upload the project somewhere. But first, I want to make sure my environment is set up right.
There's no real requirement here. My favorite setup can be seen with Breaktris or DFRM.
Not sure I understand this. Scroll works easier with orx headers being without Scroll's folder but there's no requirement for that.
You can simply modify the include paths of your project to suit your own preferences.
You need to setup your include paths correctly for your own setup. You also need to setup your link paths correctly depending on where you end up putting the orx compiled libraries.
Paths are defined in your project file, depending on your IDE of choice.
You can use any orx include folder, it's just that the one that comes with Scroll is known to work with it, which won't be the case if significant changes have been made on the svn since last time Scroll was updated.
There's no library built in the Scroll folder so you need to compile orx yourself. You can either sync to the version used by Scroll (the revision is in the hg logs) or compile the latest, in which case you need to completely override the orx include files.
It might, but the error messages hinted that some of your other classes might have been not declared correctly.