JB can you read and reply to this mail?

Hi

What Doru wrote pretty much sums it up.

CodeCity under VW was based on JUN, which provided a programmer-friendly API built on top of OpenGL. Since there is no such thing under Pharo, when I later started to work on CodeCity under Pharo, I needed to learn about how to program directly to OpenGL. And the only example I had for that was SourceCity. In the meantime I manage to get a grip on my basic needs and was ready to move forward to implementing CodeCity. Now that does not work anymore in Pharo 3.0 so I am stuck. I could continue to program under Pharo 2.0, but what's the point?

for now probably, because if you that is the one the  most interested guy in that does not have the time to understand why others that 
do not need 3D should do it. NBOpenGL was a side project to give a try of busy people too. I'm sorry to say that 
but we cannot be on all fronts especially when they are changing.

So can you tell us if you see what changed between 2 and 3. I have no idea.

I have already looked at Roassal 3d, but it was not easy to separate the API from the code.

Strange because even me I could see that the shadder code should not be in Roassal 3D but in NBOpenGL :).
Because Roassal 3d should not be about shadder but about 3D.

And it is something completely different than what I have been using (and SourceCity, too), because Roassal 3d is using the modern OpenGL methodology (with FBOs and stuff).

Yes they changed the API and deprecated the old way of doing it.

So, I would really appreciate if that API would find its way from Roassal to NBOpenGL and I could use it for CodeCity.

See below

Unfortunately I am able to help a lot with that, because I know very little about this and I also don't have enough time (I am doing CodeCity in my spare time). But, if you have concrete things that I can do, I'd be happy to help.

Three remarks:
- I know that jean-baptiste worked on moving part of roassal3d to NBOpenGL
- I'm not sure that doing 3d without investing a bit in the underlying technology is wise. Because you will be always relying 
on other people and probably frustrated when things are not working.
- Since JB does not know how to communicate here is what he did for fun instead of pushing MoosePython :)
a renderer to  video to videos stream for openGL ->  MKV, mp4 based one ffmpeg). The code is openGL extra. As an example you
can get
https://www.dropbox.com/sh/uyli3tx3drendvj/qzA_Hy0jnk

Now again if nobody builds a jun like library in Pharo it will not exist.

Stef



Cheers
Ricky




On Wed, Nov 13, 2013 at 9:44 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,

I guess that what Ricky is asking is what changed between NBOpenGL 2.0 and 3.0 such that this does not work anymore on Windows. The fact that he mentioned 64 bits is not relevant for this discussion :).

I also guess he wants to put some effort into understanding this as well but he needs a bit of guidance. Right Ricky?

Cheers,
Doru



On Tue, Nov 12, 2013 at 2:12 PM, St�phane Ducasse <stephane.ducasse@inria.fr> wrote:
Richard

you should have a look at ROASSAL 3d because ronie improved the shadder part (no more assembler)
and his code should be split in two and one part should go to NBOpenGL.
Now he is experiencing some problem with NBOpenGL on windows as you.

NativeBoost does not work on 64 bits. Yet but igor is really busy finishing the texteditor (and I can tell you that
he does not have fun there).

So it is important that you help because we are FULL
and sorry about that but really FULL.

Ronie will visit us in January and share an office with igor.

Stef


> Hi
>
> CodeCity, the project I am working on is based on NBOpenGL.
> I'd like to start working on it using Pharo 3, but it seems that NBOpenGL does not work yet with Pharo 3.0.
>
> I downloaded from jenkins the latest image with Pharo 3 and tried to execute the following code on Windows 7, 64 bits:
>
> GLTTRenderingDemo new openInWorld.
>
> but I get a 'No suitable implementation found for initializing OpenGL context for your platform'.
> It seems that NBGLContextDriver does not have a subclass for Windows 64bits. Did I omit something?
>
> Cheers
> Ricky
>





--

"Every thing has its own flow"