James Sleeman wrote:
Seems to be working ok, a bit, umm, stuttery, sort of, particularly
background wind, seemed to switch left-right a bit, but those problems
might just be me, maybe even just an illusion.
Yeah that's probably doe to improper position or orientation.Still
working on that.
Mathias Fröhlich wrote:
Hi Dave,
On Saturday 17 October 2009 18:23:44 dave perry wrote:
Is the change to SGAtomic.cxx that causes this break really necessary?
Don't know yet.
I have reverted that patch and sent the proper information to Mathias.
Erik
leee wrote:
On Friday 16 Oct 2009, Martin Spott wrote:
Instead of pouring time into a (probably) never ending chain of
backward compatibility (alias old cruft) layers, I think the
effort is much better spent for bringing the respective aircraft
configurations onto speed for FlightGear's
Durk Talsma wrote:
Hi,
On Saturday 17 October 2009 11:06:33 pm syd adams wrote:
After an update and compile this morning , I hear atc-chatter , but nothing
else.
With the s76c , I hear sounds until I start the engine , then sounds cut
out.
Is the engine still running after that (can you
daveluff wrote:
I'm also unable to run FG with the new sound system, this time on
Windows built with msvc 2005 express. In my case, dt to update_late is
definitely non-zero though. Here's the stack trace:
Thanks David, I think I've nailed this down now.
It not, could you specify any
James Sleeman wrote:
I still appear to have the same problem... compiled a couple of minutes
ago, fgfs with no command line options, backtrace follows...
../../../SimGear/simgear/sound/soundmgr_openal.cxx:430
#7 0x00989b2c in SGSampleGroup::update (this=0x318af70,
Vivian Meazza wrote:
Patched soundmgr_openal.cxx/hxx and sample_group.hxx with
+#elif defined(_WIN32)
+# include al.h
or
+#elif defined(_WIN32)
+# include al.h
+# include alc.h
+# include AL/alut.h
Olaf pointed out to me that this wasn't necessary for more than 5 yearss
and indeed
James Sleeman wrote:
I still appear to have the same problem... compiled a couple of minutes
ago, fgfs with no command line options, backtrace follows...
I think I've found the problem which might or might not be a bug in the
OpenAL implementation. It is recommended to place all updates to
Nicolas Quijano wrote:
I don't see why a WIN32 (we define WIN32, doesn't have to be _WIN32) is
such an anathema, seeing as there is one for Apple already.
Frankly I don't care to include it, but there doesn't seem to be a
consensus between windows developers which have to be sorted out before
Nicolas Quijano wrote:
Hi Erik, you should have committed the whole patch, as you broke
building under that system, which uses a bare bones alut (which is why
some of us have moved to the OpenAL SDK, plus I use it in other projects
locally, which use the standard no AL folder setup...)
So
Nicolas Quijano wrote:
#if defined(ALUT_API_MAJOR_VERSION) ALUT_API_MAJOR_VERSION = 1
msg.append(alutGetErrorString(error));
#endif
Shoot, that should also have been alGetError instead.
It's fixed, thanks.
Erik
(now i need some sleep)
Vadym Kukhtin wrote:
Hello!
I'm really like new clouds from Stuart, especially Stratus improvements.
Last weeks I had few long flights, in slow-n-low aircraft, and looked
at FG 3d-clouds for hours.
Then I look at RL clouds, and notice that they have no such smooth
edges, as in FG.
So I
James Sleeman wrote:
Is anybody else using current CVS with 64bit Ubuntu 9.04? Doesn't seem
to be working here, the last message output is
creating 3D noise texture... DONE
then it just sits there looking stupid using 100% of CPU and several
hundred meg of ram.
Are you sure this is
James Sleeman wrote:
On 18/10/09 01:25, Erik Hofman wrote:
Are you sure this is related to the new sound system? There have been
reports of such behavior for some JSBSim aircraft recently. Could you
try both the default c172 and pa28-161 to see if it makes any difference
Don't know
James Sleeman wrote:
Program received signal SIGINT, Interrupt.
[Switching to Thread 0x7fae9a707790 (LWP 5249)]
0x7fae9a418a94 in __lll_lock_wait () from /lib/libpthread.so.0
Hm, that's a thread lock problem inside the OpenAL library.
(gdb) bt
#0 0x7fae9a418a94 in __lll_lock_wait
Martin Spott wrote:
Erik Hofman wrote:
Are you sure this is related to the new sound system? There have been
reports of such behavior for some JSBSim aircraft recently. Could you
try both the default c172 and pa28-161 to see if it makes any difference?
I had checked
I finally found why the sound orientation was wrong, this should now be
fixed in CVS (sound positioning relative to the aircraft origin is still
to be done).
Erik
--
Come build with us! The BlackBerry(R) Developer
Alasdair Campbell wrote:
CVS as off 10 minutes ago gives me SimGear compile error:
sample_openal.cxx: In member function ‘void
SGSoundSample::set_relative_position(SGVec3f)’:
sample_openal.cxx:167: error: no match for ‘operator=’ in
‘((SGSoundSample*)this)-SGSoundSample::_relative_pos =
Jon Stockill wrote:
syd adams wrote:
Tried the patch and see a slight improvement ...
At the moment I have other problems ...no sound , extremely slow loading
times , etc... so I'll keep testing in between audio debugging :)
Ah, I'm glad it's not just me with sound problems - I've just
Torsten Dreyer wrote:
Hi,
todays SimGear cvs doesn't compile for me:
visual_enviro.cxx: In member function ‘void SGEnviro::drawLightning()’:
visual_enviro.cxx:759: error: ‘class SGSoundSample’ has no member
named ‘set_base_position’
sorry, I had to commit another change. it's fixed now.
Hi Nicolas,
Nicolas Quijano wrote:
(Most of this written last night before bed)
Hi all, commenting out code in the destructor won't help, as the problem
is being set-up much earlier, while FGFS is still in the initialization
stages (dt == 0) : in debug, there is a fatal assert on
Vivian Meazza wrote:
Nope, that doesn't fix it - still get crash on exit. But I no longer get
sound stopping when I change window size at runtime.
You might want to comment out some code in SGSoundMgr::~SGSoundMGr to
see what exactly might cause it.
Erik
Alex Buzin wrote:
Hi,
I got an error with the Sunday CVS - FG crashed while exiting .
gdb reports SIGSEGV error at file soundmgr_openal.cxx, line 159.
Error was fixed by changing lines 157-159 from:
buffer_map_iterator buffers_current = _buffers.begin();
buffer_map_iterator
Nicolas Quijano wrote:
Now, I can build a working exe with my old/Vivian's setup, but get no
working sound (and no errors) but I do have the crash on exit. I believe
it's because we're trying to release the alcDevice and alcContext a
second time by calling AlutExit., after doing it manually
Hi Vivian,
Vivian Meazza wrote:
Patched soundmgr_openal.cxx/hxx and sample_group.hxx with
+#elif defined(_WIN32)
+# include al.h
or
+#elif defined(_WIN32)
+# include al.h
+# include alc.h
+# include AL/alut.h
I've added these to the latest commit.
Here is a status update of the
Durk Talsma wrote:
Hi Folks,
Just wondering: Suppose we're aiming for another release by the end of the
year, would it be feasible to go ahead with our original plan and release a
1.9.2-beta version just before FSWeekend? We've seen are few relatively major
code overhauls in the recent
Ron Jensen wrote:
On Sun, 2009-10-11 at 20:56 +0200, Durk Talsma wrote:
Hi Folks,
call for a feature freeze by say mid-October
(that would be, ahem, next weekend).
I would love to see JSBSim synced before the feature freeze... There
are some tweaks to the piston code; ram-air, better
James Turner wrote:
There's quite a lot of improvements that could be made to higher
levels of MP, if arbitrary properties could be synchronised over MP :)
I once played with the idea of assigning 32-bit id's to property names
(and make the unique and consistent across clients) and a simple
Alan Teeder wrote:
Erik
Sorry, I gave the wrong missing name -- I should have written alutGetError,
as this is not in the older alut.h (or al.h or alc.h).
Ah that was just a matter of commenting out the proper section. Should
be fixed now.
Erik
Hi Anders,
Anders Gidenstam wrote:
Hi Erik,
I think I have found a small bug in the new sound system:
When I fly past (well, over) the markers (inner, middle or outer) the
marker beeps has a very neat fade in/out and doppler effect, but I'm
fairly sure the device producing the sound
Alan Teeder wrote:
Thanks for fixing this.
However the pre-built libraries referenced in README.msvc do have an old
version of alut.h which is missing the alcGetError and associated
definitions. I don´t know who maintains these useful archives.
It's not alut.h that defines these
Curtis Olson wrote:
Hi Erik,
One quick question: will the sound configuration xml files need to
change to match the new system or will there be backwards compatibility?
It's backwards compatible. I do plan a new format change to be able to
position the sounds in 3d-model space instead of
Alan Teeder wrote:
Sorry to be the messenger, but compilation of soundmgr_openal.cxx and all
flightgear files using soundmgr_openal.hxx fails under VC90.
No problem, I already was expecting these reports since I can't test on
all platforms.
See attached build log.
It's beyond me why gcc
Erik Hofman wrote:
Most of the work to transition to the new sound system has been done now
and the patch size starts toe exceed the comfort level for most so I'm
going to commit the current result somewhere today.
I'm going to take this back, I discovered a problem that needs more
Allright, the new sound system has been committed. The basics works as
follow:
There is one SoundMgr that handles multiple SoundGroup classes.
Each SoundGroup class handles multiple SoundSample classes.
A SoundSample class defines the properties of each individual sound like
pitch, volume,
Pete Morgan wrote:
I'm new to flight gear, and am rejoicing in the pleasure. However I do
have some serious reservations about the project towards global world
domination that need to be addressed.
For a start without my coders/web/brief hat on, what must be reorganized
is that
Curtis Olson wrote:
So all you need to do is come up with yet another really cool idea now and
finish it since one of them already claimed the current and any future audio
system. (Hopefully that is read as some Friday afternoon humor with lots of
smiley's) :-) :-) :-)
whehe.
But more
Most of the work to transition to the new sound system has been done now
and the patch size starts toe exceed the comfort level for most so I'm
going to commit the current result somewhere today. The code is not
completely finished yet but it will allow others to look at it and add
small
There's one problem that comes up; At the moment I am working on
updating the Sound System. While I'm not claiming this would be a
contender for the contest it's clear to me that I needed help for it in
some parts. Who's going to win then?
After all, FlightGear is and will be, a joint effort
James Turner wrote:
On 28 Sep 2009, at 08:49, Stuart Buchanan wrote:
Thanks for the patch.
I'm currently working on improvements to the 3D clouds, including some
changes/bug-fixes to the shaders.
Are you planning some enhancements to the shaders yourself? If so,
we should coordinate to
Matias D'Ambrosio wrote:
This is almost certainly a bug in fgfs or PulseAudio.
Yeah, no use in hunting this down until I've got the new sound system ready.
Erik
--
Come build with us! The BlackBerryreg; Developer
Olaf Flebbe wrote:
Erik,
I would like to see an option to disable sound at all.
The changes should make that easy. Actually it was the reason I started
changing some code and decided it could use a real update in the end.
Did you know that the sound system eats up to 30% of CPU time,
Olaf Flebbe wrote:
Windows Implementations:
git can be tedious to use on Windows: I had big problems working on a
project mixing up git repositories on linux pushed and pulled by a
windows git via samba. git at some point complained about non existing
differences: Somehow line ending
Matias D'Ambrosio wrote:
On linux there are two implementations, the old one (OpenAL Sample
Implementation, last version was 0.0.8), which had several issues
(including broken Doppler), and the new OpenAL-Soft which most desktop
distros are now carrying.
Around 1.4 or 1.5 there were a
While reworking the sound system I started to wonder about the ATC
chatter and such (like beacons and morse code).
Should these be tied to the main aircraft (and hence fade away when the
aircraft gets further away) or should these be audible no matter what?
Erik
James Turner wrote:
I suspect this should be a pref - either the local cockpit sounds are
associated with the aircraft model (realistic operation) or they are
associated with the view position (unrealistic but useful if you like
switching to an outside view but don't want to miss a bit
Good idea's John, I'll try to think about it when going further. It
might need adjustment after the first commit but I'll try to make it easy.
Erik
--
Come build with us! The BlackBerryreg; Developer Conference in SF,
The do state This is a commercial adaption of the world renown flight
Gear project. Further information available in our Developers Area in
the shopping area:
http://www.flightprosim.com/#order
Jon S. Berndt wrote:
This looks much more problematic:
http://www.flightprosim.com/disclaimer/
James Turner wrote:
Excellent news. My biggest two requests would be to get the sound code
out of main.cxx, and proper support for positional sources - i.e AI or
MP traffic. Being able to position sounds on the airframe would be
good too - engine and gear noises especialy.
Tom P
Hi John,
John Denker wrote:
That's a good thing to work on. Thanks for the heads-up.
Here's one more thing to think about in this context:
text to speech. AFAICT the status is:
1) The existing home-brew TTS system (involving
ATC/default.vce and ATC/default.wav) is very limited.
It
Hi Durk,
Durk Talsma wrote:
That sounds pretty awesome. (Sorry for the lame pun). :-)
:)
Seriously, though, since you mention that this is something you're working on
for the longer term, do you think this planned update should be included in
the new release (planned beta release around
James Turner wrote:
Let me know if I can help at all. One thing I thing I would strongly
suggest on the FG side, would be to ensure the SG side uses Mathias'
excellent basic types (SGVec3d/f, SGQuatd, etc) to express positions,
vectors and orientations to the code. The SG layer itself
James Turner wrote:
On 20 Sep 2009, at 09:25, Erik Hofman wrote:
I might need some help to understand quads, but I am converting it to
SGVec3f where ever possible.
No problem, I'm sure Mathias / Tim / myself can oblige.
Thanks!
One other I've remember from looking at the code
willie wrote:
Im also seeing a ~4degC random fluctuation in the dew-point. CVS from
1600GMT today.
Fly from KDEN you will get snow almost immediately. So its not very
high altitude.
It's way more extreme than that, the dewpoint once in a while seems to
reset to -2.8308 from it's current
Hi,
This is a heads up that I'm working on improving the sound system quite
a bit with a few new concepts in mind.
Right now the FX class is the heart of the audio system while the
SoundManager is loosely tied between the samples and the FX class. In
the future the Sound Manager will be the
I would have responded in this thread but decided not to since it
probably would only add fuel to it. Let stick to that it's tasteless and
realize that FlightGear has no support for weapons of mass murder. So
this mission will end up being merely a sightseeing mission.
Erik
AJ MacLeod wrote:
On Friday 18 September 2009 14:56:12 Curtis Olson wrote:
Github wrote us back saying: Git doesn't work very well with large amounts
of binary assets. They didn't offer further explanation to where the
problems might be? Maybe they were just putting the brakes on and
Lee,
I do agree with all you wrote and started something similar but then
decided I didn' t find this mailinglist the place to discuss it. Still,
I do agree.
Erik
--
Come build with us! The BlackBerryreg; Developer
Ah ok, I didn't realize it is aimed at machine code only.
Erik
Nicolas Quijano wrote:
binary data != binary code.
On Fri, Sep 18, 2009 at 1:07 PM, Alex Perry alex.pe...@pamurray.com
If they have, it won't help us. We're not distributing blobs of x86
machine code.
syd adams wrote:
I have no idea what the problem might be , but while the flickering
happens , the /rendering/scene/ambient and specular colors jump by about
a factor of 0.2.
I'll try to take a look at it this weekend.
Erik
syd adams wrote:
Just more observations ...
/environment/dewpoint-degc flickers by about 4.0 degrees , as if Im
going through layers as i climb , and airspeed needle starts
oscillating rapidly above a certain altitude , but haven't pinned down
the altitude when the changes start* *
That
Gene Buckle wrote:
Would it or could it be possible to reload a protocol file as the sim is
running.
I'll second this one. I'm working on adding FG support to RJGlass and the
little tweaks are killing me with 30+ second cycle times. :)
I think I've nailed this down in CVS. There is a new
Curtis Olson wrote:
I'd be interested to know if things like the telnet interface (and
other network interfaces) get closed and reopened correctly. This
sounds like a kind of drastic thing to do ... to reset the entire
network subsystem, but maybe it will be ok.
The FGIO class has always
AJ MacLeod wrote:
With the data tree, we frequently have several people working on the same
area
(aircraft models, in particular) - not only that, but many of the people
working on aircraft models have historically not had any kind of commit
access to the main repository. The line
Behlül UÇAR wrote:
Hello
I'm getting some errors while trying to build terragear.
./configure works fine for me, it says all dependencies are OK (except
nurbs library but it says it won't affect whole installation)
But make does not work fine for me, it gives some compilation errors.
Behlül UÇAR wrote:
Thanks for your answer.
But I already have plib 1.8.5 installed, I can build and run flightgear,
otherwise it would be impossible to build it without plib.
I already have simgear 1.9.1 installed.
That's odd. I would hav expected the compiler should be able to find
Tim Moore wrote:
The worst thing about that line is that it is broken :)
I can't find anything about it that makes it 'broken', knowing that
doubles are 64-bit and floats are 32-bit. It might be a bit better this
way though.
Erik
Anders Gidenstam wrote:
On Tue, 25 Aug 2009, Erik Hofman wrote:
Tim Moore wrote:
The worst thing about that line is that it is broken :)
I can't find anything about it that makes it 'broken', knowing that
doubles are 64-bit and floats are 32-bit. It might be a bit better this
way though
Tim Moore wrote:
I've committed a version of Till Busch's terrain effects, as seen at LinuxTag.
I know that he hasn't finished tuning them, and I've changed his landmass
effect
to use the base terrain texture, which he's not entirely in agreement with :)
Nevertheless, they are great
Tim Moore wrote:
Till went on vacation right around the time I checked his work in; I'm sure
he'll
have comments when he gets back. On the other hand, feel free to check in
improvements.
Ok, thanks. I'll do.
Erik
Torsten Dreyer wrote:
Hi,
There are some possible floating point exceptions in oursun.cxx:
in SGSun::update(double,double) there is
sun_exp2_punch_through = 2.0/log(visibility);
visibility is assigned the new_visibility _before_ new_visibility is clamped
to 100 % 45000. Because update
Victhor Foster wrote:
I tried applying the patch and editing it to change float n=0.06 +
dot(nvL[0], a); to float n=0.06 + dot(nvL, a);, but my framerate
hasn't improved. What's the problem?
Probably that the shaders work differently than I expected and that the
error triggered some
Victhor Foster wrote:
Want a backtrace?
No, it's expected behavior.
Erik
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment
Randall Green wrote:
Victhor,
You are absolutely amazing! But now I get file not found on jconfig.h.
Is it needed? I see the code looks like this:
#ifndef JCONFIG_INCLUDED/* in case jinclude.h already did */
#include jconfig.h/* widely used configuration options */
#endif
Tim Moore wrote:
I've committed a version of Till Busch's terrain effects, as seen at LinuxTag.
I know that he hasn't finished tuning them, and I've changed his landmass
effect
to use the base terrain texture, which he's not entirely in agreement with :)
Nevertheless, they are great examples
Torsten Dreyer wrote:
With this patch, I get a number of
No render bin number specified in render bin section
No render bin name specified in render bin section
I already got them before the patch..
Erik
--
Let
Martin Spott wrote:
This patch is probably not for everyone. At my end I'm reading the
following message in the terminal:
FRAGMENT glCompileShader FAILED
FRAGMENT Shader infolog:
0(27) : error C7011: implicit cast from float to vec4
glLinkProgram
Martin Spott wrote:
This patch is probably not for everyone. At my end I'm reading the
following message in the terminal:
FRAGMENT glCompileShader FAILED
FRAGMENT Shader infolog:
0(27) : error C7011: implicit cast from float to vec4
glLinkProgram
I wrote:
Ahh, that line should read:
float n=0.06 + dot(nvL, a);
instead of:
float n=0.06 + dot(nvL[0], a);
Which brings the frame rate back to what it was :-/
Maybe it might be a good idea to specify which of the effects you want
to turn on or not? Chances are I could care less about
Stuart Buchanan wrote:
Hi All,
I have the pleasure to announce that the latest edition of the FlightGear
Newsletter is now available:
http://wiki.flightgear.org/index.php/FlightGear_Newsletter_August_2009
Looking at the custom made scenery screenshots I must say that hand
altered
Jon S. Berndt wrote:
Erik Hofman wrote:
Apperently this was needed to compile with MSVC 9 (patch was added by
Fred twice). I probably should have made a test build before
committing
to CVS.
Which wouldn't have revealed the problem.. it might get picked up at
another location for me.
I'd
Anders Gidenstam wrote:
IMHO the one important threading benefit is if we could get all of the
rendering off the main simulation loop, meaning that the model runs
independent of the presentation. (Ok, expensive environment eye candy
like the traffic manager or wild fire CA would also be
leee wrote:
I'm not really thinking in terms of 'threading' at all, which I
think is a very limited and half-house sort of technique. But
neither though do I think it needs to be thought of as a pure real
time system. Rather, I'm thinking in terms of the external FDM
mechanism
asma ben zakour wrote:
The problem seems to be that the xml file I put into data\protocol is looking
for some plane informations it cannot find and FG crashes...
I wrote:
I must admit I never tested that..
With a bit of luck I might be able to test for that this weekend.
When I find
asma ben zakour wrote:
Hi every one !
I'm a Phd Student on data mining and prognostic , and I want to recover
some aircraft flight data from FG for testing algorithms .
I writes an XML File *thesis.xml* ( in the *data/protocol* FG directory
) witch allow to have some information from
asma ben zakour wrote:
Tahnks for the answer, actually I don't want to replay the flight, but
extract information from the output file I get from FG.
The problem seems to be that the xml file I put into data\protocol is
looking for some plane informations it cannot find and FG crashes...
It's committed. Thanks.
Erik
Nicolas Quijano wrote:
Hi all, can't build in debug atm on Doze, as a recent change in
simgear/screen/RenderTexture.cpp breaks non X11 builds because of non
isolated GLX code.
The attributes code should have been wrapped (tsk tsk 8p)
This is a bandaid, as it
Curtis Olson wrote:
I haven't looked at the code, but generally, I think it makes sense
(when dealing with live data) for the generic protocol to enter a while
loop and read data until there is no more available. That way if the
sender is sending at a higher rate or FlightGear gets behind
Erik Hofman wrote:
Curtis Olson wrote:
I haven't looked at the code, but generally, I think it makes sense
(when dealing with live data) for the generic protocol to enter a while
loop and read data until there is no more available. That way if the
sender is sending at a higher rate
Peter Völk wrote:
Hi All,
I'm trying to put my own data into FG, with the native fdm and the
generic input protocol at the same time. My problem is, that fdm works
fine, but the data is send via UDP over the generic protocol has some
kind of lag or rather delay. When I pause sending the
Petr Gotthard wrote:
To follow the do things right rule I think it would be great to implement a
generic interface for standalone I/O modules. Both Micro$oft FSX and X-Plane
have such interface. The MS HLA users would just need to build a shared
module (.dll or .so) for a particular HLA
Petr Gotthard wrote:
Let me advocate the idea:
I'm proposing a generic interface. If you look from the other side, it's a
possibility to easily implement a new I/O module for FlightGear. To help
people that might be interested to extend FlightGear but do not want to
recompile the whole
Curtis Olson wrote:
Can we just quote Mark Kilgard's comment in that thread that
modification is fine? I like Debian and I ran their distribution on my
machines for many years. I admire how carefully they follow through
with these licensing issues ... but my word ... no wonder their
Erik Hofman wrote:
If this code is just used by a utility that is useful for developers
only (normalmap) then I'd move the code oevr to that specific directory
and leave it at that.
I had a few spare minutes and the code is moved over now.
Erik
Curtis Olson wrote:
I haven't had a chance to contact Butterfly Media myself, but perhaps
someone here would be willing to pull lead on that?
http://www.butterfly-media.co.uk/index.htm
This weekend I was contacted by an ebay seller. I did a quick google
search and found that his ebay
gcc can't be trusted.. I did a test compile here :-(
I'll fix it.
Erik
Martin Spott wrote:
Hi Erik,
Erik Hofman wrote:
Update of /var/cvs/SimGear-0.3/source/simgear/screen
In directory baron.flightgear.org:/tmp/cvs-serv19946
Modified Files:
Makefile.am
Removed Files
Martin Spott wrote:
No problem, maybe the changed file just didn't make it into the CVS
commit. I'm very cautious these days for the sake of not having to deal
with this sort of stuff once we're set up at LinuxTag ;-)
Fair enough.
Erik
Curtis Olson wrote:
I don't see any thing in the license terms that states we cannot modify
the code. Are we running on the assumption that we can only do what is
expressly allowed? Perhaps Erik Hofman should address this. As I look
at the code I see it's a full C++ class. But I'm
Looking at the code it is heavily modified in the mean time, although
parts of the original texture loading code are still in place.
Erik
--
Are you an open source citizen? Join us for the Open Source Bridge conference!
Tim Moore wrote:
I mostly agree with this, though I continue to maintain that the new types
are fully in the spirit of the property system, moreso than array types would
be. I'd also suggest that no one here knows the right answer to this question,
making the option of playing with the new
601 - 700 of 1053 matches
Mail list logo
