Real vegastrike simulator

[obstriegel]

Hello!

Im new to the forums, and relatively new to vegastrike at all, so I want to introduce myself:
I am nineteen years young, born and living in germany and currently doing professional education to become an IT specialist. I have been using computers since I was a child when I started cleaning the screen of my fathers commodore CBM 3032 I am interested in computers and science fiction, which lead to my fascination for space-simulation.

Since I am so interested in science fiction and especially space-simulation I want to build a real space simulator with vegastrike.
At first I had the idea to just build a normal flight simulator but that was not enough so I thought about building a real space simulator cockpit.

I chose vegastrike because it's a great space-simulator and more important, it's open source.
I monitored the development on vegastrike for several months and some people maybe already have recognized my nick "obst" idling in the vegastrike IRC channel on freenode.

The build process of the simulator has already started and it will get three screens connected to three machines which are responsible for the 3D-images. I thought the networking capabilities of vegastrike will make this possible without havy modifications. Other screens are connected to the main computer displaying 2D instruments and other information.
Currently I am making an LED-Matrix with some shift-registers for all the LEDs in the cockpit which will be connected to a main controller which is then connected via RS232 to the main simulation computer.
Additionally I started building a python program which simulates all the internals of the ship I want to create. It has a class called "Module" and "Connection" and some others related to the simulation. The internal components of the ship are represented through extends to the class "Module" and are connected with the connection-classes. My goal is to completely simulate the ships internals behavior in this program, which is connected to all the buttons, LEDs and the 2D-image screens. This program must be interfaced to vegastrike and this is the point where I need some advice, because I don't know where the best point would be to insert some kind of interfacing code in vegastrike.

For two 2D-image screens (actually two small, same looking TVs) I made two simple graphics cards consisting of an atmel-microcontroller and 256kb video memory . They will be interfaced to the main controller and simple commands ensure that no high bandwith is required.

My simulation program is connected to the main controller and should transfer information between itself, vegastrike and the main controller for the LEDs and buttons and screens.

As I said the simulated ship wont be one of the normal ships in vegastrike, otherwise it would be tedious I think.
I thought about a ship which is harder to control (so I can install many important buttons in the cockpit) and less versatile so I have time left to look around at the LEDs and so on.

Now it would be great if some developers could tell me where the best point would be to add an interface to my own ships internals simulation or if its too hard for one person because many modifications would be necessary.
Maybe, when the simulator is ready and the software complete some of you load a modified vegastrike and then fight with their ships against mine.

Best regards,
Pascal

[loki1950]

Welcome obstriegel an other new member also has a invest in a full cockpit sim not a coder but maybe a tester for you http://vegastrike.sourceforge.net/forum ... hp?t=11752 one of the devs should be by later and may comment as where in the source tree to look.

Enjoy the Choice

[ace123]

Wow, that sounds like a fun project

For two 2D-image screens (actually two small, same looking TVs) I made two simple graphics cards consisting of an atmel-microcontroller and 256kb video memory. They will be interfaced to the main controller and simple commands ensure that no high bandwith is required.

You're also making your own video card? Do you have this setup working in X11 yet? You're probably going to have to write drivers and all that stuff.
I know it might take out some of the fun, but I would just grab some cheap graphics cards for $50 and you would be better off.

I guess I am an optimist, but everything on your list is doable as long as you are willing to do some coding and stuff like that... for examples you will probably want to get a simple chip with a serial interface to control the LEDS... or you can use the Parallel port.

Anyway, what I would suggest is to go into more specifics and say exactly the types of interfaces you need.

I am assuming that a lot of your interfaces are pretty standard... are you going to use a keyboard, or are you going to interface it as a set of buttons/switches that plug into a microprocessor and go over serial? Because then it will be more like a joystick.

When you are talking about the LEDs, are those exactly the same ones as appear in text or as lights on the cockpit display? Maybe it would be best to hook them into the cockpit code or make a copy of that function to display your LEDs.

[obstriegel]

