Latest Sphere development

[tung]

I'm getting a compilation error about "io.h" in your new zlib class.

Code:

[tung@eee sphere]$ scons
scons: Reading SConscript files ...
os.name: posix
Using compiler: linux
Found sdl-config: /usr/bin/sdl-config
Using subsystem: unix
Found sdl-config: /usr/bin/sdl-config
Found wx-config: /usr/bin/wx-config
Found sdl-config: /usr/bin/sdl-config
Found sdl-config: /usr/bin/sdl-config
scons: done reading SConscript files.
scons: Building targets ...
g++ -o source/engine/script.o -c -DNO_WRITE_MNG -DUNIX -D_GNU_SOURCE=1 -D_REENTRANT -DXP_UNIX -Isource/common -I/usr/include/js -Isource/particle_engine -I/usr/include/SDL -Isource/engine/unix source/engine/script.cpp
In file included from source/engine/script.cpp:32:
source/engine/../common/zlibengn.h:26:16: error: io.h: No such file or directory
scons: *** [source/engine/script.o] Error 1
scons: building terminated because of errors.

What sort of header is "io.h" supposed to be? Should it be packed with Sphere? What's it used for?

[FutureBoyNil]

Well, io.h is only used for filelength(), and that is not included under linux (http://poli.cs.vsb.cz/c/help/io.htm#LBL42), nice Window nice.... *SLAM! POW!* good boy!
I read this page, it helped solve the problem (they suggest using fstat() or stat() instead):

http://forums.fedoraforum.org/archive/index.php/t-53378.html

Window's fstat worked (http://poli.cs.vsb.cz/c/help/io0.htm#LBL23), and I hope its cross compilable.

cvs update.

you can test like this:

Code:

function game(){
DeflateFile("../scripts/main.js","main.js_",9);
InflateFile("main.js_","main.txt");
}

I still need to test bigger, binary files though... (as small files dont compress, they actually get bigger)

[N e o L o g i X]

a great test file would be an uncompressed riff wave. it's not likely to become as small as if it were aac compressed, but it'd still become up to 50% smaller.

[Kyuu]

@FutureBoyNil:

It seems engine.vcproj is broken. I get the following error trying to open it:

Code:

The following error has occurred during XML parsing:

File: C:\Projects\sphere\source\engine\engine.vcproj
Line: 26
Column: 4
Error Message:
Property sheet file '.\debug.vsprops' was not found or failed to load.
The file 'C:\Projects\sphere\source\engine\engine.vcproj' has failed to load.

Also, while looking through your latest changes (4 days ago) to engine.vcproj I noticed that you added a bunch of additional library directories, which are specific to your environment and therefore should not be in engine.vcproj:

Code:

AdditionalLibraryDirectories=""C:\Documents and Settings\nilton\My Documents\nilton\RPG\source\sphere
\third-party-msvc\include\smjs";"C:\Documents and Settings\nilton\My Documents\nilton\RPG\source
\sphere\third-party-msvc\include";"C:\Program Files\PSDK\misc";"C:\Program Files\PSDK
\Include";"C:\Program Files\PSDK\Lib";"C:\Documents and Settings\nilton\My
Documents\nilton\RPG\source\sphere\third-party-msvc\lib";"C:\Documents and Settings\nilton\My
Documents\nilton\RPG\source\sphere\third-party-msvc\dll";"../../third-party-msvc/lib""

You can put specific library directories to Tools -> Options... -> Projects and Solutions -> VC++ Directories.

Btw: Have you thought about adding real collision bitmasks instead of misusing the surface object? Real bitmasks would be much faster and cache friendlier than you current approach, so it might be a good point to think about it.

[N e o L o g i X]

i'm still pushing for the visibone IsInPoly function as well.

[Kyuu]

@Neo:

You mean to detect collisions between polygons? I imagine using is-in-polygon algorithms for this purpose would be very slow. A much better approach here would be the Separating Axis Theorem.

[FutureBoyNil]

@Neo: 50%? Too optimistical! (deflate != flac).
238Kb wav 11,025 Hzm stereo 1:48 (deflates to: 217Kb)
102Kb html (deflates to 16Kb).
together they take less than a second on my PC.

@Kyuu: Err... that's sloppiness on my behalf. Sorry about that. Roll it back.
I was more thinking about creating spritesets with a direction north_coll, which then translated into a surface. But bits... hmm, you get 8 pixels into one char, and using bitwise shifting it's easy to offset them.
My idea was that sprite to background collision and sprite to sprite collision behavior across games is so much different. Example:

Here, the players do not collide, until one of them punches, while in games like manic miner, just touching the baddies will make you lose a life.
I dont want to change the obstruction block, because that determines where my Person will be put at (the center of the pink block will be aligned with the center of a tile). I need it to be somewhat backwards compatible with older games.
Making sprite to background collision pixel perfect, there is the problem with the moving legs, you can get stuck into the background during a certain frame, behavior on what to do (go up x pixels, as most platformers do, or move back x pixels) is not defined. Algorithms like lithonite can smoothen the problem, but it would still be hard to define the behavior. So the best thing is to provide a quick collision detection using bitmasks, and leave the implementation details to the programmer.

[Kyuu]

I'm not sure what you mean, I didn't say you should change the way Sphere handles obstructions.
You said earlier that you added surface_object.findColor(color) in order to be able to perform pixel perfect collision detection, which seemed overkill in my eyes, so I suggested to use real bitmasks instead. The advantages in doing so are obvious:

* cache efficiency, because the data needed to be cached is reduced by the factor 32
* you can use cheap bitwise operations instead of having to use expensive 32-bit blending

Of course, using a bitmask will add complexity, because you need to use offsets and you will loose the abstraction of the already implemented blitting, but in the end it should be a much more elegant solution.

[FutureBoyNil]

I'm having doubts if the function should be: DeflateByteArray() or bytearray.deflate(), if we change that, then HashByteArray() should also change to bytearray.hash(); Opinions?

[Kyuu]

bytearray.deflate() sounds good, but if you change HashByteArray() to bytearray.hash() you will break all games, which use HashByteArray().

If you want to overhaul Sphere's API (changing global functions into methods, adding class constructors, etc., which was the intention of the experimental Sphere v2), you should branch and continue from there. Once you finish, the experimental branch can be merged with the official branch.

[FutureBoyNil]

bitmask collision detection library: pmask (made for allegro, but should be tweakable to suit our needs)
More are here:
http://www.codemonsters.de/home/content.php?show=freelibraries#6

[tung]

There was a problem with trying out the zlib routines on Linux, but I fixed them, and here's how.

I added sfxr.cpp and ssfxr.cpp to the engine's SConscript, and zlibengn.cpp to common's SConscript. That got it to build under Linux with scons.

Attempting to run engine with DeflateFile() got me a long message, including this stack trace.

Code:

======= Backtrace: =========
/lib/libc.so.6[0xa7bd6ee4]
/lib/libc.so.6(cfree+0x9c)[0xa7bd87bc]
/usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0xa7d9e971]
./engine[0x80cea6d]
./engine[0x80d07bd]
/usr/lib/libjs.so(js_Invoke+0xa92)[0xa7f6c33f]
/usr/lib/libjs.so(js_Interpret+0x7184)[0xa7f7390c]
/usr/lib/libjs.so(js_Execute+0x2f6)[0xa7f796d9]
/usr/lib/libjs.so(JS_EvaluateUCScriptForPrincipals+0x90)[0xa7f40a37]
/usr/lib/libjs.so(JS_EvaluateUCScript+0x43)[0xa7f40abc]
/usr/lib/libjs.so(JS_EvaluateScript+0x68)[0xa7f43785]
./engine[0x80bae4c]
./engine[0x8053b9f]
./engine[0x80e04aa]
./engine[0x80e09c6]
./engine[0x80e0d1a]
./engine[0x812b905]
/lib/libc.so.6(__libc_start_main+0xe5)[0xa7b816c5]
./engine[0x804d4f1]

I searched for info on reading Linux stack traces and found this, which told me about the addr2line command. Given a binary and an address, it could print the file and line from which it came.

I used addr2line on all of the ./engine lines, which got me this:

Code:

[tung@eee linux]$ addr2line -e engine 0x80cea6d
/home/tung/Projects/sphere/source/engine/script.cpp:395
[tung@eee linux]$ addr2line -e engine 0x80d07bd
/home/tung/Projects/sphere/source/engine/script.cpp:7184
[tung@eee linux]$ addr2line -e engine 0x80bae4c 0x8053b9f 0x80e04aa 0x80e09c6 0x80e0d1a 0x812b905
/home/tung/Projects/sphere/source/engine/script.cpp:536
/home/tung/Projects/sphere/source/engine/engine.cpp:171
/home/tung/Projects/sphere/source/engine/sphere.cpp:284
/home/tung/Projects/sphere/source/engine/sphere.cpp:351
/home/tung/Projects/sphere/source/engine/sphere.cpp:91
/home/tung/Projects/sphere/source/engine/unix/unix_main.cpp:211
[tung@eee linux]$ addr2line -e engine 0x804d4f1
??:0

The stack is in order from the function that caused the error, to the function that called that one, and so on to the top. So source/engine/script.cpp line 395 is where I headed.

