next »

[qMopey]

Let us talk about a hypothetical 2D rendering library. Try to imagine what you would want out of a 2D rendering library for some game you would like to make (any kind of 2D game you prefer). What does this library look like? What kind of features do you find necessary? What would you like the library to *not* do (drawing the line somewhere of what not to include is important).

I will start by sharing the outline of an API that I myself have enjoyed a lot. However, I feel like I might be missing out on some valuable ideas or features! What kind of API would you prefer?

Low level necessities:

• Shaders
• Vertex/index buffers
• Render states: blend ops, scissor box, viewport, scale/resize backbuffer, textures + wrap modes, stencil
• Explicit draw call function***
• Uniform/constant cache on CPU-side (optimization)

Higher level features that work out-of-the-box:

• Sprite batching
• Frame based animation
• FBO support (full-screen post processing effects)
• Pixel upscale shader
• Universal uniform/constant for MVP matrix
• Raster font loading/rendering
• Debug draw (lines, and common shapes like circle/AABB, wireframe mode)
• Some kind of basic CPU culling support (not even necessarily accelerated with a data structure, but that sounds nice as well)
• Image loading
• Math/matrix functions and helpers

*** This one needs explaining. By exposing the low-level functionality to explicitly build and push a draw call into a queue, the user can construct their own declarative model (setup state and let the backend sort it appropriately). Simply pushing draw calls without any special buffering + sorting would be traditional imperative model.

I didn't list 2D interpolated animation (like Spine animations), because I personally do not like this style of animating! Though I'm sure plenty of you guys absolutely require interpolated animations. But the question is... Would you want some 2D rendering API to make an attempt to do this for you? Or would you prefer to hook up your animation, and pipe data to the rendering API as-needed?

[InfiniteStateMachine]

I think I can maybe give a better answer if I know more about the type of developer the library is targetted for. I'm guessing based on your post history it's going to be a fairly low level c library?

If I'm assuming it is indeed a c or c++ library then I have some more specific stuff :

1) Do whatever it takes to make it easy to get into your build. I'm a huge fan of the stb style stuff where you do very little to your build scripts.
2) Minimal dependencies on other stuff

I guess when I'm working on c/c++, the biggest point of friction for me adopting a third part library is how much of a burden it will be on my build scripts.

That said I do have some IMO universal feelings on this stuff :

1) I don't think I've ever used an engine or library without feeling there was at least some type of debug draw function that was either missing or implemented in a way where it's annoying to use. So the more debug draw stuff the better IMO

2) This one is a little general and vague so bear with me. The hardest and most time consuming bugs I have to fix often are due to optimizations. Things like incorrect caching systems for example. I know this can sometimes be non-feasible but if you were to include something like CPU culling, the ability to disable and enable it easily is much appreciated for sanity related reasons.

[qMopey]

Wow those are some really insightful points. I especially like the comment on turning off features easily.

Can I ask, do you have any examples of dependencies that were hard to wrangle? I'm really curious what specifically were the problems you hit with dependencies when trying to integrate another library with dependencies.

As for your question on who the developer is -- you! You are the developer using this library, and it can be as high or low level as you want I described a fairly low level-ish library suitable for C/C++, but you might have wildly different preferences, and I'm interested in hearing about them

[Daid]

One of the unique features my home grown engine has is the ability to load images and directly pull them trough an image processor. So you can have HQ2x upscaled sprites. It also has the ability to process a tilemap with HQ2X, so the tiles don't bleed to each other, and different "out of bounds" handling algorithms to suit your needs for upscaled pixel graphics.
https://github.com/daid/SeriousProton2/blob/master/src/graphics/textureManager.cpp#L25

Note, I do this outside of a shader to lower the load on the GPU when rendering. As I'm currently making things for the RaspberryPI, and GPU performance isn't very high there.

[oahda]

Big agree on ease of incorporation. I have my own setup, so I generally just want to slap the source into my own codebase, not use provided build scripts and link against the library. STB is so good in this regard! I'm guessing tiles are covered under batching?

[InfiniteStateMachine]

Wow those are some really insightful points. I especially like the comment on turning off features easily.

Can I ask, do you have any examples of dependencies that were hard to wrangle? I'm really curious what specifically were the problems you hit with dependencies when trying to integrate another library with dependencies.

