Improving the competition entries

[thaaks]

Kevin, in your Developer Blog/WIP thread you mention that there are

a few (cough)dodgy(cough) bits of code in them

I am sure there are  ;D

I wouldn't mind if you point me to some of them in my code (if you want to afford the time  ;)).

I could improve the code and others can learn from your comments too.

Cheers,
Tommy

[kevin]

  Meant to get around to this the other day, but  I'll have a look at it over the weekend.

 

[thaaks]

Sounds great!

And maybe the judges come up with a decision too  ;)

[kevin]

  I have, but certain other people haven't...

[thaaks]

I know! Sisters  ;D

[kevin]

Here's a very quick page through it.

* Opens the display twice.   Moreover the second Open screen is called after GFX media is created. 

* Missing lots of short cuts when using dynamiuc creatrions..

ie.

Code Select Expand


; music stuff
Global GameMusic = GetFreeMusic()
LoadMusic "sfx\Right.mp3", GameMusic
PlayMusic(GameMusic)



Code Select Expand


; music stuff
Global GameMusic = LoadNewMusic("sfx\Right.mp3")
PlayMusic(GameMusic)



* The Game loop is using BlitIMageClear().  So the backdrop is being cleared, only to be filled with the backdrop picture during the next frame.  Invalidating the need for the clear.

[thaaks]

  * Opens the display twice.   Moreover the second Open screen is called after GFX media is created. 

Just grepped through the sources. Found only one call to OpenScreen (Main.pba, line 39). The line below is commented.

* Missing lots of short cuts when using dynamiuc creatrions..

Oh yes. I see. Thanks!

* The Game loop is using BlitIMageClear().  So the backdrop is being cleared, only to be filled with the backdrop picture during the next frame.  Invalidating the need for the clear.

Copy/Paste from some sample code  ::)
Good find.

Thanks for taking the time!

[thaaks]

A question on BlitImageClear(): I used that because I found it in some sample and I understood that it's pretty fast.
But indeed I only need to copy my private screen buffer image to the real screen without clearing it (as you already explained to me).
What is the fastest approach?

I looked for some BlitImage() in the blitimage slib but there's no such function.
What about a simple DrawImage or CopyRect? What's the fastest solution?

Thanks,
Tommy

[kevin]

Just grepped through the sources. Found only one call to OpenScreen (Main.pba, line 39). The line below is commented.

  Who said it was in the source ?  PB projects initialize the default screen, so in this case you don't have to. 

Code Select Expand


Print "User is looking at my projects default screen"
print "loading some media or something"
sync
; wait a few seconds
wait 1000
wait 1000
wait 1000

OpenScreen 640,480,32,1
Print "Manually reopen to my required size"
print "If you want the screen to be one size, then set it through"
print "IDE->Project->setting->screen"

sync
waitkey
waitnokey

 

I looked for some BlitImage() in the blitimage slib but there's no such function.
What about a simple DrawImage or CopyRect? What's the fastest solution?

   The blitimage interface is to perform combination passes.  So if your draw loop needs to cls the  virtual screen,  draw some stuff on it, then draw the virtual screen to backbuffer,    This logic can be replaced with the BlitImageClear method.     

   This sort of thing.

Code Select Expand


#include "blitimage"

sw=640
sh=480

OpenScreen sw,sh,32,1

screen=newfximage(sw,sh)

ClsColour=rgb(255,0,0)

Method=0

Do

if Method=0
; simulate the BlitimageClear function
Drawimage Screen,0,0,false
RenderToImage Screen
cls ClsColour
rendertoscreen
else
BlitImageClear(Screen,0,0,ClsColour)
endif

if Spacekey()
Method=1-method
flushkeys
endif

Text 0,0,fps()
Text 0,20,method

Sync
loop



    In this case you'll win back some time by the merged clear. 


    In your particular case,  the backdrop clear isn't required, so DrawImage Screen,0,0,false is about it.   This is direct memory copy between the source and the destination.    CopyRect is basically the same thing, but from memory, I don't think if has the same (address) alignment optimizations that drawimage methods have.    Most of this is largely irrelevant on modern systems, but can make a real impact on the old clunkers!   

[kevin]

 
  * There's parts where a generic solution is customized for the container.  Ie.   If bomb/enemies are decedent from the same parent.  Then  just wrap up a generic 'clear' function.

Code Select Expand



Function ClearObjects(Objects().ParentObjectType,Message$)
; clears all resources from the current enemies in the game
Local  i
LogLowDebug(Message$)
For i = 1 To GetArrayElements(Objects(),1)
If GetSpriteStatus(Objects(i).spr)
DeleteSprite Objects(i).spr
EndIf
Next
Dim Objects(0)
EndFunction


function ClearEnemies()
     ClearObjects(Bomb(),"Cleared Enemies")
EndFUnction

  later on..

Function ClearBombs()
     ClearObjects(Bomb(),"Cleared bombs")
EndFUnction   





  * CheckPlayerCollisions()

      If you're using pixel perfect modes, then the less you poll SpriteHit/SpriteOverlap etc  the better.   Ideally detention against bad guys and bombs,  should be combined.    So were looking for any impact that was is registered.  If there was one, we ask the object what type it was and react.   This saves at least one transformation of the Players current frame.   Doesn't sound like much, but it adds up !

[thaaks]

Just grepped through the sources. Found only one call to OpenScreen (Main.pba, line 39). The line below is commented.

  Who said it was in the source ?  PB projects initialize the default screen, so in this case you don't have to. 

Okay, I forgot about the one in the project settings.

But my idea is to read the settings from an ini file and using the read settings open the screen appropriately (resolution, windowed/fullscreen).

How can I get that functionality and avoid the opening with maybe wrong parameters from the project settings?

And thanks for the generalization tip regarding ClearObjects() and collision improvements!

[kevin]

    If you want to 'customize' the startup display mode, then default screen res is setup in the  project.    Here you could display a title logo, while you load/create game data (none graphical), then launch the game display mode.  Then load the game media after it's created.

    While on the subject of the display modes, another point that both waldo and never dawn suffer from, is they 'assume' the desktop depth is 32bit.  It might not be!  Therefore, neither will work correctly upon a 16bit desktop for example, or if the user wanted to run them in 16bit full screen mode.    The latter would be is more efficient (in most cases) for old clunkers.  So it's worth supporting!