Pocket Burning Sand (Open Source)

neilnapier

Active Member
Licensed User
Longtime User
Yes it is quite amazing however what you said is not 100% accurate becasue you can have many different elements with the same colour in it.

How are you doing with it... I know it is difficult to make it but that is why it will be so good!!!

Burning sand is my favourtite game of all time. The reason why it is so fast is that it runs purely on RAM memory or something like that.

If you want any questions to ask to the creator of the PC version of BS post here and I will contact him.
 

colin9876

Active Member
Licensed User
TimingTest

Try this, even with all the interface taken out the physics engine goes painfully slow after > 30 grains of sand! Just tap the mouse to add sand!
Proves we need the SDL.dll

So if its not done on colours - how does it do it? I doubt that there is an array storing the properties of every pixel. Can you have to substances Exactly the same colour that do different things? Remember (100,100,100) doesnt look much different than (108,100,100) etc but it would be enough to recognise it as a different element
 

Attachments

  • tt.sbp
    825 bytes · Views: 322
Last edited:

neilnapier

Active Member
Licensed User
Longtime User
Nice work but why does some of the grains turn solid? Also please note that is should be in the forelayer.
 

colin9876

Active Member
Licensed User
only a demo

It was just a demo to show that its far too slow. The only way of doing this is exploring the dll. I dont know enough about those yet- we need help! Any offers?
 

neilnapier

Active Member
Licensed User
Longtime User
I know it was just a test, for some reason on it when I change mousedown to mousemove (so that it works more like BS) it works fine until it goes in about 297 pixels when it comes out with a fault about an array.

EDIT: oh wait I get it... just change two numbers and ut sorts it.
 
Last edited:

colin9876

Active Member
Licensed User
change Dim

I only made the array 300 long. Its so slow on my PPC I cant get over 50 pixels.

Edit: As u say, If you want more,
Change the 300 in the first two Dim lines to 1000
 
Last edited:

neilnapier

Active Member
Licensed User
Longtime User
As I said in the above post i figured it out. I have not tested that yet on my PPC so I wouldn't have noticed the speed issue.

It really is good that people are finding interest in BurningSand one way or another.
 

colin9876

Active Member
Licensed User
All in one layer

Yes, its an interesting program, Will definately need some fast dll to do it though.
U know the BurningSand code is not very long, the dll library does most of it. Look at the micro version of BurningSand on the website its only 10lines long!!
I think we need to enlist the help of someone who understands the SDL.dll - theres loads about it on the web when I googled it.

By the way, if u look at BurningSand on the PC, none of it is in the foreground. All the elements overwrite what is directly underneath them when it is first placed. For example Sand/Water will create a hole in walls, solid etc.
I noticed that when puting some sand in water. When the water had made its way to the top there was actually slightly less sand - because the initial placing of water had overwritten the sand.

So basically its all done in one layer. Thats not a negative by the way!
 
Last edited:

neilnapier

Active Member
Licensed User
Longtime User
I am so happy that I found this forum and posted it here!!! My other topic on the other website (the BS one) only has had one page with just me and one other person who has posted.

As soon as moddability is done then this program will be much simplier to program as it will be much more minor things that will be implemented.

A Quick list of these are:
Swap gravity (so that things that go down g up and vic versa)
Borders on/off toggle
Load/save screen of sandbox
Pause
Slow speed/normal speed
Text pen

Then perhaps after that more things from BS2 will be implemented but that will be by far much more diffiult so I think it would be unlikely that it will be implemented.
 
Last edited:

colin9876

Active Member
Licensed User
Well Im really glad u introduced me to it, it was fun playing it today!
By the way looked at the BS forum, lots of silly talk about people getting banned from the site?! - u wouldnt think a program could cause so much contraversy lol!

None of the above are difficult functions, the only problem I see, as I keep saying, is to get it to run fast enough. We need to try and ask someone who knows about DLLS because that is the secret. It has librarys that do all the graphical stuff already written

Calling everyone...
Anybody out there know anything about SDL.dll ?
http://cs-sdl.sourceforge.net/index.php/The_absolute_newbies_guide_to_SDL.NET
 
Last edited:

neilnapier