With CVS annotate, I found who last edited script.cpp at line 395: futureboynil. The changeset shows him adding/changing a function on last Friday (27 Feb 2009): DoesFileExist.

Line 395 of source/engine/script.cpp looks like this:

Code: (c++)

static bool DoesFileExist(const char* pathandfile)
{
	FILE *f = fopen(pathandfile, "r"); 
	bool found = f ? true: false;
	if(found) fclose(f);
	delete f;
	return found;          // <- line 395
}

As it turns out, the offending line is not the return, but it's pretty close: the delete. Since C FILE handles aren't meant to be free()'d (or delete'd), the program crashed. Removing the line makes DeflateFile() and InflateFile() work as expected under Linux. Problem solved.


@fbnil: It's recommended that you use #include <cmath> instead of #include <math.h>, which is explained here.

Also, avoid tabs, since the rest of the script.cpp file and other files use spaces for indentation.

[FutureBoyNil]

Excelent work Tunginobi, thank you for squashing that one (looked pretty complex...). I'll look into cmath.

[FutureBoyNil]

Suggest to:
* graphics.js: Remove Rizen's script. Its functionality is being offered by:
   OutlinedRectangle() and Polygon(array, color , true);
   otoh, its not hurting anyone (like Firemoth's and DN7's scripts), but boy does it lack functionality... keep the name and put in some useful code.
* colors.js: Add more colors
  I added CreateColorHex() and CreateColorNamed(), so:
  Red, CreateColorHex('#FFFFFF') and CreateColorNamed('Red') are the same. Named has 300 colors... too many actually.
  Then I _tried_ to add more normal colours, by allowing the values to be 0, 128 or 255, this resulted in the following colours:
  Orange  = CreateColor(255, 128, 0,   255);
  Gray    = CreateColor(128, 128, 128, 255);
  Then I pretty much got stuck thinking about what Brown should look like.... and confused lila with fuchsia.
  Old computer manufacturers, restricted their colours in very different ways, no silver bullet:
  http://en.wikipedia.org/wiki/List_of_8-bit_computer_hardware_palettes
* colorspaces.js should RequireSystemScript('math.js'); and use those Deg2Rad and Clamp functions.
* circles.js by Genocyber. Remove; obsoleted by: OutlinedCircle() and GradientCircle()
* clock.js by WIP: added pause
* input.js added escape possibility
* merge old_spriteset.js and oldsphere.js into old_sphere.js
* Add print.js, json2.js, unittest.js, kcl*.js, persist.js, object.js and others.

[N e o L o g i X]

re colors.js:

i highly recommend that if named colors are added first we start w/web/x11 color names. acc. to wikipedia web colors article many names/hex values overlap w/x11 color set as well.