Jump to content
  • Advertisement
Sign in to follow this  
Rusildo

Architecture vs Performance [Android game]

This topic is 1329 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm make a sandbox game on Android and can't decide how best way. What you recomend?
 
~800 tiles drawing on screen 60 times per second.
 
Example 1: Architecture (6400 calls per tick)
6895212.jpg
Example 2: Performance (2 calls per tick)
6939247.jpg

Share this post


Link to post
Share on other sites
Advertisement

We can't tell you much without seeing the full code.

Plus the number of calls generally don't matter from one standpoint.

 

Profile, and see which version runs faster. You'd be surprised what stupid things will run faster than the other.

Share this post


Link to post
Share on other sites

We can't tell you much without seeing the full code.

I didn't start writing a game code yet. I only think over implementation.

Share this post


Link to post
Share on other sites


We can't tell you much without seeing the full code.

I didn't start writing a game code yet. I only think over implementation.

Premature optimization is the root of all evil.

Well maybe not, but on a more serious note; you should focus on getting a sound architecture and deal with any potential performance related issue when (if) it comes. Truth is you don't know enough about any potential issue to solve it until you've seen it. You are just as likely to introduce problems as you are to fix them should you do it now.

Share this post


Link to post
Share on other sites

I would probably test out how much you can even output tiles per frame. From what I've tried before using sprite batches on libgdx for example, on my android (Nexus5) I can spam around 10k tiles per frame. So basically as long as you try to avoid changing textures in middle of drawing you should be all good.

 

If you really are worried about the speed of your solution, you might want to make sure that you try to avoid cache misses, in other words from quick glance swap the for loops around, so that it loops y, and x inside y. So for(y ... ) { for( x ... } }, when you are using tiles[ x + y * tilesX ]. I am not even sure how much difference it would make.

Share this post


Link to post
Share on other sites

Thats not how coding with a JIT in mind works:

 

block.isSolid and block.isOpaque should get transformed into direct field reads since they're direct accessors, exactly the same with Blocks.get, its a direct accessor to an array reference. These usually get inlined, specially if they're static functions like those.

 

The issue lies in calls that are more complex, when more than one implementing class is passed, ie, if you have 10 Block sub classes and they all have different "isSolid" implementations, you're going to get all the overhead of regular virtual calls.

 

Now if you were in desktop Java land, HotSpot can inline these in a per call site basis, that means that if you have 10 Block subclasses but you only pass one or two particular subclasses to that piece of code, it can get inlined or at least it can avoid the vtable indirection. ie, if a method is virtual or final its meaningless, HotSpot decides what to do at runtime based on its profiling.

 

Since you're on Android, I have no idea. I don't think Dalvik does that kind of profile guided optimization on the fly, and ART does AOT, so YMMV. Although I'm pretty sure it should handle those static accessors just fine so I wouldn't worry about those if I were you. 

Share this post


Link to post
Share on other sites

I only over-think implementation.

Fixed.
 
While it may be a good idea to have a general plan for your overall architecture from the start, it’s not healthy to take it to the extreme and let your planning phase stop you from moving forward entirely.
 
Additionally, the way you’ve framed your question makes a false dichotomy.  The best approach is probably to focus on architecture but break away from that in places where performance is critical.  It’s not about leaning entirely in 1 direction, but about finding the balance in different places within your framework.
 
 
L. Spiro Edited by L. Spiro

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!