Ignore buffer cycling until the first frame is rendered

[bullno1]

I have no idea why this works but it works.

The sprite batcher submits a flurry of s_update_buffer in the first frame and due to SDL's cycling it creates a huge number of spare buffers.
But after the first frame, there is only one update per frame.
This is why frame rate has zero effect on resource usage because everything is decided on the first frame.
SDL's buffer cycling indeed works: It keeps reusing the gazillions of buffers created on the first frame.

The workaround is to ignore cycling on the very first frame.
There is nothing inflight so there is no chance of corruption.

Resource usage even on the RAM side is tiny now.

I think there should be a better fix if the sprite batcher is better understood.

[bullno1]

Hmm a spritebatch_defrag before a spritebatch_flush makes more sense now that I think about it.

It also helps to deal with situations like new scenes/levels where a bunch of new sprites are added.

[RandyGaul]

Ah, yes, before any atlases are constructed it may be behaving where individual draw calls are submit. That might be the crux of the issue here. It's not supposed to do that though. Usually defrag would handle that. Something must have broken somewhere.

[RandyGaul]

I would make sure to check the command layer in CF cute_draw.h and make sure it's merging draw calls there properly as a first step

[bullno1]

I tried calling defrag before flush and it solves both RAM + VRAM usage without touching the cycling flags: #275

[bullno1]

Closing because this is a hack anw. It won't protect against situations like loading a new scene/level where there are a lot of new sprites.