My plasma background animation routine is one of the biggest speed killers in Spots, although its only really noticable at high resolutions.
Function Calls Tot.with childs[s] Exec.only[s] Av.Exe[s/call]
doBackground 10232 69.701 69.701 0.007
Can anyone think of a faster way of doing this :
FUNCTION doBackground%:
?IFNDEF WINCE
?WARNING "Compiling animated background code"
LOCAL pos1,pos2
INC self.wave%,3
IF self.wave%>320
self.wave%=0
ENDIF
FOR y%=0 TO self.screenHeight%-1 STEP self.stp%
pos1 = self.cosTable[y%+self.wave%]
FOR x% = 0 TO self.screenWidth%-1 STEP self.stp%
pos2 = (self.cosTable[x%+self.wave%] + self.cosTable[x%+y%] + pos1)
STARTPOLY -1
POLYVECTOR x%+self.stp%,y%,0,0,self.colourTable[self.cosTable[pos2]]
POLYVECTOR x%,y%,0,0,self.colourTable[self.cosTable[pos2]]
POLYVECTOR x%,y%+self.stp%,0,0,self.colourTable[self.cosTable[pos2]]
POLYVECTOR x%+self.stp%,y%+self.stp%,0,0,self.colourTable[self.cosTable[pos2]]
ENDPOLY
NEXT
NEXT
?ELSE
?WARNING "No animated background code"
?ENDIF
ENDFUNCTION
I found that moving START/ENDPOLY outside the loop and you get a ray sort of effect - nice, but not what I want... :P
I did a lovely fast plasma routine in Blitz many years ago. I'll see if I can find/port it.
How about drawing every other frame for the plasma, but not the game itself. I think you might get away with it without noticing.
I used this for updating game speed on slower iphones, but it actually ran TOO fast.
I would think that would flicker a lot
Would it be quicker if you just had an animated Sprite that repeated in the background? I know you would want code to generate the graphics for you but sometimes you have to trade fancy solutions for simplistic/speed.
Let's see what Ian has, I'm curious to how quick that is and what the differences are.
shouldnt do. You still draw it every frame, but only calculate and re -move it every nth millisecond. So basically have a timer for the logic routine. I can search some backups to see if I can find the old code, but it is very simple and it does work without flickering as you draw it constantly
Trouble is, I think its the drawing routine thats the slow part - I suspect the multiple calls are the cause.
Does this work? and if so better?
FUNCTION doBackground%:
?IFNDEF WINCE
?WARNING "Compiling animated background code"
LOCAL pos1,pos2
INC self.wave%,3
IF self.wave%>320
self.wave%=0
ENDIF
STARTPOLY -1, 2 // Mode 2: strips
FOR y%=0 TO self.screenHeight%-1 STEP self.stp%
pos1 = self.cosTable[y%+self.wave%]
FOR x% = 0 TO self.screenWidth%-1 STEP self.stp%
pos2 = (self.cosTable[x%+self.wave%] + self.cosTable[x%+y%] + pos1)
POLYVECTOR x%,y%,0,0,self.colourTable[self.cosTable[pos2]]
POLYVECTOR x%+self.stp%,y%,0,0,self.colourTable[self.cosTable[pos2]]
POLYVECTOR x%,y%+self.stp%,0,0,self.colourTable[self.cosTable[pos2]]
POLYVECTOR x%+self.stp%,y%+self.stp%,0,0,self.colourTable[self.cosTable[pos2]]
POLYNEWSTRIP //Begin a new 'strip'
NEXT
NEXT
ENDPOLY
?ELSE
?WARNING "No animated background code"
?ENDIF
ENDFUNCTION
I just converted it to using multiple strips instead of multiple polys - in this case I'm not sure if it will be faster as you're not using an image for a texture (right?)...
Here are a couple of very quick, very dirty ports of two routines I used to use with BlitzBasic.
I've just finished a night-shift, so I'm too knackered to tidy them up (or even reproduce all the effects (plasma 2 changes colour in Blitz, but it stays red in GLB due to my lack of bitshifting (I'm waaaaaay too tired for that this morning))).
But anyway, they work, although you'll have to change values for screen size and colour values.
The attachment includes both sources and .EXEs.
[attachment deleted by admin]
You don't need the POLYNEWSTRIP for every quad. You can draw a stip of a full line in one, then do a new strip for the next line.
You're right, you could use a single strip for each line, something like this:
FUNCTION doBackground%:
?IFNDEF WINCE
?WARNING "Compiling animated background code"
LOCAL pos1,pos2
INC self.wave%,3
IF self.wave%>320
self.wave%=0
ENDIF
STARTPOLY -1, 2 // Mode 2: strips
FOR y%=0 TO self.screenHeight%-1+self.stp% STEP self.stp%
pos1 = self.cosTable[y%+self.wave%]
FOR x% = 0 TO self.screenWidth%-1+self.stp% STEP self.stp%
pos2 = (self.cosTable[x%+self.wave%] + self.cosTable[x%+y%] + pos1)
POLYVECTOR x%,y%,0,0,self.colourTable[self.cosTable[pos2]]
POLYVECTOR x%,y%+self.stp%,0,0,self.colourTable[self.cosTable[pos2]]
//POLYVECTOR x%+self.stp%,y%,0,0,self.colourTable[self.cosTable[pos2]]
//POLYVECTOR x%+self.stp%,y%+self.stp%,0,0,self.colourTable[self.cosTable[pos2]]
NEXT
POLYNEWSTRIP //Begin a new line
NEXT
ENDPOLY
?ELSE
?WARNING "No animated background code"
?ENDIF
ENDFUNCTION
Note: commenting out the two POLYVECTORS results in smoothing in strips (aka along the X-axis, but not the Y-axis), but halves the POLYVECTOR calls... You can see what the different is by uncommenting them anyway...
"+self.stp%" was added so the strips don't cut off a step short of the right edge of the window...
BTW these plasma routines all look very nice!
I also think that's as fast as you can go. Should run pretty smooth even on an iPhone.
Instead of the color per vertex, you should try to use a rainbow texture and set texture "u" parameters, leaving color to 0xffffff. That's a big bottleneck on OpenGL|ES.
Its certainly works better, but still hammers the processor (54% usage) :)
It'll be interesting to see if Ian's ones are better at high resolutions. If so, I'll switch over :)
Apparently they are bit slow at high resolutions - fortunately only keyboard entry is affected, so I may change my options menu routine slightly so that only one edit boxes is processed at a time.
As this only affects keyboard entry, I presume POLYVECTOR and all that dont do anything to the keyboard buffer...
It could be more efficient to have an animated sprite as XanthorXIII suggested...
Did you try QCos/QSin instead of the table?
No - its certainly an idea though.