Hi guys,

I've been working on a push-block Puzzle Game in C++ using the Oxygine engine and I was wondering if there was something out there more in-tune with the Handmade way of thinking without needing to put a lot of effort in.

Features/Tooling I'd like the engine have that Oxygine uses:

• Good resource management (ie. Texture atlas build tools)
• Simple to use API for loading/drawing sprites
• Support for Windows and Mac. (Nice to have: Emscripten support)
• Fast tile rendering capabilities

When I first tried to get started, I looked into using SDL2 but found I didn't make much progress as just adding libraries to get font rendering going and whatnot seemed time consuming and tedious. I kind of what an engine that gives me a lot of tools I can peek at and go to use so that I can get a feel for whats available to me.

Also worth mentioning I don't really use Oxygine's underlying 'Stage/Actor/Flash' for entities and instead use a pool with a monolithic entity class. (Unions are used for entity specific fields.)

What are your objectives? What exactly are you trying to do?

You've established that It's a 2D game. On top of it it's a puzzle game.
At this point - since you targeting PC or MAC - without any further details - you can do whatever you want really.

That includes an L2 cache miss per every memory read/write, and you'd still be fine.

If your objective is shipping a game, don't feel guilty about not "following the Handmade way".
Handmade philosophy is in large part orthogonal to the mindset you need to ship a game.

Almost everything Casey does on stream doesn't apply to realities of indie-game development.
It is fascinating to watch, and you can learn a lot from it, but don't rush head first to apply it in your context.

pragmatic_hero
That includes an L2 cache miss per every memory read/write, and you'd still be fine.

What?
Where do you get this from OP post?

I believe he means that with the type of game being talked about performance shouldn't be a problem. He's saying that even if there were an L2 cache miss per every memory read/write, he thinks it wouldn't affect the game play experience for a 2D puzzle game.

From experience I can say that I really don't think it is true that the handmade way is orthogonal to the reality of shipping an indie game. Unless you are working under a tight deadline, I think building up from scratch can have serious benefits. Yes, it is a hard initial investment to build the infrastructure your game will need from scratch - but I think in the long run it pays off.

For example, I've done Linux porting work in this community for both Motionbox and Milton. Both are great pieces of software, but one is built in a more traditional style with C++ and dependencies like boost and Qt. The other is essentially built from scratch with a platform layer like handmade hero. Working on Linux support for Milton was a blast, and you can see how easy (and FAST!) it was on riscy.tv (shameless plug). Whereas with Motionbox it has been more like "idk what is going on, it doesn't work, better ask bunjee".

I don't mean that in any offensive way, as I say, both are great projects. However, I've definitely observed that the handmade style code-base makes it easier and faster to get real work done. If you started a project like a video browser or a painting software, would you consider going "hardcore" and doing it from scratch? It might sound crazy, but even for projects like these - it definitely pays off in the long-term.

I've been using MonoGame recently, which I think fits into the level of abstraction you are looking for.
On the scale of [Raw OpenGL --------- Unity] It is just to the right of Raw OpenGl, but you do get fonts, resource management tool, multi-platform, open source. The catch? It is .NET, so you would be programming in C# or F#, not C/C++

Correct.

The "cache miss" part was driving home the point of how HARD it is to make a 2d game run sub 60fps on PC, especially one written in C/C++.

Some of the keywords and phrases OP used, such as - "fast tile rendering capabilities" - intuitively - seemed to imply that OPs concerns had something to do with performance.

Alright, so engines/libraries aside. The issue I'm trying to solve is that my friend is not getting a solid 60 frames-per-second rate on his old but fairly OK gaming laptop:
- Nvidia GT540M
- Intel Core i7 2630qm

So, because only 44 triangles are rendered from entities, I'm assuming the bulk of the slowdown must be coming from the tile rendering. Now, from what I've read, it looks like the best solution is to either draw the tiles to a VBO (or texture? I don't know.) or figure out how to write a fragment shader that draws tiles efficiently. (source: http://gamedev.stackexchange.com/...-tiles-with-opengl-the-modern-way)

Finally, because Oxygine doesn't offer any out-of-the-box methods to do this, I was wondering what other engines might exist that would offer this and perhaps be more suited for what I want to achieve. (As Oxygine doesn't even have an keyboard API, you just use SDL2 directly since the core developer seems to be mobile-focused)

To render 44 triangles at 60fps it is not necessary to use VBO and/or shader. Just the regular plain glVertexArray from client memory, or even glBegin/glEnd will be fine.

POST CODE!

glBegin/glEnd are not *slow* (remember you can draw multiple primitives with one glBegin/glEnd call), texture binds are!

Are you calling glBindTexture per tile?
a) Put all tiles on a texture atlas OR b) Put all vertices in separate array for each texture

Don't use a VBO.
Don't render to Texture.
Don't write a custom vertex/fragment shader (you're already using one).

All of this will make your code more complicated for no added benefit.

For reference:
Gives me 100.000 different moving sprites at 80fps in DEBUG build without any tweaks or optimizations. 20 bytes per vertex, depth testing on, alpha testing on. There is only one texture bind (uses a big texture atlas)! The memory bandwidth of my CPU is about the same as the laptop CPU.

The next reasonable upgrade to minimize memory transfers/copying would be using
But that's only worth the effort if you need more than 100.000 dynamic sprites.

profile it?
It lists update at 1ms, render at 3ms. That should be 250 fps.