Hello. I'm almost a little reluctant to post this question onto a forum, but I think it'll be alright. Basically I've made one graphical video game in the past for my senior project in college, which was a Breakout clone, and now I'm trying to make one again, from scratch, using Android's emulator/SDK and Eclipse (Java is required unfortunately). The thing is that I've found that I'm having to do some more research on efficiency. Below is a list of a few general pointers I've picked up that should be used somewhat specifically with video game programming, and I know the general idea behind trying to gain efficiency, but I wanted to ask y'all what else could be added to the list.
1: Make everything public.
2: Function calls are the devil (that's extreme, but minimize their usage whenever reasonably possible).
3: (Not sure about this one) Avoid loops whenever reasonably possible.
Not much of a list really. What else should I add to that list, which has to do somewhat specifically with video game programming? I'll also be reading up on this elsewhere in the meantime. I just didn't immediately see a post about this on this forum. Thanks!
All three of those rules are bogus, you should drop them immediately.
Class members should be as private as possible, with fields arguably always being completely private. Breaking code up in more methods makes it easier to read, so use all the method calls you want. If you don't need a loop, then don't use it. If you do need a loop, use it. It's that simple.
You should avoid recursive method calls. Recursion can always be changed into iteration with a loop, which is more efficient in Java. If you need to perform multiple method calls on one object, save the object in a temporary variable. This will avoid dereferencing arrays and/or making unnecessary method calls to getters that return the object you need.
Just write clean regular code. If your program doesn't perform fast enough, you can find out what's slowing it down later, and then improve that piece of code.
The mind is a strange and wonderful thing. I'm not sure that it will ever be able to figure itself out, everything else, maybe. From the atom to the universe, everything, except itself.
I'm trying to produce a relatively simple Breakout clone that could be published on the Android phone, using the Android SDK and emulator with Eclipse (which requires Java). Part of the reason that I feel that I need to really look at efficiency here is that mobile stuff, like the paddle, isn't really moving all that smoothly. Another part of the reason is that adding more bricks to a level really seems to be causing lag, as well as adding even basic elements of functionality. But I've been tuning it some, and I'm starting to have trouble seeing what significantly more I can do to help it. No recursion calls or consistent dynamic memory allocation btw.
Joined: Jun 28, 2009
I haven't coded for phones but I'd imagine the issue is in your coding rather any inherent lack of efficiency. I can't see how moving a paddle left and right and moving a ball should tax even a phone. I think you'll have to post some code and people will comment where they see any issues. There have been plenty of breakout games posted on here before if you want to look at other programs. Must admit I'd be interested on seeing how Java works in a phone environment.
Since you mentioned Android - I'm betting the problem has more to do with how you're trying to draw elements. Check out the Graphics section of the Android documentation. There are several ways to draw graphics in Android, and from slowest to fastest they are:
Drawing to a View
Drawing to a Canvas
Drawing via OpenGL
Which are you using?
Write once, run anywhere, because there's nowhere to hide! - /. A.C.
Regarding your unsmooth graphics, i have had a similar problem in both full screen and canvas. I used a simple green box, 32x32 and although movement was quite smooth, scrolling wasnt. Id looked through countless tutorials, posted code on forums, tried 3 different computers ans still unsmooth everytime.
The problem was with granularity of the windows timer wasnt synced with the loop containing the rendering. Not sure if this problem appears with android. After fixing it, I also changed currentTimeMillis() to .nanotime()
I'm going to whack whoever taught you those rules in the head. First of all, what are you going to do without loops? Use individual statements? And calling methods (not functions) is a basic function of OOP languages, the goto keyword doesn't even exist anymore.