Pocket Burning Sand (Open Source)

I don't have a "system" to work with. I just write code to do what I want it to do. Sometimes I use B4PPC sometimes I use Visual Studio 2005 and C# or VB.NET. If I need performance in a B4PPC app on a device I am lucky enough to have the skills and experience to implement the code in C# in a library. When other people express a need they themselves can't fulfill I try to use my experience to help them out.

I entered this thread to try to point out the performance limitations of B4PPC that you will encounter before you wasted too much time and effort on something that is not achievable - at least not on a device and not to the standard that you seem to expect. I sorry but I don't have a solution - you will need to find and evaluate one yourself.

When I said system I meant your code. I suppose I could learn another language BUT then I need to start from scratch. If PocketSand was able to do it why can't I???

There must be a way. I think that every single modder on this forum should contribute to it an ventually i'm sure it will be done well.

Plus once BASIC4PPC V6 comes out then it should be much faster.

My code is written in C# - it is another entirely different (and more complex) language.

If PocketSand was able to do it why can't I???

Click to expand...

Because they used the right tool for the job and you are not.

I know what C# is...
I do know of a few other PPC languages but have yet to learn them... any advice on which to pick.

You need a truly compiled language (Basic4PPC is not fully compiled. In its' present form it is effectively interpreted , hence the lack of performance and your problems) that can handle low-level graphics.

With .NET (apparently)the way of the future if you are learning a new language it makes sense to use a .NET based language but even then to get fast graphics at the pixel level you will need to learn how to lockdown bitmaps and access them directly - C# is better for this than VB as it has pointer support.

If you want to compile for Pocket PC you must make sure that your chosen development environment and language can do this there are not many around that produce truly compiled codefor a device. The obvious choices are Visual Studio or SharpDevelop in the language of your choice though I believe that the current version of Delphi .NET can target devices.

By the way. Even a fully compiled version of Basic4PPC is unlikely to match the speed of compiled C# or VB.NET if it is to maintain compatibility with its' present code base because supporting weak typing effectively means that everything is a string that is converted to numbers when required. This is inevitably slower than a strongly typed language that knows what type variables are at compile time.

How do you compile using VB or C# to get it to work on a PPC? I know some VB but very little C#

You write and compile in a desktop environment and download the resultant code via ActiveSync(XP) or WindowMobile(Vista) to the device. I don't know about SharpDevelop but VisualStudio supports remote debugging on the device or on a desktop emulator.

I'm not giving up using this... even if it is slow it will be better than nothing. I hope that everyone that has so far helped will continue to do so.

hmmmm .. tricky one

Thanks to AGraham for the explanation and example. I actually think its brilliant that he has got it more than 10 times faster!
Ive learnt something. I didnt realise that SDL didnt do most of the work, but in a way thats a good thing, because that means we are not dependent on a library we know nothing about.

I can do a little C but I dont have the kit - I only have the device (no pc or SDK), nor knowhow about dlls.

Im sure that with the use of a library to do the cpu intensive bits we could do this, and the moddable functions that u want can be done in Basic4ppc.

The library would need two functions
calculatepoints(px(),py(),pdx(),pdy(),pcolor(), rules(),n) 'looks at what the points have hit, how they interact etc
plotpoints(px(),py(),pcolor(),n) 'plots them on the screen in the specified colour

I would invisage the rules array containing some data like
Rules(color1,color2)=(colourchange,dx,dy,...)
Rules(yellow,white)=(red,0,0.5,...)
i.e. a yellow hitting a white pixel will turn the yellow pixel into red and move it at half speed down)

This would be loaded in from the mods file at the start of the program (in Basic)


Just out of interest Agraham - how long did it take u to port the tt demo etc into ur ttt library? If u did could do that again for the calculatepoints physics when Ive written it in Basic then we would be half way there???
Also just curious, saw u changed the Dim x(...) to INT32. Do C procedures have to accept numbers as 32bits?, what would be the default 'type' if the INT32 wasnt specified?

The fun of it isn't just playing about with it... it is modding for it and creating cool things with it. With BS2 you can create pictures or have backdrops and make REAL games like asteroids and such.

I myself made a cyberpet mod in BS1 about 6 months ago that was very good. (made some not so good ones since then)
I even started making a pacman game for Burning Sand too... and that is just with 2 functions.

It is all about the challenge.

how?

So how can you make a PacMan type game out of the falling sand? Give me an example of the 2 functions??

Element and interaction is all I would have needed... I got the ability to move left or right with it but never finished it and I have since lost it, along with half my other mods which has seriously annoyed me.

This would be an example of interactions to work pacman:


I'm a bit rusty at the old fashioned coding but yes I think that would work.

(please note that it would not work becasue would need more coding)

The elements would be solid... no need to post them.

ok

I understand, like a pacman pixels will bounce of a wall, and all move left together etc.

Its made me think we would need an array of rules of how things interact sent to the calculatepoints library routine. I'll add that to my post to Agraham.
I still think that identifying different elements by their colour is the fastest way.

That array of rules could initially be loaded from the mod file - that can be done in Basic

It would also make the program faster if it read it from a config because the file will be overall smaller.

