I'm learning a bit of functional programming in Gambit-C Scheme by restricting myself to not using set!. I thought it might be fun to write a little OpenGL game using this environment, which seems to lend itself well to game development.
However, it seems to be difficult to stick to a functional style and avoid global state when using OpenGL and GLUT. I don't think this is a fundamental limitation of game programming, per se, but a callback-based API such as GLUT does not seem to work well with functional programming.
For example, I'm trying to think of the world as a stream of mutating state vectors which is a function of an interleaved list of timestep and user input events. This idea seems to be okay, but it doesn't seem to go easily with asynchronous programming. For instance, I have to register a callback for GLUT's display function, which should somehow be able to access the "current" item in this stream. Meanwhile, there's nothing to drive the stream forward by taking from it.
Ideally, I'd need something that is sort of "outside" GLUT, a main function which somehow depends (perhaps monadically) on the various GLUT functions having been executed at some point. How could such a style of game engine be developed around GLUT, or another way to ask is how could I most successfully isolate GLUT from my engine? Is it possible to have GLUT generate such an interleaved list of events to an outside procedure? How does Haskell handle this, for instance?
You're going to have a very hard time implementing a functional graphics system. Even the Haskell bindings to GLUT use imperative programming, through the IO monad. The closest thing I've heard to what you're trying to do is Functional Reactive Programming, but the libraries aren't ready for prime-time yet and there's a severe lack of real-world tutorials for it.
You could look at the FieldTrip library for some ideas on functional graphics.
It's pretty fundemental to a state machine like openGL that it has state!
I don't see how you can have side-effect free functional programming when the side effect is drawing a collection of stuff to the screen.
Having written this question made me think about it a little, and I'm starting to wonder if the answer lies in exploiting co-routines. If the game is a functional co-routine which is triggered by GLUT idle and display calls, this would very nicely separate the game logic from GLUT's architecture. For example, it's very likely that set! cannot be avoided, but if the GLUT callbacks used set! only to modify the stream which is being fed into a co-routine, this might create a very nice boundary. Any thoughts on this? I'll have to get more experience with co-routines before knowing more..
Related
I'm starting game development, but I really want to avoid hacking together a step-by-step game. I'm thinking, what's a good system for handling all that goes on?
For example, I thought of making a menu class, that contains an array of objects for buttons in the menu, and then every game loop call update() on the menu, which in turn calls update() on all the buttons, passing user input and such along the way. Is this a good way to do it?
I'm trying to find structural techniques past the game loop, any advice would be appreciated. Thanks!
(BTW I'm using c++)
This question is not that trivial, but let me try to give you a really simple answer. You need at minimum a core architecture where you can register several engines. Take a deep look into state machines and several software patterns. There have been really greate game dev books like the Game Programming Gems. Start reading an older book from André LaMothe. Read source code ie. from Half Life 2 that could be downloaded at some places.
It sure depends on the environment, C++ is best and could be the fastest way to write games but would you like to use DirectX or OpenGL, do you need Audio and advanced input? Do you want to start with the older WinApi? Nevertheless it always starts in a single point, the main loop. There your state machine should be initialized and all resource managers need to be set up. For graphical objects you need to think about a low level init, update, draw, release and destroy cycle. UI is built up on Graphics, Input and other parts. Don't start writing your own UI or you need to spend the next 2 years with it. You need a relational game model that describes the world you want to create.
To be honest, read a lot about patterns (like mvc), state machines, gpu pipelines and framework design. Read a lot of code from very talented people that open sourced it for us:)
By the way, what is a step by step game?
First off, I'm aware that there are many questions related to this, but none of them seemed to help my specific situation. In particular, lua and python don't fit my needs as well as I could hope. It may be that no language with my requirements exists, but before coming to that conclusion it'd be nice to hear a few more opinions. :)
As you may have guessed, I need such a language for a game engine I'm trying to create. The purpose of this game engine is to provide a user with the basic tools for building a game, while still giving her the freedom of creating many different types of games.
For this reason, the scripting language should be able to handle game concepts intuitively. Among other things, it should be easy to define a variety of types, sub-type them with slightly different properties, query and modify objects dynamically, and so on.
Furthermore, it should be possible for the game developer to handle every situation they come across in the scripting language. While basic components like the renderer and networking would be implemented in C++, game-specific mechanisms such as rotating a few hundred objects around a planet will be handled in the scripting language. This means that the scripting language has to be insanely fast, 1/10 C speed is probably the minimum.
Then there's the problem of debugging. Information about the function, stack trace and variable states that the error occurred in should be accessible.
Last but not least, this is a project done by a single person. Even if I wanted to, I simply don't have the resources to spend weeks on just the glue code. Integrating the language with my project shouldn't be much harder than integrating lua.
Examining the two suggested languages, lua and python, lua is fast(luajit) and easy to integrate, but its standard debugging facilities seem to be lacking. What's even worse, lua by default has no type-system at all. Of course you can implement that on your own, but the syntax will always be weird and unintuitive.
Python, on the other hand, is very comfortable to use and has a basic class system. However, it's not that easy to integrate, it's paradigm doesn't really involve type-checking and it's definitely not fast enough for more complex games. I'd again like to point out that everything would be done in python. I'm well aware that python would likely be fast enough for 90% of the code.
There's also Scala, which I haven't seen suggested so far. Scala seems to actually fulfill most of the requirements, but embedding the Java VM with C doesn't seem very easy, and it generally seems like java expects you to build your application around java rather than the other way around. I'm also not sure if Scala's functional paradigm would be good for intuitive game-development.
EDIT: Please note that this question isn't about finding a solution at any cost. If there isn't any language better than lua, I will simply compromise and use that(I actually already have the thing linked into my program). I just want to make sure I'm not missing something that'd be more suitable before doing so, seeing as lua is far from the perfect solution for me.
You might consider mono. I only know of one success story for this approach, but it is a big one: C++ engine with mono scripting is the approach taken in Unity.
Try the Ring programming language
http://ring-lang.net
It's general-purpose multi-paradigm scripting language that can be embedded in C/C++ projects, extended using C/C++ code and/or used as standalone language. The supported programming paradigms are Imperative, Procedural, Object-Oriented, Functional, Meta programming, Declarative programming using nested structures, and Natural programming.
The language is simple, trying to be natural, encourage organization and comes with transparent implementation. It comes with compact syntax and a group of features that enable the programmer to create natural interfaces and declarative domain-specific languages in a fraction of time. It is very small, fast and comes with smart garbage collector that puts the memory under the programmer control. It supports many programming paradigms, comes with useful and practical libraries. The language is designed for productivity and developing high quality solutions that can scale.
The compiler + The Virtual Machine are 15,000 lines of C code
Embedding Ring Interpreter in C/C++ Programs
https://en.wikibooks.org/wiki/Ring/Lessons/Embedding_Ring_Interpreter_in_C/C%2B%2B_Programs
For embeddability, you might look into Tcl, or if you're into Scheme, check out SIOD or Guile. I would suggest Lua or Python in general, of course, but your question precludes them.
Since noone seems to know a combination better than lua/luajit, I think I will leave it at that. Thanks for everyone's input on this. I personally find lua to be very lacking as a high-level language for game-programming, but it's probably the best choice out there. So to whomever finds this question and has the same requirements(fast, easy to use, easy to embed), you'll either have to use lua/luajit or make your own. :)
When I recently asked about the uses of Ruby someone told me it was good for prototyping. I basically know what that means, quickly get the very base of your app up and working, see if there are conceptual problems and then add the rest.
Am I right with how I understand prototyping?
What would be a concrete example of prototyping a Snake game in Ruby or any other language?
Yep, prototyping serves as a proof of concept, to ensure what you want to build is feasible. Something might be left out in a prototype could be like exception handling, logging, etc.
A common mistake often made is teams switching from prototype to real code on the fly, i.e. just continuing on the so-called "prototype", except it just now becomes real code.
For many clients, describing what an application will do, or enumerating a set of requirements, is not enough for them to fully grasp how it will work. This leads to the infamous mid-project changes and scope creep. One way to mitigate this is to create a throwaway version that lets them see a "working" example of how the real application will operate.
It can often function as a proof-of-concept as well, but I think client communication is the more useful purpose of a prototype. In particular, you may want to do a prototype using a different technology -- Ruby/Rails, say, or pure Javascript -- than the final working application will use. If so, there's still proof-of-concept value in terms of the algorithms you're using, or the ways you may have to connect to other systems, but again, the actual code will all be thrown away.
So the part of your description I would disagree with is "add the rest" -- I'd throw the prototype out and start over.
Yes, that's a good basic description of prototyping. It's just getting the foundations working so that you know it can be done, and that it suits your needs.
An example of a Snake game prototype would be having a snake that you can move up down, left and right, eats something, maybe have one block in the middle of the board to maneuver around, and the snake growing when it eats something. So, you wouldn't have a splash screen, or keep track of high scores, or have different levels. Just the basics of the game.
Is "Good for prototyping" a polite way of saying "It's difficult to maintain"?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I've recently caught the FP bug (trying to learn Haskell), and I've been really impressed with what I've seen so far (first-class functions, lazy evaluation, and all the other goodies). I'm no expert yet, but I've already begun to find it easier to reason "functionally" than imperatively for basic algorithms (and I'm having trouble going back where I have to).
The one area where current FP seems to fall flat, however, is GUI programming. The Haskell approach seems to be to just wrap imperative GUI toolkits (such as GTK+ or wxWidgets) and to use "do" blocks to simulate an imperative style. I haven't used F#, but my understanding is that it does something similar using OOP with .NET classes. Obviously, there's a good reason for this--current GUI programming is all about IO and side effects, so purely functional programming isn't possible with most current frameworks.
My question is, is it possible to have a functional approach to GUI programming? I'm having trouble imagining what this would look like in practice. Does anyone know of any frameworks, experimental or otherwise, that try this sort of thing (or even any frameworks that are designed from the ground up for a functional language)? Or is the solution to just use a hybrid approach, with OOP for the GUI parts and FP for the logic? (I'm just asking out of curiosity--I'd love to think that FP is "the future," but GUI programming seems like a pretty large hole to fill.)
The Haskell approach seems to be to just wrap imperative GUI toolkits (such as GTK+ or wxWidgets) and to use "do" blocks to simulate an imperative style
That's not really the "Haskell approach" -- that's just how you bind to imperative GUI toolkits most directly -- via an imperative interface. Haskell just happens to have fairly prominent bindings.
There are several moderately mature, or more experimental purely functional/declarative approaches to GUIs, mostly in Haskell, and primarily using functional reactive programming.
Some examples are:
reflex-platform, https://github.com/reflex-frp/reflex-platform
grapefruit, http://hackage.haskell.org/package/grapefruit-ui-gtk
reactive, http://hackage.haskell.org/package/reactive-glut
wxFruit, http://hackage.haskell.org/package/wxFruit
reactive-banana, http://hackage.haskell.org/package/reactive-banana
For those of you not familiar with Haskell, Flapjax, http://www.flapjax-lang.org/ is an implementation of functional reactive programming on top of JavaScript.
My question is, is it possible to have a functional approach to GUI programming?
The key words you are looking for are "functional reactive programming" (FRP).
Conal Elliott and some others have made a bit of a cottage industry out of trying to find the right abstraction for FRP. There are several implementations of FRP concepts in Haskell.
You might consider starting with Conal's most recent "Push-Pull Functional Reactive Programming" paper, but there are several other (older) implementations, some linked from the haskell.org site. Conal has a knack for covering the entire domain, and his paper can be read without reference to what came before.
To get a feel for how this approach can be used for GUI development, you might want to look at Fudgets, which while it is getting a bit long in the tooth these days, being designed in the mid 90s, does present a solid FRP approach to GUI design.
Windows Presentation Foundation is a proof that functional approach works very well for GUI programming. It has many functional aspects and "good" WPF code (search for MVVM pattern) emphasizes the functional approach over imperative. I could bravely claim that WPF is the most successful real-world functional GUI toolkit :-)
WPF describes the User interface in XAML (although you can rewrite it to functionally looking C# or F# too), so to create some user interface you would write:
<!-- Declarative user interface in WPF and XAML -->
<Canvas Background="Black">
<Ellipse x:Name="greenEllipse" Width="75" Height="75"
Canvas.Left="0" Canvas.Top="0" Fill="LightGreen" />
</Canvas>
Moreover, WPF also allows you to declaratively describe animations and reactions to events using another set of declarative tags (again, same thing can be written as C#/F# code):
<DoubleAnimation
Storyboard.TargetName="greenEllipse"
Storyboard.TargetProperty="(Canvas.Left)"
From="0.0" To="100.0" Duration="0:0:5" />
In fact, I think that WPF has many things in common with Haskell's FRP (though I believe that WPF designers didn't know about FRP and it is a bit unfortunate - WPF sometimes feels a bit weird and unclear if you're using the functional point of view).
I would actually say that functional programming (F#) is much better tool for user interface programming than for example C#. You just need to think about the problem a little bit differently.
I discuss this topic in my functional programming book in Chapter 16, but there is a free excerpt available, which shows (IMHO) the most interesting pattern that you can use in F#. Say you want to implement drawing of rectangles (user pushes the button, moves the mouse and releases the button). In F#, you can write something like this:
let rec drawingLoop(clr, from) = async {
// Wait for the first MouseMove occurrence
let! move = Async.AwaitObservable(form.MouseMove)
if (move.Button &&& MouseButtons.Left) = MouseButtons.Left then
// Refresh the window & continue looping
drawRectangle(clr, from, (move.X, move.Y))
return! drawingLoop(clr, from)
else
// Return the end position of rectangle
return (move.X, move.Y) }
let waitingLoop() = async {
while true do
// Wait until the user starts drawing next rectangle
let! down = Async.AwaitObservable(form.MouseDown)
let downPos = (down.X, down.Y)
if (down.Button &&& MouseButtons.Left) = MouseButtons.Left then
// Wait for the end point of the rectangle
let! upPos = drawingLoop(Color.IndianRed, downPos)
do printfn "Drawn rectangle (%A, %A)" downPos upPos }
This is a very imperative approach (in the usual pragmatic F# style), but it avoids using mutable state for storing the current state of drawing and for storing inital location. It can be made even more functional though, I wrote a library that does that as part of my Master thesis, which should be available on my blog in the next couple of days.
Functional Reactive Programming is a more functional approach, but I find it somewhat harder to use as it relies on quite advanced Haskell features (such as arrows). However, it is very elegant in a large number of cases. It's limitation is that you cannot easily encode a state machine (which is a useful mental model for reactive programs). This is very easy using the F# technique above.
Whether you're in a hybrid functional/OO language like F# or OCaml, or in a purely functional language like Haskell where side-effects are relegated to the IO monad, it's mostly the case that a ton of the work required to manage a GUI is much more like a "side effect" than like a purely functional algorithm.
That said, there has been some really solid research put into functional GUIs. There are even some (mostly) functional toolkits such as Fudgets or FranTk.
You might check out the series by Don Syme on F# where he demo's creating a gui. the following link is to third part of the series (you can link from there to the other two parts).
Using F# for WPF development would be a very interesting GUI paradigm...
http://channel9.msdn.com/shows/Going+Deep/C9-Lectures-Dr-Don-Syme-Introduction-to-F-3-of-3/
One of mind-opening ideas behind Functional Reactive Programming is to have an event handling function producing BOTH reaction to events AND the next event handling function. Thus an evolving system is represented as a sequence of event handling functions.
For me, learning of Yampa became a crucial poing to get that functions-producing-functions thing properly. There are some nice papers about Yampa. I recommend The Yampa Arcade:
http://www.cs.nott.ac.uk/~nhn/Talks/HW2003-YampaArcade.pdf (slides, PDF)
http://www.cs.nott.ac.uk/~nhn/Publications/hw2003.pdf (full article, PDF)
There is a wiki page on Yampa at Haskell.org
http://www.haskell.org/haskellwiki/Yampa
Original Yampa home page:
http://www.haskell.org/yampa (unfortunately is broken at the moment)
Since this question was first asked, functional reactive programming has been made a bit more mainstream by Elm.
I suggest checking it out at http://elm-lang.org , which also has some truly excellent interactive tutorials on how to make a fully functional in-browser GUI.
It allows you to make fully functional GUI's where the code you need to supply yourself consists only of pure functions. I personally found it a lot easier to get into than the various Haskell GUI frameworks.
Elliot's talk on FRP can be found here.
In addition, not really an answer but a remark and a few thoughts: somehow the term "functional GUI" seems a little bit like an oxymoron (pureness and IO in the same term).
But my vague understanding is that functional GUI programming is about declaratively defining a time dependent function that takes the (real)time dependent user input and produces time dependent GUI output.
In other words, this function is defined like a differential equation declaratively, instead of by an algorithm imperatively using mutable state.
So in conventional FP one uses time independent functions, while in FRP one uses time dependent functions as building blocks for describing a program.
Let us think about simulating a ball on a spring with which the user can interact. The ball's position is the graphical output (on the screen), user pushing the ball is a keypress (input).
Describing this simulation program in FRP (according to my understanding) is done by a single differential equation (declaratively): acceleration * mass = - stretch of spring * spring constant + Force exerted by the user.
Here is a video on ELM that illustrates this viewpoint.
As of 2016, there are several more, relatively mature FRP frameworks for Haskell such as Sodium and Reflex (but also Netwire).
The Manning book on Functional Reactive Programming showcases the Java version of Sodium, for working examples, and illustrates how an FRP GUI code base behaves and scales in comparison to imperative as well as Actor based approaches.
There's also a recent paper on Arrowized FRP and the prospect of incorporating side effects, IO and mutation in a law abiding, pure FRP setting: http://haskell.cs.yale.edu/wp-content/uploads/2015/10/dwc-yale-formatted-dissertation.pdf.
Also worth noting is that JavaScript frameworks such as ReactJS and Angular and many others either already are or are moving towards using an FRP or otherwise functional approach to achieving scalable and composable GUI components.
Markup languages like XUL allow you to build a GUI in a declarative way.
To address this I posted some thoughts of mine in using F#,
http://fadsworld.wordpress.com/2011/04/13/f-in-the-enterprise-i/
http://fadsworld.wordpress.com/2011/04/17/fin-the-enterprise-ii-2/
I'm also planning to do a video tutorial to finish up the series and show how F# can contribute in UX programming.
I'm only talking in context of F# here.
-Fahad
All these other answers are built up upon functional programming, but make a lot of their own design decisions. One library that is built basically entirely out of functions and simple abstract data types is gloss. Here is the type for its play function from the source
-- | Play a game in a window. Like `simulate`, but you manage your own input events.
play :: Display -- ^ Display mode.
-> Color -- ^ Background color.
-> Int -- ^ Number of simulation steps to take for each second of real time.
-> world -- ^ The initial world.
-> (world -> Picture) -- ^ A function to convert the world a picture.
-> (Event -> world -> world)
-- ^ A function to handle input events.
-> (Float -> world -> world)
-- ^ A function to step the world one iteration.
-- It is passed the period of time (in seconds) needing to be advanced.
-> IO ()
As you can see, it works entirely by supplying pure functions with simple abstract types, that other libraries help you with.
The most apparent innovation noticed by people new to Haskell is that there is a separation between the impure world that is concerned with communicating with the outside world, and the pure world of computation and algorithms. A frequent beginner question is "How can I get rid of IO, i.e., convert IO a into a?" The way to to it is to use monads (or other abstractions) to write code that performs IO and chains effects. This code gathers data from the outside world, creates a model of it, does some computation, possibly by employing pure code, and outputs the result.
As far as the above model is concerned, I don't see anything terribly wrong with manipulating GUIs in the IO monad. The largest problem that arises from this style is that modules are not composable anymore, i.e., I lose most of my knowledge about the global execution order of statements in my program. To recover it, I have to apply similar reasoning as in concurrent, imperative GUI code. Meanwhile, for impure, non-GUI code the execution order is obvious because of the definition of the IO monad's >== operator (at least as long as there is only one thread). For pure code, it doesn't matter at all, except in corner cases to increase performance or to avoid evaluations resulting in ⊥.
The largest philosophical difference between console and graphical IO is that programs implementing the former are usually written in synchronous style. This is possible because there is (leaving aside signals and other open file descriptors) just one source of events: the byte stream commonly called stdin. GUIs are inherently asynchronous though, and have to react to keyboard events and mouse clicks.
A popular philosophy of doing asynchronous IO in a functional way is called Functional Reactive Programming (FRP). It got a lot of traction recently in impure, non-functional languages thanks to libraries such as ReactiveX, and frameworks such as Elm. In a nutshell, it's like viewing GUI elements and other things (such as files, clocks, alarms, keyboard, mouse) as event sources, called "observables", that emit streams of events. These events are combined using familiar operators such as map, foldl, zip, filter, concat, join, etc., to produce new streams. This is useful because the program state itself can be seen as scanl . map reactToEvents $ zipN <eventStreams> of the program, where N is equal to the number of observables ever considered by the program.
Working with FRP observables makes it possible to recover composability because events in a stream are ordered in time. The reason is that the event stream abstraction makes it possible to view all observables as black boxes. Ultimately, combining event streams using operators gives back some local ordering on execution. This forces me to be much more honest about which invariants my program actually relies on, similar to the way that all functions in Haskell have to be referentially transparent: if I want to pull data from another part of my program, I have to be explicit ad declare an appropriate type for my functions. (The IO monad, being a Domain-Specific language for writing impure code, effectively circumvents this)
Functional programming may have moved on from when I was at university, but as I recall the main point of a functional programming system was to stop the programmer creating any “side effect”. However users buy software due to the side effects that are created, e.g. updating a UI.
I am a hobbyist console C++ developer. I have worked with pointers, arrays, std::vectors, std::strings, classes, and several data structures, including stacks and binary trees. I have some experience in linear algebra and geometry, and know the basics of physics. I do NOT have experience with win32, QT, openGL, DX9, OGRE, etc. I am still learning about the more valuable parts of OOP, like polymorphism.
I started C++ as a first language, and do not have experience with other languages. I could probably work with C, but I'd need to get used to manipulating char*'s and regular arrays (and not initing variables).
My question is, with my experience, when should I break into the development of GUI applications/game applications? Do I need to ground myself more firmly in certain areas of math, become comfortable with win32, get used to SDK?
If this question is too subjective for you to comfortably give advice, then when did you break into GUI/game development, and what steps did you take to make yourself comfortable with it?
Editing this so it will get bumped. Does anyone else have any opinions?
Caveat: I am a very "learn-by-doing" type of person, so take this with a grain of salt.
Sounds like you know enough programming basics to jump into something more realistic, and have enough background to justify that realistic project being a game.
I'd recommend downloading Visual C# Express and Microsoft's XNA Game Studio 3.0.
XNA is a game framework that has a lot of stuff done for you (sound, sprites, 3D support, etc.) built on a professional-quality C# platform and it would be a good starting point. Create a new XNA project and play around. Get some stuff to appear on the screen, then learn to manipulate it with user input. If you are interested in 3D, make a 3D shape such as a triangle. Then, make it spin. Then, make it spin based on user input. Then, add other objects and collisions.
Surely, there will be things in the framework that you don't understand. Tackle them as they come - use Google and ask questions here until you do understand them. Take it one step at a time and you should be just fine.
I'd personally recommend you to start out with Win32; try creating a basic window & move on from that point. Try making a simple 2D game engine in which you are able to make a game like chess or so. This could also serve as project for which you could write an AI; which is another part of Game Development!
After you finish that, the next step should be 3D. You could use the engine you wrote before and modify it from 2D to 3D. Pick a 3D API; OpenGL or DirectX. Once you have a basic engine, start writing a game. Need extra functionality? Then add it to the engine!
Math-wise you should know what matrices are. Trigonometry can come in handy as well.
I wouldn't waste my time with Xna, it's just a hype. :P
It seems you already have gained the basic knowledge of a programming language to start game programming. I'm with you in building on what you have already gained, such as learning OOP, and practicing more with pointers. I recommend you move on and don't turn to learning another tool "programming language" to achieve your goals.
So if you are interested in game programming, I recommend you pick a C++ framework and work on it, you'll definitely learn more advanced programming by just using it.
I recommend Gosu. It's not full of advanced features, which can be an advantage, but it has a very clean design and uses C++ in an elegant and modern way. Which makes it very friendly especially for beginners.
Also HGE is another good 2D engine.
To sum up, dive into programming more by actually "doing it" with what you have now. That's how you'll progress, and you'll be amazed with the results. And when "doing it" don't get disturbed with other languages and tools you already know something similar to it, and at the same time when learning a tool that helps you to build on your current knowledge, in your case I mean the C++ engine, don't choose very complicated ones (IMO, like OpenGL, DirectX, Win32...etc) because you'll end up spending time on learning the tool not using it and there is a great chance you'll get frustrated. You can always learn the low level things later, and it will make a lot more sense then.
as this question is kind of subjective, because every programmer has a favourite library to start with, I will recommend SDL as it is simple, well structured, and very complete, there are a lot of tutorials out there to guide you step-by-step from making a simple window to complex 3D manipulation. Everything can be implemented with ease.
As a side note, if you want to start programming games, I would recommend, also, that you read some tuts or books about a Game basics (initialization, game loop, update cycles), so that you know how to put your knowledge to the good work.