Hey, guys,
I'd really like to give Orx a shot, but I'm having trouble getting off the ground. I have a few questions I'd really appreciate it if you could clear up.
1. iarwain told me in another thread that the way the executables are packed is causing a false positive I'm seeing with my antivirus utility. I still see it even when I compile from source -- is there anything I can do on my end to "fix" that? It's irritating having to manually disable my antivirus software every 15 minutes (the maximum duration AVG will allow). Besides, I'm hoping to make games for my friends to play, and some of them have AVG, too...
2. Could someone walk me through the build/generation process? I understand that some code is generated based on the contents of my ini files -- where does it go? How are my ini files located by the compiler, what's a standard project layout? This stuff is in the tutorials, but only sort of, and I'm still pretty lost. It doesn't help that I haven't used C much, and when I did it was with much smaller projects.
3. Is it possible to use a debugger with Orx games? It looked like my workflow would end up being "write code in VS, build in VS, run .bat or .exe" -- but being able to debug using VS (once I get far enough in to actually start supplementing Orx's generated code with my own routines) is something I really want.
There's probably more, but that's all I can think of at the moment. Mostly, I'd really love it if someone could give me a gentle introduction to HOW you guys make stuff in Orx. I get the basic ideas, but I don't quite grok the whole procedure.
And thanks, to anyone who responds, for your patience -- I know I'm being a HUGE noob, here. The help is very much appreciated.
Comments
Hey there!
No problem.
Ah, that's interesting, you're the first one that reported that issue. Does it happen only with the orx.exe launcher or also with stand alone executables (like the tutorials #10 - #12)?
I guess the only way to fix it if that still happens with everything is to fill a false positive report with AVG. As they have access to orx's code, they should be able to correct that pretty fast. I'm myself using AVAST, so I can't really help on that point for now, sorry.
Sure. So, first of all, .ini (or any config) files are only used at runtime, not at compile time.
Now for the workflow.
Orx has a bunch of build configurations as you have probably already seen. You should only bother compiling the ones that contains the word "embedded". That means that all the I/O plugins will be embedded inside orx library at compile time (as opposed to being hotloaded at runtime, which is a bit more annoying to use and comes with reduced performances).
You then have the choice between static and dynamic configurations. I recommend using dynamic ones. You'll then have to redistribute orx.dll along your own .exe, but that makes it much easier to upgrade to a new version of orx without having to recompile everything.
That leaves us with 3 configurations:
- embedded dynamic release: full performance, likely the version you're going to redistribute
- embedded dynamic profile: very similar to the above one except that orx's profiler is enabled and you can display exactly where orx's spending time in its execution with a nice graph (as well as instrumenting your own code), so a bit slower than the release
- embedded dynamic debug: the usual debug build, slow, but you'll get all the error/warning messages that will help you knowing what's going wrong
When it comes to create your own game, I'd create a stand alone executable (as shown in tutorial #10 - #12) and not use the default launcher. I know that the first 9 tutorials are still using the launcher. Historically using the launcher used to be much less complicated than building a stand alone, but that has since changed.
For that you need to define 3 functions: Init, Run, Exit, and give them to orx using the orx_Execute() function.
In the Init you create whatever you want, setup your event listeners, register update callbacks, etc.
In Run, usually I don't put much there as you should use an update callback for gameplay/logic purposes.
In Exit, you clean your stuff, but if you don't orx will do it for you anyway.
If your game is called MyGame.exe, orx will loaded by default a file name MyGame.ini in the same folder. But you can of course load/unload your own set of config files in your Init function. It's just the default behavior (which is recommended if you want easy video and input setups, for example).
Yes. It's possible and even recommended. Just build your game as you'd create any C/C++ program, link it against orx library and run/debug it from your IDE. It'll work exactly as with any other C/C++ program.
Let me know if you still have any questions on that subject.
My pleasure. Don't worry about noob questions, some might have already been answered in the forum or the wiki but it's not always easy to find what you're looking for. And I think it's better to ask what sounds as trivial/noob questions than to get frustrated and walk away!
- __orxDEBUG__ must be defined when and only when linkind against orxd.lib
- __orxPROFILER__ should be defined when linking against orxp.lib
- nothing should be defined when linking against orx.lib
I use Eclipse with MinGW. This makes cross platform compiling very easy; I have one development environment for building Windows and Linux binaries (I haven't gotten around to Mac, as I don't have a Mac). Installing MinGW is easy, and Eclipse should pick it up by default. You might have to add its directories to the path though.
If you use MinGW, you have to change almost nothing for Linux compiling.