Oolite Bulletins

I'm obsessed by the idea of building a cockpit "replica" of a cobra mkIII. That would need the ability to send graphical data to multiple screens (i.e. front, radar-various astrogation functions, sides, rear). Would this be implementable in Oolite? is there a way to plot data on different screens given a lightning fast machine with multiple video cards?

you mean like an all-views-simultaneously screen, with expanded GUI?

Evil Juice wrote:

I'm obsessed by the idea of building a cockpit "replica" of a cobra mkIII. That would need the ability to send graphical data to multiple screens (i.e. front, radar-various astrogation functions, sides, rear). Would this be implementable in Oolite? is there a way to plot data on different screens given a lightning fast machine with multiple video cards?

Wow - that's a wild idea.

There's no multi-screen support in Oolite ATM (and I'd have no idea how to do it).

But I'd be in favour of the cheap and cheerful approach of sending the same video signal to a bunch of cheap monitors and adjusting the height and width of the scan on each to show only the required element.

In theory the Objective C HeadUpDisplay object could be edited to send its output to various lights and dials (if I knew how the Cocoa/Hardware interface worked), or possibly to separate NSViews in windows on a separate screen... In theory this could even be done with the different directional view displays - each one rendered to a separate custom NSOpenGLView...

*ponders*

I'd do it if I had the hardware/budget/spare time.

In flight sims, often networked computers have provided multi screen support. But for that, Oolite would need to support being networked

winston wrote:

In flight sims, often networked computers have provided multi screen support. But for that, Oolite would need to support being networked

mmm. Of course Oolite could fairly easily be adapted with a server object running in a separate thread written to respond to simple TCIP/IP requests like an HTTP GET request with the necessary information for simple dials (rather than the full details necessary to draw an external view).

(Tiger sidetrack - then your dials could be Dashboard Widgets - NO No No!)

I wrote an NNTP client once me.

The networking necessary for multi-headed simulation is simpler than for a game, since you don’t have to handle multiple players, or send input from clients to server if the server is connected directly to the input devices.

Multi-screen simulation on a single machine is conceptually simpler, but the question then arises whether you can have OpenGL contexts on different display cards share resources. If not – and I suspect not – you’d be limited to two OpenGL screens with Oolite’s current model. On the other hand, when I get around to reimplementing meshes and materials in a more object-oriented way, keeping track of display lists, texture names etc. on a per-context basis would be relatively easy. ;-)

Not that far from that idea, I'd love to have a rearview mirror, or something like that : In the main view, you would have a kind of tiny window opened showing what is happening behind you or on the side.

It could be a device to be bought in some stations... You could buy a left, right, top, down or back "rearview mirror". If you've got all of them, you can be sure that you won't see much of what's in front of you !

Also, in the view you've got with F1 to F4, is not possible to include top and down view ? It would quite usefull when you want to turn around something.

i remember seeing a cutout technical drawing of an escape pod with an astrogation console fitted in it, it would be quite interesting to have a look at ita again, it was in a site about ArcElite but i didn't bookmark it and google is no help, someone has seen this graph?

Spooky stares longingly at his Onyx running SGI's fabulous OpenGL Performer environment.

http://www.sgi.com/products/software/performer/

It gives you the capability to scale easily to multiple processors and multiple graphics pipelines, deploy to a wide range of systems and price points, and be ready-made for the graphics systems of today and the future.

Ok, so it's not cheap... but they could do with the money

isn't it a little bit overkill? /me drools...

Spooky wrote:

Ok, so it's not cheap... but they could do with the money

Looks like my sig is overly pessimistic, at least SGI themselves think they'll be around for quite awhile yet, their cookies are good until 2026!

For the time being i'm having a look at these industrial heavy-duty OEM joysticks (the ones you use to drive caterpillars, forklifts etc...)

http://www.chproducts.com/oem_flash/index.html

made by CH, they're much better than their gaming counterparts and are USB compliant. The look is astonishingly retro.

The throttles aren't bad too.

EDIT: http://www.chproducts.com/retail/aircraft.html <--- really overkill

Not all gaming joysticks are created equal.

http://europe.thrustmaster.com/eng/d_pr ... =T65&fam=6

I'd love one of these, except for the fact that I'm an unco leftie...

Yeah, right, but for the sake of good production design i believe that in a simulated cockpit a forklift joystick would be not bad, i wonder if USB-overdrive would handle 'em.

have a look at this: this guy is nuts, look at the CD tray!
http://www.migman.com/hw/cp/simpit/simpit.htm

aegidian wrote:

mmm. Of course Oolite could fairly easily be adapted with a server object running in a separate thread written to respond to simple TCIP/IP requests like an HTTP GET request with the necessary information for simple dials (rather than the full details necessary to draw an external view).

I wanted to pose a similar suggestion earlier this week, but reconsidered since it sounded a bit "too much". :-)

In a driving simulator called Live For Speed that I play from time to time they have an interesting concept for interfacing external software to the game called InSim and another called OutSim for interfacing to motion platforms.

Both of those basically work with UDP packets being sent (if the player enables it) containing all sorts of event-related data and they allow a program to send in certain stuff too - either messages or commands to control the game using a sort of "console" approach. That way, with external programs any game extensions are not part of the main game.