next »

[Prads]

I haven't applied any up or down scaling. The texture is being displayed as it is without any scaling in orthogonal projection. I do however change the content of the texture every frame using glTexSubImage2D.

Thanks, I will swap them around...

Edit: I just realised maybe the opengl is not applying the filter because I am not scaling the image up or down. Since the image is displayed as it is, it thinks that it doesn't need to apply any filter. Is that a normal behavior of opengl?
In DirectX I could just tell it to apply linear filter and it would do it whether or not the texture is scaled, I just want that in opengl too...

[ThemsAllTook]

Yeah, filtering only applies when scaled. It's not meaningful when drawn 1:1 with the original texture size. What effect are you going for?

[Prads]

I want to have blurred (not too much blurred) kind of effect. I don't want it to look pixelated that's why I was using linear interpolation filter.

[Geti]

Sure, but linear interpolation for shrinking doesn't achieve much, since each pixel will be stepping much more than one texel (hence took's suggestion to use mipmaps). linear interpolation for no change in size achieves literally nothing because there is nothing to filter/interpolate - each pixel on screen will be a pixel of the texture!

You probably want to set up some sort of postprocessing shader or to simply use a smaller asset and scale it up a little; but your lack of understanding of what image interpolation settings do makes me wary of making suggestions beyond that :/

Screenshots of the kind of effect you would like to see would be helpful, as would a look at your assets.

[Prads]

Sure, but linear interpolation for shrinking doesn't achieve much, since each pixel will be stepping much more than one texel (hence took's suggestion to use mipmaps).

Mipmaps aren't what I need since the texture will never be scaled down and thus mipmaps is unnecessary.

linear interpolation for no change in size achieves literally nothing because there is nothing to filter/interpolate - each pixel on screen will be a pixel of the texture!

I don't want the pixel to be exactly like the pixel of the texture. I want it to be the weighted average of pixels that are next to each other so I can get that blur effect at the edges. I can do it myself by applying the filter using CPU but that's job of GPU and they do those things faster so I wanted opengl to do it for me...

Screenshots of the kind of effect you would like to see would be helpful, as would a look at your assets.

Here's is the example which is rendered using DirectX. First the one without linear filtering:

http://i.imgur.com/CeRS39T.png

Ok in the above screen shot I want you to look at the black ship which is in the middle of the screen with a red line in front of it. It's rotated and looks really pixelated. The edges of it looks rough. Also check out the bomb sprite on the top left part of the screen next to green bar, it doesn't look completely round and edges look rough too.

Now with linear filter applied:

http://i.imgur.com/sGCzUfK.png

In this screenshot, the edges of the black ship looks blurred and smoother than the previous one. The bomb sprite looks round and smooth too. I like how this screenshot looks and I want to keep this effect in opengl too...

[JakobProgsch]

Just offset your texture (coords) by half a pixel. That way your sample positions ends up "between" 4 pixels and you get linear filtering. In I think dx9 has that 0.5 pixel offset builtin per convention. Both are doing the same correct thing apart from the texture coordinate convention.

[Geti]

OpenGL is the one doing it correctly here as far as I'm concerned - you're rendering at 1:1 texel:pixel ratio.

You'll get smoothing like that if you offset the quads by half a pixel or something though, as seems to be happening in the second screenshot (put them side by side).

I understand that you don't want it to be exactly like the pixels in the texture, but until that post there was no indication of what you actually wanted beyond "smoother".

Either way, 3 options:

-Assuming you're using any "newish" opengl, you can make your fragment shader sample more than just the texel directly corresponding to the screen point. This will be done in parallel as the screen is rendered on the gpu and will be very quick, especially as you're just sampling from the one texture.

-If you just want "auto smooth" sprites you'd be better off rendering to texture upon loading your asset - using either the CPU or GPU to perform the "blurring". There will be no cost at render time, the cost will be amortized.

Would I be able to see what it looks like in the case provided with the rotated ship? That's the case where filtering should make a difference - it shouldn't on the map tiles.

