Just run under a profiler. No changes to code, no need to guess.
Thanks again for your responses… at least now I am looking in the right areas… I ran some test and on average my drawing time to update time ratio was about 25 to 1 peaking around 40 to 1 and dropping as low as 18 to 1… I also did a little more digging to find out that the main culprits are my background which is composed of 3 large images which each have transparent areas… the background currently consumes about half the drawing time, so how do we fix it?
a quick intro to my game:
you control a creature eating other creatures within a world
the world is 800x1600px
the user can move to the edge of the world and the background offsets accordingly
my background is composed of three layers with dimentions of 800x90 800x246 and 800x229 they are drawn using a scaling matrix to double this size
theMatrix.reset();
theMatrix.postScale(1.35f, 2);
theMatrix.postTranslate(-world.offsetX * .35f, -world.offsetY * .35f);
g.drawPixmap(Assets.sky, theMatrix);
theMatrix.reset();
theMatrix.postScale(2, 2);
theMatrix.postTranslate(-world.offsetX, -world.offsetY + world.worldHeight - (Assets.ground.getHeight()*2));
g.drawPixmap(Assets.ground, theMatrix);
what would you suggest I do? I would really like to use these images, they add so much to the game, but if there is not a way to at least halve the time spend drawing them I will likely have to dispose of them and adopt a new background system…
I hope you aren’t scaling every frame i.e. every paint…
Premature - happening, arriving, existing, or performed before the proper, usual, or intended time
Optimization - an act, process, or methodology of making something (as a design, system, or decision) as fully perfect, functional, or effective as possible
those were the Webster definitions.
combine them, you get
Premature optimization - Performing the act of making something as fully perfect, functional, or effective as possible, before the proper or usual time
(the proper or usual time in this case is when it becomes necessary, and for something as small as this it will probably never be necessary, but premature optimization can apply to even the most complex of systems and not just a small change like magic numbers vs constants)
where’s the oxymoron in that?
Webster’s and CS defs aren’t always the same are they? If they were then all computer languages are functional languages.
Split the background up into small-ish tiles (say, 64x64), and store the background in a tile array. When drawing, use the current camera coords to index into the array and only draw the tiles that are actually on screen. Big fat images where 90% of them aren’t on screen are usually terribly inefficient.
And as already mentioned, don’t scale them at run time, scale them at load time or compile time if possible.
Edit: what API is that? I’d suspect that drawPixmap() with a matrix argument is probably the slowest way to draw as it’ll have to fall back to a very general purpose blitting loop.
[quote]what would you suggest I do?
[/quote]
Do as much calculation as possible outside of the drawing!
Hence the value of loom_Weaver’s point: “I hope you aren’t scaling every frame i.e. every paint…”
For another example: how often (in terms of frames) does the -world.offsetX or …Y change? Is it really every frame? Or can you calculate (-world.offsetX * 0.35) and store it when the offset changes, and use the stored value in your drawing?
Or this: does “-world.offsetY + world.worldHeight - (Assets.ground.getHeight()*2)” need to be calculated in its entirety every time? Or can you precalculate some of it?
Hope this helps. I know I am continually finding ways to move code out of the innermost loops.
Thank you again for all of you who have taken the time to help…
This thread has spawned a lot of talk about premature optimization, even after my last post which is clearly an area that is in diar need of optimization… was I a little premature to try and optimize my game loop, and updating methods, maybe, but its all part of the learning process… did it eventually lead me to a problem area within my code, YES, and its a problem area that is taking up between 35-50% of my game loop time, seams significant to me, especially considering it is drawing only three elements…
Back to the issue… I am scaling every frame, the reason is that I have an extremely limited space in memory for which to store my images(24 megs), so I must store them unscaled… the offset needs to be calculated every frame as the user is moving around within the world…
It seems my best attack plan as of yet would be to break my three images into tiles and only draw the portions necessary, I will still need to scale each tile, but overall it will be much less of a scaling procedure…
there’s not really a CS definition for just ‘premature’ so, the term ‘premature optimization’ still equates to the same thing.
;D