What is Reddit's opinion of
SDL?
From 3.5 billion Reddit comments
➔ SDL website
By popularity on Reddit, this Service is:
74 reviews of this app found across Reddit:
Back when I was fiddling with OpenGL, I avoided GLUT too, but I found SDL and glfw to be really good. SDL contains more shit (networking, sound etc) if you want to make a complete game. glfw is pretty much just a tiny wrapper around OpenGL. Pick one of them and play around a little. You might like it.
I'm not a professional game developer, but I know several and work with many people who used to be and generally no, it's not as much fun as you would imagine unless you're John Carmack. Most game developers are underpaid, overworked, have strict deadlines and horrible crunch times and don't get to actually work on much that's fun.
Writing your own games as a hobby can certainly be fun, but often requires some kind of artistic talent.
If you genuinely want to be a game programmer, start by learning to program well. At the very least, learn how to program in C and C++ and start making some games. Start by making some simple games then work your way up to more complicated games. I would suggest starting out with a library like SDL too. I would also recommend contributing to some open source projects and learning as much as you can.
Now, if after a few years of that, you love doing it and can't imagine doing anything else, and have a good portfolio of games you've made, then maybe games programming is for you.
Honestly though, if it's a relaxed work environment, decent money and interesting programming you want to do, you'd be better off finding a successful and growing startup. That's what I did (after many grueling years as a programmer in the finance industry), and now I get to come in to work at 10:00am wearing jeans and a t-shirt, work from home a lot and work on some pretty cool software.
for those who can reach the website for any reason
>Due to popular demand, we’ve put some time into getting the Linux version of the pre-alpha demo ready for all of you (well, the Linux users out there). We’re doing this before we hit the stretch goal for Linux as a gesture of good faith, but please understand that the Linux demo does not guarantee a Linux version of the final game unless we hit the stretch goal. It took quite a bit of time to get it all working on Linux, as well as a bit of internal testing. Launching on other platforms takes time to adequately support and deploy, which is why the stretch goal is vital.
>You can download the Linux demo via Steam, but you’ll need to install the audio library separately as per these instructions from Audio Kinetic's site
>Note: The Wwise Unity Integration for Linux needs libSDL2 installed on the machine to work. Without this, a "DLLNotFoundException" message is displayed when launching the game. To install libSDL2 for Ubuntu 12.04, do the following:
>sudo apt-get install build-essential libasound2-dev
>wget http://www.libsdl.org/release/SDL2-2.0.3.tar.gz
>tar -zxvf SDL2-2.0.3.tar.gz
>cd SDL2-2.0.3
>./configure
>make
>sudo make install
>sudo ldconfig
And for those of us who still have no idea who that is or how monumental this may be, Sam Oscar Lantinga was the lead software engineer at Blizzard Entertainment, created the Simple Directmedia Layer, and was the lead programmer and a co-founder of the now-defunct Loki Software, which ported several game titles to Linux.
Near the end it says ' fatal error LNK1181: cannot open input file 'SDL2.lib'
The 0.4 version of the BuildingForEveryPlatform doc says this for windows:
All you need to install is the SDL2 libraries but it's a pain in the butt. The instructions here are from the sdl2 crate for building with MSVC, which is what I've found to be simplest:
- Download MSVC development libraries from http://www.libsdl.org/ (SDL2-devel-2.0.x-VC.zip).
- Unpack SDL2-devel-2.0.x-VC.zip to a folder of your choosing (You can delete it afterwards).
- Copy all lib files from
SDL2-devel-2.0.x-VC\SDL2-2.0.x\lib\x64\
to the Rust library folder. For Rustup users (most common), this folder will be in
C:\Users\{Your Username}\.rustup\toolchains\{current toolchain}\lib\rustlib\{current toolchain}\lib
or, if not using Rustup, to (for Rust 1.6 and above)
C:\Program Files\Rust\lib\rustlib\x86_64-pc-windows-msvc\lib
or to (for Rust versions 1.5 and below)
C:\Program Files\Rust\bin\rustlib\x86_64-pc-windows-msvc\lib
or to your library folder of choice, and ensure you have a system environment variable of
LIB = C:\your\rust\library\folder
Where current toolchain is likely stable-x86_64-pc-windows-msvc
.
- Copy SDL2.dll from
SDL2-devel-2.0.x-VC\SDL2-2.0.x\lib\x64\
into your cargo project, right next to your Cargo.toml.
However once this is done you should be good to go.
Chances are you're going to want to do a tutorial on how to use the SDL2 library. SDL handles input, basic graphics and audio, and lots of other stuff, in cross-platform C.
At some point - or if you want to dive in at the deep end right away - you may want to learn OpenGL, which is a cross-platform low-level graphics C API (note that SDL can create an OpenGL "context", but OpenGL is separate from SDL). OpenGL is challenging to learn, partly due to its long history. You will want to learn "modern" OpenGL, not anything dealing with its deprecated functions (such as anything using glBegin). This is my recommended tutorial for modern OpenGL, and it includes how to use SDL to get started with 3D graphics.
I don't know why you were downvoted, if you wanted to write 2d or 3d games, SDL has a simple API.
Although having to install SDL_TTF, SDL_image, and SDL_mixer in addition to SDL is a pain in the ass, also most SDL tutorials are written in C++ rather than C.
If at any point you're able to make a decently playable build for Linux, I will purchase it for sure! Even if it's an just an early access / public beta at first, I'd be glad to help test it out and give feedback, and I'm sure many others would too (especially those on /r/linux_gaming).
I'd like to ask some technical questions, if you don't mind.
Are you using your own custom engine for this game? If so, have you made use of SDL or OpenGL support in your engine? If not, are you using an engine like Unity or Unreal? (Both have Linux support.)
Use PNG and make your life easier. Go grab http://www.libsdl.org/projects/SDL_image/ and use the following:
typedef struct { GLuint id; int width, height; } TEXTURE;
TEXTURE* LoadTexture(char filename) { SDL_Surface surface; GLuint textureid; int mode;
surface = IMG_Load(filename);
/* Or if you don't use SDL_image you can use SDL_LoadBMP here instead: surface = SDL_LoadBMP(filename); */
/* Could not load image */ if (!surface) { printf("Could not load image: %s", filename); return 0; }
/* Work out what format to tell glTexImage2D to use... / if (surface->format->BytesPerPixel == 3) / RGB 24bit / { mode = GL_RGB; } else if (surface->format->BytesPerPixel == 4) / RGBA 32bit */ { mode = GL_RGBA; } else { printf("Could not determine pixel format of image: %s", filename); SDL_FreeSurface(surface); return 0; }
/* Create one texture name */ glGenTextures(1, &textureid);
/* Tell opengl to use the generated texture name */ glBindTexture(GL_TEXTURE_2D, textureid);
/* Read from the sdl surface and put it into an opengl texture */ glTexImage2D(GL_TEXTURE_2D, 0, mode, surface->w, surface->h, 0, mode, GL_UNSIGNED_BYTE, surface->pixels);
/* Set up texture filters */ glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MIN_FILTER,GL_LINEAR); glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MAG_FILTER,GL_LINEAR);
/* Allocate memory for Texture structure and fill it up / TEXTURE texture = (TEXTURE*)malloc(sizeof(TEXTURE));
/* Could not allocate memory */ if (!texture) { printf("Could not create TEXTURE struct for image: %s", filename); return 0; }
/* Set up TEXTURE structure */ texture->width = surface->w; texture->height = surface->h; texture->id = textureid;
/* Clean up */ SDL_FreeSurface(surface);
/* return pointer to image structure */ return texture; }
Uhhhhhh... libsndfile?
Or SDL_mixer for something friendly to static linking?
Not standard as in namespace std, but just as well.
ok here's how i did it:
1) Download ResidualVM from here. Drag the ResidualVM.app to your Applications/ folder.
2) If you don't already have it, download the SDL framework here. Copy the SDL.frameworks folder to your /Library/Frameworks folder.
3) Go dust off your Grim Fandango CDs (or download torrent here and convert to ISO)
4) Pop the first CD in / mount the ISO and copy the GRIM.TAB file and all .LAB files from the GAMEDATA/ folder to a folder on your harddrive.
5) Pop the second CD in / mount the ISO and copy the .LAB files from the GAMEDATA/ folder to the same folder. Overwrite any files that already exist.
6) Open ResidualVM, click Add Game, then open the directory where you just copied your Grim Fandango files to.
7) Choose "Macintosh" as your operating system.
8) Click play!
FYI I'm running Mac OS X Lion. Now go enjoy one of the greatest adventure games ever created!
You need a project. This will cause you to learn as you go about trying to implement it. You said you have made console based games. Why not try making a graphical game? It is not as hard as it sounds, and you can then get experience of learning an API. As well as learning whichever APi you go in for, you gain the experience of learning how to learn: reading API documentation, etc. Try SDL, its cross platform, well documented and works nicely with C++.
First try making space invaders or pacman (you'll be surprised at the amount of code it involves!), then maybe try a game of your own design.
This is just an idea. The important thing is to have a project in mind which you currently do not know how to make. Then you go about learning how to make it. Learning commences and knowledge is gained. Good luck.
Hi there,
A lot of people seem to really like the IDE idea, and frown upon using a text editor and a command prompt, but that's what I'm going to recommend primarily, I don't really delve into C++ so I'll simply be ignoring it. I'm also going to assume you're still using windows.
I personally use notepad++ (is free, has tabs, syntax highlighting and lots of clever features without having a learning curve) and TCC (tiny C compiler) when programming on windows. For what you want I'd recommend using MinGW (GNU C compiler for windows), notepad++ and SDL (a graphics library which has pre-compiled libs for Win32 MinGW, its also multi-platform), There's also a precompiled version of GDB floating about somewhere if you need a debugger.
People will tend to recommend code::blocks as an IDE, but I've never had anything but hassle while attempting to use it, and I've always found it a pain to try and change any setting or work my way around it without breaking something. The benefits of using it have never been apparent considering the amount of wasted time trying to get the damn thing to behave. I've also personally had problems with Visual Studio/C++.
So to summarise: MinGW, Notepad++ and SDL.
If you don't know C/C++ I recommend you run through some tutorials first and get a decent understanding of what's going on before trying to use SDL with them, else you will get confused. I can't speak for C++, but there isn't too much to C (compared to modern languages), I'd recommend the K&R book as a starting point.
I actually rather liked it, but it's worth noting that I know of at least three separate games called Maelstrom. There's a real-time strategy game from 2007 which I heard was pretty bad, there's a very pretty 1992 Mac-only Asteroids clone that was open-sourced a while back, and there's the one I'm talking about, which also dates back to 1992 and was sort of a . . . real-time empire-builder, I guess? It was a strange game.
Most people who have played Maelstrom have played either the recent one or the Mac one - in fact, if you've even heard of the empire-builder, you'll be the first person I've met in over twenty years who has.
Pretty good UI library for C++, also has a C API available, gives you control of the main loop (you call functions to tell it to collect input or render):
https://github.com/ocornut/imgui
You can run it on top of SDL: http://www.libsdl.org/download-2.0.php
SDL itself can also get input, load images, and do some basic rendering, so you could start hacking on that.
ocornut/imgui is more for dev tool sorts of things, so it's not straightforward to skin. It's unclear from your question if by GUI you mean literally just basic fields and buttons, or if you're trying to give your RPG an interface that looks interesting.
>C:\Users\You\AppData\Roaming\Mupen64Plus\mupen64plus.cfg
try changing this under [CoreEvents] >Kbd Mapping Fast Forward = 102
change 102 (F) to another key
key codes here
Unfortunately the settings window is still bugged. I looked into it and it must be a bug in SDL2 because there's no reason the scancodes for those keys shouldn't be read in properly by the library. However, I was still able to bind the Right Shift and Right Ctrl keys manually by editing the default.cfg file generated by the game and inserting the correct scancodes for those keys there. So here's a short list of scancodes for those keys and a few others that are also apparently not behaving right:
- left control key = 224
- left shift key = 225
- left alt key = 226
- left windows key = 227
- right ctrl key = 228
- right shift key = 229
- right alt key = 230
- right windows key = 231
I got those numbers by referencing one of SDL2's header files which you can see here: http://www.libsdl.org/tmp/SDL/include/SDL_scancode.h
simply insert those numbers into any of the lines that start with the /bind command in your default.cfg to rebind that key. You only have to do this once, the game will retain those settings forever.
Hope that helps :)
> There is no built-in way to load an image file to a GL Texture. The audio is simply writing PCM values to a buffer
For loading textures, use SDL2_image to load from a huge range of file formats into a SDL_Surface, then getting the pixels into a GL texture is usually very straight forward (possibly one format conversion to RGBA, then a glTexSubImage call).
For audio, you can use SDL2_mixer, which isn't quite as low level as SDL2's build in audio abstraction.
Are you talking about setting up a window with an OpenGL context to start rendering to it? In that case, go straight to SDL2! =) (Ignore the render API, just use SDL_GL_CreateContext() right after creating your window).
That's a good point. But that is still good for Linux gaming.
If a game has a Linux version, then it most likely has a Mac one as well. But now we are seeing that the converse is also true: if a (newly released) game works on Mac, then it most likely works on Linux also. This is good for both platforms, who share the same development libraries (the ones contained in the Simple DirectMedia Layer), which work great on Windows, too.
This is less about Linux vs. Mac vs. Windows and more of openGL vs. D3D, which hopefully translates to more revenue vs. less revenue.
I thought the page did a fine job explaining itself -- it's about a proof of concept for a minimalist GUI API. The rendering details are not part of what it was presenting, but it uses SDL. You can look at the source.
Just as forewarning SDL doesn't come with a primitive drawing library but there are a bunch of useful libraries that build on SDL. One of which is SDL_draw. If you want text anywhere SDL_ttf I think is the most usable text library.
These can be kind of a pain to set up and get running if I remember right, so if you are new to build automation now is a good time to learn.
For my first non-text based game, I got started off by using SDL and following the Lazy Foo Tutorial.
I really cannot recommend that website enough. It shows you everything you need to know to get started so that you can build something like Pong or Tetris, but it doesn't ever walk you step by step in making anything. Eventually, you just realize, "Hey, I probably know enough to make Tetris right now." Figuring something like that out on your own is much more rewarding and teaches you more than having someone tell you step by step how to do something specific like that.
If you want to use simple bitmaps/sprites in 2d rendering and play around in C, check out SDL. Make sure you get the 2.0 RC version, you'll want to clone it from their mercurial so you can get the extension libraries, which you will want.
SDL will let you write cross platform graphics programs without touching platform specific api, ever. In addition if you wish to use direct OpenGL and just use SDL for input and opening a window, you can drop down into OpenGL very easily. In fact in SDL2.0 the rendering functionality serves as just a simplification layer for 2d OpenGL rendering.
I'd really recommend avoiding an ancient tool like blitz basic, you'll soon run up against the limitations imposed by its age. You don't need to limit yourself with an outdated, poor quality tool to make simple 2d things. You can do it with modern tools too.
Edit: As a bonus, SDL is completely free. Blitz is old and costs money. Is there some specific reason you're attached to this outdated software?
For SDL, I find these docs very useful, clear categories, concise and tell you what each function does and the parameters + return values.
The only thing I would add to that documentation is a bit more detail about a few functions, as it seems that apart from the most used functions, the actual description is usually very short.
SDL works on most platforms
"SDL supports Linux, Windows, Windows CE, BeOS, MacOS, Mac OS X, FreeBSD, NetBSD, OpenBSD, BSD/OS, Solaris, IRIX, and QNX. The code contains support for AmigaOS, Dreamcast, Atari, AIX, OSF/Tru64, RISC OS, SymbianOS, and OS/2, but these are not officially supported.
SDL is written in C, but works with C++ natively, and has bindings to several other languages, including Ada, C#, D, Eiffel, Erlang, Euphoria, Go, Guile, Haskell, Java, Lisp, Lua, ML, Objective C, Pascal, Perl, PHP, Pike, Pliant, Python, Ruby, Smalltalk, and Tcl. "
Maybe check out using SDL with OpenGL. The tutorials will get you started. http://www.libsdl.org/
...but on the other hand, rendering is not the only thing you're going to need to think of when you want to make something cross platform. Rendering is just one part of a game. Keep in mind that things like user input, window messages, audio, and file system access all need to be considered as well.
You can also use OpenGL with different programming languages. What are you comfortable using?
Just bite the bullet and program a game for fun. You don't need to write anything original just make a copy of a classic game like Pac-Man or Space Invaders. I would recommend using something like http://www.libsdl.org/
Once you have done a few then you can start to think of something original and go from there.
I'd say SDL is what you're looking for.
You can download precompiled binary releases of SDL for Win32, Win64 and Mac OS X directly from their homepage. I guess most linux distributions have precompiled packages that you can install with the on-board tools, debian supports SDL2 since at least Jessie, same goes for SDL1.2.
What Operating System are you using, and which compiler?
You can check SDL or SFML, they are libraries that handle input and output which are very usefull for games I recommend you do a small CLI programs before making a game since learning to use these library may distract you from learning C/C++ themselfs.
I also recommend you to use SFML over SDL since it is less likely to distract you from learning C/C++.
Again I recommend you to do simple CLI projects to learn C/C++ before you start using advanced libraries to make games
I'm studying python and I'm facing that same decision. What GUI to choose. I choosed SDL. I prefer control over the GUI and freedom to do whatever I want instead of the constraints of those GUI frameworks. Even if I need to study a lot to reach some result.
If you want to learn or build a game from scratch using c++ I would at least use SDL. http://www.libsdl.org/
I tried this a while back but because I was unable to prototype anything within a month, I gave up. Tutorials: http://lazyfoo.net/SDL_tutorials/
There is no alternative to experience. Download SDL 2.0, create a single C file, and write the simplest game you can imagine in it.
http://www.libsdl.org/download-2.0.php
Follow tutorials and read the SDL wiki until you can compile your file successfuly and have created a window with sprites moving around. If you decide you want to add 3D graphics to your program later, learn OpenGL 3.x+ from these tutorials:
http://www.opengl-tutorial.org/
It's worth starting with pure C, because that's what the important APIs like OpenGL are specified in and it will give you an appreciation for how to layout your game data in memory.
They're pushing using the SDL 2 library (http://www.libsdl.org/) to make it cross-platform. I wonder how many of those 300 are AAA. And I hope performance improves a lot; the tiny bit I tried of metro last light under steamos seemed fine, but native "Steam Dig" runs horribly on my Phenom2x4/HD6870 SteamOS box for some reason. It looks fine but the framerate is very slow/choppy compared to under Win7.
Hmm odd. I don't know of any inherent problems for SDL/Virtualbox. Are you sure it's not your configuration for sound? Also, is the primary OS (not the virtualbox) also linux?
You could try this: uninstall pygame and SDL with apt, then grab it from http://pygame.org/download.shtml, and the SDL lib from http://www.libsdl.org/download-1.2.php. Install them manually and see if that helps matters.
Alternatively you could try PySDL, which has quite recently made the switch from SDL 1.2 (what pygame used) to SDL 2.0. Pygame is really just a (very convenient!) wrapper for SDL, which means you wouldn't have to do a whole lot in true SDL to get something pygame-like.
You have two choices: platform-native or a cross-platform abstraction library.
If you go platform-native, your code will only work on that operating system. In fact, it might only work on certain versions of that operating system unless you're careful. You'll also have to use a native programming language like C or C++, or possibly C# on Windows.
If you go the abstraction route, you have a choice of programming languages, and your code can be recompiled to run on other operating systems. It also generally simplifies the logic so you don't have to worry about some of the low-level details. Here are two libraries that are both really good for low-latency audio:
There are other libraries that are simpler, but I would suggest one of the two above if you want something that updates as quickly as possible.
With either library, you need to learn how to program a "callback" style. The way this works is that you tell the library that you're ready to start playing audio and you provide it a callback function. Every few milliseconds, it calls your function and asks for more audio samples. You have to respond very quickly - if you wait too long, the audio won't have time to make it to your sound card and you'll hear pops and clicks in the meantime.
Programs that do more complicated audio processing often have to create buffers where they precompute samples in advance so that when the callback occurs, you can just copy the precomputed samples. But you don't want to precompute too much, because then there's a longer delay between when things change and when the changed sound makes it to the speakers!
SDL 2.0 is not officially released yet, and as such you need to download the libraries from their Mercurial to get all the 2.0 extension libraries, or get the snapshot if you just want the base SDL 2.0 version. You will also have to build the libraries yourself.
Here is where you can get the Merucurial/snapshot clicky
I also made it clearer in Lesson 0 where exactly to download the libraries, which I hope helps in the future.
If you are planning to make a simple game, I can recommend SDL, assuming you want to do most things yourself. I'm not too familiar with game engines for 2d games, but you can probably find something that comes with more capabilities by using google and wikipedia.
Unless you're hellbent on doing this in C++, I suggest using a different language (SDL comes with bindings to many), like Python with Pygame. It is much quicker to use a language like Python, which means you'll work faster and presumably have more fun in less time.
gamedev.net
lazy foo's tutorials
Lazy foo has some great tutorials that use libsdl. Its an open source, cross platform, graphics library.
Learn C++ by making games. Creating a game program is usually much different than creating traditional programs, and since you are a computer science student already I doubt that the syntax will give you as much trouble as the concepts of render/update loops, dealing with the passage of time and framerate correctly, and other such common concepts in game programming.
A lot of people consider the SDL library a good place to start making a "raw" game as it (and it's extensions) provides functionality for the most basic stuff (blitting images to the screen, handling sound data and that sort of thing).
A good tutorial site for using SDL to create games while implementing the common game programming concepts I spoke of above can be found here. They go over framerate/logic regulation, serialization for saving game state/data, class and inheritance structure design (I think, but you can find tons of opinions on that via google), and lots of other juicy stuff.
Just having decided to do some OpenGL I found this: http://lazyfoo.net/SDL_tutorials/lesson36/index.php
Am also using source of this as reference: http://www.libsdl.org/opengl/SDLgears-1.0.2.tar.gz
Sigh, now my lack of proficiency with math starts to come out.
EDIT: I might as well ask how to translate WSAD keys into motion of object in 3d space, having yaw and pitch provided.
Also, I would appreciate if somebody could tell me how to set OpenGL to do perspective rendering.
I've been using SDL for making some games. It's pretty simple, yet low level (Which I think is a great combination for learning). The http://www.lazyfoo.net/ tutorials are quite good. I was able to make a snake game by the time I'd got up to tutorial 16.
Hey, game programmer here. While I think it's great you want to get into creating your own game you must realise the massive difficulty you face in getting your idea created. There is SO much for you to learn that it can be really overwhelming so the key is to start small. Sure, write out your idea and save it somewhere but for the first few months (or years) you'll want to focus on very simple games first.
I suggest looking into a simple game maker type tool like GameMaker which allows you to create simple 2D games and has quite an active community, simple programming 'language' and decent wiki for help learning. Try making a couple of simple games from scratch to get a feel for the whole process.
When you're ready to move on, it's time to pick a programming language and there are many out there. Most commercial (retail) games tend to be written in C++ with Lua/Python scripting as well. Java is also a popular choice. There are also many game "engines" which wrap up a lot of the common underlying functionality which can be difficult to write yourself. A couple of examples are Corona SDK which is a Lua based game development tool focused on mobile apps and SDL which is a much more advanced library for C/C++ developers to create 2D applications.
Oh, and then you've got to figure out graphics and who will create them for you? Formats? How to import and use in your games? What about audio? And UI design? And gameplay design?
I've just scratched the surface - as you can see it's a massive task to create a game from scratch with no knowledge. You are capable of doing it but realise it's a long journey from today until you're selling your city building game!
Good Luck :)
What the hell is SDL?
> Simple DirectMedia Layer is a cross-platform multimedia library designed to provide low level access to audio, keyboard, mouse, joystick, 3D hardware via OpenGL, and 2D video framebuffer.
I just googled "C read controller input" and found this library:
http://www.libsdl.org/
Just look up some examples of reading controller input, copy them and try to do what you want to do. Documentation is your best friend.
You should include the libraries your program needs with it so that there aren't issues w/ version discrepancies. I had a huge problem with some of the optional SDL libs not being a part of the same release as the libSDL itself, involving SDL_mixer, SDL_net, and SDL_image. Never again!
~~You download them from~~ the libsdl.org website: http://www.libsdl.org/projects/SDL_ttf/ it looks like you might have to build the source yourself :P unless you can figure out who the "distribution maintainer" is (wtf? gatekeepers? seems a bit antithetical to Linux' philosophy IMO)
Dang, I never realized using SDL on Linux would be more complicated than other OS'. Well there are tutorials on lazyfoo.net for doing SDL stuff on Linux so maybe that will help.
Good luck!
Sorry not the answer you're looking for but I highly recommend using a library which handles all the quirky cases like SDL 2. It recently added support for various new gamepads recently IIRC.
Of course you can also look at its Linux input / game pad code. Maybe you find the answer there. IIRC it has support for libevdev, libudev, ..
You download the source codes and compile it.
http://www.libsdl.org/download-2.0.php
You extract it;
Always go to the README file. It's tells you what to do. On this one read the INSTALL file it really tells all.
Linux and other UNIX systems:
* Run './configure; make; make install'
./configure
make
sudo make install
It should be install at this point.
Yeah, the website isn't the most intuitive with regards to the hosted projects. (Of course, you can chop the url down to [http://www.libsdl.org/projects/].
I would also suggest downloading (SDL2_gfx)[http://www.libsdl.org/projects/SDL_ttf/] as has graphics primitives functions, framerate management, image filtering, and other utility functions that can come in handy.
It's possible to code it in Python, the best way to do so (for your learning) is to use a framework like Pygame. Python is a good language to start with (ish, I still support using Java as an entry point, but a lot of Universities have recently converted their entry level programming courses to Python), and a game specific framework for Python takes care of the abstractions for things like graphics and sound so you can mostly focus on the game logic, you'll still have to put in a lot of work but it's a good balance between from scratch and using a fully featured game engine.
C++ is always a good choice to make games with, but because it's a low level language the learning curve is much higher in most cases, you can code your game from scratch (not recommended as a beginner, unless you are willing to sit down and really learn the basics of C++ beforehand), use a framework like SDL, or use a C++ based game engine like Unreal or Godot.
How difficult the game is to maintain in C++ will depend on how you program it (and through what tools) and how much you understand of programming architecture, this point isn't really C++ specific as programming games in any language can increase in scope and become spaghetti, just make sure you structure your code with common good practices and keep it in mind then you should be fine.
As for your last point, for people who really try to learn programming as a skill and not as 1 means to 1 end, there is no picking the wrong language, a lot of the skills you learn you'll be able to port across different languages. Of course, if you want to get into the industry, C++ is the best since it's a standard, but for your own games, just pick what you are comfortable with.
> OpenGL has nothing to do with sound (DirectX does with DirectSound/xACT)
DirectSound is deprecated and xACT isn't part of DirectX.
> or controllers (DirectX does with DInput/XInput).
DirectInput is also deprecated and XInput isn't part of DirectX.
Check: https://en.wikipedia.org/wiki/DirectX#Components
However, if you want something that handles input, sound, graphics, etc, use SDL.
Seems to be that this game exists. I'll try and ask around /v/ shudder. See if they can come up with something.
EDIT: The closest thing I could find was Maelstrom. The sprites (here and here) are very similar but, well, not exact. I'll keep this thread open just in case someone figures what the screenshot is and, if it drives me crazy enough, I might go and ask my prof about it when the next semester starts.
Wikipedia for Sounce engine http://en.wikipedia.org/wiki/Source_(game_engine)
> In April 2010, Valve released all of their major Source games on OS X, coinciding with the release of the Steam client on the same platform. Valve announced that all their future games will be released simultaneously for Windows and Mac.[41][42] The first of Valve's games to support Linux was Team Fortress 2, the port released in October 2012 along with the closed beta of the Linux version of Steam. Both the OS X and Linux ports of the engine take advantage of OpenGL and are powered by SDL.
And the sdl site itself, where they list every major Valve game as "made with SDL". http://www.libsdl.org/
Unity3D and UnrealEngine 4 both compile to native Linux builds.
Unity3D has always been free (no royalties) and has a large community of hobbyists and large developers (see /r/Unity3D). EDIT: Sorry, the editor doesn't work in Linux.
UnrealEngine 4 just recently became fully free (before you had to buy the engine+pay royalties, now you only pay 5% royalties if you make more than $3000 per 1/4 year AND you get full source code for the engine and editor) and has more of a community of industry game developers than newcomers. (Also see /r/UnrealEngine).
If you don't want a battleship but only a swizz army knife, then libSDL is really the first thing to look at. It's used everywhere and its features are perfect for tinkering with small games.
There are many more options, just take a look at the other answers here.
http://stackoverflow.com/questions/6161322/using-stdlibs-rand-from-multiple-threads/6163508#6163508
Edit: I'm gonna assume that SDL runs some threading voodoo and calls the callback from another thread
E2: http://www.libsdl.org/release/SDL-1.2.15/docs/html/sdlopenaudio.html > This function returns -1 if it failed to open the audio device, or couldn't set up the audio thread.
I did a quick search and it seems the only complete reference is the header file, it can be a bit too technical but I think it's still useful for non-developers.
Correct, it is not a "standard" graphics library. It's one of the oldest libraries around and I wouldn't use it for major/real-world applications. But it is quite simple to learn/code in. This stack overflow thread discusses other alternatives. One of those mentioned - SDL - looks promising.
That's a neat trick! I was about to say I'd never encountered a union before, but when I googled it and saw how it was used with structs as a form of polymorphism in C, I realized I have unwittingly used it via SDL_Event.
As for your usage being well-defined, I'm not sure where to find the relevant information in the C standard, but Wikipedia claims that all members of a union should begin at the same location in memory. If that's true, the compiler should pick a memory location that satisfies the alignment needs of both types (probably the same since both are 32-bit). I can't think of a way that a compiler would implement that correctly without guaranteeing that your trick would work.
In my code, I just pass float/double pointers (and the size in bytes) to functions that take void* and operate on them as pointers to uint8_t arrays. Like you, all the floats I've encountered were compatible across various platforms; I don't know how every platform in the world operates, but this works reliably for networking between Mac OS X PowerPC and Mac/Windows/Linux Intel (32-bit and 64-bit).
Not stupidly easy, but there is SDL_net to get a cross-platform way to manage your own TCP/UDP streams. There's also enet for a lightweight, optionally-reliable, in-order transport built on top of UDP. It's also cross-platform.
Both of those are open source and have very liberal licenses (BSD/MIT-like). RakNet is higher level, and also open-source, but with a more restrictive license. It is free, however, as long as your budget and revenue are under $100,000.
Whilst I doubt I have enough experience to judge about this, I think you should definitely have a look at SDL and its rusty wrapper. Also, I would definitely love to port an Android NDK sample to Rust.
SDLFW is a cross-platform framework from the powerful SDL library to create your own 2D games with the Lua programming language. It's easy-to-use, free, open-source, and works on Windows and Linux.
What's New in This Version?
Added support to SDL_resize :
- Easily resize images / surfaces
- High quality Lanczos3 interpolation
Added support to SDL_collide v1.1 :
- Perfect collision tests between surfaces
- Bounding box collision checks
- Circle intersection routines
Added support to SDL_zip v1.0 :
- Support to ZIP files with password
- Support to password encryption
If you have a pretty good grasp on programming, C++ with SDL and OpenGL provides a powerful framework with easy cross-platform access to input (keyboard, mouse, joystick), output (graphics, sound), and other utilities (threading, networking). You can get started using plain OpenGL, but you can pretty easily move to GLSL shader-based drawing using GLEW.
Try to get started with something really simple for your first attempt. With each project you work on, you'll get comfortable with more skills and techniques, and then more project ideas that are within your grasp should come to mind.
The biggest difference is the migration to using an SDL_Texture instead of SDL_Surfaces for your images and an SDL_Window for you window and SDL_Renderer to render things.
These changes came about because of SDL's migration to hardware accelerated rendering, ie. OpenGL as the backend with SDL providing a nice simplification layer between you and raw OpenGL.
However this won't solve your problem if the image isn't being found or loaded correctly, have you tried checking that first? Once you get that tutorial going, then you should check out SDL2
You can download and compile SDL2 and the extension libraries from their Mercurial listed on the site linked. Documentation is available in the form of their wiki, and googleing around for SDL2 tutorials should turn some stuff up. I've been putting one together slowly, which you can find here, it covers the basics at this point.
There's a /r/C_Programming subreddit you can browse.
I've used the GNU Scientific Library successfully on a few projects. For games, there's vector and matrix math and you should check out the various random number generators it provides. However, the library is GPL, which may not work for you.
If you need arbitrary precision -- unlikely for a game but I'll mention it anyway -- GMP is a great choice. It's LGPL.
There's SDL, of course, for graphics, multimedia, and general portability. If you're writing a game in C, I'd think you're likely to be using SDL and/or OpenGL.
Oh, and since you mention it explicitely, I'd recommend going straight for C99 since C89 gets really tedious (if you're following it strictly):
int i; for (i = 0; i < N; i++) { /* ... */
No // comments, no variable declarations inside for's opening, etc.
It seems like you want to help people to learn OpenGL, which means you probably want to make a good easy-to-read lib. May I suggest adding .exe .obj .log etc files to your .gitignore? Because your diffs are not something people would like to browse, IMO.
Also: did you checked SDL yet? You can use it for handling windows, input, sound, etc. Just ignore its drawing features.
Thank you
I'm on Xcode 4.4 here. But the process shouldn't be any different. First you need to get this image if you haven't already got it: http://www.libsdl.org/release/SDL-1.2.15.dmg
In it there's a Framework which you can copy to /Library/Frameworks and add to your project. Make sure it shows up under "Build Phases > Link Binary with Libraries" of your Target. Then there's SDLMain.m and SDLMain.h in the devel-lite folder. You need those in your project too. These replace your cross platform standard int main(int, char *[]) (the signature must match else you get compile errors) with a Cocoa-style NSApplication main at compile time.
Then there's a little detail I always change in SDLMain.m. The default behavior is to look for resources outside the .app-bundle but I prefer it to look in the Resources folder of the bundle. Therefore you can simply comment out the following block in SDLMain.m:
if (shouldChdir) { char parentdir[MAXPATHLEN]; CFURLRef url = CFBundleCopyBundleURL(CFBundleGetMainBundle()); CFURLRef url2 = CFURLCreateCopyDeletingLastPathComponent(0, url); if (CFURLGetFileSystemRepresentation(url2, 1, (UInt8 *)parentdir, MAXPATHLEN)) { chdir(parentdir); // chdir to the binary app's parent } CFRelease(url); CFRelease(url2); }
I've downloaded and installed Code:Blocks but it's the same sort of problem. Even If I have instructions I can follow
http://www.sdltutorials.com/sdl-tutorial-basics
The problem is that every programming interface seems to like to change their menu option slightly for no reason with each version, and every Library seems to like to change their pathing slightly so you can't follow previously written instructions. For example the under Linker settings I can't find these files
mingw32 SDLmain SDL
in the file it suggested to download. http://www.libsdl.org/release/SDL-devel-1.2.14-mingw32.tar.gz
So I switched it to
libSDLmain.a libSDL.dll.a
but I can't find something for mingw32. When I try to compile I get
"undefined reference to `WinMain@16'" which is incredibly cryptic.
I'm not asking for help to solve this problem, I'm really asking for some sort of help to solve these problem in general. Everytime I use or install a library it's the same thing. Unless I get some else to do it for I can never get a library to install and if I try to do it by following the instruction the instruction are always slightly wrong.
Gamedev is incredibly overwhelming for a newcomer. ;)
Start small and work your way up. When I started gamedev in college (with no prior knowledge of C++) our teacher had us bounce some balls in a pre-made template. Three years later I'm working on my own OpenGL engine.
Try building 2D games with SDL, and I would advise you to use Visual Studio just because it makes things so much easier in the beginning. You need to pass that first threshold and things are difficult enough when starting out with C++.
CG can be pretty easy. The thing to watch out for is that there's a good bit of matrix math, which you don't have to be stellar at, but knowledge of it will help a lot.
I did my projects in C using SDL, which is more modern and much better-supported than, e.g. GLUT. However, language choice isn't a huge problem.
You should choose some platform to develop with. C++/SDL is my choice, some likes to use pygame. LOVE2d is also good library.
It looks like C# has SDL bindings, so you should look at SDL because you know C# pretty well most likely. http://www.libsdl.org/languages.php