Hi,

the graphics adapters won't require a complex driver since they are connected to the main controller, which sends simple commands like "Draw rectangle from 0,0 to 20,30" or something like that. They can't display an X-Screen.
The resulution of these displays is currently limited to 256x254 with 256 colours so I only want them for some simple 2D-images and text. Some other old computers with cheap graphics-cards which will display prettier images.

My python program, which is called PYSIS(Python ships internals simulation) simulates all the parts of the ship and has the interface to the button/LED-controller and the 2D TV-graphics. The microcontroller-graphics are adapted from an circuit diagram in a german microcontroller forum and are already working. PYSIS is also already working with two simple modules (a fuel-tank and an generator) and displays the status of the modules as boxes on a normal screen. Every module can be attached to some LED-bars or whatever so there is space on the screen for important modules or other information.


I know C++ and can probably read into the code but since I never saw the internals of vegastrike I suggested some devs can give me an advice where to start.
It follows a diagram of the interfacing-principle. The yellow arrows show where I need help: The connection between one main rendering machine and two others, and for the interface between vegastrike and my simulation program(PYSIS).



All other connections appear easy for me to implement. The I2C-interface is a common thing for communication between micro controllers and I have already worked with it.
For the USB connection there is an application note from atmel with code, there I probably have to build a driver for the joystick but I think continuously transferring two float values into the game should be no problem through 1.4Mbit/s USB
Don't worry about the electronics behind the simulated ship, I will release circuit diagrams etc when everything is working.

For the 2nd and third 3D image I thought of misusing the network code of vegastrike by starting a network game on the main machine and connect two machines with modified versions of vegastrike which always display my cockpit from slightly different views. That could work with the fast LAN connection with minimal lag I thought.

Regards,
Pascal

Edit: scaled down the image

[safemode]

you might have to do a lot of hacking to get the other slave instances of VS (displaying the 2nd and 3rd screens via network game) dont show up in all 3 instances as a separate ship.

