Messages

1

Graphics / Re: How do I implement smooth scrolling? (example inside)

« on: March 05, 2013, 05:44:44 am »

Maybe the problem is my graphic card

Yes, it is. I have a Radeon HD 4200, and no matter what I do, it's simply impossible to achieve smooth interpolation with it. After trying out all the various fixed timestep/smooth scroll algorithms I could find, and still failing to do smooth scrolling/movement, I decided to try out some commercial games. It was a good idea, because all of them had this issue, both 2D and 3D games, with both OpenGL and Direct3D.

I can turn on VSync, but the ATI driver developers thought it wouldn't be fun if this would just work, so they messed this up as well to constantly generate 90% CPU load, even when the app does nothing but displays an empty window. (Again, not an SFML issue, because this happens with all 3D apps.) But then it seems they've "fixed" this for the 4500 so you can't even turn on VSync...

But, at least, they release hardware specifications and some code to the open source community, and this is a good thing. Under Linux with the open source ATI driver, everything works perfectly. I'm not sure why they can't do this under Windows.

2

General / Re: Grid-based sprite movement

« on: November 07, 2012, 08:05:22 pm »

Thank you all, I'll try to implement something based on your suggestions as soon as I have some time again. 

3

General / Grid-based sprite movement

« on: November 07, 2012, 04:56:35 pm »

Hello all,

Well, I think it's not specifically related to SFML, but I'm sure that some other beginners might run into this problem as well, so at least it's not completely off-topic...

Since my game world is constructed from square tiles, I want all the actor sprites to move tile by tile, not pixel by pixel. Well, just moving them by jumping from one tile to another is easy, but I don't know how to translate them smoothly, just like in basically all 2D RPGs. So even if a movement key is pressed and released immediately, the sprite would smoothly "walk" to the next tile, not just move by a few pixels and stop immediately when the key has been released.

Does anybody know a tutorial about this, or have some code to share? The only tutorial I've found was implemented in XNA, and didn't even work on my machine... Thank you in advance!

4

General discussions / Re: [Idea/Request/Question] SFML platformer tutorial

« on: September 24, 2012, 10:31:45 pm »

Well, tilemap engine should include 2d container engine, culling engine, vertex array engine, texture engine, ect. 
But seriously just culling tiles out of veiw, loading and drawing.

...and there is not a single tutorial or example about this. All the tile loader/display systems I could find in this forum (apart from a seemingly abandoned and incomplete one) uses sprites to represent tiles, which later turned out to be a complete waste of resources, but no one seems to be aware of this.

And this is not something you can just figure out by looking at the documentation or the examples that comes with SFML, no matter how experienced C++ programmer you are.

5

General discussions / Re: [Idea/Request/Question] SFML platformer tutorial

« on: September 24, 2012, 06:02:38 am »

Although I doubt we need a "Creating a platformer from the ground up" tutorial on the wiki, I agree that SFML needs some more specific tutorials.

For example, a tutorial about the basic principles/implementation of an efficient tile engine. Tile engines are versatile, and are the core of many 2D games, yet there are no tutorials about how to create a vertex array based tile engine with SFML. A working example can be put together after searching this forum, but it could take quite a few trial-and-errors to figure out how exactly it works.

6

General discussions / Re: Comparison SFML vs SDL -> GUI and OGRE3D

« on: September 22, 2012, 04:22:17 pm »

So you wanted to use SFML to handle input in your Ogre-based application?

