New Release OGLAClient 100608 (Second Tuesday edition)

[Xyon]

Guys, this is something of a moot point. Maybe Artlav will come back to the OGLA client, maybe he won't. I hope he does, in time, because I think it has a lot of promise, but that's nothing which will be decided here, nor by anyone but him. The client is, as I understand it, at a release-quality level already anyway, and it's not being abandoned, as Artlav has said.

There's really nothing else to talk about in here.

 

[computerex]

Nobody is badgering artlav to continue his work on the client. I think people are merely expressing their appreciation for his efforts.

 

[Xyon]

The way I understood it, what was being posted was more indignance at the "Nobody cares about Linux compatibility" comment. But perhaps this was not the case?

 

[tblaxland]

Nobody is badgering artlav to continue his work on the client. I think people are merely expressing their appreciation for his efforts.

I agree (and I appreciate his efforts also ).

 

[Xyon]

Fair enough, then I sit corrected. Must've just been me.

 

[n72.75]

Actualy, Orbiter is the only the reason that I still use Windows.

 

[Enjo]

Actualy, Orbiter is the only the reason that I still use Windows.

Same here. Think about the kind of productive market you could reach and bring here after it was finished and announced at http://www.winehq.org/ as "gold" (cjp is a good example. Ever heard of Ultimate Stunts?). No fluffy features are needed. Just bare bones, so that it Just Works (TM), so that Linux geeks and their converted kids can learn physics.
(Same goes for the main dev team about addon development environment which must be sticked to MS VS, but then again, I may simply not understand why it's necessary to use VS instead of MinGW)

Besides I believe that the whole idea behind MFD2::Sketchpad was platform independence ~ more FPS for MFDs.

I may sound persuasive, but if Artlav doesn't want to continue OGLA, then it's fine, but if so, then I'd like to propose creation of a community-based, open source, C++ light OpenGL client. I myself know a thing or two about OpenGL, but I'm already stuck to Launch MFD that some of you find essential, so I can't leave it and I could only code a few lines, but hey - that's why some projects are community-based, with Launch MFD being no exception. See how it's grown thanks to all the contributors?

 

[Artlav]

reason that I still use Windows.

Ever heard of Slax Linux? One of the most beautifully designed OS, with all pieces apart yet fitting together.
No f-ing installers like half the stuff on Windows come with and which i hate dearly. Yet Windows rules this weird world.

Same goes for the main dev team about addon development environment which must be sticked to MS VS, but then again, I may simply not understand why it's necessary to use VS instead of MinGW

Technical reasons - i was unable and never heard of someone being able to link GCC compiled code with Orbiter and it's .lib files. Maybe it changed later, but it's non trivial.
Then again, MSVS IDE is an example of a thing done pretty well by Microsoft, i guess because they use it themselves.

propose creation of a community-based, open source

Which is what OVP is all about, and OGLA closely defined?

C++

Don't get me started on that victim of abortion.

light OpenGL client

What constitute light/lite? What should be removed, what should be preserved?
Which systems to target, what features to keep?

It's quite trivial to get OGLA engine simpler, the less features there are, the exponentially less links between them to keep in mind.

that's why some projects are community-based, with Launch MFD being no exception. See how it's grown thanks to all the contributors?

Yet no one bothered to fix the PEG guidance code in it? I may pay you a visit. (It was quite an old version i've seen, i suppose)

 

[Enjo]

Technical reasons - i was unable and never heard of someone being able to link GCC compiled code with Orbiter and it's .lib files. Maybe it changed later, but it's non trivial.
Then again, MSVS IDE is an example of a thing done pretty well by Microsoft, i guess because they use it themselves.

Right. Then the next tough question for main dev team - does Orbiter need to be compiled in VC instead of MinGW?
[EDIT]
aaah, I remember reading somewhere that you can link with GCC .lib which was made in C language and in VC, but you can't link that lib which was made in C++. Maybe this is the case.

Which is what OVP is all about, and OGLA closely defined?

C++
Don't get me started on that victim of abortion.

Let's stop here for a second. If you want to gather a community around an open source project (OGLA), especially a project based on a project (Orbiter) built in particular language (C++), where nearly all the devs use this language, and targeting it for a platform that uses the very same language family (C/C++) for breakfast, lunch and dinner (Linux), then what you want is using just that language.
I, for example, have never thought about touching OGLA's sources because of Pascal. It won't let me learn things that I want to know and I don't want to sacrifice too much of my time to the others, so don't let me get started about THAT victim of orphaning, whose father now works for MS on a different language, while Bjarne still cares...

What constitute light/lite? What should be removed, what should be preserved?
Which systems to target, what features to keep?

If that's an honest question, then my honest answer is - please just keep texturing, one light source and mostly - try to do something about MFDs since we have Sketchpad now. Are there any options? I've never done any research in this field myself.
My point is - try not to do too much to save your time, so that you don't loose interest, and that we finally have a basic, although firm start on POSIX platforms. We don't know whom we may lure here later, especially after there actually are reasons to drop VS for MinGW in addon development.

Yet no one bothered to fix the PEG guidance code in it? I may pay you a visit. (It was quite an old version i've seen, i suppose)

Well no, but Kwan has made his Java Multistage PEG just for PEGAutopilot and Launch MFD, mind you. At least we have something to start with.
Anyway, all constructive commitments are welcome

 

[Artlav]

Let's stop here for a second.

Makes sense. I'm not yet in the mood to be serious, so let's assume our arguments cancelled each other out, ok?

If that's an honest question, then my honest answer is - please just keep texturing, one light source and mostly - try to do something about MFDs since we have Sketchpad now. Are there any options?

Honest question again - if you turn off all the features but what you've enumerated in current OGLA, what stay wrong from your point of view?

To everyone also: About MFD's - i know about a few objective problems with that, but i would have liked to get a comprehensive list of subjective problems people see (like fonts. I'm completely insensitive to them).
Or, anything in them that bothers you, wrt current version (Important, long-fixed bugs from OGLA 091029 (one that have blazing red Obsolete! sign near it but many people still trying to use) are a pain to hear about again and again).

Any help?

 

[computerex]

aaah, I remember reading somewhere that you can link with GCC .lib which was made in C language and in VC, but you can't link that lib which was made in C++. Maybe this is the case.

In C++, there needs to be some way to link methods to their classes. So each compiler has its own mangling scheme. The name of the exported method is mangled to give extra information:

?GetTrimScale@VESSEL@@QBENXZ

But the mangling scheme is specific to each compiler, soo... It should be theoretically possible to build a wrapper between the two. Lots of typing, but trivial in foundation. I'll give it a go.

 

[Enjo]

Artlav:
I'll have to see later. It's just such a moment in my "production phase of life" that I'm jobless, therefore you see me posting, and only now I can answer those questions after making some research. The biggest problem was always FPS. But you see... I'm glad that our points are at least canceled out, because even a tester wants the thing that he tests to have some sort of future, and not be trashed, because the tester's hours spent are as valuable as the programmer's.

Lots of typing, but trivial in foundation.

In that case, others like me could continue it as well.

 

[computerex]

Yay (look at bottom left)

 

[cinder1992]

Yay (look at bottom left)

0_0
how the HELL did you manage that? I thought that making add-ons in anything but VC++ was impossible (or close to it)!

 

[computerex]

0_0
how the HELL did you manage that? I thought that making add-ons in anything but VC++ was impossible (or close to it)!

http://orbiter-forum.com/showpost.php?p=197310&postcount=131
Concept is simple. You have one dll that exports a C based interface. You have another dll which loads the plug-ins created with the GNU compiler, that is the one that is activated in the launchpad. Each plug-in then dynamically links to the dll which exports the orbiter's interface. The loader dynamically links to the plug-ins, the plug-ins dynamically link to the interface dll. If implemented correctly, this should allow a shift of considerable functionality over to the gnu compiler.

 

[Chupacabra]

I just want to add that I have really appreciated Artlav's work. Not just OGLAClient.

That said, I have been drooling over OGLAClient with Orbiter 2010 since it's release. I have escaped fps-hits (unless wireframe is on, but can be fun still :lol and have found it to increase the immersion factor when you see MIR's (or the ISS's)truss segments shadow other sections. It really makes the model pop out.

Thank you Artlav for all your great, and they have all been great, contributions to Orbiter. Your additions have been a real treat.

 

[Enjo]

Artlav:

Time for some meat. I've done some tests and it looks like It's been a long time since I've checked out Ogla ...
Everything that is basic is close to be working and it makes me happy. There's no FPS drop in MFDs (how did you solve it?), which is a big plus already. Unfortunately there were some problems under Linux:

1) First there were no texts in MFDs, but after copying fonts from Windows, it started to work of course. The problem is that after this, Map MFD stopped displaying the graphics (text was OK). All the other MFDs seemed OK.

2) In the provided scenario file, after unzooming to about 28 km with terrain on and terrain only, Orbiter hung. The log is provided. Console said:
enjo@mitcsh:/media/de/backup/f/cosmo/orbiter100606$ err:ntdll:RtlpWaitForCriticalSection section 0x7e58c9c0 "x11drv_main.c: X11DRV_CritSection" wait timed out in thread 0024, blocked by 002a, retrying (60 sec)

3) I get some random, rare crashes upon selecting a target in MFDs with Shift+T. I'm trying to recreate them.

