Pocket Burning Sand (Open Source)

colin9876 said:

Basically can dlls see Globals?

Click to expand...

No - only when explicitly passed as a parameter to a library call.

Does the transparency function work in C,

Click to expand...

This is a property of the object being drawn on, not of the language. I'm not a graphics person and don't know how this works. I also don't know how the forelayer works in B4PPC. The form background is available to a library by the form image property - whether that image also contains the merged forelayer I don't know. I'd draw on a bitmap from the imagelib library displayed in an image control using only setpixel and getpixel. That gives you a chance to later do the same things with the same logic but as low level pixel work in a library.


P.S. Don't think that I will necessarily write a library for you. As I said above I don't enjoy graphics work and have other things I am doing.

Thats ok

I'll write the library myself, its not long. Can u tell me though if theres a way to get a SDK to write a library without it costing a fortune? II see that Visual Studio is expensive!
I saw on the Microsoft site that I can 'download .Net SDK for free'
Can I use that?

SharpDevelop (free) plus the microsoft SDKS (also free). Never used it myself but others here have with some success.

On another foum I go on someone else was having the same sort of problem as we are having and he got the reply of

Well, it's made a little easier on the DS. A 128x96 sandbox at 8-bit accuracy takes less than a sixteenth of a frame to clear with a couple of tricks. You could apply some of these tricks, such as addressing the sandbox array twice - once in 8-bit (or whatever you use normally) and once in 32-bit (or as big as possible) and then wipe it clean in 32-bit chunks. That pretty neatly divides the time taken by four, as it's a 32-bit processor, meaning that it's working in its native size and has a shorter list of instructions to work with.

Click to expand...

Would that work with a PPC?

idea RuleSet -Worlds simplest programing language for kids

I did think about that point of storing the pixelcolour in less bits, I understand the logic of that, but theres a bit of extra processing to decode it. The lower resolution DOES indeed help e.g. pixel doubling (so u have a 160x120 res - thats what pocketsand does and its ok)

Anyway Ive gone off on a bit of a tangent, finding all the things that r possible with just changing moding rules. I see how that appealed to u now.

added on extra argument to my rule list and now I can make all sorts of games - even things like draughts - just from modding rules-
The extra thing is Probablity that the interaction will cause a element to change,
So rule(color1,color2)=(probability,colornew,dx,dy)
the probability is value from 0 to 1 if u want randomness, & or set to -n if u want it to occur after the nth interaction


e.g.
rule(water,metal)=(0.1,rust,0,0) '10% chace each drop water of will rust metal

or
rule(invader1,grow)=(-5,invader2,1,0) 'a starting pixel of an invader will grow 5 along
rule(invader2,grow)=(-3,invader3,0,1) 'then 3 down etc

I wrote set of 15 mod_rules where any dot placed on a block of growingcolor 'enlarged' into a space-invadershape (using the technique of progressing thro slightly different color shades), then further mod_rules can make it move

In a funny kind of way I think theres something in this ... (u might think Ive gone crazy) but its like the worlds simplest programing language.
I wonder if theres a market in this for kids programming . A programmer (Just by loading in a rule set u can do amazing things) with any dots drawn on the screen by the program user

The beauty of this is the rules could be entered in a spreadsheet, all the colours along the top, and down the side, and each box contain the values (prob, newcol, dx, dy)

It is very difficult to use BS modding to make supreme programs but it is possible. Using just elements and interactions people have made multipixel objects (things that move as one, that can even be picked up) and as i aid things like pacman.

the new BS2 language is much more vast but still pretty simple. I will show you an example of the new modding. This makes a shooting canon thing thatyou use to shoot enemies.

Thats code - looks complicated

That would put someone off if they werent a programmer,
In my file u enter 4 attributes for every colorcombination and thats it. You make all the programs just by adding the rules(col1,col2)=(prob,newcol,dx,dy) first, then using the pen to place dots in realtime things happen to them!

I can move things, fire bullets, virtually everything. The actual code routine is so simple. Less than 15 lines!

People may laugh but theres something in this!

Is this program you are talking about the PPCBS?

As I said before the BS language should be universal on all BSs. Therefore the element and reactions should stay more or less the same. I could let you remove some of the numbers but that is really it.

I really want to keep the interaction and element codes the same in the config. So it is littelry a pocket version of BS.

Well as I said Im kind of going off on a tangent with a 'Rules' programming language for kids. ive had a few more ideas with it, but back to BS I dont know the Moding language - can u explain it?
I think if its complicated it defeats the whole object! How hard is it?

neilnapier said:

On another forum I go on someone else was having the same sort of problem as we are having and he got the reply of ...
Would that work with a PPC?

Click to expand...

