Difference between revisions of "Chili Framework"

Latest revision as of 13:26, 5 May 2022

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.

Core Classes

Game

Main article: Game (Chili Framework)

The Game class is where you put the code to make the game do the things. The predefined member functions UpdateModel() and 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).

Graphics

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.

MainWindow

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 Keyboard and 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 wnd.Kill().

Keyboard

Main article: Keyboard (Chili Framework)

With 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 MainWindow's belly.)

Mouse

Main article: Mouse (Chili Framework)

With 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 MainWindow's belly.)

Color

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

The 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

The class ChiliException forms the basis for all exceptions that will be generated by the framework or the game code. Graphics::Exception and 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.

ChiliWin

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.

Framebuffer Shaders

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.

Resource

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.

DXErr

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.

Miscellaneous

Criticisms

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.

How to Get the Framework

The the zipped Framework solution folder can be downloaded directly from here. You can also clone the repository on GitHub. Bone ape tit.