game-editor.com

[this is a quick code, 30 min coding]
I've managed to create a experimental water physics code using CollisionFree. (yay, no physical response!)
Source code released.
Also, make any suggestions if you will. I would like to improve it as much as possible.
The waters blue now! I'm just to lazy to change the screenshot.
(the .rar and .zip are the same, just download the one your prefer)

~meow (for old times sake)
EPIC! i have to know how this was done using collision free lolz

It's fairly nice to watch. Unfortunately though, as larger amounts of liquid will contain millions, yes, billions of pixel actors it won't be suitable for an actual game.
The computer even starts to lag in this version.
I think we'll have to find a way of drawing the water with canvas or something.

One of the pieces to this puzzle is the byte. As in, a variable of type byte.

When i used to hack GTA cars, i'd always see things in values of 0-127. I didn't understand it then cause i was a noob, but it makes sense now. That's a byte. Its how you pack a zillion things in.

Think of how easy it is to fill rgb values from a byte? byte x2. 127 * 2 = 254.

A byte is half the size of a standard int, right? That's twice as much water with almost the same code.

And is it just me, or is it super fun to type int in the forum text window just to watch the spellchecker call it an error. It also considers the word spellchecker to be an error.

not quite right DST... Instead of me explaining, go here!

http://en.wikipedia.org/wiki/Primitive_data_type

It is important for any programmer to know and understand the primitive data types.

Also, you should know that by making all your variables bytes, you're reducing your memory usage to 1/4 and not 1/2. Finally, saving memory space in this case will not change the performance considerably as the modern CPUs should use the about the same number of clock cycles to accomplish the same task regardless of the type (except if you are attempting to fetch variables larger than the size of your CPUs data bus).

to use unsigned bytes, declare them like this:

Code: Select all

unsigned char var_name;

I'm done rambling, ttyl all!

--pyro

LOL

What can I say?...

WOW!

can you post the source files please?

great man!

In ~30-60 minutes, I'll be optimizing the heck out of this thing.
Expect a new version in ~2-3 hours.

Good luck! Can just post the SOURCE files please??

I am really curious to know how do you do that.

The optimizing will be rather quick, so when I get home and finish with that, I'll post the files.

ok

pyrometal wrote:not quite right DST... Instead of me explaining, go here!

http://en.wikipedia.org/wiki/Primitive_data_type

It is important for any programmer to know and understand the primitive data types.

Also, you should know that by making all your variables bytes, you're reducing your memory usage to 1/4 and not 1/2. Finally, saving memory space in this case will not change the performance considerably as the modern CPUs should use the about the same number of clock cycles to accomplish the same task regardless of the type (except if you are attempting to fetch variables larger than the size of your CPUs data bus).

to use unsigned bytes, declare them like this:

Code: Select all

unsigned char var_name;

I'm done rambling, ttyl all!

--pyro

Correct on all accounts.

But also, I think what DST was getting at is that operations against an array of bytes is much more efficient and quick than using single pixel actors. There is a certain amount of memory usage overhead when operating an actors draw event, even when its empty. Internally GE is pushing all the registers to stack, then drawing that single pixel.. then popping registers from stack. And you do it all over again to move the pixel.

Interesting. My math says an int (from that wikipedia page, 16 bits) vs. an 8 bit byte should work out to 1/2, not 1/4.
(i'm not going to comment on what frameworks rely on long ints or short ints because i don't really know).

But you're correct that it wouldn't be faster, in fact, it might be slower, since some architectures doesn't actually use bytes, they convert them to int (full word) and block out the unnecessary bits.

If you can run true binary, however, bytes reduce the amount of necessary memory to run the game.

I got the idea from an article where the author writes an A* pathfinding grid with the nodes reduced to using bytes, giving him a working node size of <16 bytes, meaning his 1000 x 1000 grid (1 million nodes) only takes 18 mb to run.

I think that's pretty impressive based on what i know about A*, though i've a lot to learn about that too.

Of course, i have no idea which architectures he can actually use that on, and parentnode and distance may not be convertible to byte because of their size, and my A* isn't very efficient, though it works for single screen games (like...um....tower defense!) i do believe that guy understands A* thoroughly.


But however you can, you always have to reduce your code and simplify your math when dealing with quantum objects; whether bullets, particles, water, and most of all, RTS units.

Everything's fun and games until the user hacks the population limit and spawns 2,500 space marines on one map....as a warmup!

Its hard to make particle water though, so hats off to you, Dark!

A 32 bit machine handles 4 bytes at a time. Thats called a WORD, but the size of WORD changes with the architecture. A 64 bit machine has a WORD size of 8 bytes, or... 64 bits.

So 2 bytes to a 16 bit number.. DST is correct.

But those 2 bytes can accumulate a value of 65536, which is 256X256. 256*256*256*256 = 4294967296. 256 is 1/4 of a 32 bit number, so in that sense, Pyro is correct.

Shake hands gentlemen. You both know what you are talking about, and two evil genius minds should cooperate!

Source code released!