Exploring SFML Graphics in C++ – Refactoring Wave 3

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.

Program Window

The most significant change was to further diminish the presence of SFML from the main program. I accomplished this by creating a ProgramWindow class that serves as a C++ RAII style resource handle for the SFML RenderWindow. This allows me to contain an instance of RenderWindow in a central place and manage how it is accessed, updated, configured, as well as object lifetime. In the context of this C++ program, it operates cleanly such that when an object instance of ProgramWindow goes out of scope, the objects it contains are cleaned up automatically.

As I want to reduce heap allocations, the ProgramWindow type aids me in that effort with respect to the RenderWindow type. I can have a single pointer to the RenderWindow type that I can contain entirely in the ProgramWindow type. I am managing pointer characteristics in this particular instance by making use of the shared_ptr from C++ll. The definition and implementation of the ProgramWindow is shown below.

ProgramWindow: Definition

pic001 - SFML App Framework v2 - Eval Program - 2014-09-04

ProgramWindow: Implementation

pic002 - SFML App Framework v2 - Eval Program - 2014-09-04

Window View Manager

Eventually, I will have separate screens for the program. The aim is to have all of the SFML and main window process well in the background so that the only concern and activity is the creation of views in as generic a manner as possible. That is the real goal. Views and interactivity defined in a way that resembles a fair amount of the capabilities of existing application frameworks. However, the end result will be much more limited since the world of interactivity (mobile devices and modern desktops) in many areas are trending towards simplicity. The evolving nature of user interface sensibilities may prove useful to our goals.

The WindowViewManager class contains the actual graphics that each screen will put out. It takes these graphics and sends them to SFML which, in turn, works with OpenGL to transform the graphics into a visual representation on a computer monitor or mobile device screen. One promising prospect to this is that individual screens can do their thing (logic, databases, web requests, etc) and then send their graphical result out to a view manager. The view manager (you could theoretically have different view managers for different types of graphical output situations) mediates between the view and the graphics system. It fit within the MVC concept but towards the low-level rather than the high-level. It is a necessary utility function of the system. What follows is the definition and implementation of the WindowViewManager.

WindowViewManager: Definition

pic003 - SFML App Framework v2 - Eval Program - 2014-09-04

WindowViewManager: Implementation

pic004 - SFML App Framework v2 - Eval Program - 2014-09-04Program

At last we come to the core of the main program. The overall sequence of the program is defined in the class, Program. The Program class is concerned with integration and is the point of convergence between SFML, the higher order logic, and the end-user. The achievement in this round of revisions has been to simplify and reduce the program text that comprise the Program class.

Program: Definition

pic005 - SFML App Framework v2 - Eval Program - 2014-09-04

Program: Implementation

pic006 - SFML App Framework v2 - Eval Program - 2014-09-04

Additional Code Listings

I have made the full text of the code pictured above available from a dedicated page. That page has the snapshot of this code as it appears in this article. See below for details on full code listings.

Update 2/10/2015:

Related Articles


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s