Pocket Burning Sand (Open Source)

[colin9876]

Neil new features that u requested in v2.14
The Groups work
Straight lines draw
Have lessened the new jumpiness with the fixed drawing - Can start/stop pixels by clicking tap

AG - Neil noticed that the pen drawing was more jumpy with the new libraries. It was true. The reason was that although the new lib is much faster with big n's, but actually slower with small n's! It seems Fixing the bits is a 'Fixed cost' negated by variable savings!

I timed thousands of calls in a loop and estimate on my ppc

approx time for a call to oldlib = ( 15 + n ) miliseconds
approx time for a call to newlib= ( 75 + 0.1*n ) miliseconds

new lib can cope well with high numbers!

Ive tracked the extra time down to the first 3 bitfixing lines in the Timer, why do they take so long and can this can be reduced??

 

[neilnapier]

This is good! Now we have the ability of pause (which has an icon BTW) Groups and one of the lines are back.

Good work.

 

[agraham]

I thought you said that it couldn't get any faster

From post #116 of this thread

BTW I think that I can get this a lot faster but it would mean restricting it to Compact Framework 2.0 on the device (where it would be of most use) as CF 1.0 does not have the functionality needed.

As you use ImageLibEx, which needs CF 2.0 I implemented it.

Have you thought of a way to get interactions working yet?

I'm just implementing Colin's logic at the moment. As you might just have quessed by now I am more than capable of doing this stuff for myself - but it's you guys' project, I'm just tagging along.

 

[colin9876]

New Release

Neil, if u want ur start/stop buttons at the top rather than toggling on the tap

1) AddStart ImageButton with code Timer1.enabled=True

2) Add Stop ImageButton with code Timer1.enabled=False

3) Remove the first 2 lines
..Draw.text =" Elements (on/off)"
..Timer1.enabled=(True/False)
FROM BOTH the SetOn & SetOff subprocedures

Then post it here as v2.15 ?

Perhaps this would be a good time to release it as ur new version on the front page because my next v2.16 will be quite different and wont be out till after the weekend?

 

[agraham]

approx time for a call to oldlib = ( 15 + n ) miliseconds
approx time for a call to newlib= ( 75 + 0.1*n ) miliseconds

I'm a bit suprised it's that long but devices vary dramatically in their performance - especially if you've got power saving enabled. I use a 624Mhz Axim with the power saving off which is one of the fastest, if not the fastest, PDAs around so maybe I shouldn't be surprised.

Ive tracked the extra time down to the first 3 bitfixing lines in the Timer, why do they take so long and can this can be reduced??

Also the second last line - Unlock bits. The time is taken in copying the forms' bitmap to a safe place and then copying the changed version back afterwards. At the moment I lock the entire bitmap - I could try just locking the "playing" area but at best, if things scale linearly and they may not, that would probably only bring the overhead down to 50mS from 75mS. I may try that next time though it means having to tweak all the limits. Other than that there is no more performance to come though I can do some marginal tweaks like inlining the get and set colour functions. We are at the limit of the .NET platform. It's downhill from here every time you add something. The only way to get better performance is to go to native C/C+ or even Assembler and write GDI or GAPI code - and I'm not in that game.

 

[colin9876]

sreen mix->max only?

Interesting. AG this will be the last request for a while, can u send me a version of the lib just locking the playing area please?

As approx 200x200 <<240x360 then it may make quite a difference?

 

[agraham]

Interesting. AG this will be the last request for a while, can u send me a version of the lib just locking the playing area please?

As approx 200x200 <<240x360 then it may make quite a difference?

Not that big a difference as the form bitmap the app sees is not the full screen size. More like 185x207 / 240x268 = 60% = 45mS. May take a while (tomorrow or Saturday) as I've other stuff to get out of the way - and as it's a nice bright crisp day and I don't get out enough so I'm going for a walk round our garden (all 2 acres of it )

 

[colin9876]

no probs enjoy ur walk

Actually Ive been thinking do we really need to lock down the area at all?

First of all WMs got the screen stored in memory somewhere anyway,
Does WM move the screen round in memory much. Cant we just tell it not to? and if so cant we just track the pointer to the start of the screen?

Logically it doesnt make sense. Storing 200x200 screen pixels every tick is actually more work than storing our 8000 or so moving pixels! It shouldnt be necessary.

 

[agraham]

Actually Ive been thinking do we really need to lock down the area at all?

Yes - it's the only way to get a pointer to it under .NET.

