drawstuff compile error on Snow Leopard

59 views
Skip to first unread message

hiroaki

unread,
Sep 9, 2009, 2:53:26 AM9/9/09
to ode-users
im trying to compile drawstuff on Snow Leopard(version 10.6), but it
keeps giving me this error.

----------------------------------------------
osx.cpp:73: error: ‘kEventWindowDrawContent’ was not declared in this
scope
osx.cpp: In function ‘OSStatus osxKeyEventHandler
(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*)’:
osx.cpp:185: error: ‘GetScriptVariable’ was not declared in this scope
osx.cpp:186: error: ‘KeyTranslate’ was not declared in this scope
osx.cpp:188: error: ‘UppercaseText’ was not declared in this scope
osx.cpp: In function ‘void osxCloseMainWindow()’:
osx.cpp:320: warning: ‘aglSetDrawable’ is deprecated (declared at /
System/Library/Frameworks/AGL.framework/Headers/agl.h:313)
osx.cpp:320: warning: ‘aglSetDrawable’ is deprecated (declared at /
System/Library/Frameworks/AGL.framework/Headers/agl.h:313)
osx.cpp:326: error: ‘ReleaseWindow’ was not declared in this scope
osx.cpp: In function ‘OSStatus osxWindowEventHandler
(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*)’:
osx.cpp:339: error: ‘GetWindowPortBounds’ was not declared in this
scope
osx.cpp:348: error: ‘kEventWindowDrawContent’ was not declared in this
scope
osx.cpp: In function ‘void osxCreateMainWindow(int, int)’:
osx.cpp:389: warning: ‘AGLDevice’ is deprecated (declared at /System/
Library/Frameworks/AGL.framework/Headers/agl.h:40)
osx.cpp:389: error: ‘GetMainDevice’ was not declared in this scope
osx.cpp:417: error: ‘CreateNewWindow’ was not declared in this scope
osx.cpp:425: error: ‘GetWindowEventTarget’ was not declared in this
scope
osx.cpp:439: error: ‘SetWindowTitleWithCFString’ was not declared in
this scope
osx.cpp:440: error: ‘RepositionWindow’ was not declared in this scope
osx.cpp:442: error: ‘ShowWindow’ was not declared in this scope
osx.cpp:444: warning: ‘aglSetDrawable’ is deprecated (declared at /
System/Library/Frameworks/AGL.framework/Headers/agl.h:313)
osx.cpp:444: error: ‘GetWindowPort’ was not declared in this scope
----------------------------------------------


any help will be highly appreciated, thank you very much in advance.

hiroaki

unread,
Sep 9, 2009, 4:00:13 AM9/9/09
to ode-users
i've searched and found that drawstuff of ODE uses QuickDraw API,
which is no longer in Snow Leopard, so i guess i have to rewrite
drawstuff using Quartz or so.

I still wanna run drawstuff on Snow Leopard, so any help will be
highly appreciated. thanks.

Danny Price

unread,
Sep 9, 2009, 4:08:10 AM9/9/09
to ode-...@googlegroups.com
So is it just drawstuff that has trouble?

Glad I don't use it :)

hiroaki

unread,
Sep 9, 2009, 4:25:26 AM9/9/09
to ode-users
Hi, can you tell me which you use other than drawstuff?

Danny Price

unread,
Sep 9, 2009, 4:32:16 AM9/9/09
to ode-...@googlegroups.com
My own GL code.

hiroaki

unread,
Sep 9, 2009, 4:41:47 AM9/9/09
to ode-users
Thanks a lot, i think i should write my own too.

Peter Newman

unread,
Sep 9, 2009, 5:04:30 AM9/9/09
to ode-...@googlegroups.com
I would suggest using something like OGRE3D rather then writing your
own. I don't know if it's currently available on Snow Leopard, but if it
isn't, it will be very soon, I'm sure.

Peter N

Danny Price

unread,
Sep 9, 2009, 5:57:29 AM9/9/09
to ode-...@googlegroups.com
Ogre is a full blown gaming SDK.

If you can use ODE, you can build an OpenGL library to draw ODE primitives. If you want to create a full-blown polished game then yes, you Ogre but as an alternative to drawstuff it's overkill.