The answer is probably not. That technique only works for single byte per pixel 256 colour bitmaps which you probably won't find on a PPC .NET image or control. I'm pretty sure that pixels are 32bit integers on PPCs to support RGB colour, although the underlying displays usually can't handle the full gamut and the program specified values are often rounded to what the display can support. That kind of code requires pointers which you could only implement in a B4PPC library using "unsafe" C# or unmanaged C++ code.

colin9876 said:

BS I dont know the Moding language - can u explain it?
I think if its complicated it defeats the whole object! How hard is it?

Click to expand...

I have already made many posts on it including a link to a guide. This is based on BS1 NOT BS2 so all that BS1 has is 4 functions... very simple. Already there are hundreds of users of the modding language.
here is the guide:
--------------
Creating a New Group

Group [Name] [Order] [Icon/Text]

Name: The the name of the group. One word only
Order: The order of the group in the menu (1 is first, 9999 is last)
File Icon/Text: What it shows in the left menu to signify the group.

Examples:

Creating a New Element

To create a new Element, simply start a line like this (at the very bottom of you config.cfg file):

Element [Group] [Name] [Colour-Red] [Color-Green] [Color-Blue] [Weight] [Spray] [Slide] [Viscosity] [Deathrate] [Die to] [Order] [Icon/Text]

Group: The group that this Element is Categorized in. "None" means that it's not in any group. "Clear" means that it's in the first group of the original config, the one with the "X".
Name: The name of the Element. One word only. Can be two words, with an underscore in between.

Color-Red: In RGB what colour is it (0-255)
Color-Green: In RGB what colour is it (0-255)
Color-Blue: In RGB what colour is it (0-255)

Weight: The weight of the element... or how fast it falls... 0 means it cannot fall, 1000 means maximum falling ability. Going beyond 1000 has no real meaning in physics. However, doing so will determine the mass between Elements, which falls through which, etc.
Spray: The rate of this Element spreading apart in midair.
Slide: The rate of horizontal movement for the Element when it hits something. 0 means it will stay straight, any higher means it will spread out.
Viscosity: The rate of which an Element moves through this Element. Or the thickness. IT CANNOT BE 0.
Deathrate: The rate of this Element dying. 0 means it cannot die. 32768 means it dies instantly.
Die to: What the Element transforms into when it dies.
Order: The order of the Element in the Menu. (1-9999)
Icon/Text: What it shows in the right menu to signify the Element.

Examples:

Adding Interactions

Interactions are actually quite simple. To create a new interaction, start a line like this:

Interaction [Element] [Neighbor] [Element converts to] [Neightbor converts to] [Rate] [Except For]

Element: The Element that is starting the interaction
Neighbor: The Element that is touching it
Element converts to: What the Element changes into when the interaction starts. Clear means erase...
Neighbor converts to: What the Neighbor changes into when the interaction starts. Clear means erase...
Rate: Rate of change. 32768 means instant interaction.
Except for: When an interaction is made with "All", you can put ONE element here meaning "except for this"

Example:

Remember, elements and interactions combined in complex ways make good mods work. Try out different combinations, and it'll probably be easier for you to make a more complex mod by thinking it through before you make it.

A random mod not thought out, without much idea, or rushed will never end up as a good mod! Remember that.

Multiple Interactions

Sometimes you may want to include multiple interactions using one element in your mod. To do this, simply make... 2 interactions...

Example:

It makes sense. In this case, saltwater interacting with fire will not only make it turn into water, but also into salt. Thus an effect of "separation" occurs.
Saltwater + Fire = Water & Salt.

ok I see, it was the IFS and SETs and procedures in the BS2 that confused me.

Anyway all those BS1 commands I can do with
Rule(object1,object2)=(probability, object3, dx,dy)

for example for viscosity, rule that sand is heavier than water
Rule(sand,water)=(1,sand,0,0.2)

Still if its a replication of BS1 u want fair enough

Hello guy's,

I've been keeping track of the work you've been doing and have been trying to come up with some way of speeding things up for you.

My idea is to use the image library and set the pixels you want using values stored in an array.
The thinking behind this was that the array could be updated by user events or a timer event, and the screen could be refreshed independantly using a different timed event.

I'm still working on this but attached is a simple example which still needs work doing. It does not for instance reduce the N value which is the number of grains that are falling. Ideally this needs to be tracked somehow i.e first in first out.

Its still pretty slow on the device, but maybe you can adapt it to your own needs.

PS don't forget that you need to include the Imagelib.dll in your program folder on the device!!

Regards,
RandomCoder

It works quite well except from the inability to click down. Also would it be possible to change how spread out horizontally they spread (like spray)

EDIT: Oops I forogt the function mousemove... lol.

EDIT2: Just tried it on PPC... god that is slow.

