Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Sqasher

Pages: [1] 2
Feature requests / Re: Mipmapping for OpenGL texture creation?
« on: April 25, 2014, 12:55:23 pm »
I did a little bit of research and found out that mipmaps are a good thing in general, but can look blurry when used, because they are build by averaging the pixels. Also for good results with non power of two textures or arbitrary scales, you must use polyphase filters.

Possible solutions for the blurriness are:
- Use premade mipmaps
- Use a sharpening algorithm like the Kaiser filter: Mipmapping, Part 1  Mipmapping, Part 2
- Modify the mipmap bias (GL_TEXTURE_LOD_BIAS) http://www.opengl.org/registry/specs/EXT/texture_lod_bias.txt
- Don't use mipmaps

http://forums.tigsource.com/index.php?topic=26733, http://developer.nvidia.com/content/non-power-two-mipmapping

Window / Re: Unresolved External on changing Window Size
« on: April 14, 2014, 01:36:41 am »
The code seems fine to me. That error is definitely a linker error. See here:
Linker Tools Error LNK2019

Maybe you are using Visual Studio 2013 and downloaded the libraries from the website? Then you would need to compile SFML yourself.

General / Re: A way to cobble sprites?
« on: April 09, 2014, 11:03:05 pm »
It's the simplest way of doing it.

If you want to keep the textures seperated, you could "stitch" them together at runtime. So when the game starts you load all texturefiles, build a big texturefile out of them and use that in combination with a vertex array. You can use the copy function of sf::Image for that. Minecraft uses this approach too.

Graphics / Re: Trying to implement a shockwave shader using sf::Shader
« on: January 18, 2014, 10:59:09 pm »
You convert the int to float in the shockwave fragment shader anyway:

float x = in_Center.x / float(in_WindowWidth);
float y = (float(in_WindowHeight) - in_Center.y) / float(in_WindowHeight);

Also, graphics cards are made specifically for floating point calculations and can be slow in integer calculations. So I think this won't be added to SFML.

Graphics / Re: Weird lines in particle test
« on: December 01, 2013, 09:03:06 pm »
I'm using MinGW 4.8 32bit on Windows 7 with a nVidia GeForce GTX 680 and the latest drivers.

I commented the music part out, but that shouldn't make any difference.

This code should give you a completely white window:
#include <SFML/Graphics.hpp>

int main() {
        int windowWidth = 800;
        int windowHeight = 600;

        sf::VertexArray vertices(sf::PrimitiveType::Points);

        for (int y = 0; y <= windowHeight; ++y) {
                for (int x = 0; x <= windowWidth; ++x) {
                        vertices.append(sf::Vertex(sf::Vector2f(x, y), sf::Color::White));

        sf::RenderWindow window(sf::VideoMode(windowWidth, windowHeight), "Test", sf::Style::Close);

        while (window.isOpen()) {
                sf::Event event;
                while (window.pollEvent(event)) {
                        if (event.type == sf::Event::Closed) {

        return 0;

Graphics / Re: Weird lines in particle test
« on: December 01, 2013, 06:35:04 pm »
I don't have those weird lines, so it could be a driver issue.

If you don't want the particles to form a yellow block, you can increase the spawning area and the lifetime and decrease the number of particles.
ParticleInfo[a].LifeTime = RandomizeInt(15,40);
ParticleInfo[a].X = ParticleInfo[a].X + RandomizeInt(0,20) - 10;
ParticleInfo[a].Y = ParticleInfo[a].Y + RandomizeInt(0,20) - 10;

Graphics / Re: Unknown problem with drawing.
« on: November 25, 2013, 08:03:17 pm »
Third,  what global variables?

Line 7 in SFMLApp.cpp:
TextureManager* SFMLApp::textureManager = new TextureManager();

As for the "unnecessary" include files... what's unnecessary about them? I can't very well use an SFML class without including the appropriate header...

Just include what you need. If you need the RenderWindow, you include <SFML/Graphics/RenderWindow.hpp>. If you need a Sprite, you include <SFML/Graphics/Sprite.hpp> and so on.

It makes the include part look longer and it takes time getting used to, but it speeds up the building process.

and yes, the Init() method, rather than a constructor was necessary... how else do you expect me to return a boolean value to tell the Execute() method whether or not the window was properly initialized?


But back to the topic:
Try to print out the scale, position and size of the tile your mouse is hovering over or even put the whole tilemap into a text file. Then investigate which variable is wrong. I could even imagine that there are tiles with no texture over the actual tiles.

P.S.: Nexus is right, your map generation algorithm is short, but complex and error-prone. Look here or here for some ideas.

General / Re: missing sfml-graphics-2.dll
« on: November 15, 2013, 11:22:33 pm »
If you want to link dynamically you link to sfml-graphics, sfml-window, sfml-system, sfml-audio, sfml-network and put the .dlls into the directory of the executable. For the debug version you link against the -d libs and put the -d.dll files into the directory.

If you want to link statically you only link to sfml-graphics-s, sfml-window-s, sfml-system-s, sfml-audio-s, sfml-network-s. For the debug version you link against the -d libs.

Don't mix static and dynamic linking.

Just google:


Note that the 64-bit tools are not available on the Express versions by default.

Graphics / Re: Antialiasing of pixel art.
« on: September 21, 2013, 09:15:15 pm »
Before you do that, have you tried setting the antialiasingLevel with sf::ContextSettings? Or does that also give you a blurry mess?

Graphics / Re: Antialiasing of pixel art.
« on: September 21, 2013, 05:57:28 pm »
There are some anti-aliasing shaders like fxaa or smaa, but I don't know if they work with SFML.

Graphics / Re: Lightening Effect
« on: September 09, 2013, 05:53:22 pm »
A google search for "algorithm for lightning" turned up this:


That should give you an idea how to begin.

Why would you store 340 textures in memory if they are exactly the same? 339 of them are basicly useless.

You could use a map and load the texture only once. If it doesn't exist you load it. If it does, you just return a pointer to the texture.

Graphics / Re: sf::Triangles pixel accuracy
« on: July 28, 2013, 10:28:06 pm »
I think SFML uses grid coordinates, not pixel coordinates. (Otherwise the tutorials would be wrong  ;))
Here is a good explanation.

Graphics / Re: sf::Triangles pixel accuracy
« on: July 28, 2013, 01:47:36 pm »
You know that your texture is 28 x 33 pixels instead of 27 x 32?

Pages: [1] 2