World: r3wp

a VERY cool and somewhat, excentric, group of people hehe... nothing 
real parties at tradeshow events like siggraph... usually where the 
most sought after events...   S&M show with boobs on fire :-)  nude 
circus acts.  world-renowned dj's doing the music... ahh... those 
where the good times.

now.. you've got stuck-up companies like autodesk litterally controlling 
the whole industry with parties which would make your grandma wish 
she could leave early.  ;-)

shake still today is preferred for very large effects shots... it 
can layer 500 full frame cinema images (2048p or more) using a few 
hundred megs of RAM.  other softwares need 8GB of RAM just to handle 
10. and render exponentially slower.

So Max - when do we get FullHD editing in R3? :-)

give me a few months  ;-)

... so you want to do in few months, what was not done in 12 years 
of View's existence? Cool then :-)

a lot of the stuff is already coded... it just needs to be translated 
for R3.

it took me just a few hours to have OpenGL running in an extension.... 
 which includes downloading all the OGL libs, and C compiler and 
stuff.

well, for those of you who are on devchat... you can see my (humorous) 
host-lib compilation post there, but for all others... just I just 
want to tell the world that... 

ITS ALIVE!!!! hehehahahahaha (evil grin and laugther)...


yep, I am on the short list of lucky individuals who got the host 
code, and it compiled the very first time I tried, so, mission accomplished 
and congratulations to Carl.

Maxim - on Windows, or some other system?

on windows... I  don't have my Mac setup for compiling yet.

Cyphre has reported compiling on code::blocks (don't know what OS)

OK, and what compiler have you used?

MSVC express edition... the free version.

so far, I really like the Device model, there's nothing like C OOP 
without the ++  

Exactly like the Amiga philosophy used to be.  :-)


I guess C++ coders will just be screaming as to why this isn't all 
classes and objects...  but its simple to code in any case

As long as the host code can be integrated into existing C++ code 
that's good for me. I'll be testing that ASAP.

Just being able to compile the host source with a C++ compiler would 
be sufficient - having declarations still work, for instance. The 
rest could be handled with shim code, basicaly what most of the host 
code is anyways.

So far, that is - see recent blogs for details.

I try all to keep away from C++ these days. It just gives to much 
hassles when going from one compiler to the next.

Guys, there's a trouble with OS-X or so it seems. Any experienced 
OS-X coder to help? Message from Carl on R3 Chat:


I must set OS X on the back burner... I've wasted far too much time 
on it.

There are three choices on it:
1. find a tool that does what 
I need
2. make a tool that does what I need
3. join all the sources 
into one large .c compile

Note that gcc -fvisibility=hidden does 
not work, nor does __private_extern__ wor
k either.

I've got to 
get on with other projects now. So, if you happen to find the soluti
on, 
let me know. (PS, yes, using GCC > 4.0.)

Some explanation:


Back to OS X, the problem is that they're not really libs, they're 
.a's. This ev
en appears to be the case when -dynamic-lib is used.

I 
should mention that I've had -dynamic-lib built OS X libr3 and host 
working fo
r several days. But, the libr3 isn't in the form I want, 
because it's not intern
ally linked and resolved. Examining it with 
nm it looks like just a concat of .o
 files.

Specifically, I want 
all internal symbols resolved, and I only want to export th
e library 
interface.

If OS X only builds libs (dynamic or otherwise) as concatenated 
.o files, that's
 a serious breach of coding ethics! There are two 
reasons:

1. it means I can link against the internal interfaces 
- a serious short circuit
 in code encapsulation rules.

2. it means 
I can discover the entire internal structure of any product... say 
I
 want to peek inside Photoshop to see how it does something.

If 
I nm a lib that's been properly prepared, I should only see its API, 
nothing
else. So far, this has not been possible on OS X.

I suppose 
I could easily confirm this by nm'ing some of the various apps I 
have
on OS X and checking if I can see their internals. Let's hope 
not.

Wow, that explains why Apple has to sue developers for using undocumented 
APIs instead of just not exporting them.

wow

Well, I think I found the solution - it looks like Carl's assesmenmt 
of dylibs was wrong. Solutions posted in reply to him in chat.

I've been under that impression myself... but haven't found an exact 
solution.