I'm here to discuss a topic about a C++ alternative to Java's AWT Canvas object.

In Java Canvas, one can obtain a Graphics2D object that draws BufferedImages to the screen from BufferStrategy. For each BufferedImages, one can edit/modify/rasterize the data buffers by modifying the data values, which when drawn to the screen by the Graphics2D object, it will show up the modified data values, or pixels. Each pixel contains many different data value types, depending on how the BufferedImage is created. For example, alpha values and RGB values can be modified altogether by rasterizing the BufferedImages.

In C++, the first thing I see is that in Win32 API, there's a function called SetPixel(). However, I can't seem to find where I can change/modify the alpha value of the pixels themselves. The COLORREF reference shows that the high order byte values must be zero, therefore one can only modify the RGB values, but not the alpha values, since they don't exist. However, there are other methods available. It's just not possible to do it at a much higher level of simplicity.

In Java, one can simply load a BufferedImage by using the core library's ImageIO static methods. This is really simple to use.

In C++, loading a bitmap itself is a daunting task. There are a few known methods of loading bitmaps, such as this, or this.

In each of the cases, Java's Canvas and Win32 API functions similarly, and they are both known to be slow.

So, you got any C++ alternatives for Java's Canvas?

What kind of game are you making?

Java's AWT was designed to be portable and was not designed around optimizations. If you read from a BufferedImage, or if you do any of a large number of operations, Java will stop using hardware acceleration for graphics. Performance will plummet, often making games drop to one or two seconds per frame (not frames per second). This is usually a very bad thing.

For the Windows api side, there are SetPixel and GetPixel functions that work on bitmaps. Bitmaps are kept in main memory as well, but have slightly better performance than the BufferedImage. Also, the GDI function do not support alpha channels (as you have discovered). You can use GDI+ objects or .net Graphics objects (which are wrappers for GDI+ that also includes image loading and processing functions) if that makes things easier for you. GDi+ supports alpha channels.

In both cases, most games will use a game-centric graphics library, such as JOGL in Java or OpenGL or DirectX on Windows. Then they will keep the graphics on the video card for high performance, always writing to them and usually never reading back from the graphics to main memory. These methods support all the fancy rendering techniques, alpha channels, and all the other good stuff. It is a bit more complicated to learn, but generally well worth the effort.

I have no clue to what games I'm making, but at least the game itself is not graphics-heavy, therefore shaders, 3D models, etc. can be ignored. The only thing that is graphics-intensive would be the pixels and the manipulations themselves, that's all.

And thank you for telling me more about the Java's AWT and the GDI functions. Now, I understand why everyone is pushing themselves to use the more fancier graphics libraries.