question about RenderTextures, and co

[lezebulon]

Hi!

let's say for example I intend to make a game like Age of Empires 2 ie overhead view, huge map and potentially lots of different sprites intersecting with the current view.
What is the optimal way to do something like this, in terms of RenderTextures ? I admit I'm a bit confused.

The simple solution would be :
- have single rendtexture of the size of the view
- redraw at each frame everything that is viewable

Now, let's assume for instance that the ground texture takes a significative amount of time to draw (for instance, because shaders, or could be tons of textures blended), and that I somehow want to cache it. The same problem would also happen if I wanted to make a game like Baldur's Gate, where the whole map (maybe 10k*10k pixels) is apparently a huge image with no repetitions, and I wouldn't want to load from disk chunks of the map at each frame, when the camera is moving.

I was thinking of doing something like that :
- split the whole map into RenderTextures of 512x512 pixels that would have the cached ground texture
- depending on the current view, draw first the correct cached textures, then draw on top the sprites

My question is : how is that approach scalable with respect to the map size ? I don't really understand how RenderTextures are actually working: is the data stored on GPU ? what's the max number of RenderTextures I can cache? How to compute this max number ?

Basically, what would your advice be for this specific use case ?

[eXpl0it3r]

Start with drawing everything all the time. It might sound "bad", but unless you get performance issues, optimizing before you've anything implemented, won't do you much good.

A render texture is basically the RAM of a GPU. So while on the CPU you save data in arrays and other variables, on the GPU you save everything in (render) textures.

If at the enz of the day you still have performance issues, pre-rendering things to a "pool' of render textures is a good solution.

[lezebulon]

alright, but then how do games like Baldur's Gate 1 (from 1999), managed to have very huge maps with no texture repetition and apparently no streaming from disk?
I'm basically looking at different texture management strategies here... the fact that SFML is simple doesn't mean we can't have discussions about how to manage ressources

[Ixrec]

It's still better to have that discussion after you've made a prototype and have concrete, measurable bottlenecks to talk about alongside some minimal code examples.

[zsbzsb]

alright, but then how do games like Baldur's Gate 1 (from 1999), managed to have very huge maps with no texture repetition and apparently no streaming from disk?

Most likely several things are happening. First off anything that is not visible on the screen is culled and simply not drawn. Secondly map data is most likely being streamed from the HDD in the background and then any needed textures are also loaded. And as you move around map chunks that are too far away from the player are freed as new chunks are loaded. This will give the allusion that everything is being loaded at once since the player is not aware of the background loading.

But as Ixrec said, you should focus on getting your game to work and then come back and make any optimization changes that are necessary after using a profiler on your code.

[lezebulon]

alright thanks!
I have another question:
let's say I want to draw a 100x100 sprite on a 1000x1000 RenderTexture , with a shader.
We are sure that the shader will loop over the sprite pixels and not over the whole range of the RenderTexture right ?

[Ixrec]

That depends on the vertices that get passed to the draw() call, same as when you draw to a window.  A 100x100 sprite will of course use vertices corresponding to a 100x100 IntRect when you call draw() on it.

In general, drawing to a RenderTexture is usually the same as drawing to a RenderWindow.  It just doesn't appear on the user's screen.

[lezebulon]

thanks!
I have a similar question about 2D graphics and SFML:
what is the fastest way to send info from the CPU to the GPU ?
I'm planning to do fog of war through a shader, which would mean sending ~400 bools each frame to the shader (20 x 20 tiles at each frame on screen), through any means possible.
I don't think I can actually send that many shader parameters in real time, what would you guys advise?

[Ixrec]

There are many good ways to do it (see https://stackoverflow.com/questions/7954927/glsl-passing-a-list-of-values-to-fragment-shader).  The problem is I'm not sure if SFML currently supports anything other than 2D textures.

But since premature optimization is the root of all evil, at least try the naive approaches of passing all 400 bools or stuffing them into a 2D texture.  Don't do anything complicated until you've proven it's necessary.

[lezebulon]

how would I stuff them in a 2D texture with SFML?

[Ixrec]

A texture is just an array of Uint8s.  The sf::Texture::update() functions let you change any arbitrary subset of them to whatever values you want.