Active Member
Licensed User
Longtime User
Colin, in BS2 there is the ability to use a forelyer but you are correct that there is no forelayer in BS1 which this is based on.

BS2 has about 100 different functions compared to the 4 in BS1 so that is why I based it on BS1.

Also there is a program called PocketSand that is a sandbox too.
 
Last edited:

colin9876

Active Member
Licensed User
Pocket Sand already?

Ive just taken a look at screenshots of the PocketSand u mentioned. It looks like a version of BurningSand!

So why are we doing this if its already been done?
 

neilnapier

Active Member
Licensed User
Longtime User
With that you are unable to mod for it. It is limited in what you can do it and the interactions are often unstable. Also there are a group of about 200 casual users of BS that would obviously prfer the GUI of BS to all others.

This is a worthy program to make most definetely.
 

colin9876

Active Member
Licensed User
pocket sand

Tried pocketsand - the graphics are good - again it uses the SML.dll to do the fast movements. I see what u mean about it being limited tho.
I mixed Salt & water and it didnt disolve the salt.
It just needs a few more things added to it - but it looks like its not been updated for a while.

Anyway as to PocketBS, Im stuck until we work out the function calls of SML.dll - its how all these sand programs are done
 

neilnapier

Active Member
Licensed User
Longtime User
You mean SDL not SML; anyway I'm not sure either about that. I suppose I could PM Sieben (creator of BS) and ask him if he knows anything of the sort.
 

neilnapier

Active Member
Licensed User
Longtime User
AH HA!!! I have found this site that has lots of sdl's for PPC!!!!!

Does that work???

EDIT: AH!!! Just checked it again... I searched for ppc but this doesn't have anything to do with pocket pcs!!!! BACK TO THE DRAWIG BOARD!!!
 
Last edited:

agraham

Expert
Licensed User
Longtime User
Sorry but I am about to rain on your parade. I am afraid you guys are attributing magic to SDL that does not exist.
U know the BurningSand code is not very long, the dll library does most of it. Look at the micro version of BurningSand on the website its only 10lines long!!
It's MUCH more than ten lines of appallingly tortured C code when unravelled and all that it is using the SDL library for is to get and set pixels on an SDL surface i.e. a bitmap. Any magic that exists in Burning Sand is in the logic of the physics engine and has nothing to do with SDL which is merely used as a conduit to the display.

With B4PPC you are facing a performance problem. The trade off-for the simplicity of B4PPC is the lack of performance and we are talking literally orders of magnitude here. To show you what you are up against I took your tt.sbp and moved the timer and destroy code into a library. Actually I cheated a bit by missing out the "rnd" and just did "py(i)=py(i)+1". This can smoothly handle about 500 points on my PPC but that gives no time left over for the physics calculations! This library uses a .NET standard bitmap and its GetPixel and SetPixel methods which are not very efficient. It could be improved by a factor of at least 10 by going in at a lower level. If you run this on a desktop keep the cursor away from the right side and bottom or you may get a crash - I didn't bother too much with limit checking.

So I am afraid that the bottom line is that to get a viable BS to run under B4PPC you would have to write it in a library - which rather defeats the point of the excercise of writing it in B4PPC! :sign0013:
 

Attachments

  • ttt.zip
    2.4 KB · Views: 287

agraham

Expert
Licensed User
Longtime User
Could you please add that to my proram please (wth blnDRAG and such)
Sorry but this library does nothing that is appropriate to your program. It accepts two arrays of pixels and drops them all down one pixel and draws them on the form background image whenever it is called. Your program (neatly done layout by the way) has no storage for pixel data.

In order to go further you will need a timer loop in which to redraw the data. Some physics logic to determine how each pixel moves. Storage for each pixels' state and any fixed elements and graphics code that understands how to render the stored data. Physics, storage and graphics must be designed together to execute as efficiently as possible on the given platform. As I pointed out you won't manage anything significant in B4PPC code. Just moving out the graphics won't help as the program will still bog down on the physics code with only a few points being capable of being supported in real time.
 

neilnapier

Active Member
Licensed User
Longtime User
Do you have any idea on what I should do then??? If I learn a new ppc language then I will have to start from scratch, which I really do not want to do... isn't there anyway you could work your system into mine???
 
Top