New Release OGLAClient 100608 (Second Tuesday edition)

Cornflake

New member
Joined
Feb 5, 2008
Messages
117
Reaction score
3
Points
0
Location
Colorado, USA
I've had quite a few crashes in just a short time of trying to get this to work.

Here's my crash log. Most of them are when I either tried to load a DG-IV or load a Delta-Glider in Cape Canaveral. Once in a while, it will load fine in Cape Canaveral, only there aren't any of the changes from this. Or I'm in a sea of blue with no textures around, and zooming out reveals that the Earth is actually a black hole. And attempting to load a previous simulation results in tv-style static being placed everywhere and the framerate dropping to the speed of a dying cow.

Also, the fact that I have to alt-tab (but not enough to leave the game) in order to get to menus such as the scenario editor is rather annoying.

Same problems here. I am running Win 7 Ultumate x86. I thought it was enabling shadows that caused the problem, but I think it's more of an issue with the DG's and Cape Canaveral. I'd rather not have to run Orbiter in it's default DX7 mode as it is slow as frozen dog turds on any OS newer than XP :facepalm: Log is attached.

P.S. Unless I am in Windowed mode (or click on the desktop on my right monitor) I can't access F* menus
 

Attachments

  • ogla.txt
    13 KB · Views: 3
  • Orbiter.txt
    6.9 KB · Views: 2

Cornflake

New member
Joined
Feb 5, 2008
Messages
117
Reaction score
3
Points
0
Location
Colorado, USA
When I did successfully start up, here's what I did see (attachment). Look, ma! floating!

orbiter 2010-09-15 10-10-32-69.png

And I also attached a screen of my settings. I'm running on nVidia drivers 190.38 w/ GTX 260

ogla_settings.png
 

dumbo2007

Crazy about real time sims
Joined
Nov 29, 2009
Messages
675
Reaction score
0
Points
0
Location
India
Hi,
I have a clean install with just the base and patch. I tried to run OGLA and it was fine till I pressed F1 to enter the cockpit view. At that point it crashes. I have attached the log files. Anyone else has a similar problem ?
OpenGL 2.0/GMA 4500M/Win 7

Exactly the same problem with Orulex and the normal Orbiter.exe
 

Attachments

  • logs.zip
    2.5 KB · Views: 7
Last edited:

haze39

Member
Joined
Mar 23, 2008
Messages
30
Reaction score
0
Points
6
OGLA CLIENT ORBITER 2010 INSTALLATION ORDER

Hi

Just a question about the OGLA Client,and how to install it in the perfect order into Orbiter2010?.Anybody who has done this and made it work properly,please send me a reply:tiphat:


Thanks
haze39:hello:
 

Rtyh-12

New member
Joined
Sep 12, 2010
Messages
918
Reaction score
0
Points
0
Location
Kraken Mare
If this is a thread about installing OGLA anyway, I think it wouldn't be considered off-topic if I ask whether the same installation can run both OGLA and non-OGLA (not at the same time of course, but separately the no graphics .exe and the graphics .exe).
 

Linguofreak

Well-known member
Joined
May 10, 2008
Messages
5,017
Reaction score
1,254
Points
188
Location
Dallas, TX
I'm having joystick trouble under Wine. Neither throttle nor rudder will work on either of my joysticks under OGLAClient/Wine, whereas both will work under OGLAClient or the builtin on WinXP. I'm uncertain whether this is an OGLAClient specific problem or a general Orbiter problem, as the builtin client CTDs on Wine, making how it interacts with the joystick untestable. Does OGLAClient touch the joystick handling, or is that completely the domain of the server?
 

Artlav

Aperiodic traveller
Addon Developer
Beta Tester
Joined
Jan 7, 2008
Messages
5,789
Reaction score
778
Points
203
Location
Earth
Website
orbides.org
Preferred Pronouns
she/her
OpenGL 2.0/GMA 4500M/Win 7
Sounds like 2D elements issues - MFD's, screen, panels. Does it work if you turn them off in config?
Does it also crash with terrain, but in outside view?

how to install it in the perfect order into Orbiter2010?
OGLA Client+Orbiter2010P1 update ETA 2011.

whether the same installation can run both OGLA and non-OGLA
Should work fine, OGLA is just a plugin.

Does OGLAClient touch the joystick handling, or is that completely the domain of the server?
OGLA intercepts mouse and keyboard for client commands, passing the rest to the core. No explicit interactions with joysticks.
 

Linguofreak

Well-known member
Joined
May 10, 2008
Messages
5,017
Reaction score
1,254
Points
188
Location
Dallas, TX
OGLA intercepts mouse and keyboard for client commands, passing the rest to the core. No explicit interactions with joysticks.

OK, thanks. Some further testing seems to indicate that Wine itself is doing something weird to the joystick input. I was getting response with one program from the in-program joystick axis assignment dialog, but not during normal operation.
 

Linguofreak

Well-known member
Joined
May 10, 2008
Messages
5,017
Reaction score
1,254
Points
188
Location
Dallas, TX
I have a feature request. I posted it as a general feature request for Orbiter here, and was told that it's handled completely by the graphics client. The idea is to have star system config files specify the location for star data, using star.bin as a fallback if no location (or an invalid location) is specified, rather than loading the star data for all systems from star.bin.
 

Wishbone

Clueless developer
Addon Developer
Joined
Sep 12, 2010
Messages
2,421
Reaction score
1
Points
0
Location
Moscow
Will be posting the response in the bug thread but I think it should be the standard set by Dr.Schweiger, not disparate attempts by front-end developers...
 

Linguofreak

