The Chili Framework is designed as a vehicle to make it fun and easy to learn C++ in a graphical context. It lightly wraps a bunch of pain-in-the-ass WinAPI and Direct3D bullshit giving us direct access to the framebuffer for manipulating screen pixels. This allows us to explore basic graphical concepts at the same time that we are learning the fundamentals of the C++ language. Our research shows that this results in a 69% lower incidence of learners shitting themselves to death out of sheer boredom.
- Main article: Game (Chili Framework)
Game class is where you put the code to make the game do the things. The predefined member functions
ComposeFrame() are where you put your game logic and your rendering code, respectively.
Game is composed of the
Graphics object used for drawing and keeps a reference to the
MainWindow object to interface with the Windows system (which includes the keyboard and mouse inputs).
- Main article: Graphics (Chili Framework)
This class takes care of all the Direct3D setup bullshit and provides an interface to the graphical output of the application. Use
Graphics to draw on the screen, anything you like, even dicks (especially dicks).
PutPixel() is generally how this is gone about, although later on more sophisticated dick-drawing routines are created based on
PutPixel(). You can also use
Graphics::ScreenWidth etc. to make sure you keep your dicks inside the screen boundaries.
- Main article: MainWindow (Chili Framework)
Takes care of creating the window and handling the window messages. The message handling involves piping the mouse and keyboard messages to their respective objects. In fact,
MainWindow has eaten
Mouse alive, and now they live in its belly. So you need to go through
MainWindow to get your input done, à la
wnd.mouse.Read(). You can also use this class to figure out whether the main window is minimized or if it's out of focus, and you can kill the fat bastard with
- Main article: Keyboard (Chili Framework)
Keyboard, you can get the current state of depressed keys (have a Valium mate), and you can pop key press and release events out of an
Event queue contained in
Keyboard. You can also turn autorepeat on/off. Whopee. (Note: the
kbd object lives in
- Main article: Mouse (Chili Framework)
Mouse, you can get the current state of the mouse keys and the pointer position, and you can pop mouse events out of an
Event queue contained in
Mouse. You can also check whether the mouse is in the window client region. Whopee. (Note: lives in
Color represents a 32-bit RGBA color value (or a single pixel if you like), and gives you member functions to access the (fudge) packed channels. There is also a
Colors namespace with predefined colors, like
Colors::Aqua (not to be confused with Aqua, the majestic Danish eurodance group).
Other Bullshit Components
Main.cpp file contains the function
wWinMain(), which is the entry point for the program (where the whole shebang starts). It creates the
MainWindow object, creates the
Game object, and repeatedly performs the steps a) process all pending windows messages and b) process a game frame, until it is time for the big sleep. There is also a bunch of exception catching code to catch any stray exceptions and display their error information via a message box.
ChiliException forms the basis for all exceptions that will be generated by the framework or the game code.
MainWindow::Exception are specific types that inherit from
ChiliException. If you want to
throw your own exceptions, you should inherit from
ChiliException, but that's kind of an advanced topic, so don't sweat it Broseph.
This file should be included in lieu of
<Windows.h>. It includes
<Windows.h>, but before doing so it defines some preprocessor switches which set the target minimum version of Windows (Vista) and cut some unused bullshit from the included Windows code, saving on compilation time. If you somehow end up using weird WinAPI bullshit, you might need to modify this file to re-enable that code.
Since D3D11 is a little bitch and won't let us touch its goodies (i.e. the backbuffer), we have to copy our composed frame over to a texture and then draw that texture to the backbuffer. Therefore, we need pixel and vertex shaders. Note that the solution is set up to first compile the shader sources to C++ header files (extension
*.shh, which I just pulled out of my ass by the way) and then compile the C++ source files.
Graphics.cpp includes the
*.shh files, so when browsing the code of a fresh/cleaned solution you may notice errors in
Graphics.cpp, but that's probably just because the
*.shh files don't exist yet. Build once and those errors should disappear.
ChiliFramework.rc is the resource script for baking the icon
Chili.ico into the executable, and
Resource.h contains the ID number used to load the icon from the executable at runtime.
Some code written by a guy at Microsoft that translates DirectX error codes into something with a little more je ne sais quoi. Used to be part of the SDK, but whatever I guess. Licensing status not really clear.
Some people resent a custom framework being used in the tutorials, because they feel that following the tutorials will "lock them into" someone else's proprietary framework, or because they want to start from an empty project. If you're one of these people, just chill out my dawg. The framework is pretty tiny and lightweight in the grand scheme of things, so you're not even going to invest enough time learning it to feel "locked in". This series is about learning C++, graphics, and games, not about learning a framework.
The framework is just an accelerator that allows us to manipulate pixels directly, giving us intimate, carnal knowledge of how graphics works. The end goal is to work with Direct3D directly, so SDL, SFML, Unity, etc. are all overkill and would distract us from our main goal. The training wheels will come off when the time is right, and until then, the framework will allow us to focus on the most important topics first without a lot of bullshit that would just slow us down and maybe cause you to lose interest.