Jump to content

  • Log In with Google      Sign In   
  • Create Account

noodleBowl

Member Since 08 Sep 2013
Offline Last Active Feb 17 2016 08:50 AM

Posts I've Made

In Topic: Using GLES2/3 depending on hardware (Android)

17 December 2015 - 03:16 PM

... depending on my previous USING_GLES3 define


IMO, you need to get away from this train of thought

You are not making 2 builds. You have one platform, which is Android.
You need to be able to keep track of that new glesVersion flag you have. The purpose of that flag is to know if you are running ES 2 or ES 3. That flag should be the deciding factor of whether you use shorts or ints.

You could do something like
int* AllocIndicesBufferES3(int numSegments)
{
    int* indices = (int*)malloc(numSegments * 2 * sizeof(int));
    for (unsigned int i = 0; i < numSegments; i++)
    {
        indices[i * 2 + 0] = i;
        indices[i * 2 + 1] = i + 1;
    }
}

short* AllocIndicesBufferES2(int numSegments)
{
    short* indices = (short*)malloc(numSegments * 2 * sizeof(short));
    for (unsigned int i = 0; i < numSegments; i++)
    {
        indices[i * 2 + 0] = i;
        indices[i * 2 + 1] = i + 1;
    }
}


//Whereever in your code that you would normally have this
void ThatOneMethod()
{

   if(glesVersion == 3)
   {
      indicesES3 = AllocIndicesBufferES3(numSegments); 
   }
   else
   {
      indicesES2 = AllocIndicesBufferES2(numSegments);
   }
}


In Topic: Using GLES2/3 depending on hardware (Android)

17 December 2015 - 12:52 PM

#ifdef USING_GLES3
const EGLint attribs2[] = { EGL_CONTEXT_CLIENT_VERSION, 3, EGL_NONE };
#else
const EGLint attribs2[] = { EGL_CONTEXT_CLIENT_VERSION, 2, EGL_NONE };
#endif
context = eglCreateContext(display, config, NULL, attribs2);


This would not work, because you are doing the USING_GLES3 if statement. What you have here would be a compile time thing.
You want a run time thing. I was thinking something like this


EGLint attribsES3[] = { EGL_CONTEXT_CLIENT_VERSION, 3, EGL_NONE };
context = eglCreateContext(display, config, NULL, attribsES3);
if(context == EGL_NO_CONTEXT)
{
   //We failed to create the ES 3 context. Try ES 2
   EGLint attribsES2[] = { EGL_CONTEXT_CLIENT_VERSION, 2, EGL_NONE };
   context = eglCreateContext(display, config, NULL, attribsES2);
   if(context == EGL_NO_CONTEXT)
   {
       //Something is wrong... Failed to create the ES2 context
       LogError("Failed to create a supported ES Context");
   }
}

//Other code to create the EGL Display


In Topic: Using GLES2/3 depending on hardware (Android)

17 December 2015 - 10:08 AM

I'm not saying this would work (I'm making an educated guess here)

Now I'm now sure how you are creating your opengl context. Since you are using the NDK I assume you are doing the part where you create a EGL Display with the function eglCreateContext

What I think you could do is try to create a context with EGL_CONTEXT_CLIENT_VERSION 3 and if the creation fails default to EGL_CONTEXT_CLIENT_VERSION 2. Then set some kind of flag saying you should be using ES 3 or ES 2 render commands

I'm a bit unsure how Google Play would handle that though, since you then technically can use the gles2 version on a gles3 device still


This is also very true, even though I dont think you want to do this. You could build and run your code for ES 2 and at least that way you can have your application run on both ES 2 and ES 3 devices

In Topic: User defined functions?

17 December 2015 - 09:22 AM

The easiest and most intuitive way to allow users control over updating and rendering is to use polymorphism.
General Game/Engine Structure
Obviously this works over DLL’s as your DLL factory just needs to spit out the appropriate instance type.


L. Spiro

 

100% honest, this is Ironic

 

I am porting my engine over from Java and originally in my Java code I had a Engine / Application class. Where the user extended from this class and used override methods on things like Update, Render, etc. But when I came over to C++ I felt that this was "too" Java and went a completely different direction


In Topic: Vector Push Back?

09 December 2015 - 04:45 PM

And don't forget when working in batches to reserve enough space for everything in advance.
 
Resizing a vector is potentially a slow operation, especially when objects are not trivially movable.  Even when they are easily moved, code that triggers multiple vector resizes can have a huge performance hit.


See this the tiny dilemma that I have. I want to better my sprite batcher as now it currently just does a intermediate mode (no sorting, no support for changing shaders, etc). But I do not know which is worse:

Creating and allocating additional VBOs for the GPU when I do not have a "free" VBO

OR

Creating one large VBO and have something like the batch class above.
Then when I do not have a "free / used" batch I create a new one and add it onto some vector

 

Boiling down using up more GPU memory or system memory 
Keeping in mind I am targeting mobile devices, using OpenGL es 2.0 where I do not have direct mapping functions for pushing data directly into a VBO.


PARTNERS