OpenGL ES Tutorial

[Fernando Carvalho]

Hi everyone,

I'm planning to learn OpenGL ES for programming in NaCl, after I finished my C.G. course this semester.

Do someone have any indication of tutorial or a good book where I can learn this?

In my course we used only legacy OpenGL, only for learning proposes, so I'm really lost when I came with newer versions of OpenGL.

--
Fernando

[Nicholas Fullagar]

The book I like is:
  OpenGL ES 2.0 Programming Guide, Aaftab Munshi, Dan Ginsburg, Dave Shreiner, Addison-Wesley 2009
...as NaCl also targets OpenGL ES 2.0.  It's a good intro to OpenGL ES and GLSL shaders.

These books, while also recommended, have likely moved on beyond version 2.0 of the OpenGL ES & GLSL specifications.
  OpenGL SuperBible Fifth Edition, Richard S. Wright, Jr. etc., Addison-Wesley 2010
  OpenGL Shading Language Third Edition, Randi Roost etc. Addison-Wesley 2010

--
You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.
To post to this group, send email to native-cli...@googlegroups.com.
To unsubscribe from this group, send email to native-client-di...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/native-client-discuss?hl=en.

[Fernando Carvalho]

Thanks for your suggestions, I'm going to see where can I find them here in Brazil.

--
Fernando

[Nick Bray]

Once you're comfortable with the API, you might find PDF files of the specification useful:

http://www.khronos.org/opengles/

http://www.khronos.org/registry/gles/specs/2.0/es_full_spec_2.0.25.pdf

A good collection of links:
http://realtimerendering.com/

[Fernando Carvalho]

I'm very thankful of your support and I hope to soon be able to produce some NaCl content to be published in the web store.

I'm very confident that NaCl will bring lots of great content to the Web.

Fernando

