Updated Readme

Small fix for x86 warnings

README.md

@@ -4,6 +4,10 @@
 
 It's my first project ever in graphics programming, and my first screensaver too. Whichever is hardest to learn, I'll let you be the judge.
 
+### Where can I find it? I want to try it
+
+You can grab a binary form the "Releases" section, both 32-bit and 64-bit versions are available. To be able to set it as your screensaver, right click on the ``.scr`` file, and select "Install".
+
 ### Technical details and requirements
 
 The program is implemented in C (standard 17) and HLSL, and uses the Win32 and Direct3D 11 APIs.
@@ -28,7 +32,7 @@ Hopefully, this will get as close as possible to the video, without blowing up a
 
 I want to dedicate a special section here to _those_ takeaways that may not be clear at all when developing such programs, and nothing seems to concretely help you even with your best efforts.
 
-### _Screensavers don't like files<sup>1</sup>_
+### _"Screensavers don't like files"_
 
 To some, this may sound obvious at first. Observe that this is a program that is required _by design_ to execute without a console. Barring debuggers, a very easy choice for getting a trace of what is happening at runtime is to setup a logfile.
 
@@ -38,11 +42,25 @@ The only hint of what happens on crash is in the Windows Event Viewer, which rep
 
 However, the sneaky catch lies in the consequences for DirectX 11: a popular strategy in building the graphics pipeline involves compiling the shaders' files at runtime by using ``D3DCompileFromFile``. As you might have guessed by now, this is a file operation. _Same problem here_.
 
+Another quirk of screensaver's aversion to files is, when showing the configuration dialog, it is possible to open/create new files with Win32 functions, but writes will effectively become no-ops.
+
+If this isn't enough, the [Microsoft doc page](https://docs.microsoft.com/en-us/windows/win32/lwef/screen-saver-library#creating-a-screen-saver) talks about saving the screensaver configuration in an ``.ini`` file _or_ the registry by using old Win32 funcions that had their behaviour changed ove the years; turns out they don't seem to work reliably, and it's easier and more readable to save the configuration using directly the registry functions anyways.
+
 The takeaway here is: when you want to build an ``.scr`` file that _actually works_, check carefully for anything that may involve a file, and possibly change it to avoid using the file itself.
 
-Do however keep a logging infrastructure for a separate build scenario, if you feel comfortable with it. I know I did.
+Do however keep a logging infrastructure for a separate build scenario, if you manage for it to work. I did, and it still serves me well.
+
+### _"Screensavers don't like ``WM_PAINT`` much either"_
+
+That doc page for screensavers also does not cite the paint message ``WM_PAINT`` in the main routine either, delegating the draw triggers to a timer. Originally, this program did use the paint message to draw the graphics, as a DirectX app is normally expected to do that.
+
+The point is: if you let the paint message fall through your routine, and pass it to the default procedure, then the routine will stop receiving more paint messages. The obvious effect of this, if no other trigger loop is in place, is that your graphic drawings will freeze.
+
+Having said that, there are two approaches to build a draw loop:
+* either let the paint message in the default procedure (thus stopping them), and build a timer to trigger the drawings, as seen in the sample doc,
+* or keep using the paint message to draw, and take care to not pass it to the default procedure; no timer involved here.
 
-<sub><sup>1</sup>: To add to confusion, the [MSDN page dedicated to screensavers](https://docs.microsoft.com/en-us/windows/win32/lwef/screen-saver-library) talks frequently about interacting with an ``.ini`` configuration file. I admit that I still haven't investigated much about that.</sub>
+The advantage of the first approach is that refresh rate throttling is more immediate to regulate, but I am yet to see if the second approach has a more reliable, accurate timing mechanism.
 
 ## Acknowledgements and pointers*
 
@@ -54,7 +72,7 @@ Other than that, [BraynzarSoft](https://www.braynzarsoft.net/) is a nice complem
 
 And of course, MSDN and StackExchange are regular places to go look for specific stuff. Although, in my opinion, some times MSDN can be your best friend (obviously), and your worst enemy (_not so_ obviously): bring lots of patience.
 
-Many thanks go to [McLytar](https://github.com/mclytar) for testing it consistenlty on his system; it helps a lot to have a different testing environment... with multiple screens, or just better GPUs.
+Many thanks go to my friends [McLytar](https://github.com/mclytar), [Gaamda Lurt](https://github.com/gaamdalurt) and MarMik for testing the program on their machines, providing better tessellations for the L2 surfaces, and assisting me in indexing them.
 
 Tech stuff aside, I'm deeply grateful to [Sevish](https://www.youtube.com/channel/UCmq2yMo-lTfC7BQLth_PqOw), the artist behind the inspirational video, and all the guys that are in his Discord corner: now I know that I'll never run out of interesting stuff to learn and new, good music to listen. Thank you, I really mean it.
 

graphics.c

@@ -91,9 +91,9 @@ D3D11_INPUT_ELEMENT_DESC vertexInputSpec[2] = {
 struct shape_impl {
     vertex* vertices;
     unsigned int* indices;
-    size_t vertexSize;
-    size_t indexSize;
-    size_t indexCount;
+    UINT vertexSize;
+    UINT indexSize;
+    UINT indexCount;
 };
 
 shape mengerL1 = {