First of all WMs got the screen stored in memory somewhere anyway,
Does WM move the screen round in memory much. Cant we just tell it not to? and if so cant we just track the pointer to the start of the screen?

The brief answer is no. I can't be bothered to explain why as it would take too long as you haven't got the knowledge of what's happening under the hood.

Logically it doesnt make sense. Storing 200x200 screen pixels every tick is actually more work than storing our 8000 or so moving pixels! It shouldnt be necessary.

Roll with it. That's the way it is! Even in native code in windowing environments you draw on buffers that a Screen Manager blits to the real screen together with everyone elses buffers - handling overlapping, window positioning etc. on the way.

Like I said before the only way to get more performance is to leave .NET and go low-level native code.

 

[colin9876]

lol! Well I dont like low level. Even C# is too low level for me - give me Basic4ppc anyday! Anyway no rush, but if u can make the change to locking just smaller Min->Max of play area that would be good. As I said no hurry as Im going to be tied up with this modding stuff for a few days!

 

[neilnapier]

Here it is... the officially released PPCBS Version 2.15

Included is:
Pause
Reversed Gravity
Liquids, Gases & Solids
Groups...

and much much more!!!

EDIT: 2 minor problems... One is that the style for the horizontal line it wrong so that needs to be sorted and a vertical one added AND how come when using the line style the pen doesn't dot around the place link the circle pen. Couldn't something like that be implemented so there is no more dotty pen?

 

[colin9876]

Neil,
Keep the line that we have - its useful, but change its icon if u want.

Then add ur horizontal Icon button with code
style=5
fixed=False

vertical button with code
style=6
fixed =false


Then after the End if after the if style=3 bit in the main code loop add

if style=5 then burningsands.line(x-3,y,x+3,y,cDraw)
if style=6 then burningsands.line(x,y-3,x,y+3,cDraw)

This will do what u want. The reason I want to keep the line type we have is because it joins up the points as it draws so guarantees non-broken lines. But change the icon to a squiggly line or something!

 

[neilnapier]

Will do, i wasn't asking for it to be removed I was wondering why the wrong icon had been chosen and why the other one wasn't able to be done too. (and why the circle pens can't be done in the same way so no breaks)

 

[colin9876]

Neil, Ive just downloaded ur v2.15


Why have all that code reseting the Top values of some of the buttons?
U know u can have them in their correct places in the form, even if they are on top of each other. U should only need to change the visibility

 

[neilnapier]

What? I never reset anything to do with the left? All I did was make the buttons go to the top of the right menu if the group was selected.

 

[colin9876]

Yes but for instance go into the form & set the Fires.top etc to 25

Its quicker than moving it to 25 the code
That icon is always at 25, its just whether u can see it that changes!

 

[JoeMaximum]

Ok guys i have fixed the jumpy point, by using Sieben method of drawing line. Converted to Basic4PPC by me so here is it, try it and give me new

DrawLen= Sqrt(((x - x1) * (x - x1)) + ((y - y1) * (y - y1)))
For drawlinepos= 0 To DrawLen
[INDENT]iX=(x1 + (((x - x1) * drawlinepos) / DrawLen))
iY=(y1 + (((y - y1) * drawlinepos) / DrawLen))
BurningSand.Circle(iX,iY,Pensize,cDraw,F)[/INDENT]
Next
      
x1=x
y1=y

This is to put in the mousemove event, IF style=1 part

 

[colin9876]

Ive already fixed that, a faster way. The new squigly line joins up the points as u go with series of straight lines. Much better to use this as 1st choice for line drawing rather than chain of circles.

Its tricky all working on the same bit of code simultaneously. Im quite happy to back off & let u carry on Joe but I just want to get this stage out.

Neil in the stone group u cant have gravity as 10! - gravity goes from -1 to +1

 

[JoeMaximum]

Havent noticed that it was fixed in the last version, and i just took BS2 code and change it to Basic4PPC so it took about 2 min to make. Im not sure to be able to carry out now, but if i study the code a bit, i may get how it work, im more used to VB6 and Basic4PPC is similar but very different.
Anyway amazing job you made guys, and if you have time take a look at Burning Sand 2 too, because it is almost becoming a complete programming language. Its very fun to mod.

 

[neilnapier]

Neil in the stone group u cant have gravity as 10!

gravity goes from -1 to +1

Oops!!! That was a typo.

EDIT: How would the cirlce pen be able to be done so that it doesn't jump? Also how would it be possible to clear liquids using the clear pen. BTW when it comes to modding clear is an element too.