Five years roughly spans how long I have spent privately researching native graphics programming technology. It is not a professional effort but a work of curiosity. Several blog posts cover my encounter with native graphics code. The effort broadened my insight beyond what I had anticipated. This article covers the evolution of that understanding and continues from the Sept. 2014 discussion of the SFML Graphics programming library. Continue reading
The application framework that we have embarked upon has seen a few modifications on the way to a solid basis upon which to build a program. Abstractions were introduced in the last article, Exploring SFML Graphics in C++ – Refactoring Wave 3, that focused on cleaner and clearer ways to represent certain concepts such as windows and views. I have refined this framework to better express the idea of a view. A view is where graphic elements are arranged and contained and there needs to be an approach for defining, introducing and transitioning views. I do not describe that latter objective here but defining and introducing views or, in this case, a single view, is necessary. The information that follows show the progress that has been made in reaching this goal.
This is the final article on this particular series of refinements to the application framework and test program that I have been exploring. First, let’s start with some code.
An incremental revision the application framework is described in this post. After testing out some ideas in terms of a type of scene graph that would work comfortably with the application framework I am building I decided to consolidate and simplify a few areas. First, I needed to migrate towards a more consistent representation of the type system I am setting up. Not so much on paper as in actual code form in C++. What you define in an initial blueprint and what actually works and feels well can differ by a modest measure.
As I proceed along the shaping of the framework I am observing that more effective C++ code trends towards the concept of Resource Acquisition Is Initialization as espoused by the creator of C++. While the RAII technique may be viewed as entirely optional in languages like C#, C, and Java among others, in C++, RAII can be somewhat necessary to have code work well with the language specification. Rather than avoid RAII in favor of more generalized class based OOP, I decided to embrace it more in the context of C++ to streamline the design and function of the program. The remainder of my post documents some of the changes I made that clarifies the program in a more legible and streamlined design. Continue reading
This is part of a series of articles looking at the SFML library in C++. The previous article, Exploring SFML Graphics in C++ – Refactoring Wave 1, showed how we take exploratory code shown in the article, Exploring SFML Graphics in C++, and improve the structure of that code. This article focuses on the organization of the code into folders within the CodeBlocks IDE. This change does not affect how the code is stored on the computer but how it is represented in the code editor. The following is a listing of where files are placed in the code editor, changes to the project configurations, and test of the code at the end. Continue reading
The previous article, Exploring SFML Graphics in C++, covered a basic window and input demo using C++98 and the SFML Library. That demo was a small, concise exploration of graphics concepts using SFML but was hardly shaped for a more structured software project. That article concluded with a visual roadmap of how a more structured solution may be defined. We presented a new structure in a UML diagram. After pursuing a new structure in C++11 using both the SFML demo code and the diagram as an initial guide, we have a refined version.
First, lets look the project at a glance. Below are screenshots that show all the files organized within the Code::Blocks IDE. We have C++ header and implementation files that together realizes a working solution. This solution is a mapping of SFML capabilities to an application level framework for generic visual interfaces. We have essentially refactored the demo code into a new structure that will be more easily reviewed, modified, and reused.
Listing of Header Files in Code::Blocks
Listing of Implementation Files in Code::Blocks
Next, comes the full text of the header and source files. They are listed in links as there is a sizable amount of text in aggregate. The next article on this subject will cover the individual files in detail in a version that is more fully developed.
Software Code Listing
The code is divided into the main program and the application level framework.
Gautier SFML Program
The program starts in the main function which references the program implementation. The program implementation is in a class called Program declared in program.h and defined in program.cpp.
Many of the common types for the management of visual mechanisms and geometric types are aliased or declared in the visualcommon.h header file. A small extract of this file is as follows:
Gautier SFML App Framework
The application framework is the initial beginnings of a reusable means to apply the SFML library to efforts targeting general application building. It contains a regular structure that intends to be both practical and holding cyclomatic complexity in balance. The framework emphasizes stack based allocation while striving to reduce the appearance of heap oriented structures or underlying framework mechanisms for a cleaner interface. In a subsequent iteration, virtual functions may have to be introduced to allow the processing of dynamic UI views.
All other code files are listed with links to their contents : Continue reading
Graphics programming through Allegro was something I last looked at in 2012. The article I wrote about it, Cross Platform C++ Programming with Allegro goes into some detail about the possibility of Allegro as a basis for cross platform software. The rationale expressed in that article has not changed but I decided to explore other options. One of those options are classified as application level software frameworks such as Qt, GTK and wxWidgets. I speak about them in my July 2014 article, Insight into Cross Platform Software GUI Development. At the same time, I decided to review graphics frameworks such as SDL and SFML. I was aided by the availability of books on the subject. SDL Game Development by Shaun Mitchell and SFML Game Development by Artur Moreira/Jan Haller/Henrick Hansson are both published by PACKT and provide a good background on two good graphics technologies. With the requisite introduction to the technologies, I decided to explore the idea of using SFML as a foundation for an GUI application framework.
Choosing SFML and C++
Over the last few months, I had been reviewing a number of works in areas of technology. One of those dealt with software security from Robert Seacord whose work I discuss in a series of articles (Raw Numerical Security, Raw Code Security, and Raw Data Security). Prior to reading his work, I was quite certain that the most productive way to write classically compiled, native computer programs was to use the C programming language. After reading Robert Seacord’s books in detail and considering the information he presents, I still believe that C is the most productive, quickest way to build native programs but that C++ has a design edge in drafting better structured code that could be better secured.
As a result of these considerations, I decided to keep with C++. As SDL is more C centric, that made SFML the default choice. During my prior exploration of the Allegro library as described in the C++ Cross Platform Programming article, I had taken the C centric Allegro library and shrouded it in C++. I did not want to do that again with SDL and thus having a clean, vetted, and ready library that is more compliant with C++ would save tremendous time and effort.
Code Blocks IDE
The operating system I am using for this exploration is Xubuntu 14.04 LTS running as a virtual machine under Ubuntu 14.04 LTS. Initially, I decided to just write the C++ code in a text editor and compile on the command line (as I did in an article for Allegro/C++) and that worked for a while, but to ramp up productivity, I decided to use an IDE. While I used Eclipse CDT in the past, I decided to go with Code::Blocks. I was skeptical at first, but after setting up an empty project and importing the text files that I had written, things looked up.
I setup an empty project in Code::Blocks and set the appropriate options to have the IDE reference the right SFML include files and libraries. After 3 weeks of working through the new code I had written, I found that Code::Blocks works pretty well in Xubuntu. I have to say that while I did not use Code::Blocks for wxWidgets programming in C or C++, it does work well for straight C or C++ in general. The only thing I do not like about Code::Blocks is the debugging facilities do not appear as productive as with Eclipse CDT but I can accept that as I would rather have a native code IDE for C and C++ code.
Initial Project and Build
See below my latest compile of the project I setup to explore SFML. In the Build log tab below, you see the command line that Code::Blocks is forwarding to gcc.
Run the SFML based Program
We invoke program execution through the IDE. The code I have written has produced a screen using SFML facilities to minimize the window, resize the window while redrawing the blue square centered while maintaining a 10 pixel break from the edge of the square and the window.
At first, the square would not remain centered whenever I resized the window. I thought my mathematics was off. That could not be since running the calculations on paper produced the correct result. The behavior of the resize made me consider that it was something else. I kept researching the matter, and came up empty until I started thinking about viewports. After a week, I went back to the sfml-dev website until I found a good article on 2D cameras and views. Within that article was a section titled, Showing more when the window is resized. The information in that section was what I needed to make the overall adjustment of the window contents maintain the proper aspect ratio.