Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 08 Sep 2013
Offline Last Active Nov 24 2015 02:10 PM

Posts I've Made

In Topic: IDE for Android NDK

23 November 2015 - 03:20 PM

I started using vs 2015. It supports ndk debugging, and the emulator is smooth and fast.

VS 2015 works great for me, although I pretty much just using it for intellisense when it comes to android. The emulator can't run opengl calls for me and the NDK debugging part won't work cause my device is too old. Otherwise awesome smile.png

In Topic: MyClass myClass VS myClass = new MyClass()

20 November 2015 - 03:26 PM

I think using pointers and new for everything is a sign that you should have stayed in Java. smile.png

This is what I'm trying to avoid. Making all of my C++ very Java esque
What is the general consensus on creating objects on the stack and then having to call an init function?
MyClass myClass;
But I kind of feel like this is counter productive to the constructor of the class
The reason I ask all of this is, well, long story short. I'm currently working in Android and struggling with class creation when they use OpenGL calls in their constructors.
As they need a valid OpenGL context in order for them to work/not crash the application. I would like to have my classes created on the stack, but because my constructors have OpenGL calls in them I need a valid OpenGL context created first. This is where I'm not sure how to handle them as things like:
void MainLoop()
	bool run = true;
			run = false;
		if(window->OpenGLContext->Inited() == false)
		//Would like to create objects on the stack. This object uses OpenGL calls in its constructor.
		//Not sure how to do this without either: Keep on creating it (super bad) or having it stuck in local scope
			if(window->OpenGLContext->Inited() == false)
				SpriteBatcher batcher; //not sure how to use out of local scope
                                firstRun = false;
		SpriteBatcher batcher; 
Hope my issue above makes sense, never really had to wait for a window callback (Android triggers onNativeWindowCreated when the window is ready to display / used)in order to tie a OpenGL context to it. Always had something along of the lines of create the window right now and then use it

In Topic: Android Native Window Create, Destroy, and OpenGL Context

19 November 2015 - 03:18 PM

You objects are invalidated, thus you MUST recreate them. Its a royal pain, but  you seems to be on the right track.

Do all of my objects (non OpenGL buffers, textures, shaders, and etc) still exist?
EG If I create a Texture Class does the object that is the Texture Class till exist when my application things go into the background? Basically I only need to reload the texture, but I can still use the same container

Tips on how I should be handling m app coming back into the background? EG a switch:
//In the On Start (or my case onNativeWindowCreate)
   case MENU:

   case LEVEL1:

   //Other things like it

In Topic: Android Native Window Create, Destroy, and OpenGL Context

19 November 2015 - 09:12 AM

any way i am not sure if this is my apps fault but when its supposed to be paused (because android pauses the activity it should be reopened very fast (they say that) but the thing is it starts the app again, and uses the data from old ogl context which is now used by something else. (this is the case for wrong buffer, texture etc deletion) the best way would be to handle home and back button and kill the process (stop activity, kill it destory it) so app will crash and whole resources that are stored for the game are being set that can be rewritten tongue.png (giving Appname has stopped working on exit) well i wasnt aware of the thing that i need to destroy all objects, in opengl thread, need to write a specific function that does that (few hundred opengl glDeleteXX(); calls ....

This part is what I'm curious about. So let me explain with the Android lifecycle steps (I think this would make more sense).

So lets say we are running, the user can see our app and they can interact with it. Then they hit the home button.
The app will go into the back ground. So Android does its callbacks:

onPause() <- onNativeWindowDestroyed gets called right about here in my case. Current OpenGL context is destroyed

In the onPause() you lose the OpenGl context right? So all of your buffers, textures, and etc for OpenGL are invalidated.
Now to simplify my question, what should one do when the user reopens the app. So the Android system preforms the callbacks:

onResume() <- onNativeWindowCreated gets called right about here in my case. New OpenGl context

That is what I'm not really sure how to handle

In Topic: Void Pointers as variables?

18 November 2015 - 03:11 PM

The android/ios names suggest to me that this is for different window types on different platforms? Presumably you need to build different binaries for different platforms, so why not use #ifdef directives to control this instead (I mean... how would you implement CreateIOSWindow on android anyway?)

Sorry I never fully explained this, but yes you are correct it is for creating different windows on different platforms.
Basically my idea was to call CreateWindow(void *windowHandle) and then the guts of this method would look like:
void EGLDisplayWindow::CreateWindow(void * windowHandle)
     this.windowHandle = windowHandle;

#if defined(_ANDROID_)


//Other platforms that need EGL Windows


Your code above, however, is not using a void* but trying to instantiate a void.  That's not gonna work.

Yep! It was a typo. I fixed it up top

The protected keyword in C++ is ugly. It's usually a good hint there's a better design hiding somewhere. That's off topic though smile.png

Why is protected bad in C++? How else do you hide data members  from everyone and only expose them to the inherited classes?

Personally, I like to make my own opaque pointer types for better self-documentation.

To make an opaque pointer is it literally only a empty struct?