# What features should a 2D graphics library have? [closed]

I am making a 2D graphics library in Python designed to make 2D easy and fast. Internally it uses OpenGL. The library does cover a bit more then a graphics library, it also includes windowing and sound (and all necessary features to get working, like texture loading).

I've got a good beginning working with good performance, and I'd like to expand and refine my feature set.

Now I'm wondering, what features should a 2D graphics library have? After some brainstorming I made a little list:

• Fast sprite class for displaying rotated, scaled, colored and translated textures
• Sprite batching
• Drawing geometry: lines, polygons, circles, etc
• Alpha with blending modes on all of the above
• Texture regions (and texture atlases)
• Blitting texture(regions) into other textures
• Particle systems
• Off-screen rendering surfaces (FBO's?)

But I feel I have only scratched the surface of features. What am I missing?

One thing you must keep in mind that all of this in Python with C extensions. Any work in the library is fast, any work the user must do is relatively much slower. In addition to that Python calls are quite expensive, so the library largely benefits from batching.

(In case anyone cares, the library in question is pygrafix and can be found here: http://github.com/nightcracker/pygrafix)

## closed as not constructive by Nicol Bolas, TetradFeb 15 '12 at 17:20

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.

• -1 This doesn't really fit into the Q/A style of this website, there's no correct answer, just opinions. Please find a way to word the question in a less discussion-oriented manner. FAQ – John McDonald Feb 15 '12 at 16:20
• What John said, plus there's the opinion that the features should be driven by the game that you're making. – Tetrad Feb 15 '12 at 17:20

For a 2d Graphics library, needs naturally vary according to application, but there are some things that I always find are "must haves".

I must be able to draw primitives. I must be able to draw images. I must be able to draw text.

Of course, if the library in question only did these three things, I'd be no better off with it than I am with just using OpenGL directly.

So, regarding primitives:

At the very least, I need pixels, lines, rectangles, ellipses, rounded rectangles, line based polygons, and filled versions of all of these, with the options of different pens and brushes and whatever else. Above all else, this needs to be easy to use. My requirements for easy to use are not stringent.

Regarding images:

I have the graphic formats that I like to use. Generally, this means PNG file, with alpha. If a 2d graphics library doesn't support this, I generally won't be interested. I must also be able to transform my images through color shading, rotating, scaling, flipping, and pretty much all of the other usual expected image manipulation.

What I DONT want is to think about textures. I want to think in terms of images and spritesheets and tilesets.

Regarding text:

I want to be able to draw text to the screen as easily as on other 2d libraries. I don't want to have to make some goofy grayscaled bitmapped font. I don't mind having to run a command line utility to convert a ttf into something else that the lib can use, but I'd prefer to deal with the ttf directly if I could.

Your library looks to be a "3d lib that can also be adapted for 2d use, provided the user is willing to think in 3d terms", which I would take a pass on.

You may wish to look at Slick2D as a model of a 2d lib that I regard as done correctly.

The ability for the user to set a "world window". By this I mean they supply a rectangle in world co-ordinates and you fit this to the viewport (display it to fit the entire window). By using this function, they can zoom and pan as they see fit. OpenGL has calls that you can pass this on to: glOrtho(r.l, r.r, r.b, r.t, -1, 1); By the way, the user specifies everything in world co-ordinates from now on.

You could also implement some utility routines to aid in collision detection: Nearness checks using bounding boxes or circles and a more expensive polygon intersection test.