what do u mean? Why u say config file faster than a mods file - arent we talking about the same thing?, (i.e. a simple text file that describes the properties)

Yes load the rules into an array from the file at the beginning! It wont slow the program down however u load them in as that bit is only done once at the start and can be done in Basic ?

Actually all the physics rules can be done like that e.g. Rule(color1,color2)=(newcolor,dx,dy,..
grey gas rises if it hits a black space, stays grey, but moves upwards, ... Rule(grey,black,)=(grey,0,-1,...

If we have say 32 distinct elements that would need an array of rules about 1000 big

I mean that the actual program (PPCBS) would be very slow if every single element and interaction was programmed into it. However if it read it from a external file then the program would have a much smaller filesize because the code would only need to be inputed once.

Logic! Further Question for Our Graham!

Making huge progress on this now, got all the physics working (admittedly too slowly in Basic) come up with a brilliant idea which makes it all so simple.
Basically using slightly different shades of dark grey (looks black) (8,0,0) (0,8,0) etc can introduce movement to the pixels as they fall which doesnt take any more programing. I.e. before the loop begins place some dark grey pixels on the screen for 'random' wobbles, the eye cant see them but they make the sand wiggle when it hits them.

for example for yellow sand
Rule(yellow,grey1)=(color,-1,0) move left
Rule (yellow,grey2)=(color,1,0) move right
Also coating slanted lines with a 'layer' of 'move left' grey1 for example makes the sand move left as it falls down the slope.

'the main loop is still simple ...

sub calculatepixeld(px(),py(),pcolor())
color2=getpixel(px,py) 'look at the pixel under me in the backround layer
for i=1 to n
px(i)=px(i)+rule(pcolor(i),color2).dx
py(i)=py(i)+rule(pcolor(i),color2).dy
next
end sub

The rules array MaxColors x MaxColorsx3 (how colors react with colors) and 3 values for newcolor, dx, dy

My questions to Agraham are
1) if I set my rules array as a global (say 32x32x3) can dll librarys access the array without it being a parameter? or do dll librarys need all the variables passed into them? Thanks
2) Do C librarys support the transparency concept? (No problem if not - I would just have to have another array p_old_color() to store the pixel colour 'under' the element, so it can be replaced when the element moves on)

Rule(col1,col2)=(newcol,dx,dy)

Found more things are possible just by changing the modding rules, u wont believe it but Ive managed to do moving images now, e.g. a moving space invader, just by changing the mod rules of different shades of colours (which rotate through a cycle)

Its difficult to explain but simple example- heres a spiraling green gas

Green1=RGB(0,255,0)
Green2=RGB(0,254,0)
Green3=RGB(0,253,0)
Green4=RGB(0,252,0)

Rule(Green1,Black)=(Green2,1,-1) 'change to green2 then move up&right
Rule(Green2,Black)=(Green3,-1,-1) 'change to green3 then move up &left
Rule(Green3,Black)=(Green4,-1,1) 'change to green4 and move down& right
Rule(Green4,Black)=(Green1,1,0) 'move right one

This rotation through 4 similar shades of green makes the gas move round in a small circle and end up just one pixel up!

Anyway so much can be done with just changing the modding rules.
The procedures calculatepixels and plotpixels are very short, they just add the dx and dy to the positions and change the colour and plot the point. Less than 10 lines. If we can get that bit in a fast library it will be great

colin9876 said:

Just out of interest Agraham - how long did it take u to port the tt demo etc into ur ttt library?

Click to expand...

About 20 minutes! But I'm in practice and it was a hack, not production quality code, with no error checking etc. Bear in mind that was just setting pixels from an array. It would slow down a lot once any logic and the error checking was incoporated.

Also just curious, saw u changed the Dim x(...) to INT32. Do C procedures have to accept numbers as 32bits?

Click to expand...

Everything inside B4PPC is a String or a Double(64 bit float). When a simple variable is passed to a library B4PPC converts it to whatever the library expects. To save time it does NOT convert arrays when it passes them (instead it converts them when they are referenced internally). As the pixel x and y parameters are required as integers by a .NET Bitmap it makes sense to declare them as integers to save the cost of a type conversion in the library.

what would be the default 'type' if the INT32 wasnt specified?

Click to expand...

Possibly Double but I have never tried as I have a strongly typed background and always play safe and specify types.

Thanks - last questions for the moment

Im making the calculatepoint and plotpoint procedures small.
All calculate does is apply the rule for that color hitting another pixel
i.e. change the colour if necc, and add dx, and dy to (x,y)

In the calc routine theres just one line that destroys blackpixels -then all error checking can be just done with mod rules e.g.
Rule(cSandcolor,cLowerBordercolor)=(cBlack,0,0) ' so if sand hits a border then it will disappear!
The beauty of this is adding more logic to the rules array wont slow it down, as it only applys rule(col1,col2) per pixel hit

Anyway questions are
1) if I load my array of rules from a config file at the start of the program, and have rules(colormax,colormax) declared as a Global array will a library be able to see it without being passed as a parameter?
Basically can dlls see Globals?

2) Does the transparency fuction work in C, or do I need another array old_color(n) to store the color of the background under where the point is plotted, so it can be colored back in when the element moves on?