Tag Info

New answers tagged

0

Answer by OFE in StackOverFlow: You will need to perform transformations to the texture co-ordinates yourself, you could do this in one of four places: -Apply the transformation to your raw model data. -Apply the transformation in the CPU (not recommended unless you have good reason as this is what vertex shaders are for). -Apply the transformation in ...


0

Your problem is most likely the fact that you create copies of your blocks when adding them to your vector. That way once the original copy/block is destroyed, the texture won't be valid anymore (since there's a shallow copy happening, so even the new copies still point to the old texture, despite having their own copy). As a potential fix, change your ...


0

I am the guy who asked this question. When I asked this question I didn't knew much about sprites and textures, but then I learned quite a lot from the internet and sfml tutorials. Actually what I was doing in the program was not correct. I was storing the texture in a local scope which was getting destroyed at the end of the scope. Textures should be stored ...


0

The simplest solution is to keep textures in World class, like this: class World { public: World(); void draw(sf::RenderWindow *window); vector<Block> blocks; private: int level[12][16]; int wd; int hi; sf::Texture Texture; }; And definition: World::World() { if ...


0

If you are doing webgl and can make pixel shaders, check out signed distance textures. They are textures but scale like vector graphics. http://blog.demofox.org/2014/06/30/distance-field-textures/


1

So the short answer to my own question is, "Yes." The long answer is... Using Metal—and, I assume, OpenGL ES—you can create no-copy data buffers from memory-mapped files on disk. From there, you can create textures from those buffers. There are constraints, however, in that the texture data must be an uncompressed pixel format, can only have one mipmap ...


0

A quick test, just grab the logo image from the SFML site and paste it into the working directory of your project (or just somewhere simple and explicitly state that in code i.e. "C:\test\img.png") #include <vector> #include <iostream> #include <SFML/Graphics.hpp> int main() { sf::Texture texture; if ...


0

You appear to be correctly storing a texture and then setting that texture to a sprite, so I don't think the White Square problem they're referring to in the documentation applies to you in this situation as you don't have the texture being created in a local function scope etc. std::vector<T>::push_back() creates a copy of the argument and stores it ...


0

For my system I use a spritesheet with 16 tile variations on it. Upon creating a tile type I cut up the texture into regions specified in the constructor (which means my tiles can have varying resolutions). That means you can provide it with an image like this http://www.promagra.de/Downloads/Platformer/Pl5t.png and the transitions will take care of ...


0

Think about having only one final Tile class and it defines only the data needed to render and update like the id of the Sprite or TextureRegion public class Tile { private int type; private int spriteId; some other data that you need and that belongs to a Tile ... public int getType() { return type; } public int ...


0

Turns out, the png file doesn't have any background (I expected there to be a white background behind the flag image). This is how Unity handles textures when the texture file (PNG) doesn't have a background. Get a white background in the texture file and you're good to go.


0

If you are sure you want to keep it around, you can call DontDestroyOnLoad. See http://docs.unity3d.com/ScriptReference/Object.DontDestroyOnLoad.html If you set that, it will not be destroyed when the scene loads. Keep in mind that you are now explicitly in charge of destroying that object, as it won't otherwise go away. I would therefore make sure to track ...


2

Unity is pretty smart about keeping stuff around that you need in the future. What's more difficult is telling it when to get rid of stuff you don't need anymore. So yes, once this texture is loaded, it will recognize that and not load it again provided something hasn't removed it from memory in the meantime.


0

Having all Tiles be Actors that draw their sprite in the Actor's draw() call is an option. Of course there are many ways to draw a map, but this definitely is one of them. However I would warn against using Sprites. Since you said all tiles are 16x16px you will likely have very many of them in each level of your game. This would mean that you would have ...



Top 50 recent answers are included