Colin has already come up with ways of making the grains interact and making them spread out.
I was just trying to assist with speeding the program up on the device.
The idea being that the array of grains could be calculated and the bitmap updated as required, but every set number of milliseconds the screen would refresh with the latest bitmap. It doesn't matter if all grains have been assigned their new position when the screen refreshes as this is an ongoing process.

It's slow but maybe this approach can be improved upon?

PS On the device I've had to change the timer interval to 300 for timer 1 and 250 for timer 2 so that the limit speed of the device can keep up.

Regards,
RandomCoder.

pros and cons

Its an interesting idea updating the pixel positions independently of re-plotting them -I can see the logic in that. The only problem is that in the current design the code looks at the colour of the screen pixel where the grains going to move, to determine what interaction to do. Therefore the screen does need to be updated each time.
Thanks for the idea tho.

By the way Random, I was looking at ur SplatMaster game as want to get my head round the transparency fn, curious why does the cathead icon leave a line of pixels when it moves -(did that when I ran it on my machine - dont know if uve noticed?)

Colin how is the modding coming along?

I think that due to the speed on colins/agraham that would be the best option to use.

colin9876 said:

Its an interesting idea updating the pixel positions independently of re-plotting them -I can see the logic in that. The only problem is that in the current design the code looks at the colour of the screen pixel where the grains going to move, to determine what interaction to do. Therefore the screen does need to be updated each time.
Thanks for the idea tho.

Click to expand...

Yes I understand your dilemma, but if you look carefully at my demo I'm storing the grain's in an array. This can be done in the back ground exactly the same as you had intended, just instead of using the screen get and set pixels, you use the bitmap.

The screen can then be updated at a different interval.

To try to clarify the way I was thinking....
Say for instance it takes 3 seconds to update all grains of sand on the screen and that this was done using Colin's method i.e check the pixel, update the new position, delete the old pixel then redraw in the new position. Lets say that there was 300 grains in this example. Then that is a lot of going back and forward, first to check the screen and then to draw on the screen to delete the old grain and redraw it in a new position.
Now look at my approach, use an array to store each grain. Still use the same procedure as Colin but using the array instead of the screen. Now this can be happening in the background. The screen is just updated every quarter of a second which in our example would draw approximately 75 grains in one go.
I was hoping that by not having to update the screen so frequently there would have been a saving in the overall time taken.
Maybe my example is just poorly executed?
I'm mostly self taught and just do this for fun.

colin9876 said:

By the way Random, I was looking at ur SplatMaster game as want to get my head round the transparency fn, curious why does the cathead icon leave a line of pixels when it moves -(did that when I ran it on my machine - dont know if uve noticed?)

Click to expand...

I don't experience this behaviour on either the desktop or the device. At a guess it's probably to do with the call to erase the old image. To try and speed up the program I only delete the area that was occupied by the last image. For some reason it would appear that it is not erasing a large enough area on your machine. If you search for ferase you will find four instance's that delete the old image, try modifying these to see if it cures the problem.

Regards,
RandomCoder

ahhhh

1) Ur right, I described the problem with Splat the wrong way round - it actually works fine on the device. It leaves a trail running on the desktop. Question is could this be a 'bug' with v 5.80 as my stopwatch program ran differently on the desktop too?
*by the way ur programming style is very neat - how do u do the commands in colors?*

2) I understand what u mean but I already store the pixels in array. The reason it needs to look at the screen is
i) There are objects such as fixed walls that need to interact and are not stored in the array
ii) its much quicker to ceck the color of the pixel ur going to than check thro x(n),y(n) each time to see if any of the 1000's of pixels are in the spot ur going to move to

Anyway got round the speed prob now, Ive got it so 100 pixels can move in a reasonable time by keeping the recaculate routine to 5 lines. With AGrahams example of using a library this could speed it up 10x so it would be ok
Only issue if modding language, it will go fast with a simplified ruleset of
(object1,object2)=(Probability,object3,dx,dy)
but Neil wants the bs modding language which is more complicated so does take more processing!

A1) SplatMaster works correctly on the desktop for me, I've just tested it using V5.8 and nothing seems to have changed. I'm not sure why you are seeing part of the image remaining???.... it's probably linked with the size of the ferase area which should be the same size as the splat image.
The key words always appear in colour on the desktop, its part of the IDE. On the device, because of its limited memory and speed, everything is black and white.
(SplatMaster was the second application I wrote using B4PPC, which I tried to do completely in runtime. The only exception to that was the score board because it wasn't possible to add a table at runtime.)

A2) Yes the grains are stored in the array, but by using a bitmap you could still check for walls and obstacles. The thing I'm not sure about is if it is quicker to access the bitmap object or to update the screen?

Anyway, I'm glad that your making progress, it looks like an interesting challenge.

Regards,
RandomCoder