Date: January 11, 2014
Screenshot #471: With a bit more height, typical of what you might encounter in the jumbo levels, you'll begin to see the blue daytime sky as before. Unlike the previous system where the rim top had a wide variation in height, this design has the rim's top look rather smooth. This is because other layers are often in the way and the rim's top still curves upwards and over.
Date: January 11, 2014
Screenshot #472: Higher yet, still within the range of a jumbo level (one of the higher ones), you'll see a view like this - the mountains beyond are visible. This was quite a scenic sight so I thought I'd grab a screenshot of it.
Date: January 11, 2014
Screenshot #473: With the expected height seen with the supersize level, you'll be able to see the farthest visible parts of the rim, at 27 SU (the closest visible is at 16 SU) so it's almost 70% more distant. Due to the Sun just "glancing by" and, farther out, "missing" the slopes, they are very dark.
Date: January 14, 2014
Screenshot #474: With the old GDI system I was using before, there wasn't a way to simply multiply the source image's color values to produce a new color. I had to use a different method, a messy, long-winded approach. This screenshot shows only part of it - it's very messy and highly repetitive.
I used the HSV system for this. I needed to make 8 varieties of each slope of platform to be able to reproduce any color. I needed the 3 primary colors, the 3 secondary colors, a white version, and a black version. That's basically having a platform that's maximally red, yellow, green, cyan, blue, magenta, white, and black. Let's say I have the RGB color of 207R, 143G, and 239B. To reproduce that, I'd need 4 draws. The first step is to find the hue, saturation, and value for this. Hue takes the most effort to calculate but I get exactly 280° for this. Saturation is "(High-Low)/High" which gives me 40.17%. Value is the easiest as it's nothing more than "High/255", which gives me 93.73%.
The first step in drawing was starting from one of the primary or secondary colors (it doesn't matter which) and drawing it fully opaque. The second step is drawing the other color partially opaque on top of that. If I choose to draw the blue fully opaque, blue being 240° hue, I'd then draw magenta, which is a 300° hue, on top of this that's "(Hue-240)/60" percent opaque (that's 2/3 or 170 for the alpha). It works the same drawing magenta fully opaque with blue (at 1/3 or 85 for the alpha) being the variable opacity color. The third step is drawing the all-white image on top of these 2. With saturation at 40.17%, the opacity is 59.83% as you have "1-Saturation". That is an alpha of 153 after rounding. The final step is drawing the all-black image on top of these 3, also with varying opacity. With 93.73% as the value, the opacity is "1-Value" or 6.27%, giving an alpha of 16. When these 4 are done, you get the final result.
With SDL, I didn't need this long-winded approach and I only need a single draw. With dynamic color multiplication and dynamic alpha, I have far more flexibility and boy did this code really shrink! In fact, I'm using fewer lines of code for all 16 slope variations than I did for just the floors and walls I originally only had (and to think I would have had to multiply the code length for drawing the platforms by 8... yeah, okay (good thing for copy paste!)).
Date: January 15, 2014
Screenshot #475: Once I got all the SelectObject calls from the GDI system changed, fixed the errors, set up notices for fatal errors such as too low of a resolution or required handles not being created due to some problem. I want you to look back at screenshot 349 when I last attempted SDL. The image in the top left corner has the output from SDL - note that it's upside-down. The image in the center is the real input as rendered through GDI. Here, in this new attempt, this old problem is back. Everything is upside-down in the place it's supposed to be drawn, sometimes not even in the right position. If you look very closely, ignoring the JPG artifacts, you can see banding present, the mountains that actually shouldn't be visible (as fully opaque objects are drawn in front of them). This banding is due to SDL apparently misinterpreting 24-bit images as 32-bit images, something I was expecting to happen.
Date: January 18, 2014
Screenshot #476: With the SDL migration complete, after flipping the images during loading, I began utilizing QueryPerformanceCounter and the like to see just what effect SDL had. For a complex world like Ronnisa Plains, 500 fps is just crazy! Of course, this wasn't the only thing I needed. A lot more was in store.
Date: January 19, 2014
Screenshot #477: With SDL's color multiplication feature now available, I could make a major optimization, one that knocked off more than 10 MB total memory. The platforms originally needed 8 colors to reproduce a given color through 4 draws. Not any more. It's only 1. So, deleting 7 images from each of the 7 slope variations meant saving 9.7 MB alone, rather crazy. What's more is that I could, at least, make vanishing platforms do what I originally wanted them to do early on: make them fade away. Like before, they blink repeatedly, slow at first then getting faster. Instead of the final speed for the blinking, I make the vanishing platform fade away. This screenshot shows this very well as you can clearly see the platform but you can also see through the platform too.
Date: January 20, 2014
Screenshot #478: The feature where things darken with height is now better than before... slightly. Thanks to SDL's color multiplication, I don't need to have to have the extra all-black part in the images of various game objects. Every object benefits, even the character that I still need to replace. You can see this in this screenshot very well. The goal platform didn't darken before either but now it does. What's more is that I've set up my code so that I could easily integrate fires and there's even a lighting quality setting available as well. From 32 at the lowest quality to 4 at the highest, the smaller the number, the smoother the gradient. Anything less than 4 has no meaning and uses excessive draws for virtually no improvement. 16 is the default which offers the best balance between quality and draws that I can see... so far. I won't know for sure until I can add in the fires. Yes, that's right, fires. The upper areas of Carnivalesta and everywhere in the Barugan Islands is really dark, to the point it's almost very difficult to see where you're at or going or where objects are. Fires, however, will light the way, but be sure to avoid touching them as they will sap HP quite quickly. Get too far from a fire and things really get dark.
Date: January 21, 2014
Screenshot #479: Needing to check to see what was going on with the cloud layers not drawing properly for stormy worlds, I needed to debug them, but found that I had to go through many loops and the like. So, I changed my code around to optimize the drawing of the clouds and one stubborn bug I had was with the odd lines from being exactly dead on a boundary between layers that wasn't correctly being accounted for. Strangely enough, use the exact same setup with the ground decals and these odd lines don't occur. It does with the clouds though. The clouds do use a slightly different setup than the ground decals so I guess that is the culprit. The solid ground was also not working as, due to removing the cloud fog solid ground image, the far ground doesn't get faded away. That change occurred later on.
Date: January 29, 2014
Screenshot #480: After a long while, I got the fonts updated to the new design, fixed the known bugs I had, and attempted to get Earth's curvature added in. Regardless on what I did, it just never worked out. An object that's 2048 SU (38.836 miles or 62.5 kilometers) distant, the farthest visible, gets shifted down about 3 1/3 pixels or about 6800 CU (1000 feet or 300 meters) if exactly level with the ground.