[WMCoolmon]

I like the TCP/IP interface idea.

Serial port is very touch and go. There are a lot of variables involved in serial port communication that I don't totally understand. When I worked with it I was fortunate to know all the bitrate/parity/stop bit stuff.

[Nuke]

its not that complicated, most of the variables deal with the structure of the packet (like data bits, parity bits, and stop bits), baud rate and some other less important settings. generally speaking the settings at both ends need to be identical. real issue is you need to have real time control over the uart and some things just cant wait for the frame to end. arduino uses a usb to serial bridge right on the dev board (newer version replace this with an mcu which can be re-programmed for native usb) frankly i'm surprised that serial is still used at all when you have interfaces like i2c, spi, 1-wire, etc.

[Nuke]

i am now looking at the luasocket module. this provides facilities for socket programming in lua. i am considering using a udp socket to communicate with external software and other devices (such as arduino + ethernet shield). since i dont have an ethernet shield, i will use loopback and try to talk to another lua interpreter on the local computer for the time being. if i manage to make it work, this would allow both ipc and a hardware interface with pretty good speed as well.

this kinda thing would be capable of streaming graphics in real time. and pretty much every other application i can think of. it also supports http so you could probably browse the net on one of the rtt displays in your fighter's cockpit, provided someone scripts a web browser. this library is well documented and seems to be fairly easy to use. like i downloaded a web page with 2 lines of script, and you guys were worried about serial ports

[Nuke]

well its official freespace module support is indeed enabled. managed to get the a weapon energy printout in another lua interpreter using loopback, here is the "server" script that runs in the game's interpreter:

Code: [Select]

#Conditional Hooks
$Application: FS2_Open
$State: GS_STATE_GAME_PLAY
$On State Start:
[
--server
socket = require("socket")
ip = "127.0.0.1"
port = 1666
destport = 2666
udp = socket.udp()
udp:setsockname(ip, port)
udp:sendto("connection established", ip, destport)
timestamp = 0
]
$On Frame:
[
shp = mn.Ships["Alpha 1"]
--write out the ship's weapon energy in the range of 0-100
if shp:isValid() and mn.getMissionTime() > timestamp then
timestamp = mn.getMissionTime() + 5 --update every 5 seconds
local wepeng = math.floor((shp.WeaponEnergyLeft / shp.WeaponEnergyMax)*100)
--make it stringy
local message = "Weapon energy at "..wepeng.."%."
--send it to the client
udp:sendto(message, ip, destport)
end
]
$On State End:
[
udp:sendto("end connection", ip, destport)
]
#End

in some other lua interpreter out side of the game, run this script. this mostly just runs an infinite loop, waiting for data, and then printing it out.

Code: [Select]

--client
socket = require("socket")
ip = "127.0.0.1"
port = 2666
udp = socket.udp()
udp:setsockname(ip, port)

while true do
data = udp:receive()
if type(data) ~= "nil" then
print(data)
if data == "end connection" then
break
end
end
end

note for this to work the luasockets library must be installed in both the freespace dir, and the external interpreters dir. in addition you need to copy the lua5.1.dll (comes with lua binaries) to your freespace root dir.

i havent tested it over the network yet, but i dont see why it wouldnt work if loopback works. but this allows for ipc and ,at some point, communication with hardware (need to find money for an ethernet shield now). i should also point out that this was a quick and dirty hack, and some error handeling code definately needs to be thrown in.

[Nuke]

i just tested this over the network and it worked fine. and i should also point out that the client at the other end need not be written in lua. it should work with any other socket library for any other programming language you can think of. only reason i used the lua client was because i didnt want to learn two libraries in the same day. you could probably even talk to some service on the web, like twitter, and tell the world whenever you blow up a sathanas beam cannon. you could probibly go as far as creating an achievements system for the game and mods, if you were so inclined.

