diff --git a/README.md b/README.md index 84d1ba5..4c14d30 100644 --- a/README.md +++ b/README.md @@ -1,5 +1,12 @@ # v6-place +
+ + +Proof that I am talented at writing wonderfully awful software. +
+ I found a neat website called [**Place: IPv6**](https://v6.sys42.net/) and found the idea really cool. If you've ever heard of /r/place, you'll remember that you can place pixels on a globally-synchronized @@ -27,6 +34,22 @@ The simple steps to this program are: - Upload all pixels from the target image - Once done, we will check the difference again and upload those pixels. +## Usage + +> This repository is highly experimental. Expect to be writing, developing & learning code inside it if you want to use it. Seriously. + +I use `pipenv` for managing my virtual environments & packages. Once installed, use `pipenv install` to grab all packages & setup the environment. + +Setup environment variables in `.env`: +```env +SOURCE_FILE= # Point it to some file you want to upload. Should support most things implicitly, png, jpeg, bmp etc. +WEBSOCKET_ADDRESS= # Grab me from IPv6 website. If you don't know how to find this, then you don't deserve to use it. +CANVAS_WIDTH=512 +CANVAS_HEIGHT=512 +``` + +Then just execute `main.py` (activate the Pipenv shell, or run `pipenv run python main.py`). + ## Issues There is one glaring flaw with this application, and most of the processing is done to fix it (indirectly)... @@ -36,8 +59,51 @@ There is one glaring flaw with this application, and most of the processing is d Why? I have no earthly idea. But unfortunately, I believe it is inherent to the speed at which I dispatch ICMP Echo requests, and lowering the speed even by 50% would be untenable, and even doing that did not resolve the issue. -So, as it stands now, the issue is solved by being efficient rather than accurate (making sure each pixel is painted correctly). -- By efficient, I mean only targeting pixels that _need_ to be changed. +So, as it stands now, the issue is solved by being efficient (only targeting pixels that _need_ to be changed.) rather than accurate (making sure each pixel is painted correctly). + +## Future + +This was just a small one-day project to mess around with the site, but in the case that it grabs someone's attention, +or if I really want to work on it in the future, here are some improvements to try for: +- Use numpy, CPython or some kind of compiled processing libraries to speed up the processing. + - I have very little practice in this space, so getting some would definitely be fun to learn! +- Optimize transfers using 2x2 pixels + - This optional is available, but is completely ignored & untested by me. + - If implemented, this should be implemented as 'late' in the process as possible. + - Check each pixel if all of it's neighbors (if available) are the same color. + - If so, then remove neighbors & swap to 2x2 pixel. +- Look into alternative ways of completing the `echo`. I somehow doubt that the server is listening to complete `ICMP` packets +and verifying their authenticity - to even be able to support >10,000 pings per second without shitting the bed, it would have to be +customized, at least a little bit. + - Look into the composition of ICMP packets, and try manually sending packets to the address until one works. + - Once a packet is found, switch to C, look for low-level network & program optimizations, and see what the maximum "ping" rate is. +- Create various transitions + - This is the fun idea I'm interested in. Essentially, I want to change the order of pixel placement as they are 'transferred' + to the canvas. Instead of placing them from top to bottom, left to right or even randomly, what about a 'Radial Wipe'? + By simply sorting the pixels by their angle to the center (with an offset, if necessary), a radial wipe effect could be achieved. + - Pixel (16x16 blocks of pixels at a time) + - Disc Wipe + - Order disc by their distance from the center. + - Optional: Group pixels by their distance, divided by 50 & rounded down. This would create a 'layering' effect. + - Additionally, in order to deal with the effects of packet loss in regards to the animation, 'grouping' of pixels + while completing the transfer would be interesting. + - Instead of completing the entire layer of packets & recalculating what is next, one could process + PART of the transition, slowly revealing parts of the image in 'layers'. + - Each layer or group would be targeted, resolved (all pixels would be fully checked as 'written') in order. + +- Add a CLI frontend + - Currently, the entire app is controlled via environment variables & changing the code. + This is horrible for any 'normal' user. +- Improve transparency support + - The application doesn't handle transparency very well. Allowing the use of transparent input would be nice. +- Improve logging + - Feedback, at least for debugging purposes, would be very helpful. +- Improve feedback + - Progress bars, logging and in general, more feedback for the user to know what's going on would be great. +- Use asyncio properly + - Currently, the application doesn't actually use asyncio to allow websocket handling & pinging simultaneously. + It's better than nothing, but it could be better. A lot better. + - Also, the application takes several more seconds than it should to exit. Why? Do I have to close the connection manually? [pypi-multiping]: https://pypi.org/project/multiping/ [pypi-websockets]: https://pypi.org/project/websockets/ \ No newline at end of file