Jump to content

  • Log In with Google      Sign In   
  • Create Account

LoneDwarf

Member Since 27 Oct 2006
Offline Last Active Yesterday, 04:58 PM

Posts I've Made

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

19 December 2015 - 09:25 AM

There is also GL_OES_element_index_uint extension that allows u32 indices.

 

I still think you're making more work for yourself than needed. I would get it to run on ES 2.0 and then add and extensions or ES 3.0 as a bonus if time permits. It's pretty trivial to write and index buffer class that handles the breaking up for you as long as you're drawing the whole thing instead of ranges. If you're drawing ranges then you have already broken the index buffer up somehow.


In Topic: Your development workflow

18 December 2015 - 02:32 PM

While (task = tasks.pop()) task.perform();

 

That one is awesome but I have to say it's not thread safe. Are you telling me you only get tasks from one place!


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

18 December 2015 - 02:22 PM

If you have managed to write support using ES 2.0 then why bother with 3.0? I'm still at ES 2.0 and won't change until I have no other choice or becomes the dominant version. Why limited your target audience?

 

What I do for this sort of thing is have abstract classes and then check extensions and make run-time choices. This is basically how I do my platform independence also.

 

The indices problem I solved off line by breaking the assets up as part of the asset pipeline. This rarely happens and I would somewhat question why you need that many indices on a mobile device.

VertexArrayObject* OpenGLGraphicsDevice::createVertexArrayObject( VertexBuffer& vb, const VertexFormat& vf )
{
	if ( isOpenGlES3() == true )
		return new OpenGLVertexArrayObject( vb, vf, vb.getTag() );

	if ( hasOES_vertex_array_object() == true )
		return new OpenGLVertexArrayObjectOES( vb, vf, vb.getTag() );

	return new OpenGLVertexArrayObjectEmulated( vb, vf, vb.getTag() );
}


In Topic: java.lang.NoClassDefFoundError:

09 November 2015 - 09:05 PM

Kinda offtopic but I'd just try with Android Studio instead.

 

Make no mistake, I use Eclipse for day to day Java, but Android Studio is a pretty hassle free experience for Android dev.

What about NDK these days? Is it well supported?


In Topic: Mobile games with big file size

09 November 2015 - 01:50 PM

I would work VERY hard to get this game to be much smaller. Yes there are bigger games but to think your game is so good that people will dump 250MB isn't realistic. It's not an insult or meant to pull you down, it's just reality. There is a reason apps can be sorted by size on your phone and you don't want to be in the top ten in that list. It is SO hard to get people to even try your game and that file size is a deterrent.

 

Have you looked into doing an expansion file on android? It does require work and is one more point of failure you have to deal with.

 

Perhaps I am wrong but I get the feeling this is a small 1-2 person team. If so realistically, I doubt you could have generated that much content. Spend sometime looking how you could reduce the size. Can you tell me what kind of resources are using the most space and perhaps I could offer some advice?  Textures, geometry, audio etc


PARTNERS