hardware experimentation is gonna have to wait though, until i can get the cash for that ethernet shield. of course i could easily write a proxy program to relay data from loopback to the serial port and vise versa. i could slap something together with lua in a few minutes, however i think id rather try doing this in c/++, for speed, and for error checking (serial has no inherent checking so i like to use 7 or 8 bit crcs), something not so easily written in lua. i think i also want to try tcp and see what kind of performance that can do. tcp would be better suited to everything except streaming (udp would handle that better).

as far as streaming goes the game doesnt really give me anything as far as reading textures. i can create them, draw them and use them, but you cant read the raw texel data. id like to be able to stream out render targets and other textures in real time. this would require some c code in the engine. cramming a 24 bit 512*512 texture through the tubes 30 times a second would require 189 megabits of throughput. pushing that through gigabit ethernet would be easy, but likely 100mbit would not be able to handle it. you can also downsample the texture pretty fast in real time, convert a 24 bit image into 16 or 8 bit could be done with some inexpensive shift operations. 8 bit would still require 63 megabit. block compression like you find in dxt1 would half that to 32megabit, probably fast enough to move over wifi, and serial if you reduce resolution and framerate.

for speed you would probably just use a 2d engine at the other end for panel elements, only streaming over the sprites, and only once at init. frame to frame you would just give commands to the 2d renderer on the external device. so you want to do a sensor panel like the one on the hud. you send the background sprite, raster font for text readouts, indicator bars and other graphic elements. every frame you tell it what to draw where and how. the little 3d ship icon could be drawn as a tiny render target, which would be streamed un-compressed, but its not like you are transfering the whole gauge, unless of course you want to implement a 3d renderer at the other end. likely whatever device will not have a lot of cpu power. probibly an mcu with some kind of graphics processor. if you wanted to do a little rear view camera display on a small lcd with fast refresh and high resolution, your hardware starts to get expensive.

[The E]

Well, my question would be why you're transmitting bitmaps, when you could just as well leave all the rendering **** to the client at the other end.

[Nuke]

Well, my question would be why you're transmitting bitmaps, when you could just as well leave all the rendering **** to the client at the other end.

you can only go so far with primitives. might be able to draw a wireframe or a gradient, but its likely it would not look as good as a bitmap. you could skip that whole process and just copy the bitmaps over to the other device. this has some advantages, it could be pre-econverted to the right pixel format. perhaps the other device might be a re-purposed pda, might be a single board computer (usually used for embedded applications), in which case it would likely have the storage to cache all the various bitmaps it would use to draw graphics. on the other hand its just as likely being an mcu or two on a protoboard. you might have a few k of ram, some flash (which is refered to as program memory on an avr), and maybe an eeprom, though its not hard to drive an sd card from an mcu, it might add complexity and cost to the system. it would also likely be built to be multipurpose, maybe other games would want to use it, and it might create a situation where you have to re-flash the firmware to change graphics sets.

now that i think about it i dont think id need to do anything in c to send your typical texture. i could just read it with c file as text and pipe it off to the device. it would of course need to be capable of parsing it. that would not quite work for render targets. going back to the rearview camera idea, you would really need to limit your resolution. i find 512^2 to be really kind of large for a render target. i would use something like 320*240*12bpp*30fps = 28mbit. 12bbp is a common bit depth on small low res lcd screens. it doesnt need the same quality as your monitor. its also not hard to convert 24->12, just drop the 4lsbs of all 3 channels, and scrunch 2 pixels into 3 bytes. still this is probibly not the best way to do this. support multiple dispalys where each display can have different camera setup, and then drive the little mfd monitors from the video card.

of course the point here isnt to draw coders off of there current tasks, the point is to get a bunch of hardware hackers interested in freespace. get the game to support a hodgepodge of open source sim hardware. much of what needed in terms of development is hardware and software external to freespace, and some lua. working camera displays are something that can be put off till after we got freespace working in a sim and someone says "now what".

[The E]

I'm just a bit worried about the throughput the engine can give you before it impacts performance.

[Reprobator]

i wonder if 15/20 fps would not be' enough for a rear camera no?

[Nuke]

