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 - Hapax

Pages: [1] 2 3 ... 199
Graphics / Re: Alpha blendMode
« on: Today at 09:19:54 pm »
You could draw them all to a render texture first at full alpha and then draw the render texture with adjusted alpha. Wouldn't even need blend modes for this.

General / Re: Sprite rotation on tile map
« on: Today at 09:12:31 pm »
You want to match the sprite's position to the position it would've been inside the tile map after the tile map has been rotated?

Determine the position in the tile map that the sprite should be before rotation of the tile map and then use the tile map's transform to transform that point to where it will actually be when drawn.

Assuming that the sprite position would be (3, 3) of the tile map at each being 125x125, its "unlinked" position would be (3x125, 3x125) = (375, 375) and therefore it could be something like:
sf::Vector2f spriteLocalPosition{ 375.f, 375.f };
sf::Vector2f spriteGlobalPosition{ tilemap.getTransform().transformPoint(spriteLocalPosition) };

Remember that it's the local position within the tile map so position/translation, scaling etc. of the tilemap should not be included in the local sprite position.

If you need to find the local position of its current position, you can do the opposite process:
sf::Vector2f currentSpriteGlobalPosition{ 500.f, 500.f };
sf::Vector2f currentSpriteLocalPosition{ tilemap.getInverseTransform().transformPoint(currentSpriteGlobalPosition) };

You may want to use that in conjunction with the first one to "move" with the tile map (this bit would be first).

General / Re: BG & FG Level design ?
« on: July 13, 2020, 11:40:01 pm »
Using "tile maps", one can use smaller pieces as "building blocks" for the bigger picture, repeating small parts where they need to be. This is very similar to the approach of "instancing" in 3D - you basically start with a few types and repeat them in different places.

A simple grid-based tile map could look something like this (as an example):

(source: https://www.sfml-dev.org/tutorials/2.5/graphics-vertex-array.php#example-tile-map )
You can see that in that example, there are only four different "tiles" (small images) and they are repeated where needed to make up the level.

General / Re: Sorting a vector of rectangles
« on: July 13, 2020, 11:34:50 pm »
It will affect the order they are drawn, which you need to be aware of when objects overlap.

Also, don't forget to clear the window each time :P

General / Re: Weird Behaviour with tilemap
« on: July 13, 2020, 11:32:53 pm »
I think you need to decide how you wish to use the Tilemap class. You are creating it multiple times (every frame?) and use differing values to set it up.

tilemap.create(Vector2u(nTileWidth, nTileWidth), defMap, nLevelWidth, nLevelHeigth, Vector2u(16, 16), Vector2f(0.f, 0.f));

tilemap.create(Vector2u(nTileWidth, nTileWidth), drawMap, nTileVisX + 1  , nTileVisY + 1, Vector2u(16, 16), Vector2f(fOffsetX, fOffsetY));

Graphics / Re: Problem with slow VertexArray draw
« on: July 13, 2020, 11:26:31 pm »
You're welcome. Glad it helped.

Remember that constantly creating, destroying and relocating memory can be a bottleneck if done a lot in every frame. A simple solution is to create the object in memory - preferably the maximum size from the start - at the start and only change it in the loop. By change, I mean modify the elements - not add or remove elements. You can even only use some of the elements and ignore others to avoid resizing.
If you absolutely must change the number of elements/change memory, consider allocating an amount of memory first for the maximum amount it will need.
e.g. std::vector::reserve

General discussions / Re: Using opengl
« on: July 13, 2020, 11:18:12 pm »
Apologies. I intended to mention the use of direct OpenGL in tandem with SFML in your game!
Does the "remake" use SFML exclusively and does it still have 3D elements?

Graphics / Re: Drawing text immediately crashes
« on: July 12, 2020, 11:18:04 pm »
Are you sure that the font is loading successfully? You aren't checking its return value. If the font doesn't load, you're asking the text to draw using an invalid font.

General discussions / Re: Using opengl
« on: July 12, 2020, 11:13:54 pm »
Hi! :)

It's likely that it's the capture software that is showing lag. Without using OpenGL directly, 2D can be done (just as) smoothly using just SFML (yes, SFML uses OpenGL itself).

You can skip or duplicate pixels to resize images but there are simpler or better ways.

A simpler way would be to create a render texture, draw the sprite onto it while using its scale to adjust size, and then transferring the render texture's texture to an image.

"Better" ways would involve manually calculations which take into account "sub-pixel" positions, whether that be - for example - by multiple samples or by first converting the pixels to rectangles.

Graphics / Re: Problem with slow VertexArray draw
« on: July 12, 2020, 10:38:41 pm »
It doesn't look like it's the draw method that's the problem, rather the ShowVisual method in general.

If you really want to know whether it's the draw method or not, remove the draws from that method and check ;D

ShowVisual does a lot of things. A couple of things that could be made more efficient:
1) don't create the vertex arrays every time. Store it and manipulate it in the method. Vertex arrays are wrappers around std::vectors so if the memory is being created and destroyed every time.
2) don't create the text every time. Although texts are generally quite lightweight objects, changing the font or its size could cause it to re-render the font for its size - a relatively slow process. Create the text outside of this method and store it. If it changes, change it once when it does, not every frame.

Also, I don't know what Block_Base is but you are looping and creating a lot of them in that method. Similar to the vertex arrays, when you add an item to it, it has a chance of having to resize the memory block and move the entire thing. This could happen multiple times in just one call of ShowVisual.

Hope this helps :)

Graphics / Re: Enemies path following
« on: July 09, 2020, 10:23:03 pm »
Honestly, I'm not sure what you're having a problem with.

Related to this small piece of code, I have to say that is sometimes given me problems because getting closer to the next point becomes difficult as the higher the speed of the enemies is.
Which problems? What is difficult?

Is there any other way to be more accurate on path following independtly of the enemy speed?
What do you mean by "accurate" here?

Audio / Re: Audio output only on one channel
« on: July 09, 2020, 10:16:44 pm »
My only other suggestion that I can think of at the moment is probably too obvious that you've checked this already (if it applies) but do you have any outboard effects (between card and speakers) and are they switched off/turned fully dry?

Other than that, I'm not sure what else to suggest. Sorry :-[

Audio / Re: Audio output only on one channel
« on: July 08, 2020, 10:20:07 pm »
That seems correct too. It looks like this is a sound card/driver issue to be honest.

Do you have any global "environment" effects? e.g. reverb.

Is your speaker setup identical to what the driver thinks it is? e.g. headphones for headphones, 2-channel for 2 speakers, 5.1 for 5 speakers and subwoofer. It could be mixing surround sound into fewer channels or vice versa.

Audio / Re: Audio output only on one channel
« on: July 08, 2020, 01:04:07 am »
Rather than create a stereo buffer with one channel as silence, you could create a mono buffer from that stereo buffer. Or, create two from it and control them separately.
You should note that spacial positioning only applies to mono sound sources; stereo sounds are always stereo (I'm guessing this is where you're finding some error).

I've already given an example that shows how to split a stereo SFML sound buffer into two mono SFML sounds buffers. You can find that here:

That said, you seem to already understand how to create a buffer from scratch. Try just a mono buffer (1 channel) and the move it's position in space to the left (as you mentioned).

Pages: [1] 2 3 ... 199