vectors, maps, and all the std:: stuff is not available in plain C. If you want dynamic lists you have to code yourself for every kind of structure you think at. It's not that difficult, it's only boring.

Generics? void*

C is a beauty language to me, but I quote ultramailman: use it in its original flavor of a procedural language, with elegant modules of functions, rather than push it to an unnatural OOP

How would you guys implement a TextureManager and SceneManager in ANSI C?

There's nothing really different here. Just do it like you'd do it in C++, only manually performing every operation and hand-coding all the data structures you need. Structurally and algorithmically, it's basically the same. Remember that C++ is not _really_ an OOP language; it's just a bunch of syntactic sugar (mostly) over C, just like C is mostly just a bunch of syntactic sugar over assembly, which is just syntactic sugar over raw machine code. You can almost directly port any code from one "language layer" down to the next without much trouble; you'll just need to write a bunch of extra code for things that the higher layer did automatically (like instantiate template specializations, or automatically invoke destructors). There are some idioms that tend to differ as ultamailman said, but translating from the good practice of one layer to another is still fairly easy if you understand both.

Shaun uses std::map and std::vector a lot, but i'm not really sure if C is able to support such dynamic structures well in ANSI C (while maintaining portability and not using third-party libs).

It doesn't. The best you can do is to make some really gnarly macros. Some folks choose to make "generic" data structures that just hold void pointers to data and add in all the extra necessary casts (and pay the performance cost of the extra indirections and allocations). This is one of the most damning things about C. Expressing data structures in C is very difficult compared to what C++ does easily and generic C data structures usually have measurably worse performance than their C++ equivalents.

This is not too different from the case with generic data structures in old versions of Java or C# before they had generics. A statically-typed language without generics (like C) can be a huge pain in the butt to work with.

And what about memory allocation/deallocation? A scene manager is responsible for transitioning between scenes and cleaning stuff up. I imagine the scene class as a struct and many arrays with the objects in the scene. But to clean them up automagically on free(struct)?

This is all manual in C. You'll need some functions like scene_free(SceneMgr*) or the like that clean up resource trees in systems. Likewise for any shared resources, you need functions like game_object_acquire(GameObject*) and game_object_release(GameObject*) and be darn sure you call them manually everywhere you need to since none of it will ever be done automatically for you.

A struct with flexible types? Maybe something like this?

This could be done with a union, which is roughly what they're for. Just be aware that C/C++ unions are not "tagged" meaning that the language has no idea which element of the union is properly initialized and ready for use, so you usually need to keep some other piece of data along with the union (like an enum) to keep track yourself. If you're just dealing with different kinds of pointers you can also just store a void* and an enum and cast as appropriate whenever you use it.

You should probably just use C++. There's little good reason (in my opinion, at least) to favor pure C over C++. A lot of game developers that claim to prefer C really use a subset of C++ that just eschews all the things they don't like and makes minimal but effective use of the other non-C features. C is a decent choice for small libraries and tools; it's increasingly difficult to justify it in projects of today's games' scale, though.

For some of your tasks, perhaps something like this could help:

struct Texture
{
  SDL_Surface* surface;
};

struct Sprite
{
  struct Texture texture; // *Not* a pointer to the struct
  int frames;
  int x;
  int y;
};

What is quite cool about this is that a Sprite can now be passed into a Texture function (in C, I don't even think you would need to cast it). i.e

struct Texture* tex = texture_create("someimage.png");
struct Sprite* sprite = sprite_create("someimage.png");
...
texture_get_width(tex);
texture_get_width(sprite);

This technique is used in large C libraries like Gtk+. It also means if you do this form of "poor man's inheritance" on all your structures in the game, you could use a generic type of Object as the array type for example.

When using the popular component entity system (preferring composition over inheritance), I find using C is much more feasible for games development.