Irrlicht in Native Client

[centipede]

I am trying to build Irrlicht (http://irrlicht.sourceforge.net) for
Nacl. It works a little bit. I'm getting a file access error which
somebody here may be able to explain.

There's an archive of the source here: http://atomicmonstergirls.net/work/nacl/my-irrlicht-0.1.tar.gz
Just unpack it alongside the other tests so it becomes <nacl>/
googleclient/native_client/tests/my-irrlicht

PLEASE NOTE! ... that I have copied the nacl sdk into /opt/nacl and
added it to the path. Thus:
nacl-gcc is in /opt/nacl/bin/nacl-gcc
includes are in /opt/nacl/include
libs are in /opt/nacl/lib

I've gotten it to work proof-of-concept-like with very few
modifications, namely adding a new minimal CIrrDeviceNaCl and skipping
some file path stuff. I've merged Irrlicht's include and source folder
into the same folder. There's a diff file in the "irrlicht"
subdirectory (DIFF_BETWEEN_NACLIRRLICHT_AND_PUREIRRLICHT.diff). For
the copy-pasters of the world:

Unpack:
cd <nacl>/googleclient/native_client/tests
wget http://atomicmonstergirls.net/work/nacl/my-irrlicht-0.1.tar.gz
tar -xzf my-irrlicht-0.1.tar.gz

Build:
cd <nacl>/googleclient/native_client/tests/my-irrlicht
cd irrlicht
CC=nacl-gcc CXX=nacl-gcc AR=nacl-ar make
cd ..
make nacl debug

Run:
./sel_ldr -d testirrlicht.nexe

Never mind the colors. I haven't made a proper conversion from RGB565
that Irrlicht's software renderer creates to RGB888 that Nacl uses. I
plan to code another rasterizer anyway.
You also have to move the mouse around inside the window to see any
updates on the screen, as I'm not using a thread/timer yet.

If you do not add the -d flag to sel_ldr, then I'm getting an error
trying to open a local file:
[0000383d:11:17:53.569903] IGNORING Invalid access mode bits 0666
[0000383d:11:17:53.569925] NaClSysOpen: Path: ./media/sydney.md2
[0000383d:11:17:53.569975] NaClOpenAclCheck(0xbf942ce0, ./media/
sydney.md2, 00, 0600)
Could not load mesh, because file could not be opened.: ./media/
sydney.md2

Permissions of the involved files:

drwxrwxrwx 2 rene users 4096 2008-12-14 08:04 media
-rw-rw-rw- 1 rene users 60522 2008-12-14 07:15 media/sydney.bmp
-rw-rw-rw- 1 rene users 302128 2008-12-14 07:15 media/sydney.md2

I'd appreciate any hint on the matter.

Happy New Year :)
Rene Jensen / Centipede

[Bennet Yee (余仕斌)]

hi,

NaCl modules are not permitted to open local files; without controls,
this could end up being a privacy problem. please see how quake and
the url-as-NaCl-desc test for how we make files/file-like resources
available to NaCl modules, and this obeys (a strict form of) the
same-origin policy. note that the descriptor passing for the url is
done as a read-only I/O descriptor, since this might be an object in
the browser cache.

-bsy

--
bennet s yee
i usually don't capitalize due to mild tendonitis

[gtar...@gmail.com]

Great work centipede! Surely irrlicht is more suitable for porting,
and what you' ve done looks very promising, I' ll keep an eye on It. I
think what Bennet suggested is the best way to follow, nacl is very
strict. If anyone knows how the quake demo deals with meshes and local
things like that He would save me a lot of time! Thanks and happy new
year!!

> > wgethttp://atomicmonstergirls.net/work/nacl/my-irrlicht-0.1.tar.gz

[centipede]

I've been waiting like fifteen years for something like nacl to
happen. I really hope that the project will not be canned ;-)

Question about fileloading via SRPC. From the examples I have gathered
the following picture. All file loads are basically initiated by
JavaScript...

1) JS: Get a reference to the NaCl plugin like this:

plugin = document.getElementById('my-nacl-embed');

2) JS => C++: Invoke a method called __urlAsNaClDesc on the plugin,
which checks the url, and opens a file descriptor to it. Funny enough,
this method seems to be only reachable from Javascript, not from the
plugin itself?!

plugin.__urlAsNaClDesc(url, new MyHandler("media/something.jpg"));

