Ryan McDougall kirjoitti:
> builds, but no one volunteered for Linux. We briefly wrung our hands
> over it, especially the part about breaking code freeze over it, then
> agreed that this was a minor release and Linux users often prefer to
>
Actually we did break one code freeze to apply a patch to make the new
stuff in communications module to compile on linux/posix also, so that
the 0.0.2 tag compiles I think fully on Linux. But yes, as it was just a
snapshot release anyway and we continue to improve things in trunk, and
are AFAIK not introducing new dependencies now soon, so will be better
for linux (and mac) builders to just use trunk.
As you are able to run otherwise ok but get the threading crash in
texture decoding, might be an interesting experiment to disable texture
decoding to see how much and how reliably other things work. And perhaps
make a small standalone test app with just the texture decoding if the
prob is not easy to find otherwise .. of course that might not have the
threading issue you're having in the full app though.
One thing we discussed with Erno, who was fixing the windows specific
stuff in communications to build on posix & gcc too, was that it would
be good to set a build-bot on some server to ensure that things compile
an all/both (msvc&gcc) platforms after every commit. Is kind of standard
practice and I think good to have, 'cause mistakes are easy to make both
ways (Blender often gets commits that break visual studio compiling,
also doesn't have a buildbot yet, so ppl complain on irc or mailing
list). Erno was interested in setting this up as a part of his work for
rex,. We've been also planning to do the future stuff with the py api in
a test driven fashion (the namespace refactor from hackish c++ rexviewer
-> pythonic naali in c++ & py) and it would be good to have a server
setup for running the tests after commits too, against a test server
setup to verify that also the networking works.
Regarding Cg, it may be that the current Naali uses some shader written
in cg by default (perhaps the water?), but even if that's the case it
doesn't mean that it would be a somehow integral part of the
application. From an engine perspective, shaders are just content (like
an image), and what content you use is more a configuration than a
programming issue. With Ogre it usually works so that in code you apply
materials, and the material definitions refer to texture images and
shader programs that are used, and those are easily changed. The use of
shaders needs to be configurable to support low end hardware too ('cause
reportedly (Lasse said) Ogre doesn't do a good job detecting itself what
is supported).
About a Mac build, I've once ported (or more like just built, with small
things added) a 3d game engine called Soya3d to Mac and also Petri in
our team knows something about Mac app development. We just haven't had
time to address that at all now, and have quite a lot to do in the
coming weeks and months too so may well not get to address it soon. So
if there's anyone out there who can give a shot, please do so, and try
to help. In my experience things are quite normal there from a Posix
perspective, normal gcc, normal versions of libs like libfreetype and
openjpeg and friends, available both via the version of bsdports called
darwinports and the port of debian called fink. And there's a prebuilt
SDK for Ogre. I suppose qt is somehow readily available too. Sachamange
was installing Naali deps and trying to get started with running cmake
in may/june, perhaps he can tell how far got.
~Toni
> Cheers,
>
> On Sat, Nov 7, 2009 at 3:23 PM, Kripken <[email protected]> wrote:
>
>> Oh, ok, I think I see the misunderstanding now. What happened from my
>> perspective was this:
>>
>> 1. I saw there was a 0.0.2 release, so I looked for Linux binaries. Couldn't
>> find any, so I asked on IRC what the status of Linux support is.
>> 2. Responses implied there were some problems. One response was 'something
>> with Cg perhaps'.
>> 3. So I posted on the mailing list to ask what the status of Linux is, and
>> also whether Cg is used or not.
>>
>> Sorry if I wasn't being clear earlier.
>>
>> - kripken
>>
>>
>>
>> On Sat, Nov 7, 2009 at 11:54 AM, Ryan McDougall <[email protected]> wrote:
>>
>>> On Sat, Nov 7, 2009 at 11:15 AM, Kripken <[email protected]> wrote:
>>>
>>>> On Sat, Nov 7, 2009 at 11:04 AM, Ryan McDougall <[email protected]>
>>>> wrote:
>>>>
>>>>> What's almost as helpful as a patch is a bug report. Were you able to
>>>>> file
>>>>> one?
>>>>>
>>>>>
>>>> I can file a generic "Would be nice to have reX run on Linux" bug, would
>>>> that be appropriate?
>>>>
>>> Heh, not really. :)
>>>
>>> It's hard for me to see what lead you to believe Cg was causing your
>>> problems, as I've never had that issue, so clearly something is new
>>> there. We have done nothing with Cg, so I'm at a loss to explain why
>>> it's become an issue for you.
>>>
>>>
>>>>>>> Nearest I can tell you're referring to the fact that, Ogre3D, the
>>>>>>> _LGPL_ licensed (up until 1.7 is released) rendering engine we use
>>>>>>> has
>>>>>>> Cg support. If you think that is restrictive to your freedoms,
>>>>>>> you'll
>>>>>>> have to take it up with the upstream project, as we use their engine
>>>>>>> as-is.
>>>>>>>
>>>>>>>
>>>>>> My concern is not about the existence of support (e.g. Ogre also
>>>>>> supports
>>>>>> the closed-source DirectX), but whether realXtend is using Ogre in a
>>>>>> way
>>>>>> that makes Cg necessary.
>>>>>>
>>>>>> That is, Ogre can be used with and without Cg, so my question is - is
>>>>>> realXtend using Ogre in a way that requires Cg, or not?
>>>>>>
>>>>> I don't believe we are at all, but it's hard to say what's happening
>>>>> without the context of your previous conversation on IRC.
>>>>>
>>>> Well, the IRC conversation is not that relevant anymore. My question is:
>>>> Can
>>>> realXtend be run without having Cg installed, or not?
>>>>
>>> Yes. So I'm not sure why you're having problems with it, so I am
>>> clearly lacking some context for your issue.
>>>
>>> If you disable CommunicationsModule in in CMakeOptionalModules.txt (as
>>> it depends on a highly specialized version of QtTelepathy), 0.0.2
>>> builds fine on Linux.
>>>
>>> (However running it appears to have deadlocks.)
>>>
>>>
>>>> (To make the matter concrete: Some of the demos that come with Ogre run
>>>> fine
>>>> without Cg installed, while others require Cg. Is realXtend like the
>>>> first
>>>> group, or the second?)
>>>>
>>>> - kripken
>>>>
>>> Cheers,
>>>
>>>
>>>>
>>>
>>
>
> >
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/realxtend
http://www.realxtend.org
-~----------~----~----~----~------~----~------~--~---
