46
Graphics / Re: Shaking the Camera
« on: January 31, 2020, 07:34:17 pm »
GDC is really good source:
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.
47
Graphics / Re: Drawing points
« on: September 09, 2019, 09:56:14 am »
You can use quads instead of points.
48
General discussions / Re: Advice on "actually" making games with SFML?
« on: August 16, 2019, 10:37:44 am »
Make a simple game engine with managers, scenes, GUI.. and create the own tools (simple animation system, GUI) or interface for existing tools like Spine, parcticle editors. You can improve anything in next project.
You can use another languages than C++, with readable syntax, that allows you to think more globally and which are more bulletproof.
You can use another languages than C++, with readable syntax, that allows you to think more globally and which are more bulletproof.
49
General / Re: Is this Efficient (sf::RectangleShape vs tilemaps) ??
« on: July 31, 2019, 09:51:38 am »
Rectangleshape = 1x vertexarray = 1x draw call. If you draw whole 10x10 tilemap then you have 100 vertexarrays = 100 draw calls.
If you use one vertexarray for whole tilemap it's only 1 draw call => better performance.
If you use one vertexarray for whole tilemap it's only 1 draw call => better performance.
50
Graphics / Re: Why does my tile draw a way darker color than the rest of my tiles?
« on: July 16, 2019, 11:52:53 pm »OpenDoor Renders really dark and unseeable almost just faintly but OpenDoorRotated renders as would be expected
These two files also have different PNG format, it's clear from file size.
51
Graphics / Re: SFML and Game time
« on: November 21, 2018, 12:38:55 pm »applyLogicAndPhysics(deltaTime * 0.5);
This seems working fine. I found one thing, sf::Texture::setSmooth = false (GL_NEAREST) causes some rounding and it also affects sprite movement, "it's jumping by integers". With GL_LINEAR it's smooth even on low update rates / lower multiplier.
Quote from: Hapax
Another way is to use a clock in which the speed of time can be changed. I'll mention Kairos' Timestep
..
You could change only the speed of the clock, which means that the same delta time takes longer so might update more jerkily at slower speeds but updates logically identically, or change the speed of the clock and scale the delta time used to match, which means that the updates takes the same amount of actual time and can be more smooth at slower speeds but updates are logically different since the timestep has now changed.
In both cases it's still tied with system time (lockstep, amount of game time elapsed per tick is constant)? Anyway I will test it.
52
Graphics / Re: SFML and Game time
« on: November 19, 2018, 05:51:48 pm »Some pseudo code for an implementation of fixed timestep:deltaTime = 0.1 seconds
while (windowIsOpen)
{
currentTime = clock.currentTime
timeToProcess = timeToProcess + currentTime - previousTime
previousTime = currentTime
while (timeToProcess >= deltaTime)
{
applyLogicAndPhysics()
timeToProcess = timeToProcess - deltaTime
}
prepareDisplay()
drawDisplay()
}
One question here.
In RTS games like SimCity or Age of Empires player can change game speed by changing deltaTime. World simulation can run 0.5x slower (1/15), 1x - normal speed (1/30) or 10x times faster (1/300). Thats right approach if I'm not wrong.
But what with rest of logic - some GUI updates, smooth camera movement (1/60), determine which object is under cursor (1/10). They should be outside world simulation but also they need some limitation - not to burden the CPU, not move too fast (camera). Can I just use more fixed updates (in row) like the one above or what is propper way?
53
General discussions / Re: SFML 2.5.0 released
« on: November 01, 2018, 08:02:44 am »
+1 for CSFML 
unfortunately I can not be useful, C/C++ is not my language
unfortunately I can not be useful, C/C++ is not my language
54
SFML projects / Re: ALAGEngine - 2.5D Isometric Shading Engine
« on: March 09, 2018, 11:40:42 am »
Is there big performance drop if you have more objects in scene?
55
General / Re: Gamestates - in which order?
« on: February 19, 2018, 01:12:00 am »
It depends on your game loop. The basis is not to have any complex code in the draw procedure. So you can put spawning into update phase or make some event queue.
56
General / Re: Image of Sprite Skipping on Screen
« on: February 16, 2018, 10:14:24 pm »
Ok, no problem. Forget about it because it's not C/C++ language (I'm using Pascal bindings). I can give you the source codes but without compilation you can't test it
57
General / Re: Image of Sprite Skipping on Screen
« on: February 16, 2018, 09:57:46 pm »
@Kondie
I'm not sure if Pioneers game have smooth scrolling or sprite movement. Don't take it as benchmark.
I have similar problems with my projects, sometimes when I run exe there is really bad tearing without any reason. But mostly it's ok (AMD RX480).
I sent you PM, if you can test it. I'm just curious.
I'm not sure if Pioneers game have smooth scrolling or sprite movement. Don't take it as benchmark.
I have similar problems with my projects, sometimes when I run exe there is really bad tearing without any reason. But mostly it's ok (AMD RX480).
I sent you PM, if you can test it. I'm just curious.
58
General / Re: Using multiple views for level and entities
« on: February 01, 2018, 07:12:19 pm »
But now it's more functional I think. You can use normal math for game logic (e.g. collisions) instead of some conversion from one view to another.
You should definitely have a basic ratio for graphics, if you want same graphics quality for everything just have objects (sprites, textures) in their real/natural sizes. Then scale your object to needed dimensions but not through View, use setScale for sprites. For example if you need small rock and big rock.
Mixing different ratios and values does not work. You can't have tile with 16x16 pixels and player with 200 x 200 pixels (in world math). Tiles must be in right ratio mathematically. You can map 16 x 16 texture on them or use texture with better resolution, it does not matter anymore.
Shortly:
Dimensions of objects in the game world must have right proportion. Player vs house, vs wall, vs dog. And graphics (textures, sprites) can be eventually scaled to these dimensions.
You should definitely have a basic ratio for graphics, if you want same graphics quality for everything just have objects (sprites, textures) in their real/natural sizes. Then scale your object to needed dimensions but not through View, use setScale for sprites. For example if you need small rock and big rock.
Mixing different ratios and values does not work. You can't have tile with 16x16 pixels and player with 200 x 200 pixels (in world math). Tiles must be in right ratio mathematically. You can map 16 x 16 texture on them or use texture with better resolution, it does not matter anymore.
Shortly:
Dimensions of objects in the game world must have right proportion. Player vs house, vs wall, vs dog. And graphics (textures, sprites) can be eventually scaled to these dimensions.
59
General / Re: Using multiple views for level and entities
« on: February 01, 2018, 06:27:01 pm »
Simple way:
- 1 system of coorinates for all your world elements - tiles, characters, items and also for player position
- change player.x, player.y when is player moving
All this should be 1 camera (levelView), now just use levelView.setCenter( player.x, player.y );
Then you do not have to worry about the positions of entities or about mixing views somehow.
- 1 system of coorinates for all your world elements - tiles, characters, items and also for player position
- change player.x, player.y when is player moving
All this should be 1 camera (levelView), now just use levelView.setCenter( player.x, player.y );
Then you do not have to worry about the positions of entities or about mixing views somehow.
60
General / Re: Using multiple views for level and entities
« on: February 01, 2018, 05:58:06 pm »
Sorry, I read it badly
You can change player position instead of levelView position and set levelView center to player position. So it will be virtually the same.
You can change player position instead of levelView position and set levelView center to player position. So it will be virtually the same.