Actually, if possible I intended to treat the apps as separate objects.
So each object will have something like a shutdown method to clean up any resources used. I will likely start the “newapp” inside my update method in “currentapp”. this is so that I don’t need to initialize glut again.
But I understand that once GlutMainLoop is called it is eternal until the whole application is exited. I read somewhere that FreeGlut has implemented something in there to overcome this.
Unless of course we can clean the resources while GlutMainLoop is still executing ya.
Im am currently using WindowsXP. What do you recommend?
ah ok – currently this is not possible but we are definitely planning a system in the future that will run OF apps in that manner.
alternatively, you could code classes that have their own “start/setup/update/draw/end” routines and you can control them from the main app. you would get the ability to do the same sort of things: start, run and close an app except they would all be run inside of the same system.
if you are interested in trying that, I could code a small example of how to do that.
I needed / need to focus on the things that pay the bills for a sec. I suspect I should be able to post something later today. thanks for being patient
maybe this is a totally ridiculous idea, but it should be possible to launch and close an application using shell scripting. i’m actually trying to figure out how to do this myself for a personal project.
here’s an example shell script that opens two different oF apps (openfiles.sh)
#/bin/sh
open /Users/cinema/Desktop/app1/openFrameworks.app
open /Users/cinema/Desktop/app2/openFrameworks.app
and launch the script by typing ./openfiles.sh into the terminal (if you’re on osx).
now i just have to figure out how to kill the application.
shell script make sense, but it’s also useful to code “scenes” in c++, so you can have different modes that you cycle through.
the code I posted shows how to start and start different modes (called “modules”), as opposed to opening and closing different OF apps.
unless your apps use different libraries or have conflicting things, it often makes sense to try to code them into one app. the advantage over shell scripting is that the switches are seamless (ie, opengl doesn’t close and reopen) and easy to do, and all of the apps are initialized at once, so there is less overhead in going from A to B, B to C, etc.
sorry for the late response, internet service problems.
Thank you for the skeleton Zack.
Hope you don’t mind some input. I can imagine we will be calling those virtuals every loop. But, I see that there is no way to avoid it if we have a base class.
When something has to do with virtual…it gives me an eeary feeling, coz there might be a slight performance hit as compared with not using virtual.
Is there an alternative design where we can do without the virtual call?
I’m sorry but I’m not sure that virtual will have any meaningful impact on performance at all … it’s one function call — I wouldn’t worry for a second about it. if you were calling is 100,000 times per frame, then well, worry a bit
Honestly, I have encountered some lower frame rates with some virtual functions around. But I have not managed to pin point to the root cause yet due to the multi threaded nature of some of my programs.
Virtual functions are called using pointer indirection, which results in a few extra instructions per method invocation as compared to a non-virtual method invocation.
its one call with a few “extra instructions”, not millions of calls, per frame… I think we are talking about something very, very small.
for example, if you added this code:
void update(){
float pointlessFloat = ofRandomf(); // something silly, just wasting a cycle.
}
to your update, it’d likely be many more instructions then the virtual functions add. It’s like having one line of pointless code, per frame…
I’d argue the benefits of object oriented programming outweigh the potential overhead, which is remarkably negligable in this case. because we do OOP, we can subclass out our base class and create an array of the base class to manipulate. the result is very flexible and I believe, a very good way to program.
I would also argue the smartest optimization is in looking at the “for” loops, the repetitive operations, the things that are really taxing – in your case likely the threading & conflicting mutexs, etc, as opposed to the negligible things.
at anyrate, you asked for a simple example of how you can program scenes and I made it for you. I hope you find it useful. if you want to make it non-virtual function calling, go for it!