I recommend GLFW (http://glfw.sourceforge.net/) for creating a cross-platform context. It has functions for threading and image loading.

Peter Newman

unread,
Sep 9, 2009, 5:59:18 AM9/9/09
to ode-...@googlegroups.com
No, it's not. It's specifically just a graphics library. Although it is
aimed at being a full graphics solution, it's true, more then just
tossing out primitives for debugging.

Peter N

Danny Price wrote:
> Ogre is a full blown gaming SDK.
>
> If you can use ODE, you can build an OpenGL library to draw ODE
> primitives. If you want to create a full-blown polished game then yes,
> you Ogre but as an alternative to drawstuff it's overkill.
>
> I recommend GLFW (http://glfw.sourceforge.net/) for creating a
> cross-platform context. It has functions for threading and image loading.
>
> On Wed, Sep 9, 2009 at 10:04 AM, Peter Newman <wiz...@gmail.com
> <mailto:wiz...@gmail.com>> wrote:
>
>
> I would suggest using something like OGRE3D rather then writing your
> own. I don't know if it's currently available on Snow Leopard, but if it
> isn't, it will be very soon, I'm sure.
>
> Peter N
>
> hiroaki wrote:
> > Thanks a lot, i think i should write my own too.
> >
> > On Sep 9, 5:32 pm, Danny Price <deepblue...@googlemail.com

Danny Price

unread,
Sep 9, 2009, 6:35:05 AM9/9/09
to ode-...@googlegroups.com


From your list of errors, DS is not using QuickDraw extensively. Given that most of DS is just basic OpenGL, it's probably just using some old QuickDraw APIs to create the window and rendering context. There's no reason why most of the code cannot be ported to GLFW without changes (assuming GLFW works on SL - I've yet to try it). You could use anything that creates a valid GL context - even Cocoa.

Not that you should use DS afor anything other than the demos, but it shouldn't be too hard to port it...

Bill Sellers

unread,
Sep 9, 2009, 10:16:10 AM9/9/09
to ode-...@googlegroups.com
I think that just to run the demos we don't want any additional
dependencies. They used to run under GLUT (which comes with MacOSX)
but it is much better that they don't use it. My suggestion as a work
around would be to enable the X11 version for Snow Leopard by default
(perhaps with a warning message from configure) so that people can run
the demos for the time being. However ultimately there are issues with
64 bit compilation under Snow Leopard. That probably stops a carbon-
based (and hence C based) Quartz implementation since I think that
will limit you to 32 bit. Wrapping an Objective C cocoa interface is
probably the best long term solution although it's a bit of extra
work. For the record I now use Qt for all my ODE stuff and they are
moving over to an entirely Cocoa based option to support MacOS.

Cheers
Bill

Danny Price

unread,
Sep 9, 2009, 11:41:54 AM9/9/09
to ode-...@googlegroups.com
Yeah I'm a qt dev in my day job and Nokia are doing a good job but even they don't support SL yet.

Enabling X11 for the demos sounds like the way to go. I'm a little surprised that drawstuff uses QuickDraw at all though.

Is ODE and Opcode/Gimpact 64-bit ready?

Daniel K. O.

unread,
Sep 9, 2009, 12:39:51 PM9/9/09
to ode-...@googlegroups.com
Danny Price escreveu:

> Is ODE and Opcode/Gimpact 64-bit ready?

Of course.

--
Daniel K. O.
"The only way to succeed is to build success yourself"

shizzy0

unread,
Nov 3, 2009, 8:03:30 PM11/3/09
to ode-users
Hello,

I ran into the same problem today. I got drawstuff to compile on Snow
Leopard without changing the source code the latest ODE checkout from
SVN (rev 1706). I used the following script 'myconfigure'.

#!/bin/bash
# myconfigure

export CPPFLAGS=-I/usr/X11/include
export LDFLAGS="-L/usr/X11/lib -lGL -lGLU -lglut -lX11"
./configure --with-drawstuff=X11 --enable-demos "$@"

This will build the drawstuff library and most of the demos
correctly. However, it does fail on 'demo_ode.cpp' with the following
series of errors:

g++ -DHAVE_CONFIG_H -I. -I../../ode/src -I/Users/shane/Desktop/ode-
svn/include -DDRAWSTUFF_TEXTURE_PATH="\"/Users/shane/Desktop/ode-svn/
drawstuff/textures\"" -DdTRIMESH_ENABLED -I/usr/X11/include -DdSINGLE
-g -O2 -MT demo_ode.o -MD -MP -MF .deps/demo_ode.Tpo -c -o demo_ode.o
demo_ode.cpp
demo_ode.cpp:333:31: error: macro "dFactorCholesky" requires 3
arguments, but only 2 given
demo_ode.cpp:358:31: error: macro "dFactorCholesky" requires 3
arguments, but only 2 given
demo_ode.cpp:363:28: error: macro "dSolveCholesky" requires 4
arguments, but only 3 given
demo_ode.cpp:384:36: error: macro "dInvertPDMatrix" requires 4
arguments, but only 3 given
demo_ode.cpp:408:47: error: macro "dIsPositiveDefinite" requires 3
arguments, but only 2 given
demo_ode.cpp:409:47: error: macro "dIsPositiveDefinite" requires 3
arguments, but only 2 given
demo_ode.cpp:476:33: error: macro "dLDLTAddTL" requires 6 arguments,
but only 5 given
demo_ode.cpp:548:58: error: macro "dLDLTRemove" requires 9 arguments,
but only 8 given

Hope that helps.

-Shane

On Sep 8, 10:53 pm, hiroaki <hiro...@mamemilk.com> wrote:
> im trying to compile drawstuff onSnowLeopard(version 10.6), but it

Oleh Derevenko

unread,
Nov 4, 2009, 12:26:26 PM11/4/09
to ode-...@googlegroups.com
You have to make sure __ODE__ macro IS NOT defined for demo_ode.cpp
This macro should be defined for ODE library itself but not for the code
that uses it.

Oleh Derevenko
-- Skype with underscore

Oleh Derevenko

unread,
Nov 4, 2009, 12:58:20 PM11/4/09
to ode-...@googlegroups.com
Aha... This is because of include

#include "../src/array.h"
#include "../src/array.cpp"

It's necessary to get rid of those. Private files should not be included.

Daniel K. O.

unread,
Nov 7, 2009, 1:16:14 PM11/7/09
to ode-...@googlegroups.com
Oleh Derevenko wrote:
> Aha... This is because of include
>
> #include "../src/array.h"
> #include "../src/array.cpp"
>
> It's necessary to get rid of those. Private files should not be included.

How else would you do internal unit testing (which is what demo_ode.cpp
actually is) ?

Oleh Derevenko

unread,
Nov 7, 2009, 5:28:14 PM11/7/09
to ode-...@googlegroups.com
I don't really think an array class (just an assumption drawn from file
name - I did not check what's inside of it) is such and important and
frequently changing feature that it needs to be tested each time. I suppose
you could just verify the implentation with your eyes (I could if you can't)
and forget about it forever.

Oleh Derevenko
-- Skype with underscore


----- Original Message -----
From: "Daniel K. O." <danielk...@gmail.com>
To: <ode-...@googlegroups.com>
Sent: Saturday, November 07, 2009 8:16 PM
Subject: [ode-users] Re: drawstuff compile error on Snow Leopard



Daniel K. O.

unread,
Nov 8, 2009, 12:13:11 AM11/8/09
to ode-...@googlegroups.com
Oleh Derevenko wrote:
> I don't really think an array class (just an assumption drawn from file
> name - I did not check what's inside of it) is such and important and
> frequently changing feature that it needs to be tested each time. I suppose
> you could just verify the implentation with your eyes (I could if you can't)
> and forget about it forever.


It doesn't change the fact that demo_ode.cpp (which shouldn't have been
renamed from test_ode.cpp) performs unit testing, and needs to access
private features.

Also, dArray mostly a cheap std::vector replacement. I trust my STL
vendor's std::vector much more than some obscure implementation with
gratuitous features that aren't used anywhere
(dArrayBase::constructLocalArray).


Anyway, dArray is used in that file just to hold up a list of pointers
to test some other thing, not to test dArray itself. Replacing it with
std::vector is straightforward and will eliminate the array.h dependency.

Reply all
Reply to author
Forward
0 new messages