3) C++ => JS: One of the parameters to __urlAsNaClDesc is a reference
to a JS object which must have two methods: onload(filedesc) and onfail
(object). Either one or the other is invoked depending on the legality
of the url given to __urlAsNaClDesc...

var MyHandler = function (theFileName) {
this.fileName = theFileName
this.onload = function (theFileDescriptor) { }
this.onfail = function (object) { }
}

4) JS => C++: Via the SRPC interface, JavaScript hands over the file
descriptor to C++ through some function that the C++ plugin must
export...

...
this.onload = function (theFileDescriptor) {
// Invoke the SRPC handler that ends up using the file
descriptor for loading
plugin.myHandler (theFileDescriptor, this.fileName)
}

5) C++: Load and cache the file through an implementation of the
handler mentioned above.

int myHandler (NaClAppArg **in_args, NaClAppArg **out_args);
NACL_SRPC_METHOD("myHandler:hs", myHandler);

int myHandler (NaClAppArg **in_args, NaClAppArg **out_args) {
int filedesc = in_args[0]->u.hval;
char* filename = in_args[1]->u.sval;
FILE* file = fdopen (filedesc, "r");
// ... Check for errors, read from the file, cache the data.
fclose(file);

// Or to put it into the framework below... call
myRetreiveFileDescFromJS (filename, fd)
return RPC_OK;
}

I'd like to have a "step 0" in the above scheme, where I can call out
from C++ to JS and start the (probably highly asynchronous) process of
retrieving a file descriptor and putting it back to C++. So basically
we replace this simple C operation:

file = fopen("media/something.jpg", "r");

with all the JS above plus this C++:

map<string, int> globalFileDescriptors;
pthread_cond_t globalFDCond = PTHREAD_COND_INITIALIZER;
pthread_mutex_t globalFDMutex = PTHREAD_MUTEX_INITIALIZER;

void loadSomeTexture()
{
askJStoLoadFile("media/something.jpg");

// Sleep until JS has reported back via the SRPC function
below.
pthread_mutex_lock( &globalFDMutex );
while (globalFileDescriptors.find)"media/something.jpg") ==
globalFileDescriptors.end())
pthread_cond_wait( &globalFDCond, &globalFDMutex );
pthread_mutex_unlock( &globalFDMutex );


}

void myRetreiveFileDescFromJS (filename, fd)
{
globalFileDescriptors[filename] = fd;
pthread_mutex_lock( &globalFDMutex );
pthread_cond_signal( &globalFDCond, &globalFDMutex );
pthread_mutex_unlock( &globalFDMutex );
}


It all seems a bit elaborate :)

Now for the questions: First, before I go on, I would like to hear
that this is the simplest way of doing things.
Second, assuming that it is, I'd be happy if somebody could point me
to a code example where invocation from C++ => JS takes place. I would
much prefer to use SRPC alone to keep dependencies to a minimum.

Cheers


P.S. gtardini... Don't give up on Ogre yet. I'd be happy to cooperate
on that one once Irrlicht is running steady and I've had some fun with
it. After Irrlicht, I'd probably mess with a sound library next
though.

On Jan 1, 2:01 am, Bennet Yee (余仕斌) <b...@google.com> wrote:

> > wgethttp://atomicmonstergirls.net/work/nacl/my-irrlicht-0.1.tar.gz

[gtar...@gmail.com]

Mmm this is just my second nacl day and I understand why You say You'
ve been waiting It for 15 year! I thank You a lot for the knowledge
You' re sharing with everyone and I wanted to say something about file
loading: in the earth example It loads the texture through an
hexadecimal file, and replacing the code inside the "earth_image.inc"
file with the one of another jpg It changes the texture, so I think
that loading files in this way would be great since the only needed
effort is the conversion, am I right? Maybe I' ve just misunderstood
everything, but It looks quite convenient.

[centipede]

Heh, easy, they did the hard work. I'm only sticking to the trivial
stuff ;-)

Embedding binary data in the code... sure, one could do that, but it
won't necessarily become any easier. In projects like Irrlicht, where
they have wrapped the file access into a CFileSystem class, there's a
chance of substituting the file loading procedure { fopen(), data=fread
(), fclose() } with a simple { return the_global_data_array; }
In other kinds of projects, they usually have direct access to the
FILE* handle. Takes a lot of changes.

Then there's the issue of streaming. Embedding 200MB video files does
increase the size considerably. It all depends on what one is working
on, I guess.

The method with Javascript and Srpc does seem convoluted, but it
amounts to the size of the email approximately, compared to a huge
amount of small changes in the engine code itself. Plus you also get
something else in the bargain: Early response because the browser can
start to show information ("Loading textures... 60%"). Besides
embedding data in the source basically mean you have to discard e.g.
Ogre's very advanced resource management subsystem. Quite a loss.

Dunno what the best solution would be, but I'm going for whatever is
ready to use..

[gtar...@gmail.com]

I' ve tried your srpc method and It' s surely more flexible and I
think It' s the right way, also because I haven't found anything else
about srpc loading in the examples and in the api docs. For what
concerns your question I think this article may help you
http://www.codeguru.com/cpp/i-n/ieprogram/article.php/c4399 . Hope
It' s useful!

[centipede]

I am having trouble getting the srpc approach to work.
Apparently the following call never triggers a callback to MyHandler:

myPlugin.__urlAsNaClDesc(url, new MyHandler("media/sydney.md2"));

I have tried two approaches:
1) With only one main thread which blocks before the __urlAsNaClDesc
is executed, waiting for the consequence of the call
2) With two threads in the nacl module: One which blocks waiting for
the descriptor being handed over through srpc and the main thread
which just exits.
Both give the same response: MyHandler never being invoked

I've uploaded the code. Same procedure...

Unpack:
cd <nacl>/googleclient/native_client/tests
wget http://atomicmonstergirls.net/work/nacl/my-irrlicht-0.2a.tar.gz
tar -xzf my-irrlicht-0.2a.tar.gz

Build:
cd <nacl>/googleclient/native_client/tests/my-irrlicht
cd irrlicht
CC=nacl-gcc CXX=nacl-gcc AR=nacl-ar make
cd ..
make nacl debug

Run:

firefox testirrlicht.html # You need to close firefox before
starting if you want the output to appear in the bash prompt