20 would look ok. i figure most gauges would only need to update about 10 times a second, 15 would look better. 20 works out good because its about 1/3 of your usual framerate, therefore you only need to update the render target every 3 frames, giving you 2 frames in which to stream out the contents of the render target. the game computer runs fast enough to do the work, but the mcu or embedded system that youre using to drive an mfd display, would likely need time to commit the image to its framebuffer. the mcu on arduino is only 16 mhz, where most operations take 1 cycle (multiplies take 2 and floating point math takes more). the chip can clock up to 20 mhz, any faster and its overclocking. likely you will be working with an external sram (dual ported) for a frame buffer, big enough to store 2 frames for double buffering. you might have an mcu just to handle the output from the ram. it would just do its own thing. reading the sram and driving whatever display (could be vga, composite, or digital lcd). it would likely have some lines to talk to the other mcu, telling it what buffer its reading from at the time. these would trigger an interrupt on another mcu, and tell it what buffer it can write to. that mcu would read the stream through its network interface. and place the pixels in the buffer. the parts for this would not be expensive, at least to proto it in a breadboard, price shoots up when you start needing custom pcbs. so this hardware is what kind of limits what you can do, freespace will run circles around it.

[Reprobator]

I wonder : why not using simple "miniscreen" for the mcu? and let the computer do all the math job via a software running in background on the pc?
freespace is monothreaded so it give space for many things else at the same time.

[Nuke]

because an mcu isnt a screen
an mcu is a complete computer on a single chip. its suited to runing a single, simple program in real time. its is at the heart of %99 of all electronics these days. and i bet your computer has many of them inside of it. every mouse, every joystick every keyboard has at least 1. they are also very cheap. point here is to get hardware hackers all over the game. but you do have a point. you can run a 2d engine in another program, and output it to a small screen. you can use the loopback demo i posted earlier to communicate to the engine. you can get little 3.5" sreens off of ebay for like $30. they are usually for car rearview cameras and have a composite interface. most video cards have at least one composite out connection. multi card setups would give you more. it still doesnt let you capture a render target. so that rear-view mfd wouldn't be doable. actually all you would need for that is the pointer to the render target. after that it should be fairly easy to extract the data, and freepace doesnt need to do anything.

[Nuke]

oops dp

[Reprobator]

ooops a bit confused with mcu ; thought that was the 2nd name of mfdin dcs a10 for exemple.
anyway once again you interested me, i just changed my 3 screen, so i was thinking about saving one for doing this :




under my triplehead setup.

[Nuke]

this is exactly the kind of thing i want to stir up. im quite fond of these little chinese made rearview camera monitors. i own one and its not a bad little screen to have, and are fairly cheap, though they are not quite the right shape for a cockpit mfd like that one. not to say that it coudn't be used.

[Nuke]

i wrote a relay script using the rs232 and luasocket libraries. to sned data from udp loopback to serial. and managed to get my led on my arduino to change its brightness based on weapon energy. it worked at first but at some point it stopped working. i think im gonna blame the rs232 library. i think lua is just not fast enough to keep up with the timing, or perhaps windows ran it on the same core as freespace. so i think i definitely want to write a c relay application. this is just an interim solution till i can get ahold of an ethernet shield.

i think my next step with be to drive some hobby servos to make a scale model of a full motion simulator. i can build it out of legos, so i could probibly have something working by the end of the day, if i dont end up playing starcrack2 all day.

[Nuke]

i just ordered my ethernet shield. its one of those cheap chinese knockoffs, so its going to take several weeks to get here. il probibly start a new interfacing with hardware thread when it gets here. save the trouble of having to use middleware.

[Nuke]

got the ethernet shield, took me all day to realize i was using the wrong ethernet shield library. but i found the right one and did a ping to check connectivity. it all seems to work now. i might take some hardware servos and do a simple set of analog gauges on a panel as kind of a hello world. perhaps tomorrow, but i have one hell of a cold so dont bet on it. i think il start a new thread though, but id ask that posts regarding security concerns of module loading to stay here, and il make a point to direct people to this thread to discuss them. that said id like to point out that it is currently possible to interface the game to whatever hardware you could cobble together around an arduino, or other mcu dev platform.