"Huge Sprites"

[Laurent]

I think it's quite easy to add a "DoesCachePixels()/SetCachePixels(bool)" to the image interface, it's trivial (As "IsSmooth()/SetSmooth()")

I know it's technically easy to add, but it's not my main concern.
I could add many of these specific small functions, but one day I'll take a global look at SFML and realize it's become bloated and not-so-simple
But again, I'm not saying it's useless, actually it is, and it's even on my roadmap. I'm just saying it's globally not as simple as you may think.

In the case of not-caching, swap would be the only way to really free (as and only if wanted) that myPixels member after the CreateTexture().

In this case I would directly use a temporary vector instead of the member. No clear needed.

I don't want to sound as a smart-ass, I'm just trying to contribute... so don't take it personal, man.

It's ok, no problem dude
I appreciate this kind of feedback, and any effort to help implementing such important features. I'll be very interested to see what you get.

In
"void Image::SetSmooth(bool Smooth)"

It could check if "myIsSmooth != Smooth" before doing all the bind-change parameter-etc

That's right, I'll add it. This is probably because I didn't store this state before, and I forgot to add this optimization

void EnsureTextureUpdate() const;
Should be public, as I may want to modify images and batch-update them before the first time they get binded (that could hog the CPU in different moments).

I don't like providing such functions in the public interface. It's really not what I'm aiming at for SFML. What about calling Bind() in your case ? It may sound like a workaround, but your situation is a very specific optimization and I don't want to change the public interface for such specific code.

[nitram_cero]

Thanks for the reply!

What about calling Bind() in your case ?

You're totally right, that's the best solution , it slipped my mind (somehow I thought it was protected/Sprite-friend or something)

I'll post the BigImage/BigSprite as soon as I finish them.

Regards
-Martín

[nitram_cero]

OK, the BigImage/BigSprite are somewhat functional.

Test demo download link: (http://nitram.cero.googlepages.com/BigImageBigSpriteTest.rar)
(VC++2008 Express project included)

EDIT:
Update: Code tide up and better doxygen like in-code documentation.
Update: Bug-fix

Notes:

It must be built static (for now) because it needs references from internal ImageLoader.cpp and GraphicsContext.cpp
and in DLL mode they are not exported.
Sorry if the project can't be compiled "out of the box", some dependencies in Linker could need to be changed.

Sub Width and Sub Height

BigImage::LoadFromFile differs from the sf::Image version because it has two extra parameters that define the image sub-width and sub-height.


Let me expand a little on that:

If you pass BigImage::DefaultDimension, it uses the maximum allowed by the Graphics card.

In some cases you might want to use lower values for vertex culling and such.

If the one selected is no valid, it's made valid (power of 2 and not higher than the card's max).
i.e.: If you choose 500x500 but the card supports max of 256x256 (as really old Voodoo3's did), it will use 256.
With a Radeon 9800 that supports 2048x2048, but only power-of-two textures, then the it would use 512x512.


Pixel caching in system memory:

Caching of pixels (because of the nature of BIG images) is disabled by default.
This means you can't use SetPixel.

but...
If you use SetCachePixels(true) BEFORE calling LoadFromFile(), then the buffers are not freed, so you can SetPixel all you want because it will be re-applied to the texture.

Use it with caution as big images are usually heavy. The example image in the demo is 4000x2200 pixels (not that big) and it uses 34MB of memory! :shock:


The Demo:

In the demo it takes a while to load because it slices the 34MB (uncompressed) picture into smaller buffers.
And then loads it to textures.

Move: Arrows
Rotate: Numpad "+","-"
Scale: "," and "." (Comma and Period next to the shift key)

For the curious: The picture was taken in Capilla del Monte, Córdoba, Argentina.


Conclusion:

The classes need more work and functionality, but it's quite what I need right now for my game, so it's the best I can offer.

I tried my best to make it at transparent as possible to the interface of sf::Sprite and sf::Image

Maybe I'll work on it some more, adding functions to them to better approximate to the sf::Image/sf::Sprite classes.
But that'll have to wait 'til March.

I hope this is useful to someone
Thanks for reading and tolerating my endless feature-request nagging  :lol:
-Martín

[nitram_cero]

I'm sorry to resurrect this thread, but I finished a game for a competition that uses this "BigImage/BigSprite" that I posted some time ago in this thread to easily work with huge images (as if it would be a regular sf::Sprite/sf::Image).
Notice the background while you play, it's a big ass image. And it works like a charm.

I'm still thinking it would be a great addition to the library.

Thanks for the great library! Laurent, I love you man... you and Erin Catto (Box2D)  :lol: .

http://nitram.cero.googlepages.com/avor
It's not finished (will it ever be? who knows) but it's playable.
Speech voice translation is not done yet, sorry.

Good luck!
-Martín

[Laurent]

Yeah, I didn't forget about this, and I'd like to have something working for SFML 2.0.

Your class is very good actually, but I want to see first if I can integrate it in a better way into SFML. My ultimate goal is to avoid creating a new class, but it won't be easy.

By the way, very good and funny game :lol: