@Chris - I've played around with PureGDK betas for some time now and I've noticed that it runs at approximately the same speed as Dark Basic with only the speed difference of C++ really. But still, you get the freedom of the rest of the API's with PureGDK where DarkGDK you're stuck within it's setup.
I still can't beat my score or yours either come to think of it...
@Joe Staff - I read what you mentioned last night and came up with a few things to speed it up just a tad. Thanks for the input, it really made me think. Here's what I come up with: (explanation first though)
On the x86 processors every instruction takes up 'x' amount of cpu clock cycles. The ADD, SUB and CMP will take up either 1 or 2 cpu cycles (faster if programmed correctly on the instruction cache pipeline). Whereas the MUL / IMUL will take approx 60 cpu cycles, and the DIV will take upto 125 cpu cycles.
Coming to making a quick speed fix to the "function TREES_FIND_CLOSEST()", already it was optimised so that it's not using the sqrt() every time which would slow it down, but it does have two multiplies in the loop, 120 cpu cycles taken there. So I thought adding more code as usual does increase speed.
As in the updated version of the function below, I've grabbed the X distance then done some nested compares, obviously if these are true then it will then grab the Y distance and do the same thing. Thus shaving the cpu cycles on thousands of trees that are not within range. Even so, the speed increase is negligible, you had made me think about it.
Here's the updated source for "function TREES_FIND_CLOSEST()" which makes a slight difference on my slow laptop.
function TREES_FIND_CLOSEST()
local count as integer
local cdist as integer : local dist as integer
local xd as integer : local yd as integer
local bx as integer : local by as integer
bx = bike.xpos : by = bike.ypos
cdist=8000000
count = tree_count
while count >= 0
xd=bx - trees(count).x
if xd>-4
if xd<4
yd=by - trees(count).z
if yd>-4
if yd<4
dist=(xd*xd)+(yd*yd)
if dist<cdist
cdist=dist
Endif
endif
endif
endif
endif
dec count
Endwhile
Endfunction cdist
The "function TREES_PLACE(num)" is where it will randomly add the trees to the map. It will not place trees under the water line ( < 100 ) and also it will place certain trees within height ranges.
The two slowest parts of the game currently are:
1. Loading the bikes model which I should have converted to a dbo file. DBO's are native to DBPro and do not need converting upon loading.
2. The generation of the clouds using the perlin noise. I am generating a 1024 x 1024 texture for the sky dome.
EDIT: After just reading through the Intel documents I've actually found that my cpu cycles are incorrect, IMUL has a latency or 10-14 and DIV has a latency of upto 65. Plus I hadn't considered the fact the DBPro may actually call sub-routines to do the calculations (which I doubt). Either way, the above optimisation will still increase the performance of the function with the nested compares.
Mental arithmetic? Me? (That's for computers) I can't subtract a fart from a plate of beans!
Warning! May contain Nuts!