sf::Texture implemented in SFML 2

[Groogy]

Well, do it the way you prefer, you're not forced to use the same name for all the overloads. CSFML uses three functions: UpdateFromPixels, UpdateFromImage and UpdateFromWindow.

Well since I don't have any online reference for rbSFML and the documentation is easily out of date I try to keep it as close to C++ SFML as possible so you can use your online documentation. I even break the Ruby code standard(but still support it) so that you can use the same symbols as you could in C++ so it's easy to get started. I feel making it easier to use is way more important than making it easier for me to develop it.

So you could say that this is the way I prefer it just that I got unlucky with having so many overloaded methods. :wink:

Anyway it was not as hard to do as I made it sound just that the code became a little ugly and obscure for my taste. I like it when you can read the code straight of and immediately get a grip of what's going on.

[Tank]

Great addition to SFML2. Breaks my 10K+ source lines of code project at a lot of places, but also enhances the usage. Thanks

[SinisterRainbow]

The only drawback of this modification is that you can't retrieve pixels from a texture, and thus from a sprite, anymore. For pixel-perfect collision detection you must now store the collision data yourself (which allows more optimizations, by the way).

Why was this needed? This breaks ALOT of stuff for me :/ also my project has been on ice in waiting for SFML2 Release, and now this? WHY? youre breaking my heart......



...

What about tile-based games (think legend of zelda/shining force)? If you have a texture loaded into video memory with all tiles (like: dirt, grass, stone, entrance). Wouldn't a texture.Copy(texture, coordinates,intrect) be the fastest way to go about this?

Also, it seems like it would be compatible with earlier versions - and give users greater freedom in their coding.

[Haikarainen]

Why was this needed? This breaks ALOT of stuff for me :/ also my project has been on ice in waiting for SFML2 Release, and now this? WHY? youre breaking my heart......



...

What about tile-based games (think legend of zelda/shining force)? If you have a texture loaded into video memory with all tiles (like: dirt, grass, stone, entrance). Wouldn't a texture.Copy(texture, coordinates,intrect) be the fastest way to go about this?

Also, it seems like it would be compatible with earlier versions - and give users greater freedom in their coding.

Lol, i was really tired and cranky when i wrote that Been thinking about it and i really like this change! Will create  2darrays of bools to generate collisionmaps at resourceloading, this will give me way more freedom and also speed up gameplay and performance significantly!

[vidjogamer]

Is this supposed to cause the speakers to repeatedly beep?
Also it crashes and the file is in the application directory.

Code: [Select]


sf::Texture texture;
texture.LoadFromFile("green_128.png");


[Laurent]

Is this supposed to cause the speakers to repeatedly beep?
Also it crashes and the file is in the application directory.

Of course not... so please open a new thread and give all the required details.
http://www.sfml-dev.org/forum/viewtopic.php?t=5559

[vidjogamer]

Sorry. I actually deleted that test project. The code was really that simple though. Just initialization and a sound played on the LoadFromFile() line.

I believe that the strange behavior was a result of linking the libs wrong. Maybe linking to release from a debug build. That solved some other strange issues I had in another project, but I have not tested it here.

You would probably know more than I if that could cause such a problem?