Well-known member
Joined
May 10, 2008
Messages
5,017
Reaction score
1,254
Points
188
Location
Dallas, TX
I just came across something interesting in the Wine FAQ (Section 10.2):

When run under Wine, a Windows app can do anything your user can. Wine does not (and cannot) stop a Windows app directly calling Linux syscalls, messing with your files, altering your startup scripts, or doing other nasty things.

(Emphasis mine). I'm thinking that, in the context of OGLAClient for Linux users, the ability for a Window's app to directly make Linux syscalls might not be a nasty thing at all. If a Windows program running under Wine can make Linux syscalls, then couldn't we make an Orbiter module that was a native Linux graphics client for Orbiter?
 

Artlav

Aperiodic traveller
Addon Developer
Beta Tester
Joined
Jan 7, 2008
Messages
5,789
Reaction score
778
Points
203
Location
Earth
Website
orbides.org
Preferred Pronouns
she/her
Linking a VC++ 2008 program to libc? That's going to be one hell of a Frankenstein monster, if even possible.
syscalls are not the right domain, as far a i know.
 

Linguofreak

Well-known member
Joined
May 10, 2008
Messages
5,017
Reaction score
1,254
Points
188
Location
Dallas, TX
Linking a VC++ 2008 program to libc? That's going to be one hell of a Frankenstein monster, if even possible.
syscalls are not the right domain, as far a i know.

From what I've heard about how Wine works, a Windows process is set up as a normal Linux process and then any Windows syscalls made are translated to Linux syscalls by Wine.

Furthermore, I'm not sure it's easy to *prevent* a Windows process under Wine from making Linux syscalls, since syscalls are made with int 0x80 (32 bit Linux) or syscall (64 bit Linux). You might not be able to use the libc wrapper functions for the syscalls, but you should be able to use embedded assembly code to call the syscalls directly.

So you should be able, if nothing else, to use a few int 0x80 calls to fork-exec an independent Linux executable with a pair of pipes connecting it to the Wine program.
 

Artlav

Aperiodic traveller
Addon Developer
Beta Tester
Joined
Jan 7, 2008
Messages
5,789
Reaction score
778
Points
203
Location
Earth
Website
orbides.org
Preferred Pronouns
she/her
So you should be able, if nothing else, to use a few int 0x80 calls to fork-exec an independent Linux executable with a pair of pipes connecting it to the Wine program.
Interesting idea. Unfortunately, as far as i am aware, Orbiter cannot surrender it's window.
The window is created and handled internally, giving the client a context to draw to. The fork+shmem idea would have worked if Orbiter accepted events from the client, letting the window be handled by the client, thus allowing it to create its window in a different domain, like the native linux.

As it is, Orbiter would create the window, and it would be inaccessible from outside, making the client create another window do draw to.

As the experience with the linux thinclient and over-the-network rendering showed, passing input roundabout does not quite work.
 

Linguofreak

Well-known member
Joined
May 10, 2008
Messages
5,017
Reaction score
1,254
Points
188
Location
Dallas, TX
Interesting idea. Unfortunately, as far as i am aware, Orbiter cannot surrender it's window.
The window is created and handled internally, giving the client a context to draw to. The fork+shmem idea would have worked if Orbiter accepted events from the client, letting the window be handled by the client, thus allowing it to create its window in a different domain, like the native linux.

As it is, Orbiter would create the window, and it would be inaccessible from outside, making the client create another window do draw to.

It might still be technically possible, depending on exactly how Wine does things, and how much "Linux stuff" you could actually do from inside the Windows process, but it does seem you'd lose any potential advantages that could be gained by bypassing the Windows windowing API altogether on the client side if it's the main program that's handling the window and passing events to the client...

Can you think of any other Orbiter-on-Linux things other than graphics clients where the technique might be useful?
 

Artlav

Aperiodic traveller
Addon Developer
Beta Tester
Joined
Jan 7, 2008
Messages
5,789
Reaction score
778
Points
203
Location
Earth
Website
orbides.org
Preferred Pronouns
she/her
It is possible, just tried it.
I can execute an external program and i can establish whatever communications with it, while the wine program runs nicely.
Definitely works.

What this can give?
If Orbiter would surrender it's window - fully featured native graphics client.

What else?
An add-on written as native linux code linked to Orbiter thru a wrapper dll. Any use for that?

And, this did remind me of one thing i tried, but never finished - http://www.linuxforums.org/forum/miscellaneous/104594-wine-vice-versa.html
 

Linguofreak

Well-known member
Joined
May 10, 2008
Messages
5,017
Reaction score
1,254
Points
188
Location
Dallas, TX
It is possible, just tried it.
I can execute an external program and i can establish whatever communications with it, while the wine program runs nicely.
Definitely works.

What this can give?
If Orbiter would surrender it's window - fully featured native graphics client.

What else?
An add-on written as native linux code linked to Orbiter thru a wrapper dll. Any use for that?

Workarounds for bugs that only occur on Linux/Wine systems?

Interfacing with Linux-only programs?

OrbiTermMFD, for those who need a terminal emulator while playing Orbiter?

And, this did remind me of one thing i tried, but never finished - http://www.linuxforums.org/forum/miscellaneous/104594-wine-vice-versa.html

Interesting... I'd kinda like to see such a program. I hear that translating fork() to Windows native syscalls involves bulky and slow code, though...
 

Hielor

Defender of Truth
Donator
Beta Tester
Joined
May 30, 2008
Messages
5,580
Reaction score
2
Points
0
Interesting... I'd kinda like to see such a program. I hear that translating fork() to Windows native syscalls involves bulky and slow code, though...
Cygwin is what I used when I needed a Linux emulator sort of thing for Windows, but it doesn't just automagically run native Linux binaries.
 
Top