0
\$\begingroup\$

I have been dreaming for years about programming a relatively simple, but from the standpoint of the game engine, a very unusual 2D game engine for the PC platform. I am planning to use either C or C++ for the core engine, and maybe later expose the engine to a scripting language such as ruby, python or lua (for higher level programming of the content of the game). Not having ever programmed any noteworthy GUI applications let alone games, i am not really sure about which API:s to select for the task.

The requirements for the API:s are unlike other 2D games, since instead of drawing sprites, glows etc. using OpenGL, Allegro or SDL, i only need to be able to open a window instance, clear the framebuffer, write individual pixels to it, and then draw everything to the screen. Thus the API needs to be really really fast, and no additional functionality is needed from the API.

Additionally i need user input and sound output, through an additional API if necessary. Do you have any suggestions for the best course of action?

\$\endgroup\$
  • 1
    \$\begingroup\$ This is kind of a which tech to use question. There really isn't a single correct answer to the question. It might help to read what gamedev.stackexchange is all about. \$\endgroup\$ – John McDonald Jul 6 '13 at 20:28
  • \$\begingroup\$ This may be possible to salvage as a good question if it was refocussed around ways to efficiently draw pixels to the framebuffer, and the "recommend me a technology" part was removed. \$\endgroup\$ – Maximus Minimus Jul 7 '13 at 1:43
0
\$\begingroup\$

Well I think that using SDL (yes I read your question to the end : you do not need all the extra API stuff from SDL) is still a viable option for what you want to do, because SDL is fast and reliable.

If you don't want to use the rest of the API, then fine, just leave it where it is. But SDL will be fast enough for you I believe. It has pixel manipulation and sound (through the use of sdl_mixer).

Now, you can go even deeper by using directX I guess, but isn't that too much harasment for what you want to do?

EDIT:

There's also SFML that also has pixel manipulation & sound. It is "like SDL" (very roughly) but more object oriented.

EDIT 2:

Forgot about user input, I find SFML better for that (it's just personal taste though), though the recent SDL2.0 simplified this task a bit.

\$\endgroup\$
0
\$\begingroup\$

I would recommend just using OpenGL. There's a few ways I could see you going about doing this

  1. Use a stream VBO with render mode set to points
  2. Use glDrawPixels
  3. Put your pixels in a texture and render it on a quad
  4. Draw a screen sized textured quad and do all your drawing via a fragment shader (probably a bad idea)

The list goes on. I would highly recommend OpenGL over SDL or DirectX

EDIT

I should clarify that I don't mean using only OpenGL. Add in a framework like GLFW or use OpenGL for QT to handle your window creation. Don't use GLUT. Really. Additionally, GLEW will handle platform specific extensions quite nicely

\$\endgroup\$
  • \$\begingroup\$ I Don't think using OpenGL alone is such a good idea. You would need to write platform-specific complex code for window creation. I highly recommend instead SDL2 (from the repository) which will manage platform-specific code for you and provide you with a clear OpenGL interface. As well as sound support from SDL2_Mixer. Edit: Also writing to the screen through OpenGL is an unneccessary complication, it is much simpler to just straight draw it to the screen(or backbuffer) using a simple blit. \$\endgroup\$ – akaltar Jul 6 '13 at 20:08
  • \$\begingroup\$ Well, not OpenGL alone, but with a toolkit, such as QT or GLFW. GLEW can will handle much of the platform abstraction \$\endgroup\$ – Outurnate Jul 6 '13 at 20:21

Not the answer you're looking for? Browse other questions tagged or ask your own question.