My GPU is NVIDIA GeForce 9400 GT


And to answer your question about Ogla lite, as a physics lover, I'd be fine with just the Terrain feature. That's it. I can help you debug this while I have time because I understand your frustration about outdated bug reports and I myself still have some free time.

Thanks so far.

 

[Zachstar]

I am personally for the OGLA lite idea. If Shadows and maps are giving you that much headache Linux users can made do with what Normal Orbiter folks use in my opinion.

For the bigger stuff I am of the personal opinion of going to Direct X 10

 

[Artlav]

The problem is that after this, Map MFD stopped displaying the graphics (text was OK).

Graphics in Map MFD are pure GDI, and they are often unpredictable. I haven't figured out yet why they appear or disappear every other run, on any platform. Known issue.

2) In the provided scenario file, after unzooming to about 28 km with terrain on and terrain only, Orbiter hung. The log is provided.

Let's see. Under Linux means Wine, but which version?
First thing first, is there proper windows on that system and is there such a problem there?

Second, let's try to get Wine out of the picture:
http://orbides.1gb.ru/orbf/oglathin-100818_server.zip Goes to Orbiter dir under Wine
http://orbides.1gb.ru/orbf/oglathin-100818.tar.gz Goes to it's own dir in Linux
Textures for planets you care about go to textures folder of the latter part.
Heightmaps go to heightmaps. Capitalization should be lower-case for both dirs.

