Messages

211

General / Re: How would i make the games logic

« on: November 29, 2017, 11:47:29 pm »

Check out the SFML game development book

https://www.packtpub.com/game-development/sfml-game-development

It walks you through making a simple game from start to finish

212

Graphics / Re: TileMap show artifacts

« on: November 29, 2017, 02:33:52 pm »

This is quite a common problem and there are a few other posts about it:

https://en.sfml-dev.org/forums/index.php?topic=15338.0
https://en.sfml-dev.org/forums/index.php?topic=6665.0
https://en.sfml-dev.org/forums/index.php?topic=19821.0

The most effective fix I've found is to use a shader to draw the tiles, which is explained here:

https://github.com/SFML/SFML/wiki/Source%3A-ShaderTileMap
http://www.the2dgame.com/index.php?page=articles&ref=ART8

213

SFML projects / Re: Screenshot Thread

« on: November 25, 2017, 11:22:03 am »

I can see a lot of Bubble Bobble inspiration in there.

Hah, yeah well it did start off as a straight up cone, only with networked multiplayer. It's grown a bit since I started using my own artwork (though there's still some OGA in there) and added the crate mechanic from my Crush game.

214

SFML projects / Re: Screenshot Thread

« on: November 24, 2017, 08:32:02 pm »

A little retro themed arcade type game I've been working on:

215

SFML projects / Re: AchBall

« on: November 04, 2017, 10:53:48 pm »

I have to point out that, although it looks like a really good game, the title in english sounds a lot like ball ache which is uh... not so good :S

216

Window / Re: View -> Fullscreen Window. How to apply empty margin?

« on: October 27, 2017, 12:16:20 am »

This wiki entry should point you in the right direction:
https://github.com/SFML/SFML/wiki/Source%3A-Letterbox-effect-using-a-view

217

General / Re: Jump Code

« on: October 08, 2017, 11:23:56 pm »

Check out the Sonic Physics guide
http://info.sonicretro.org/SPG:Jumping

It has loads of really useful info on platform physics It's worth noting that gravity isn't 'activated' at some point in the jump - it's applied all the time the character is in the air.

218

Graphics / Re: Need help with collision and gravity

« on: October 01, 2017, 11:35:10 am »

Have a look at this post I made a while back
http://trederia.blogspot.co.uk/2016/02/2d-physics-101-pong.html

It describes calculating the collision 'manifold' which tells you the direction of a collision. It also contains some examples at the bottom written in sfml

219

Graphics / Re: [SOLVED] White square problem using vector<Texture>

« on: September 27, 2017, 02:01:04 pm »

I think it's worth noting that if you're using a vector of textures a call to push_back() may cause it to resize. When this happens the existing textures will be moved around in memory (probably using some fairly heavy copy operations due to the way sf::Texture is implemented) and invalidate existing pointers, returning you to your white square problem. Take a look at how the resource manager is implemented in the sfml game development book, it has served me well for many years

https://github.com/SFML/SFML-Game-Development-Book/blob/master/02_Resources/Include/Book/ResourceHolder.hpp

220

Graphics / Re: creating a decent camera movement

« on: September 17, 2017, 10:12:32 pm »

dt or 'delta time' ie the time difference between frames, is derived from the assumption you're using something along these lines: https://gafferongames.com/post/fix_your_timestep/

221

Graphics / Re: creating a decent camera movement

« on: September 17, 2017, 05:07:50 pm »

Something like this:

Camera::update(float dt)
{
    sf::Vector2f movement = player.getPosition() - camera.getPosition();
    camera.move(movement * dt);
}
 

If you do that every frame the camera will move slightly closer to the player (1/60th of the distance or whatever your delta time is) which means the next frame the distance will be smaller if the player is not moving, slowing down the camera. The smaller the distance the slower the camera movement, until eventually it reaches the player position (you might have to clamp it within a few pixels here) and the camera stops moving. This will give a nice deceleration as the camera reaches its target. The target does not necessarily have to be the player position, if you want the player to be able to move within some sort of bounds without the camera moving you can set the target position to be the point at which the player intersects those bounds.

222

Graphics / Re: creating a decent camera movement

« on: September 17, 2017, 12:31:12 pm »

Try moving the camera by the distance between it and the player multiplied by the frame time. It'll move faster the further away it is, decelerating smoothly as it gets closer to the player.

223

General / Re: Ping Tutorial Question

« on: August 26, 2017, 10:14:14 am »

For the state stack it's understandable to use heap allocation as it stores the states as pointer to base class - although modern C++ would prefer a smart pointer (aka RAII) which can be stored in a vector using std::move() and takes care of the new/delete problem. Members such as font and text have no need for heap allocation, and can be initialised via the constructor's initialiser list rather than using double initialisation (which is still true even if you do decide to use smart pointers). It seems unusual to write 'this' everywhere (to me at least), although it appears to be a preference thing - many people instead prefix members with m_ or _. If you can, check out the first SFML game development book, it has a great example of a state stack, and is probably the best of the bunch.

224

General / Re: FPS issue

« on: July 14, 2017, 10:41:41 am »

The main bottleneck is often the number of calls to draw(). 6000 of them is going to be slow. A vertex array allows you to group geometry together into a single array of data, for which you only need to call draw() once. You can read about them here. Bear in mind, however, vertex arrays can have their own problems such as this.

225

Graphics / Re: Get texture from sf::Text object

« on: July 06, 2017, 05:53:59 pm »

Use the getTexture() function of the sf::Font associated with the text.

https://www.sfml-dev.org/documentation/2.4.2/classsf_1_1Font.php#a887368a4e6a3dfa32dea89d2af315951