What i'm thinking is a customized ship for you. One that has a main cockpit, then two turrets with a fixed view on opposite sides of the ship. These turrets would be otherwise invisible, and the Ai for them could be such that they are directed in the view you want. The other two slave VS's could then connect to the network game and their "ship" can be these two turrets. Thus you dont have to hack much of the internals of VS at all, an you automatically get the function of viewing the correct way, following the ship (you're attached), and you can disable collisions with the invisible turrets and such too fairly simply.


I think that's a much less intrusive way to go about it. You would need some minor editing of the VS source, and a customized version of whatever ship you're looking for with some new invisible turrets

[ace123]

Multiplayer doesn't support sub-units yet, sorry.

It's a bit harder because you have to deal with adding on the parent ship's position, and a lot of code relies on iterating through all units in a system, which happens to miss all the subunits.

I might be able to work on some preliminary support to allow you to fly in a subunit even if it's invisible to other players.

[safemode]

i'm not sure i would bother with putting such code in trunk. I can't imagine any legitimate use for it other than some unique situations like this.

[obstriegel]

Hello again and thanks for the contributions.
It's a separate project so it's no matter if its a separated code tree.

The idea with the invisible turrets is nice and it's also my wish to build or modify an existing ship so I think thats the right direction.

Maybe after I got the work of ace123 on the preliminary subunit-support running it can go back into the main tree when it works robust since I think many people out there want to use more screens to watch the beautiful vega universe

What about getting the interface between the python application and vegastrike? I thought there is a point in the code where all information of the ship is up-to-date and then displayed, so I could add one step to exchange information between vega and the python app, right before the screen of the user gets updated, it could also be enough to just exchange information every 3-5 frames to save speed for rendering? Correct me if my thinking goes in the wrong direction!

Regards,
Pascal

[ace123]

I'm thinking that network application is not the way to go for this.
Not only because it's not written yet (and getting subunits working in a stable way is probably going to be hard, not to mention low on my priority list).
You will notice a lot of inconsistencies just because of the way that multiplayer games are written--one side may see an update before the other side, for example, and there might be lag... just a lot of potential for problems that you might not notice if you are only on a single computer.

I would probably suggest instead just hooking both screens to one computer and creating a large desktop (have the window spread across both monitors, which should be possible if you have any modern graphics card). You won't be able to distribute computing power but it will be much more stable.

As to when to do it, the best place is probably in "main_loop", which is in main_loop.cpp.

That gets executed a lot of times per second, so if you want to do something only periodically you can just put a counter in there.

But in reality, updating LEDs and so on will be very, very fast and it shouldn't cause any noticable delay if you just did it every frame, unless the I/O starts to block.
one possibility is that you could have once computer only handle the game and graphics, and then have another computer handle the hardware.
Then, you can have them talk back and forth using a TCP socket, which you would query in the main_loop using select().

[bookofthefuture]

Wow, serendipity. Just as I post a request for support for a cockpit with multiple screens, up you pop planning to build exactly that - and with the coding skills I so sorely lack!

If there's anything I can do to help Obstriegel, let me know.

At the moment I am working on the centre console of a dashboard, combining a small TFT monitor (hacked from a portable playstation screen) and a series of push-button controls (connected via a hacked USB keyboard interface). As soon as I have it working/decent looking I'll post some images.

I also picked up a further couple of 5.5in TFT screens at a computer fair this weekend for the princely sum of £20. Now I just need a way to use them!

[obstriegel]

I had also the idea of using sockets to make communication possible but I thought the main computer can run both applications. But thats not the point.
Relating to networking you argue that there could occur lag between the computers which would be disturbing since you watch all the screens at once. And you mentioned that the code is not ready for subunits.

I can't argue on point one. I will have to test it simply.

But considering the network code is smart enough not to lag with 100Mbit connections, there should be no visible effects for the player I think. Also a minimal lag should be no problem since the screens have borders.

After testing network performance I talk to you again about that topic

About hooking all screens to one computer...
I don't have the money for such cool graphics hardware and if I had it, I would insert it into my desktop machine not in the experimental simulator downstairs so sorry I have to do that the multiplayer way.
Maybe it climbs up your priority list when first successes are made and more people start building a home-made vegastrike-cockpit

@bookofthefuture:
I like to see that there is another self-made project under construction!
We should put our work on at least button and light-interfacing and release it so everyone can build something with it.
Maybe you also like my simulation program and build your ships internals with it. It is home-brew shit, physically incorrect but simulates nice bar graphs and system failures .
I described above a bit but here are more details:
The modules can have multiple inputs and outputs. To each input and output a connection can be attached. Because I can't simulate complete physical correct behaviors of electronics and so on I bring this simple model, which can be used for any connection, including fuel-pipes or copper-wiring:
Modules inputs request power/fuel/whatever from other modules outputs.
When the simulation iterates through the modules, the module code can request something through an input or put something to an output. So in the simulation malfunctioning modules can output power even when no module requested that power.
Additionally every connection has constants for heating and cooling so an energy connection to the weapon capacitors heats up depending on the amount of energy which goes through it.
If you have any further ideas, post them!
As you can assume from my past postings a design with these cheap atmel controllers is my favorite for a good starting point because they are widely available and well documented, but I want to hear your opinion about that.
What do you plan to use to control these displays and the buttons?
The atmels have multiple ADC-Channels which can be used for resistor-button-matrices or other analog devices (I want to make a good joystick which can be pushed and pulled maybe with simple resistor-wire). Thats what I propose.
My work on the 2D graphic adapters and yours on the LCD-Panels is very project specific I think and don't needs to be described in detail.

Regards,
Pascal

[ace123]

Sadly it's not just lag that is the problem--the code can be changed so as to saturate the connection.

However, there were just some things that since I knew there would be too much latency to get it anywhere near right. Still, it's a possibility and there's no harm in trying.

It would indeed be best if the keyboard is hooked up to a computer without a display, so hopefully the lag will be equal between all client computers that have screens.

Actually what might be easier to do than turrets might be for the server to basically broadcast all messages to a set of clients, each flying the same units.
Then, on each client computer, modify the cockpit to have a different location and orientation... though I actually have no idea if this is possible or if it is fixed at (0,0,0) pointing straight.

I have some other ideas too if that doesn't work, like have the server actually send the "wrong" orientation and position to each "client" connected to the same ship. Then, when put together on the three or four displays it would look like different angles from the same ship.

As to the graphics cards, if you want to go with the simple single-computer setup, you can get a cheap NVidia card for $50-100 that will have two ports and should be able to display at least at something like 1600x600 across both of them them. (though I am not entirely certain about this).
This would only work with two displays, however, unless you got a SLI or port splitter setup (which then costs more money)

[bookofthefuture]

Wow - I get the feeling your technological capabilities far outweigh my own and I'm going to need some time to get my head around this. I did a degree in Mechatronic Engineering, but I've forgotten more than I learned after ten years in marketing.

The principle for the keyboard button hacks is very simple and well described elsewhere - notably here: http://www.instructables.com/id/Hacking-a-USB-Keyboard/

Basically get a cheap USB keyboard (50p in my case), map the contacts that connect to produce each letter, cut off the contact sheets and replace with wires. Now when you connect specific wires with a switch, you get equivalent key inputs. There are better alternatives available with higher performance etc but nothing beats recycling in my book.

I like the sound of your microcontroller-based screens and am sure I could wire them up with the right diagram. Be great to get a copy of the sim software and wiring plans when you're done. What is the interface between the ADCs and the screens? The ones I have only have a composite plug on the outside but sure I can hack around if necessary inside. I had assumed that I would be hooking them up to multiple PCs via old graphics cards (I bought a handful of unboxed FX5600s for a fiver each a few years ago and planned to use those in a pair of old athlon XP machines).

Funnilly enough I was in Germany recently and watched the European cup final right next to the Atmel fab in Heilbronn. In fact I met one of the factory managers - small world.

Anyway, will be very keen to follow your progress - keep me posted.

[obstriegel]

Hello!

@bookofthefuture:
The idea with the hacked keyboard is very good. It would save the work of implementing a connection between controllers and vega for the keys because the computer simply recognizes it as normal keys.
I'm not sure what method to use because on one hand it saves the work, on the other hand using the keyboard means that you are limited to the number of keys on it and maybe there is a situation where you need the keys as usual. But I have to think about that.

@ace123:

I tested the networking feature on two machines. They were connected over a 100Mbit Nway-Switch. I was wondering why vega looks uglier in windows with a X1600 graka (256MB) (the trade planet was single-colour only) than on linux with a geforce 2 (32MB) haha, but thats not the point.

I tried hasty moves and always watched the reaction on a second screen and it seems to me that the lag is small enough so you can't see the difference. Only when moving in the opposite direction I noticed that movement turns on the other machine like 1/10 second later.

I saw netcode which acts worse and displays one player moving to the left, when he really started turning to the right or something like that in gta san andreas multiplayer, which is fan project. I could not see any buggy movements of the other ship, so even in combat it could work fast enough so you don't loose the overview.

Btw, is there a table anywhere which describes the error codes of the network functions?

Regards,
Pascal

[ace123]

I suspect that if you actually bring in a third computer, and run the server as well as a client on that, and attach the keyboard to it... then you connect two clients with screens, the two clients with screens should see exactly the same thing since everything is broadcast to everyone (and on a LAN the ping times are so fast you can't notice it)

The error codes are values from "errno" -- on windows they are 10000 + the errno codes.
If you google for "errno 32" or "10032" for example you should see a result that has some code like EINPROGRESS or some such name, and googling for that should give more information on what it means.

It was actually on my todo list to fix make it run "strerror" on the numbers and have it print out a human readable error code, but I just plain forgot about that.
Error 0 is the most common and means a timeout when connecting, or a server was not running.