Development: Difference between revisions
imported>Zekiah m Typo fix on pixel packet |
→Pixel packet:: Fix code sample and confusing writing |
||
| Line 8: | Line 8: | ||
=== Pixel packet: === | === Pixel packet: === | ||
The pixel packet is one of the simplest. It is a six byte packet, the first byte being the '''code,''' the '''position (board index)''' of the pixel, represented by a 4 byte unsigned 32 bit integer, and finally a byte representing the index of the '''colour''' in the palette that the pixel represents. | The pixel packet is one of the simplest. It is a six byte packet, the first byte being the packet '''code,''' the second to 5th | ||
bytes being '''position (board index)''' of the pixel, represented by a 4 byte unsigned 32 bit integer, and finally a byte representing the index of the '''colour''' in the palette that the pixel represents. | |||
One can retrieve the X and Y from an given pixel index with some basic math. To get the X position, we do '''index % | One can retrieve the X and Y position from an given pixel index with some basic math. To get the X position, we do '''index % canvas_width''', and to get the Y position '''floor(index / canvas_width)'''. | ||
Revision as of 02:58, 15 July 2023
rplace.tk has had a rocky development history. With such a high demand for different things, features have remained broken, scrapped or non-existent for long periods of time. Despite these issues, with the 10+ contributors to the main project, lead mostly by zekiahepic, and initially BlobKat. The site has found a relatively stable update cycle, with new features, fixes and bug improvements appearing each fortnight.
The game protocol
The site was initially coded within a day, and main development, jump started by BlobKat over three. This has had many long lasting impacts on the site, resulting in some development decisions that made sense for that short term period, but have proved very complicated and confusing in the long term. One of the biggest impacts was the choice to use "git and changes system", for syncing the canvas between the client and server, while also ensuring minimal bandwidth on the hoster's behalf. Further complicated by the introduction of the new server software, RplaceServer, which chose to use a completely new system, wherein the site is solely dependent on the monolithic server software, which handles both the socket live pixels, and hosting the canvas files directly for client consumption in a compressed form.
Packets
The site uses websocket for live client server communication. All packets are composed of an initial code byte, representing the type of the packet to be identified on the server, with all numberic packet data being formatted as big endian.
Pixel packet:
The pixel packet is one of the simplest. It is a six byte packet, the first byte being the packet code, the second to 5th bytes being position (board index) of the pixel, represented by a 4 byte unsigned 32 bit integer, and finally a byte representing the index of the colour in the palette that the pixel represents.
One can retrieve the X and Y position from an given pixel index with some basic math. To get the X position, we do index % canvas_width, and to get the Y position floor(index / canvas_width).