Now, start Orbiter in Wine and get the scenario running, then run "oglathin 127.0.0.1". Once it loads, enable terrain (OGLA window, F7-5) and try the stunt. (Controls work best from Orbiter window, not OGLA window).

This way the rendering engine runs natively, and if it's still crashing then the bug is mine or one in drivers.

3) I get some random, rare crashes upon selecting a target in MFDs with Shift+T. I'm trying to recreate them.

Hard to say, might be Wine fault. Can they be reproduced under proper windows?

And to answer your question about Ogla lite, as a physics lover, I'd be fine with just the Terrain feature.

Of all the slowpoke features, why terrain, the slowest of them? +below.

I am personally for the OGLA lite idea. If Shadows and maps are giving you that much headache Linux users can made do with what Normal Orbiter folks use in my opinion.

Personally, i don't see a point - OGLA was designed modular, almost all it's features can be disabled and enabled, many at run time, and once disabled they don't influence anything. It also means that features don't interfere with each other's development much.

So, cutting something out of the code is somewhat useless - you want it to run on ancient pc, turn off al the flashy stuff and it will run.

 

[Enjo]

Let's see. Under Linux means Wine, but which version? First thing first, is there proper windows on that system and is there such a problem there?

I've just upgraded to 1.2 and it's the same. On Windows I'm not getting any of such problems.

Now, start Orbiter in Wine and get the scenario running, then run "oglathin 127.0.0.1". Once it loads, enable terrain (OGLA window, F7-5) and try the stunt. (Controls work best from Orbiter window, not OGLA window).

This way the rendering engine runs natively, and if it's still crashing then the bug is mine or one in drivers.

Done it. The thin client gets hung in the same manner.

Hard to say, might be Wine fault. Can they be reproduced under proper windows?

I'll try when I'm there. I will also try it under Linux and new Wine 1.2

Of all the slowpoke features, why terrain, the slowest of them? +below.

Personally, i don't see a point - OGLA was designed modular, almost all it's features can be disabled and enabled, many at run time, and once disabled they don't influence anything. It also means that features don't interfere with each other's development much.

So, cutting something out of the code is somewhat useless - you want it to run on ancient pc, turn off al the flashy stuff and it will run.

I see that you've spent some time on the terrain. Actually all I'd need are textures for my purposes. You got it all in one big pack.

As for limiting features and their modularity, you said:

It's quite trivial to get OGLA engine simpler, the less features there are, the exponentially less links between them to keep in mind.

I think that Zachstar, as well as I, are trying just to save your time, if nothing else


I'd like to ask just one question while we're here:
Wasn't the idea behind OGLA to replace the DX7 client which runs poorly under Wine, while the DX10 runs OK (does it?) ? If this is true and since we have DX10 underway, then yes, I'd agree with you about letting OGLA go, Artlav.
Could I ask someone to clarify the DX10 situation under Wine?