VIDEO GAME IN A PAC USING RFB

Error message

  • Notice: Undefined index: taxonomy_term in similarterms_taxonomy_node_get_terms() (line 518 of /home/cabsoluw/public_html/absolutelyautomation/sites/all/modules/similarterms/similarterms.module).
  • Notice: Undefined offset: 0 in similarterms_list() (line 221 of /home/cabsoluw/public_html/absolutelyautomation/sites/all/modules/similarterms/similarterms.module).
  • Notice: Undefined offset: 1 in similarterms_list() (line 222 of /home/cabsoluw/public_html/absolutelyautomation/sites/all/modules/similarterms/similarterms.module).
administrador's picture
Image of classic video game programmed in PAC

RFB PROTOCOL

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

RFB SERVER

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.

A PAC (in this case an Opto22 SNAP UP1 ADS) has these characteristics. If there is no PAC available, a free simulator PAC Sim can be used.

PAC OPTO22 SNAP UP1 ADS used to run the video game app using RFB

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!

Video game programming using PAC PROJECT  Optoscript

CONCLUSIONS

* 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.

DOCUMENTATION

(See bottom part - Attached files)

* Article in PDF
* PAC CONTROL video game source files

VIDEO

The following video shows two tests: Real PAC playing thru VNC and test with PAC Simulator