[Yuriy O'Donnell]

I think it would be very useful to include more GLES samples in the SDK. Tumbler sample is alright, but kind of goes off on tangents a little bit (like all the interaction with javascript stuff). So it is quite difficult to understand which code is necessary/important and which code is just there for the purposes of the sample. 

I'd like to see some basic API examples, starting from the minimal code which initializes GL context and renders a single flat shaded triangle.

[Fernando Carvalho]

I got a copy of the "OpenGL ES 2.0 Programming Guide" as Nicholas
Fullagar suggested me, but I'm having trouble to easily test code on
Mac OS and Linux. I don't have a Windows machine and I don't know how
to run Xcode projects, since I usually program using VIM and compile
on the terminal.
Do someone have a suggestion to me?
I'm seeking something that I can rapidly test modifications to the
code, in order to become more familiar with the API.

On Wed, Dec 7, 2011 at 7:26 PM, Yuriy O'Donnell <yur...@gmail.com> wrote:
>
> I think it would be very useful to include more GLES samples in the SDK. Tumbler sample is alright, but kind of goes off on tangents a little bit (like all the interaction with javascript stuff). So it is quite difficult to understand which code is necessary/important and which code is just there for the purposes of the sample.
>
> I'd like to see some basic API examples, starting from the minimal code which initializes GL context and renders a single flat shaded triangle.
>

> --
> You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.

> To view this discussion on the web visit https://groups.google.com/d/msg/native-client-discuss/-/rbba3JUd8loJ.

[Nicholas Fullagar]

Hi Fernando,

First I'd recommend the NaCl SDK and follow the example "tumbler" which makes some basic use of OpenGLES 2.0.  This might be enough to get you a compile-run-edit cycle to experiment with.

[Fernando Carvalho]

But I would need to set up NaCl related thinks, like the webserver,
the browser communication and some other things.
Do you know something that it more quickly to build and run?
Or is it possible to put Chrome to run a module without setting all
those things?
I can confess to you that I'm going to need to build the applications
many times, before understanding something. If lose to much time with
the build process I'm going to take ages to finish the whole book.

--
Fernando

[Nicholas Fullagar]

Hi Fernando,

I usually open multiple terminals.  One to continuously run the python server on localhost:5103, and a second for edit/compile/run cycles.  I have a collection of short bash scripts to build the example and then run chrome using a path to the html file.  I usually use a local build of chromium for testing; replace the out/Release/chrome with the location of your chrome executable.  On each platform the path will be a bit different, below is for Linux.

out/Release/chrome --disable-gpu-vsync --show-fps-counter --incognito --user-data-dir=/home/nfullagar/tempdata http://localhost:5103/a_path_to_nacl_html_example

With the above as part of a script to build the example and then launch chrome and run it, you should have a pretty quick edit/compile/run cycle.

[Fernando Carvalho]

Thanks for your suggestion, I'm going to set up this.
But, for instance, do you know if it is possible to make Chrome load
files from "file:///path/to/tumbler_example/fullscreen_tumbler.html",
by putting "--allow-file-access" and "--allow-file-access-from-files"
switches on command line?
I had tried that, but Chrome's console tells: "NativeClient: NaCl
module load failed: could not load manifest url."

On Mon, Dec 12, 2011 at 10:34 PM, Nicholas Fullagar

[David Springer]

On Tue, Dec 13, 2011 at 5:14 AM, Fernando Carvalho <fernandocar...@gmail.com> wrote:

Thanks for your suggestion, I'm going to set up this.
But, for instance, do you know if it is possible to make Chrome load
files from "file:///path/to/tumbler_example/fullscreen_tumbler.html",
by putting "--allow-file-access" and "--allow-file-access-from-files"
switches on command line?
I had tried that, but Chrome's console tells: "NativeClient: NaCl
module load failed: could not load manifest url."

file: schemes are specifically not allowed in NaCl, even with the switches you mention.

Is running a local http: server not working for you?  A simple python-based HTTP server comes with the NaCl SDK.  With the auto-complete feature of Chrome, it should be about the same number of keystrokes to get to localhost:5103/.... as to get to a file: URL, so this shouldn't interfere too much with your development cycle.

[Egor Pasko]

On Tue, Dec 13, 2011 at 4:14 PM, Fernando Carvalho
<fernandocar...@gmail.com> wrote:
> Thanks for your suggestion, I'm going to set up this.
> But, for instance, do you know if it is possible to make Chrome load
> files from "file:///path/to/tumbler_example/fullscreen_tumbler.html",
> by putting "--allow-file-access" and "--allow-file-access-from-files"
> switches on command line?
> I had tried that, but Chrome's console tells: "NativeClient: NaCl
> module load failed: could not load manifest url."

To start your app from disk without a web server ...
... make a chrome extension out of your app (requires writing a small
extension manifest file), add the directory containing the manifest to
chrome via about:extensions plus "Load unpacked extension" ("Developer
mode" checkbox must be checked), in the chrome command line use
--app-id=idjjgbgmcjneochlobpnbmldblahblah (put your application id
here). Replacing .nexe files in your extension does _not_ require
re-adding the extension, just rerun chrome.

--
Egor Pasko

[Fernando Carvalho]

The server is running. It was only something that I was wondering if
it is possible.
Because if it were possible I would write a script to build and
display the my tests that doesn't rely on the presence of the server.
But as I can see, it will not be possible, so I need to start the
server manually before working.

Now I'm wondering why I can't access NaCl files with these switches
on. Normal people would never start Chrome with these. I think that it
should be a development feature in Chrome, since it is easier to test
if a webpage is running properly.

[Fernando Carvalho]

Hi everyone,

I've created an Makefile to build and run the tumbler fullscreen example.
https://docs.google.com/document/pub?id=1gv65sO2tbi1bDSHv5Tiy-8hEVfgqrZuxnj19TcKlkMo

The only issue that I have now, is that my .nexe file is too large (1.2MB for the 32 bit and 1.4MB for the 64 bit). Do someone have a suggestion to improve my Makefile?

--
Fernando

[Victor Khimenko]

On Tue, Dec 13, 2011 at 11:36 PM, Fernando Carvalho <fernandocar...@gmail.com> wrote:

Hi everyone,

I've created an Makefile to build and run the tumbler fullscreen example.
https://docs.google.com/document/pub?id=1gv65sO2tbi1bDSHv5Tiy-8hEVfgqrZuxnj19TcKlkMo

The only issue that I have now, is that my .nexe file is too large (1.2MB for the 32 bit and 1.4MB for the 64 bit).

This is about what you should expect. Compare with native case:

$ cat hello.C

#include <iostream>

int main() {

  std::cout << "Hello, world" << std::endl;

}

$ g++ -m64 hello.C -o hello -static

$ ls -al hello

-rwxr-x--- 1 khim eng 1472395 2011-12-13 23:43 hello

$ g++ -m32 hello.C -o hello -static

$ ls -al hello

-rwxr-x--- 1 khim eng 1283762 2011-12-13 23:43 hello

$ g++ --version

g++ (Ubuntu 4.4.3-4ubuntu5) 4.4.3

Copyright (C) 2009 Free Software Foundation, Inc.

This is free software; see the source for copying conditions.  There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

You can save some space by stripping the debug info, but this will make it much harder to debug stuff. You can try to use glibc-based toolchain, but this will not change the equation much: your file will be tiny but you'll need to distribute few hefty libraries with it.

[Christian Stefansen]

Hi Fernando,

You could strip the nexes by using, say, i686-nacl-strip --strip-all. In the deployment stage you should deploy a stripped version of the executable and *keep* the original executable with the debug symbols around to aid in deciphering stack traces/crash addresses. As Victor noted, stripping the executable does make debugging somewhat more cumbersome.

If you prefer, you can have nacl-gcc do the stripping via the -s flag. Typical nacl-gcc flags are something like this:

• DEBUG: -g -O0
• PROFILE: [-g] -O{2|3} -msse -mfpmath=sse -ffast-math -fomit-frame-pointer
• DEPLOY: -s -O{2|3} -msse -mfpmath=sse -ffast-math -fomit-frame-pointer
  

Cheers,

Christian

Christian Stefansen

Product Manager

Google

If you received this communication by mistake, please don't forward it to anyone else (it may contain confidential or privileged information), please erase all copies of it, including all attachments, and please let the sender know it went to the wrong person. Thanks.

[Fernando Carvalho]

Now I understand, why the executable is so large.

I had a quick idea here:

Why Google do not provide a dynamic library to save some space?

So we could compile an application like this, for example:

x86_64-nacl-g++ -Lhttp://libs.google.com/ main.c -o hello.x64.nexe

So everytime the application needs a shared library, it would check if it is in cache, if not it should be downloaded from the internet on the link provided during compilation time.

[Victor Khimenko]

On Wed, Dec 14, 2011 at 12:10 AM, Fernando Carvalho <fernandocar...@gmail.com> wrote:

Now I understand, why the executable is so large.

I had a quick idea here:

Why Google do not provide a dynamic library to save some space?

Because it's much harder to do then to say. Before you can do that you must make sure your ABI is long-term supportable. So you just take a look on functions provided in a standard library and see if they all work fine, right?

Well... kinda. But the devil in details:

$ objdump -T /lib/libc.so.6 | wc

   2162   15091  157224

$ objdump -T /lib/libm.so.6 | wc

    337    2310   22626

$ objdump -T /lib/libpthread.so.0 | wc

    322    2144   24937

$ objdump -T /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | wc

   3754   26124  392457

Over 6 thousand functions are exposed just in a few basic libraries! Ouch.

 

So we could compile an application like this, for example:

x86_64-nacl-g++ -Lhttp://libs.google.com/ main.c -o hello.x64.nexe

So everytime the application needs a shared library, it would check if it is in cache, if not it should be downloaded from the internet on the link provided during compilation time.

And what will happen if library will go away and/or will be changed in some incompatible way? The number of moving parts in the whole solution will be staggering!

This does not mean that we don't ever plan to do that (we've ported glibc which includes DSO support, as you know - this is first step in this direction) - but we consciously decided against trying to support such schemes in the first release. For now all the code which is needed to start your program must come from your web site. Initial loading process ( http://www.chromium.org/nativeclient/design-documents/nacl-manifest-file-format-for-glibc ) does not even support CORS... 

You already can share libraries among different apps on your own web site - but that's as far as we are ready to go at this stage.

[Fernando Carvalho]

Hi everyone,

I'm starting coding my first NaCl applications, but I'm a little confused on how to start drawing to a NaCl screen object.

I already understood how to create the modules, embed them on the page and get them working.

I've got the Tumbler example, but it is written in C++ and I have lots of trouble following OO code, since it has heritages, casts and some other thinks that drives me crazy.

Do someone have a simple C application using OpenGL ES on NaCl? I know that it is very newbie, but I can only learn when I start from a simple C application. After that I should be able to understand the C++ code.

[Nicholas Fullagar]

Hi Fernando, please see if the attached helps.  It doesn't use any shaders, just enough to see something happen with glClear.  It is intended to be small and use the C interface.  It also has some very simple event & audio feedback.

-nicholas

[Yuriy O'Donnell]

This kind of sample is exactly what I had in mind! SDK needs more samples like this.

[Nicholas Fullagar]

thx.  I realized after it could be smaller, and removed no longer used test code.  Here's the smaller version.

On Thu, Dec 15, 2011 at 1:13 PM, Yuriy O'Donnell <yur...@gmail.com> wrote:

This kind of sample is exactly what I had in mind! SDK needs more samples like this.

--

You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.

To view this discussion on the web visit https://groups.google.com/d/msg/native-client-discuss/-/uSTr7x5D9AgJ.

[Fernando Carvalho]

Mnay thanks for your example. I'm going to walk through it and see what I can understand.

If you put it in the NaCl Developers page, this would be perfect for starting.

In my opinion all starter developer examples should be written in pure C, because it is easier to follow and understand.

To became even easier, I would suggest to put all examples in a single source file, so people don't need to jump between code tabs in order to see where things were declared.

After that, there should be an advanced section that describes the design patterns recommended to create modular NaCl applications. So it should suggest how to structure classes and other OO related things.

To people that are starting coding with an API is hard to follow and understand code that is large, contained in multiple files and with OO things, like inheritances, communicating modules and other sort of things. These are good practices to maintain code, not to teach someone how to use an API.

Many thanks for your support.

--
Fernando

[Fernando Carvalho]

Hi Nicholas,

I'm trying to compile your code, but I'm having the following error when linking the code:

/home/fernando/Code/nacl_sdk/pepper_17/toolchain/linux_x86_newlib/bin/i686-nacl-g++ -m32  nacl_opengl.c -I/home/fernando/Code/nacl_sdk/pepper_17/ -L/home/fernando/Code/nacl_sdk/pepper_17/ -lppapi -lppapi_cpp -lppapi_gles2 -lplatform -lpthread -lgio -o nacl_opengl_x86-32.nexe

/tmp/cc2XeJ4Q.o: In function `RenderLoop(void*, int)':

nacl_opengl.c:(.text+0x3c): undefined reference to `RenderFrameStartup(InstanceInfo*)'

nacl_opengl.c:(.text+0x5c): undefined reference to `RenderFrame(InstanceInfo*)'

Do you have any suggestions?

--
Fernando

[Fernando Carvalho]

Hey,

Forget that, I haven't included the "ppapi_njf_frame.cc" on my source.

Sorry for that.

--
Fernando

[Fernando Carvalho]

Thanks Nicholas, I've compiled and run it successfully.

My only doubt now, is why I can't compile it using nacl-gcc. It works when compiled with nacl-g++, but not when with nacl-gcc

Here is the source in the attachment, in case you have time to see.

--
Fernando

[Nicholas Fullagar]

Hi Fernando, despite using the 'c' ppapi interface the sample code is actually c++ (hence the .cc file extensions)  Sorry for the confusion.

[Mike Acton]

Nicholas's sample updated for Pepper 18:  https://github.com/macton/ppapi_njf_demo

Mike.