VIDEO GAME IN A PAC USING RFB
RFB or "Remote Frame Buffer" protocol was created in the Olivetti Research Laboratory to manage graphic interfaces remotely. The idea was to create a protocol as simple as possible, so as much hardware as possible (thin clients) could deal with it. One of its simplest function is to draw rectangles specifying basically 5 parameters: x position, y position, width, height and color. In that way an image can be composed of multiple rectangles, sending only 5 parameters per rectangle and there's no need to send desktop image pixel by pixel to the thin client, saving bandwidth.
* Este articulo tambien esta disponible en Español haciendo clic aqui
The main use today of RFB servers is to take an actual image of a desktop (windows, menus, icons, apps, etc.) and send them to the remote client, also capture client actions ( mouse movements, clicks, key press) and send them to the desktop. However, due to the protocol independence from any operating system, this can be used to generate content for the client that not necessarily exists in a graphical form in the server. A classic example is a game server, where the server doesn't have screen, graphic card, controllers or keyboard, only data processing and a communication channel, it's on the client side (player) where the graphic card, monitor and keyboard are installed.
IMPLEMENTING RFB IN PAC
To develop an app RFB server two things are needed: some kind of network connectivity and some platform to write programs than can send/receive network packets. There are some examples of RFB apps, in this case a counter that can be compiled on any system with a suitable C compiler, and an extreme case where an ESP8266 module is used as an RFB server.
OPTOSCRIPT AND FLOWCHART PROGRAMMING
The game was developed using free PAC control for Windows suite. There isn't an official tool to program an Opto22 PAC using Linux, however, due to the control strategies sent to the PAC are text files with content coded in FORTH shouldn't be very hard to develop an alternative.The programming language uses flowcharts. Several charts could be created and run in parallel, in that way the game's logic could be split from RFB protocol implementation. A big advantage of PAC vs PLC (the gap is closes a bit every day!) is the ability to use basic network primitives, that can be used to build new protocols not included like RFB. In this case the primitives are very close to the client/server socket functions of familiar programming languages.
The game's logic, paddle positioning, ball movement, collision detection and scores were programmed in an independent flowchart, in that way the game could be accessed by other means or protocols like digital or analog I/O, or using a SCADA with Modbus, etc. The game is for a single player and there's a small "smart" algorithm that plays as a computer opponent.
In the implementation of RFB protocol some shortcuts were taken, a lot of client requests are ignored, a very simple color palette was transmitted and a very crude rectangle encoding were used, so the game have not very advanced graphics!
* It is possible to implement the RFB protocol in an Opto22 PAC. A possible use for it is to develop "less fun" apps like remote SCADA or HMI accessible via VNC client, as a different alternative for IoT apps.
* The game only allows one single client connected, however, is possible to modify it for two or more simultaneous remote players.
* Rectangle based games where the screen doesn't scroll or changes often (i.e. Pong, Tetris, Breakout) are easier to develop using RFB.
* The control strategy works with a real PAC or with a PAC SImulator.
(See bottom part - Attached files)
* Article in PDF
* PAC CONTROL video game source files
The following video shows two tests: Real PAC playing thru VNC and test with PAC Simulator