You should see something like this in the shell:
make: Native Client target specified
make: Nothing to be done for `debug'.
NPP_Initialize
NPP_New 'application/x-nacl-srpc'
NPP_SetWindow
NPP_SetWindow
NPP_NewStream
NPP_StreamAsFile: /home/rene/Projects/work/nacl/googleclient/
native_client/tests/my-irrlicht/testirrlicht.nexe
starting: /home/rene/.mozilla/plugins/sel_ldr
/home/rene/.mozilla/plugins/sel_ldr_bin: /usr/lib/libcrypto.so.0.9.8:
no version information available (required by /home/rene/.mozilla/
plugins/sel_ldr_bin)
Irrlicht Engine version 1.5
NaClIrrlicht0.1
nacl_thread_id: 0x6E74D0 0x6E74D0
NPP_DestroyStream
nacl_av: embedded in browser
nacl_av: multimedia NOT initialized
NPP_SetWindow
Waiting for file media/sydney.md2 to arrive


Cheers,
Centipede

On Jan 2, 1:16 pm, "gtard...@gmail.com" <gtard...@gmail.com> wrote:
> I' ve tried your srpc method and It' s surely more flexible and I
> think It' s the right way, also because I haven't found anything else
> about srpc loading in the examples and in the api docs. For what

> concerns your question I think this article may help youhttp://www.codeguru.com/cpp/i-n/ieprogram/article.php/c4399 . Hope

> ...
>
> read more >>

[gtar...@gmail.com]

What do you mean? The C++ code doesn' t give anything back to the
javascript? Or the C++ function isn't executed at all? If the problem
is the first you can write another js function to be called using the
method described in the article I posted previously. When I come back
home I' ll try to compile the second version of your irrlicht, your
project is really interesting, thanks again!

On 2 Gen, 18:22, centipede <centipede...@gmail.com> wrote:
> I am having trouble getting the srpc approach to work.
> Apparently the following call never triggers a callback to MyHandler:
>
> myPlugin.__urlAsNaClDesc(url, new MyHandler("media/sydney.md2"));
>
> I have tried two approaches:
> 1) With only one main thread which blocks before the __urlAsNaClDesc
> is executed, waiting for the consequence of the call
> 2) With two threads in the nacl module: One which blocks waiting for
> the descriptor being handed over through srpc and the main thread
> which just exits.
> Both give the same response: MyHandler never being invoked
>
> I've uploaded the code. Same procedure...
>
> Unpack:
> cd <nacl>/googleclient/native_client/tests

> wgethttp://atomicmonstergirls.net/work/nacl/my-irrlicht-0.2a.tar.gz

> > concerns your question I think this article may help youhttp://www.codeguru.com/cpp/i-n/ieprogram/article.php/c4399. Hope

> ...
>
> leggi tutto

[centipede]

Hard to say what happens since __urlAsNaClDesc lies buried deep within
the NaCl environment code.

I appreciate your effort in finding information about C++-to-
javascript... but eh.. that was MFC-code in Internet Explorer :-)
Might be a bit outside this scope.
There is an example of how to do it the NPAPI way in the nacl tests
folder somewhere. Anyway, it's no that horrible to have to open all
files from javascript first, so stricly speaking, I don't need that
callback. It just becomes a bit annoying to have to update the .html
file each time I add a mesh or a texture. Doesn't hurt.

Cheers

> ...
>
> read more »

[gtar...@gmail.com]

Ahah oh my God, that was embarassing! Maybe I haven't checked the code
very carefully ;) Sorry! But does the mesh get loaded?

> ...
>
> leggi tutto- Nascondi testo citato
>
> - Mostra testo citato -

[centipede]

Embarrassing! It was a stupid JavaScript bug. I'm a bit further now.
Change these line in "testirrlicht.html" from:

myPlugin.__urlAsNaClDesc(url, new MyHandler("media/
sydney.md2"));
myPlugin.__urlAsNaClDesc(url, new MyHandler("media/
sydney.bmp"));
to
myPlugin.__urlAsNaClDesc("media/sydney.md2", new
MyHandler("media/sydney.md2"));
myPlugin.__urlAsNaClDesc("media/sydney.bmp", new
MyHandler("media/sydney.bmp"));

Doh!

> ...
>
> read more »

[centipede]

This version has browser action...
Unpack:
cd <nacl>/googleclient/native_client/tests
wget http://atomicmonstergirls.net/work/nacl/my-irrlicht-0.2.tar.gz

tar -xzf my-irrlicht-0.2a.tar.gz
Build:
cd <nacl>/googleclient/native_client/tests/my-irrlicht
cd irrlicht
CC=nacl-gcc CXX=nacl-gcc AR=nacl-ar make
cd ..
make nacl debug
Run:

firefox testirrlicht.html # Close firefox first

You need to move the mouse around inside the browser before screen
updates will take place :)
I'm out of time for the rest of the weekend until somewhere around
thursday. Then I'll start to work completing the CIrrDeviceNaCl with
input and all that funny stuff (on proper screen refreshing). Adding
to that, I need to try the second software renderer in Irrlicht. It is
32bit RGB8888, like NaCl, does proper 3D clipping (the current one
doesn't do any clipping), but it is also a bit slower. If that isn't
too good either, I have some code in the drawer for a simple
rasterizer. One could also try to pull the rasterizer from Quake, but
personally I'm more familiar with my own ;-)

'be seeing you
Centipede

> ...
>
> read more »

[KKI]

Hi, centipede

Here is a quick hack to correct color.

http://demo-n.e-neta.jp/files/MacOSX/nacl-irrlicht-0.2.patch

This is a screen shot.

http://demo-n.e-neta.jp/files/MacOSX/nacl-irrlicht.png

On 1月3日, 午後7:16, centipede <centipede...@gmail.com> wrote:
> This version has browser action...
> Unpack:
> cd <nacl>/googleclient/native_client/tests

> wgethttp://atomicmonstergirls.net/work/nacl/my-irrlicht-0.2.tar.gz

> ...
>
> もっと読む >>

[SATOH Keiki]

Hi, centipede

Here is a quick hack to correct color.

--- my-irrlicht.orig/irrlicht/CIrrDeviceNaCl.cpp 2009-01-03
17:39:02.000000000 +0900
+++ my-irrlicht/irrlicht/CIrrDeviceNaCl.cpp 2009-01-03 19:35:24.000000000 +0900
@@ -17,6 +17,7 @@
#include <stdio.h>
#include <stdlib.h>
#include "SIrrCreationParameters.h"
+#include "CColorConverter.h"

uint32_t * pixelBuffer;

@@ -342,16 +343,8 @@
bool CIrrDeviceNaCl::present(video::IImage* surface, void* windowId,
core::rect<s32>* srcClip)
{
uint16_t* data = (uint16_t*) surface->lock();
- int i=0;

- for (int y=0; y<400; ++y)
- {
- for (int x=0; x<800; ++x)
- {
- pixelBuffer[i] = data[i];
- i++;
- }
- }
+ video::CColorConverter::convert_A1R5G5B5toA8R8G8B8(data, 800*400,
pixelBuffer);

surface->unlock();

This is a screen shot.
http://demo-n.e-neta.jp/files/MacOSX/nacl-irrlicht.png

2009/1/3 centipede <centip...@gmail.com>:
- 引用テキストを表示 -

--
Keiki SATOH (a.k.a. KKI)

[SATOH Keiki]

Hi, centipede

Here is a quick hack to correct color.

http://demo-n.e-neta.jp/files/MacOSX/nacl-irrlicht-0.2.patch

This is a screen shot.
http://demo-n.e-neta.jp/files/MacOSX/nacl-irrlicht.png


2009/1/3 centipede <centip...@gmail.com>:
>

[centipede]

Thanks Sato.
Your patch is in now. Nice to see that it works on Mac as well, btw.

wget http://atomicmonstergirls.net/work/nacl/my-irrlicht-0.2.1.tar.gz

- Centipede

On Jan 3, 12:07 pm, "SATOH Keiki" <keiki.sa...@gmail.com> wrote:
> Hi, centipede
>

> Here is a quick hack to correct color.http://demo-n.e-neta.jp/files/MacOSX/nacl-irrlicht-0.2.patch

>
> This is a screen shot.http://demo-n.e-neta.jp/files/MacOSX/nacl-irrlicht.png
>

> 2009/1/3 centipede <centipede...@gmail.com>:

>
>
>
> > This version has browser action...
> > Unpack:
> >        cd <nacl>/googleclient/native_client/tests

> >        wgethttp://atomicmonstergirls.net/work/nacl/my-irrlicht-0.2.tar.gz

> ...
>
> read more »

[gtar...@gmail.com]

I tried to compile It, but there were problems, It said:


gio@gio-laptop:~/Desktop/nacl/googleclient/native_client/tests/my-
irrlicht$ make nacl debug

make: Native Client target specified

/home/gio/Desktop/nacl/googleclient/third_party/nacl_sdk/linux/sdk/
nacl-sdk/bin/nacl-g++ testirrlicht.cc libIrrlicht.a -I/home/gio/
Desktop/nacl/googleclient -g -Wall -Werror -I./irrlicht -O0 -g -lav
-lsrpc -lpthread -lm -o testirrlicht_debug.nexe
testirrlicht.cc:59: error: ‘NaClAppArg’ was not declared in this scope
testirrlicht.cc:59: error: ‘in_args’ was not declared in this scope
testirrlicht.cc:59: error: ‘NaClAppArg’ was not declared in this scope
testirrlicht.cc:59: error: ‘out_args’ was not declared in this scope
testirrlicht.cc:59: error: initializer expression list treated as
compound expression
testirrlicht.cc:60: error: invalid conversion from ‘int’ to ‘int (*)
(NaClSrpcChannel*, NaClSrpcArg**, NaClSrpcArg**)’
testirrlicht.cc:62: error: redefinition of ‘int myHandler’
testirrlicht.cc:59: error: ‘int myHandler’ previously defined here
testirrlicht.cc:62: error: ‘NaClAppArg’ was not declared in this scope
testirrlicht.cc:62: error: ‘in_args’ was not declared in this scope
testirrlicht.cc:62: error: ‘NaClAppArg’ was not declared in this scope
testirrlicht.cc:62: error: ‘out_args’ was not declared in this scope
make: *** [testirrlicht_debug.nexe] Error 1


and so I had to change some lines of the code:

from:

int myHandler (NaClAppArg **in_args, NaClAppArg **out_args);
NACL_SRPC_METHOD("myHandler:hs:", myHandler);

int myHandler (NaClAppArg **in_args, NaClAppArg **out_args)
{

to:

int myHandler (NaClSrpcChannel *channel, NaClSrpcArg **in_args,
NaClSrpcArg **out_args);

NACL_SRPC_METHOD("myHandler:hs:", myHandler);

int myHandler (NaClSrpcChannel *channel, NaClSrpcArg **in_args,
NaClSrpcArg **out_args)
{

and It worked
.

I' m compiling on my Ubuntu 8.10 machine, maybe It' s only a platform
dependent error.. Hope It' s useful if anyone else had my same
problem. (the version was the last You posted
http://atomicmonstergirls.net/work/nacl/my-irrlicht-0.2.1.tar.gz ).

On Jan 3, 12:56 pm, centipede <centipede...@gmail.com> wrote:
> Thanks Sato.
> Your patch is in now. Nice to see that it works on Mac as well, btw.
>

> wgethttp://atomicmonstergirls.net/work/nacl/my-irrlicht-0.2.1.tar.gz

> ...
>
> read more »

[centipede]

Thanks mate. I'll look into it.
I see that Nacl has been bumped to a newer release version. I reckon
that I am using nacl_linux_0.1_9380090.tgz. It looks like a pure
version issue, not anything Ubuntu specific or otherwise platform
related.

> ...
>
> read more »

[gtar...@gmail.com]

Don't mention It! Yes, in fact It is a version issue, this morning I
tried to compile It (without any modifications ) with your nacl
version and It worked without any problems.

> ...
>
> read more »

[gtar...@gmail.com]

And what about hardware acceleration using direct3d or opengl? Just
for fun i tried to change the software renderer with opengl but It
didn't work, does nacl allow something similar?

> ...
>
> leggi tutto

[gtar...@gmail.com]

Ah sorry, I forgot to say that you have to modify "return RPC_OK;"
with "return NACL_SRPC_RESULT_OK;" in the "myHandler" function.

> ...
>
> read more »

[centipede]

Hi again.

Thinking that it would be a clever gesture to clean up the act and use
gtardinis suggestions for latest nacl, I took the liberty of reducing
the included source to a diff-patch to the original Irrlicht source.
Get the new package from here [http://atomicmonstergirls.net/work/
nacl] and do like this:

Prepare:
wget http://atomicmonstergirls.net/work/nacl/nacl-irrlicht-0.1.tar.gz
tar -xzf nacl-irrlicht-0.1.tar.gz
cd irrlicht
./Irrlicht-Setup-and-Patch.sh

Build:
./Irrlicht-Build.sh

make nacl debug

Run:
firefox testirrlicht.html

The Setup-and-Patch script will download the Irrlicht source from
sourceforge (that step may fail... knowing how stable SF can be) and
patch it.
There's also a Make-Patches script to make the patch files (Irrlicht-
Patch-Changes.diff and Irrlicht-Patch-Additions.tgz) which you must
edit by hand to add new files to the Addition tarball. Sorry, I'm not
a bash guru.

*I REPEAT*: ... that you must copy the nacl sdk into /opt/nacl and add
it to the path. Like this:

nacl-gcc is in /opt/nacl/bin/nacl-gcc
includes are in /opt/nacl/include
libs are in /opt/nacl/lib

From now on I will work on completing the Nacl Device, get a better/
working software render backend and probably create a new type of
Irrlicht filesystem which can load files checked in via Firefox
+Javascript (and thus undoing the changes to CFileSystem etc. The
fewer modications, the better).

See you later when it gets exciting ;-)
Centipede

[centipede]

Sorry about the delay. Had some pressing matters to tend to.

Download nacl-irrlicht-0.2.tar.gz. Otherwise the instructions are the
same as always.
http://atomicmonstergirls.net/work/nacl

Changes:

- Removed most changes from the existing CFileSystem and CReadFile,
and instead added another kind of resource archive: The
CNaClBundleReader. You basically register all the files that the
plugin should know about via JavaScript, and the archive handles
serving files to the rest of Irrlicht. Just like Irrlicht's own zip
archive handler.

- Started to work with mouse and key input in the CIrrDeviceNaCl. The
current example code uses W,S,A,D and mouse for interaction.

- Switched to and tested Irrlicht's other software renderer
(Burning... something). It seems to work. As previously mentioned, it
is slower, but unlike the first one, it clips triangles that are
outside the screen.

- Converted a few more examples, but I am having problems with some of
them.


Bugs and plans:

- I still have problems loading various files. Perhaps it relates to
seeking, but I'm not sure.
- Need a better strategy with mouse handling. Perhaps grabbing the
mouse on button-click would be better. Pretty common.
- Finish key mappings etc.
- Get past the hardwired 800x400 resolution ;-)
- Handle resize?

'be seeing you
centipede

On Jan 5, 11:52 pm, centipede <centipede...@gmail.com> wrote:
> Hi again.
>
> Thinking that it would be a clever gesture to clean up the act and use
> gtardinis suggestions for latest nacl, I took the liberty of reducing
> the included source to a diff-patch to the original Irrlicht source.
> Get the new package from here [http://atomicmonstergirls.net/work/
> nacl] and do like this:
>
> Prepare:

>     wgethttp://atomicmonstergirls.net/work/nacl/nacl-irrlicht-0.1.tar.gz

[gtar...@gmail.com]

Great work centipede!

On 10 Gen, 21:36, centipede <centipede...@gmail.com> wrote:
> Sorry about the delay. Had some pressing matters to tend to.
>
> Download nacl-irrlicht-0.2.tar.gz. Otherwise the instructions are the

> same as always.http://atomicmonstergirls.net/work/nacl

[centipede]

I'm working with proper initialization/finalization right now.
The webpage has been changed to use dynamic construction/destruction
of an embed-element. I've tried with the voronoi plugin and that does
init/exit without crashing firefox. Guess Irrlicht is more fickle, or
perhaps it's me not dealing properly with global static variables and
mutexes.

As always...
Prepare
put the nacl SDK in /opt/nacl/{bin,include,lib...} and add nacl-
gcc to PATH.
wget http://atomicmonstergirls.net/work/nacl/nacl-irrlicht-0.3.tar.gz

[centipede]

- Less crashing on behalf of Firefox (see other thread about that).
- Changed the Makefile so you don't need to put nacl-sdk in /opt/nacl
anymore. Repeating myself...

Prepare:
cd <nacl>/googleclient/native_client/tests
wget http://atomicmonstergirls.net/work/nacl/nacl-irrlicht-0.4.tar.gz
tar -xzf nacl-irrlicht-0.4.tar.gz

cd irrlicht
./Irrlicht-Setup-and-Patch.sh

Build:
./Irrlicht-Build.sh

Run:
firefox testirrlicht.html

[centipede]

> Prepare:
> cd <nacl>/googleclient/native_client/tests
> wgethttp://atomicmonstergirls.net/work/nacl/nacl-irrlicht-0.4.tar.gz

> tar -xzf nacl-irrlicht-0.4.tar.gz
> cd irrlicht
> ./Irrlicht-Setup-and-Patch.sh
>
> Build:
> ./Irrlicht-Build.sh
>
> Run:
> firefox testirrlicht.html

Now it's
http://atomicmonstergirls.net/work/nacl/nacl-irrlicht-0.5.tar.gz

And you need the very latest NaCl from Google. Changes:

- Those examples that use first-person-shooter like interface must be
controlled like this: Left-click somewhere on the screen and now the
camera-controller is engaged. Right-click and it's not.
- Removed last hardwired reference to screen size. Purely controlled
by html-code now.
- Added a few more examples. Number 12 doesn't work. Should have been
a height field that one flew over.

Regards,
Rene Jensen (Centipede)

[Linaxys]

Hey centipede, great work !
Will it be possible to use OpenGL instead of BURNINGSVIDEO ?

Thanks !

[centipede]

> Will it be possible to use OpenGL instead of BURNINGSVIDEO ?

It all depends on what plans Brad, Bennet and the other coders at
Google have kept up their sleeve. Mark Seaborn has done some work on
dynamic module loading (which I'm looking very much forward to play
with myself). But frankly I don't know how the whole OpenGL
infrastructure works.
Querying the libGL.so library with ldd yields these needed libraries
amongst others, on my Ubuntu machine: libnvidia-tls, libXext, libX11,
libXau, libxcb-xlib libxcb, libXdmcp.

If we desire a solution with pure module loading, then at least all
those modules should be recompiled with nacl-gcc. There's a good
chance that the involved libraries uses one of the banned system calls
as well. I guess the only realistic solution would be to have a
(validated) plugin for NaCl which supplies a binding layer to opengl,
which is probably also a lot easier when we speak of developing cross
platform for Windows and Mac.

Cheers,
Rene

[Mark Seaborn]

centipede <centip...@gmail.com> wrote:

I'm not too familiar with OpenGL either, but Xvfb appears to support
it (xdpyinfo lists the GLX extension), so there is a reasonable chance
of getting Xvfb to run under NaCl with unaccelerated graphics without
any special NaCl extensions. But accelerated graphics are another
matter, and that is probably why you would want to use OpenGL.

Mark