(ninja'd, drat)

[Prads]

Awesome! Offsetting the texture coordinates by 0.5 pixel gave the desired effect. Thanks guys! :D

I had to go through this article to fully understand the problem: http://drilian.com/2008/11/25/understanding-half-pixel-and-half-texel-offsets/

If you just want "auto smooth" sprites you'd be better off rendering to texture upon loading your asset - using either the CPU or GPU to perform the "blurring". There will be no cost at render time, the cost will be amortized.

I am not sure if that would work since the pixelation happens when I rotate the sprite. For this to work I would have to rotate the image from 0 to 360 degree and apply filter for all those rotation and at the end I would have 360 copies of same sprite.

[ThemsAllTook]

It sounds like multisampling might do the job even better for what you want. It's a little bit cumbersome to set up, but the results are quite nice.

[JakobProgsch]

Multisampling in the usual sense only affects borders of polygons. It doesn't actually blur/antialias textures.

[DC]

Panda3D, I love that you made the effort to try to automatically handle wall and floor collision, but having objects cut through solid corners and not allowing any separation from the floor respectively just aren't gonna cut it. Time to roll my own collision code.

[InfiniteStateMachine]

Seems the best way to handle it would be to just do the blurring in the fragment shader. Is there a reason you wouldn't want to do that?

[Geti]

I am not sure if that would work since the pixelation happens when I rotate the sprite. For this to work I would have to rotate the image from 0 to 360 degree and apply filter for all those rotation and at the end I would have 360 copies of same sprite.

Have a look at the difference in the tiles. Filtering would handle the rotated cases better with an antialiased spritesheet. If you're happy with the result of half pixel offset sprites though then great.

Panda3D, I love that you made the effort to try to automatically handle wall and floor collision, but having objects cut through solid corners and not allowing any separation from the floor respectively just aren't gonna cut it. Time to roll my own collision code.

Afaik panda has a bunch of specific collision code that you'll have to set up (maybe there's simple automatic stuff on by default?); a friend of mine uses it for prototyping and I've seen him do some fairly physical things with it before. Make sure to read the documentation before rolling your own code and burning precious daylight. http://www.panda3d.org/manual/index.php/Collision_Solids

[DC]

Afaik panda has a bunch of specific collision code that you'll have to set up (maybe there's simple automatic stuff on by default?); a friend of mine uses it for prototyping and I've seen him do some fairly physical things with it before. Make sure to read the documentation before rolling your own code and burning precious daylight. http://www.panda3d.org/manual/index.php/Collision_Solids

Thanks for the tip, but I'm already using CollisionSolids. I just meant I'd have to make my own code using those instead of using a CollisionHandlerPusher for walls and a CollisionHandlerFloor for floors, since the special collision handlers are kind of lacking in a couple ways that I need them to work.

[Twinklebear]

Spent about two days trying to track down a bug with layered rendering in OpenGL where I'd only render to the first layer of the texture. Turned out that the issue was with gDEBugger not reading the entire texture properly but only the first layer which I found when trying to draw my own debug output quads (thus having to re-bind the default framebuffer) I saw the expected output both on my quads and in gDEBugger, and it seems like simply re-binding the default framebuffer fixes "something" with gDEBugger and it reads the full texture array back from OpenGL, showing the expected render.

So shadow mapping point lights is next

[sublinimal]

The weirdest bug of the year so far. Creating an instance of any class at all crashed my C++ program. I thought it was unbelievable at first, but there was an eerie consistency about it. The base entity inheritant crashed. The game state class crashed. And you better believe creating an SFML window crashed. Hell, at one point my program was literally

Code:

int main() {
    sf::Clock c;
    return 0;
}

...and even that was fatal.

At the brink of losing my sense of reality, a debugger revealed that all SFML constructors have their arguments shifted by one. Like when I say "sf::VideoMode vm(x,y)", the constructor should have the arguments (this, x, y), but the call stack says (x, y, <garbage>). As weird as that is, at least it explained where the problem came from, since all of my classes contained an sf::Sprite or other utility.

Only in C++ could one encounter a bug like this. I'm convinced it isn't anything I'm doing wrong because SFML 1.6 works just fine. (But I won't revert to that because 2.0 specifically has a feature I need.)

The SFML author's official response to people who've encountered this is "just recompile the library", but of course I can't get that to happen because Codeblocks complains about the cmake-generated Codeblocks project.

I really really hate wasting time on stupid tweaking like this. Just let me code, C++.

[ekun]

I really really hate wasting time on stupid tweaking like this. Just let me code, C++.

I know that feeling.

[Will Vale]

Sounds like a mismatched calling convention between the precompiled SFML DLLs and your compiler settings. If you search for "SFML calling convention" there are a few threads on this, but all the advice boils down to "recompile SFML"

e.g. http://en.sfml-dev.org/forums/index.php?topic=8320.0

What compiler are you using, and what was used to compile SFML?

Will

[sublinimal]

Sorry, neglected to mention - I did eventually manage to fix that. In case it helps someone else later, I ended up downloading the nightly builds.

As usual, it didn't end there, though. Despite getting things to compile, it wasn't exactly functional. Delving deeper into the debugging jungle, it seemed like my graphics card just plain didn't get along with the library. So I reinstalled drivers, tried to recompile with all possible combinations of settings and builds, and all of it was a waste of time.

In the end, I moved the project to a different computer altogether. The official SFML builds didn't work there either, so I went straight for the nightly builds. Stubbornly retracing all my steps so far, one particular configuration actually went through with no graphics card issues, so I finally got something on the screen again. At that moment, a marching band came by and played me a fanfare.

[ThemsAllTook]

How to be an asshole: When someone talks about a programming problem they're trying to solve, if it looks remotely similar to something that already exists, immediately jump into the conversation and say "don't reinvent the wheel". Make no effort to actually understand the problem that's being solved; assume the programmer has no idea what they're doing and insist they should be using your favorite existing implementation and that it will obviously fit their needs perfectly.

(sorry, had to let off a bit of steam)