From post #116 of this threadI thought you said that it couldn't get any faster
As you use ImageLibEx, which needs CF 2.0 I implemented it.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.
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.Have you thought of a way to get interactions working yet?
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.approx time for a call to oldlib = ( 15 + n ) miliseconds
approx time for a call to newlib= ( 75 + 0.1*n ) miliseconds
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.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??
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 itInteresting. 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?
Yes - it's the only way to get a pointer to it under .NET.Actually Ive been thinking do we really need to lock down the area at all?
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.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?
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.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.
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
Neil in the stone group u cant have gravity as 10!
gravity goes from -1 to +1
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?