As for your question on who the developer is -- you! You are the developer using this library, and it can be as high or low level as you want I described a fairly low level-ish library suitable for C/C++, but you might have wildly different preferences, and I'm interested in hearing about them

Thanks

Here's some experiences and elaborations on dependency stuff.

This stuff tends to hurt the hardest when working on a large engine. You can have a large number of target/platform combinations (say 10 targets and 2-7 platforms which might use 1-4 different compilers). Inevitably the build script gets a little fatter with some declarative conditional logic for which libraries to link against which platform combination group. An engine of that size takes a while to build so it's also not feasible to test every combination unless you have considerable resources. Even then you have to sit and wait.

Maybe adding one library is manageable but when you have many third party libraries, all which may or may not have their own way to build, you get a fairly complicated build script that looks daunting to someone looking at it for the first time.

One particularly rough example I can think of is having to have multiple high level build systems for a single project. For example you have an engine that has its own build system but has a plugin model. You then have a plugin that has a dependency on a library that uses something like cmake. Then your build system is calling another build system! All of this ends up working fine but I can't help but think of how many hours I spent maintaining a project rather than working on the project.

I think at this point I have to apologize because it came off as a bit of a rant . I think I can sum this up into a higher level concept : When I write c++, it most often tends to be the language that loses me the most pure programming time. By that I mean things like auditing includes, build script management, figuring out weird linker errors etc etc. Anything to spend more time programming and less time doing stuff around the project has my gratitude.

-------------------------------------------------------------------------------------------------


As for the developer type question the reason I have to qualify it is because my choice varies greatly depending on my project and state of mind :

Game Jam : I go straight to HaxeFlixel 90% of the time. It's batteries included and I can have something up on the screen in a few mins. It has a crazy OOP inheritance hierarchy. I think the main sprite class is about 6 levels deep. So it makes a long term project a case of fighting the library because everything is bolted on to an uber class directly but those same flaws make getting something functional a really quick endeavor. It's a little out of scope because it includes input/collision.

Learning and full control : I tend to go to C or Orthodox c++. This is usually when I want to do a lot of direct manipulation of stuff higher level libraries make difficult to get at like various buffers. Another reason is I tend to enjoy working with it despite it's flaws. C/C++ in their ideal state can be super fun to use, it's fun being able to have more direct access to memory (until it isn't of course :D).

It's funny, today I was working on some problems that required me to do some 2D math. It was in an environment that wasn't wonderful for prototyping algorithms so I looked around for a 2D repl I could use to test stuff out. I couldn't find anything that fit my personal needs. I ended up using a javascript 2d repl which worked but I just don't know javascript so I was spending more time learning how to javascript then writing the algorithm. I have some thoughts on this which I think involve wrapping a low level c drawing library to .net then using f#'s repl. That's a very specific preference though haha.

[buto]

Interesting topic!

I think good and detailed documentation is super important. Besides reference documentation (with small code examples on intended usage) there should ideally also be some introductory documents, which explain how the library can be used to realise common scenarios and nice special effects. Ideally with a minimum amount of fully functional code.

[SamSerious]

I would like it to be very simple. 2D rendering is really a piece of cake even for mobile CPUs, hence I wouldn't want any opengl etc. dependencies, no batching or texture format magic. Just a simple CPU implementation with some headers (and eventually cpp) files.
Also no dependency on a window/input library. Something Simple like

Code:

CImage TileMap("font.png",16,16);//stb_image based -> eats all formats
CImage Image(1280,720);
Image.DrawTile(TileMap,
               4,2,     //tile index
               100,100, //destination offset
               2,4);    //scale
Image.DrawLine(100,100,200,100,CImage::RGB(255,0,255));
Image.SaveTo("foo.tga");

to output stuff, e.g. with PixelToaster

Code:

#include "PixelToaster.h"
..
Display display( "hello Image",Image.Res().x,Image.Res().y);
display.update(Image.Raw());

[poohshoes]

Another way of looking at any library is having lots of layers.  One layer is simple access that will be used %95 of the time such as function with a texture, position, and rotation.  But I like to have access to the back buffer so that the occasional time to read from and write to it.  Build it so that you have a lot of control and low level access and then build helper functions that do a default thing in case you don't care about the nitty gritty.