# Foul Sorcery v1.1 - Performance/Optimization Help

• ### Question

• A friend and I have been working on a little top down shooter in Small Basic called Foul Sorcery!, you can download it here(You'll need to unzip it before running). It uses left and right mouse to move your character and space bar to cast a fireball. The game features random level generation and multiple enemy types(Watch out for the red knights, they are beatable, but tough).

While it is playable, there are some performance issues when it comes to collision. There are too many sprites colliding and it slows down the game. We've been holding back some features, like multiple attacks and a mana system, because the game becomes unplayable.

Thanks everyone for the suggestions, we have started to redo our code with some noticeable improvement! You can see v1.1 here. We are working on upgrading to the LitDev Extension and should have it by next week.

Thanks again!

Saturday, May 16, 2015 1:10 AM

### All replies

• Do you use the litdev extentions?

Best Regards Martin

Sunday, May 17, 2015 9:29 AM
• Altough I didn't make an extensive analysis of your program, I noticed a number of  If x=1 .. Endif; if x=2 ... Endif ; if x=3 ...EndIf sequences.

The use of  If x=1 ... ElseIf x=2 ...  ElseIf x=3 ... Endif is quicker, especially if you put the most used  x as the first one.

The following testprogram shows speed increase for the second case:

```a=1
t0= Clock.ElapsedMilliseconds
For i=1 To 10000
If a=1 Then
EndIf
If a=2 Then
EndIf
If a=3 Then
EndIf
If a=4 Then
EndIf
EndFor
t1= Clock.ElapsedMilliseconds
For i=1 To 10000
If a=1 Then
ElseIf a=2 then
ElseIf a=3 then
ElseIf a=4 then
EndIf
EndFor
t2= Clock.ElapsedMilliseconds

TextWindow.WriteLine(t1-t0)
TextWindow.WriteLine(t2-t1)```

For a=1 the times are  76 and 24 msec, for a=4 the times are  76 and 66 msec.

Jan [ WhTurner ] The Netherlands

Sunday, May 17, 2015 12:57 PM
• The main things that slow Small Basic (apart from inefficient coding) are:

1. No variable types - strings, numbers etc need to be checked at run time - not so much we can do about this and its not usually too bad.
2. Arrays - they are stored in a way that means quite a lot of overhead compared to some other ways - it is done this way for good reasons to keep the language simple, but can be slow or very slow for large or multi-dimensional arrays.
3. Graphics update, again quite a lot of overhead moving or modifying shapes.

If you are considering using LitDev extension, then look at LDArray amd LDList for point 2 and LDFastShapes for point 3.

I would recommend doing some simple test programs to see the speed advantages and how to use them.

http://social.technet.microsoft.com/wiki/contents/articles/15062.small-basic-array-basics.aspx

http://social.technet.microsoft.com/wiki/contents/articles/24857.small-basic-sprite-arrays.aspx

http://social.technet.microsoft.com/wiki/contents/articles/24946.small-basic-list-extension.aspx

Sunday, May 17, 2015 7:49 PM
• No I did not, so far this is all vanilla Small Basic.

Did you mean the one found here? If so I will begin to use it!

Thanks

Sunday, May 17, 2015 8:56 PM

Sunday, May 17, 2015 9:05 PM

I tried to know where is the bottle neck in Foul Sorcery 1.0.

Program ID BND561-0 is profiler version of Foul Sorcery 1.0.  This program counts up current subroutine every 50 ms.

```import : 1
Main : 1299
generateStack : 3
generateMap : 264
nextLevel : 3
initStage : 16
displayTiles : 16
displayInactive : 23
MouseMove : 306
collision : 219
moveSprites : 47
pathing : 8
displayActive : 1
death : 144```

My impression is:

• Subroutine MouseMove may be a bottle neck.
• fireRate > 30 is too large for fire interval.

Nonki Takahashi

Thursday, June 11, 2015 8:18 AM
• Thanks Nonki,I am fiddling with that now, I'll get back with the results!
Thursday, June 11, 2015 11:09 PM