In this case, you're doing it wrong. OIS is very well integrated into Ogre since many years, and is considered to be the de facto input system for OGRE. It even comes with the Ogre SDK. It is used in almost all Ogre games. It is more sophisticated than SFML's input system (since it's only purpose is to handle input), and supports many "exotic" devices.

Save yourself from a lots of (pointless) work, and just go with OIS. If you're experiencing some issues with it, head to the Ogre forum and report it there. The main OIS developer (pjcast on the Ogre forums) used to be a member of the Ogre development team, and although he retired now, there are many OIS-experts there.

7

General discussions / Re: Comparison SFML vs SDL -> GUI and OGRE3D

« on: September 19, 2012, 06:33:04 am »

I don't really get what's the problem with the input system. Although haven't tried it myself, I've seen people using SFML for rendering and using OIS for input handling. OIS is engine/framework independent, you can even use it with text-mode applications if you want.

But, think about it. SFML already has its own input system, designed and developed by the same developer who did the library itself, so unless you need to use some really special input device (PS2/PS3/XBox(360)/Wii controllers, steering wheels, etc.), don't make your life harder and just use the input system that comes with SFML.

8

Graphics / Re: Drawing things on viewport

« on: September 19, 2012, 03:59:04 am »

Thanks, although I've gone a different way, I've found out that this is explained in View.hpp: set up the camera, draw the things that are supposed to be observed through the camera, then use renderWindow.setView(renderWindow.getDefaultView()) to return to the default view, then draw the things that are supposed to be drawn on the screen.

9

Graphics / Drawing things on viewport

« on: September 18, 2012, 06:28:54 am »

Hi all,

Is there a way to draw text/sprites onto an sf::View? I use the view as a camera, instead of scrolling the game map, I move the viewport. But when I try to display some text, it will be drawn on the map, not on the viewport, and it will go out of sight when I move the camera. Or do I have to transform the text element(s) at the same speed and in the same direction as the viewport itself?

10

General / Re: Animated tiles

« on: September 17, 2012, 05:12:08 am »

Yes but you're covering the old quads with new ones instead of removing the old ones(which is going to be hard if you have holes between quads in your vertexarray).

Although I completely abandoned the idea to use vertex arrays for the animated tiles, I can't sleep because of this. 

In what way did I cover the old quads? When the tile index is zero or 29, it hasn't been created at all on the first pass, so with my test app, there were no quads created at all and the array was empty. Then, at the second pass, the parser iterated through the map again, and only rendered tiles with ID 29. So in the end, these were the only quads created.

I'm not professional, I don't have animated tiles in ee(I might consider it but it'd mean api breaking changes to several classes), and it's open source release is not happening anytime soon.

Okay then, the sprite based system will stay for a while...  (Unless I learn how to properly use SFML.)

I might write example of my approach to that tomorrow.

Now that would be great.

11

General / Re: Animated tiles

« on: September 17, 2012, 01:57:32 am »

That's it, I'll go with the sprite based approach. Using vertex arrays/polygons/quads are certainly beyond my current capabilities. I'll wait until you release your Eduard Engine as open source so I can look at how the professionals do it. Until that, I just won't render oceans using animated sprites.

On a side note, I just started up a game that was made with RPG Maker 2000 (which is written in Object Pascal/Delphi (so there's no extreme Assembly-optimization), and uses no hardware acceleration at all (dates back to 1996 when 3D-capable cards were very expensive), and used to run fine on a (definitely) non-3D S3 card back then). There is a map which is filled with animated water tiles, yet the system is able to keep running at constant 60 FPS, so I honestly don't know why wouldn't this approach work in SFML.

12

General / Re: Animated tiles

« on: September 17, 2012, 01:15:20 am »

I believe you, but still not sure when I need to clear them. Since there are no memory leaks at exit (at least neither Visual Leak Detector nor the integrated MSVS debugger found any), it seems that SFML cleans them up automatically.

13

General / Re: Animated tiles

« on: September 17, 2012, 12:10:29 am »

Just appending. When/why should I clear them?

14

General / Re: Animated tiles

« on: September 16, 2012, 11:21:24 pm »

I've made a little experiment, and came up with this:

for(int x3=0; x3 < layer_width; ++x3)
{
        for(int y3=0; y3 < layer_height; ++y3)
        {
                if(Layer2->GetTileId(x3, y3) != 0 && Layer2->GetTileId(x3, y3) != 29)
                {
                        int currentTile3 = Layer2->GetTileId(x3, y3);
                        int tx3 = currentTile3 % horizontalTiles;
                        int ty3 = currentTile3 / horizontalTiles;

                        Array2.append(sf::Vertex(sf::Vector2f((x3 + 0) * tile_x, (y3 + 0) * tile_y), sf::Vector2f((tx3 + 0) * tile_x, (ty3 + 0) * tile_y)));
                        Array2.append(sf::Vertex(sf::Vector2f((x3 + 0) * tile_x, (y3 + 1) * tile_y), sf::Vector2f((tx3 + 0) * tile_x, (ty3 + 1) * tile_y)));
                        Array2.append(sf::Vertex(sf::Vector2f((x3 + 1) * tile_x, (y3 + 1) * tile_y), sf::Vector2f((tx3 + 1) * tile_x, (ty3 + 1) * tile_y)));
                        Array2.append(sf::Vertex(sf::Vector2f((x3 + 1) * tile_x, (y3 + 0) * tile_y), sf::Vector2f((tx3 + 1) * tile_x, (ty3 + 0) * tile_y)));
                }
                else if (Layer2->GetTileId(x3, y3) == 29)
                {
                        int currentTile4 = currentFrame;
                        int tx3 = currentTile4 % horizontalTiles;
                        int ty3 = currentTile4 / horizontalTiles;

                        Array2.append(sf::Vertex(sf::Vector2f((x3 + 0) * tile_x, (y3 + 0) * tile_y), sf::Vector2f((tx3 + 0) * tile_x, (ty3 + 0) * tile_y)));
                        Array2.append(sf::Vertex(sf::Vector2f((x3 + 0) * tile_x, (y3 + 1) * tile_y), sf::Vector2f((tx3 + 0) * tile_x, (ty3 + 1) * tile_y)));
                        Array2.append(sf::Vertex(sf::Vector2f((x3 + 1) * tile_x, (y3 + 1) * tile_y), sf::Vector2f((tx3 + 1) * tile_x, (ty3 + 1) * tile_y)));
                        Array2.append(sf::Vertex(sf::Vector2f((x3 + 1) * tile_x, (y3 + 0) * tile_y), sf::Vector2f((tx3 + 1) * tile_x, (ty3 + 0) * tile_y)));
                }
        }
}

(Just like last time, GetTileId(X, Y) returns the ID of the tile at position XY, Layer2 is the tile layer that is being parsed, and Array2 is sf::VertexArray Array2(sf::Quads).)

It kinda works, if the tile ID is zero or 29 , the quad is not being created. But at the next step, if the tile ID is 29, the quads are being created after the base layout has been parsed. Then, I can manipulate currentTile4 to change the texture coordinates. But I'm a bit concerned: won't this mess up the vertex array? (It's hard to examine how these quads look like withouth having a wireframe/point rendering mode, and my computer is fast enought to not to lag when something's wrong while rendering this few polygons.)

15

General / Re: Animated tiles

« on: September 16, 2012, 05:23:33 am »

What I'd do:
If they can be synchronized:
get main layer with all tiles
get few other layers each with all animated tiled changed to their next frame and holes for static tiles
draw main and then one of few others which gets updated somehow
If not sync:
same as above but during loading desynchronize the few other layers randomly

What do you mean by "synchronized"? Like having different animations playing at the same speed?

Yes but you'll just die keeping all the information to do that stored, organised and accessible.

So in the end, it would be easier to render them as sprites? Thinking about it, sooner or later, I'll need to implement some kind of visibility determination system to hide all the sprites (players and dynamic objects) that are not in the view. And if I do that, I think I can safely fill the screen with sprite-based tiles without slowing the system down.