2956
Graphics / Re: how to get pixel color ??
« on: September 12, 2014, 05:16:43 pm »
If speed is not an issue, it may be simpler to capture the window directly to an image. You will then have you image on which to use getPixel().
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.
2957
Graphics / Re: VertexArray, setTextureRect and setRepeated
« on: September 12, 2014, 05:11:51 pm »
Your question seems to be: "can you repeat texture rects instead of only being able to repeat the entire texture" and, after a quick scan of the docs, it doesn't look like that is possible.
2958
Graphics / Re: Creating a dynamic array of vertexArrays
« on: September 08, 2014, 02:08:07 pm »
zsbzsb is right; there isn't really enough information to know what problem you're actually experiencing.
That said, a couple of things you may want to consider:
1) update the current_array when you push a new one so that you're accessing the newly created one, not the previously last one. In fact, instead of using vector[lastIndex] to access the last element in a vector, try vector.back()
2) I would presume that this "callback" would be a number of times each second so dynamically allocating a new vector seems like more work than is necessary. Wouldn't it make sense to pre-allocate the "maximum" amount (which would presumably be reached quickly).
That said, a couple of things you may want to consider:
1) update the current_array when you push a new one so that you're accessing the newly created one, not the previously last one. In fact, instead of using vector[lastIndex] to access the last element in a vector, try vector.back()
2) I would presume that this "callback" would be a number of times each second so dynamically allocating a new vector seems like more work than is necessary. Wouldn't it make sense to pre-allocate the "maximum" amount (which would presumably be reached quickly).
2959
Graphics / Re: Creating a circle of circles
« on: September 08, 2014, 01:44:36 pm »
You're welcome 
It turns out that you don't actually need a second move as it still draws a circle; it's just larger and not arranged around the centre (setPosition is still the better way). The problem you had, it seems, was the use of cos and sin's ranges; it was ringRadius that made it do something!
Don't forget to use a constant/variable for the angle step rather than hard-coding it (as I did)!
It turns out that you don't actually need a second move as it still draws a circle; it's just larger and not arranged around the centre (setPosition is still the better way). The problem you had, it seems, was the use of cos and sin's ranges; it was ringRadius that made it do something!
Don't forget to use a constant/variable for the angle step rather than hard-coding it (as I did)!
2960
Graphics / Re: Creating a circle of circles
« on: September 08, 2014, 07:28:50 am »
If you're going to use move(), you'll need to move back to the centre when you've drawn it, ready for the next time.
cos and sin return a value between 0 and 1 so your "ring" has a radius of 1 whereas the circle that you're using to draw it has a radius of 10.
This would make your code work:
e.g.
Here it is again but casting to float explicitly (stops warnings):
cos and sin return a value between 0 and 1 so your "ring" has a radius of 1 whereas the circle that you're using to draw it has a radius of 10.
This would make your code work:
for (int i = 0; i < 360; i += 20)
{
const float ringRadius = 65.f;
shape.move(ringRadius * cos(i*PI / 180), ringRadius * sin(i*PI / 180));
window.draw(shape);
shape.move(-ringRadius * cos(i*PI / 180), -ringRadius * sin(i*PI / 180));
}
but I'm not sure it's the best method. I would probably recommend using setPosition inside the loop and set the position from there.{
const float ringRadius = 65.f;
shape.move(ringRadius * cos(i*PI / 180), ringRadius * sin(i*PI / 180));
window.draw(shape);
shape.move(-ringRadius * cos(i*PI / 180), -ringRadius * sin(i*PI / 180));
}
e.g.
shape.setPosition(window.getSize().x / 2 + ringRadius * cos(i*PI / 180), window.getSize().y / 2 + ringRadius * sin(i*PI / 180));
instead of the moves.Here it is again but casting to float explicitly (stops warnings):
shape.setPosition(static_cast<float>(window.getSize().x / 2 + ringRadius * cos(i*PI / 180)), static_cast<float>(window.getSize().y / 2 + ringRadius * sin(i*PI / 180)));
2961
General / Re: undefined reference to ' '
« on: September 08, 2014, 07:12:11 am » (click to show/hide)
2962
Audio / Re: No sound after update to 2.1
« on: September 08, 2014, 07:07:05 am »Relative paths have nothing to do with this.You couldn't've been certain of this. It could have been pointing to an empty or silent sound file that loads fine.
It's not that though because he's tried full path
I'd also recommend upgrading to the latest github version. It scares me that you're considering going back to 1.6.
2963
Audio / Re: No sound after update to 2.1
« on: September 07, 2014, 02:21:24 pm »
Have you tried it with a specific file location i.e. full address?
2965
SFML projects / Re: Morpheus - Ludum Dare Jam #30 Entry
« on: September 02, 2014, 09:27:49 pm »I don't know how long such a gap between songs needs to be before actually being audibleI agree that it would be fine for normal songs that are independent of each other but stops being acceptable when you want to make an infinite piece of music by looping a section (like the endgame music in the OP game does; not sure about the background music).
2966
SFML projects / Re: Morpheus - Ludum Dare Jam #30 Entry
« on: September 02, 2014, 08:54:25 pm »
It's a shame this game didn't develop a little more; it seems a little cut short.
I completed it first time without ever being hit. I wasn't even sure at which point I would be hit so I just (easily) avoided each one completely. I even forgot to try to jump; I didn't need it! I tried it again to see what happens when you get hit and ended up running through to the 19th (I think) room without being touched. If you continue with the development of this, you may want to limit the progress speed e.g. maybe open a door every few seconds, start with a few open etc..
On relation to the music looping discussion, the music when you complete the game loops with very noticable delays between each loop. Also, SFML's music has a loop option. I'm not sure how long it's had one, though, so you may need a new version to use it. It seems to do so well though (tested using a 3.5 minutes .wav file and an .ogg file).
I completed it first time without ever being hit. I wasn't even sure at which point I would be hit so I just (easily) avoided each one completely. I even forgot to try to jump; I didn't need it! I tried it again to see what happens when you get hit and ended up running through to the 19th (I think) room without being touched. If you continue with the development of this, you may want to limit the progress speed e.g. maybe open a door every few seconds, start with a few open etc..
On relation to the music looping discussion, the music when you complete the game loops with very noticable delays between each loop. Also, SFML's music has a loop option. I'm not sure how long it's had one, though, so you may need a new version to use it. It seems to do so well though (tested using a 3.5 minutes .wav file and an .ogg file).
2967
General / Re: Collision... yer driving me crazy
« on: September 01, 2014, 02:12:14 am »
If it is that - and I'm guessing because I can't actually see the code - then you'll need to do all testing first, then do all the fixes afterwards.
2968
General / Re: Collision... yer driving me crazy
« on: August 31, 2014, 09:16:44 pm »
It looks like this:
When the horizontal detection is found, it corrects the collision by moving it so that it no longer collides.
Then, when the vertical detection goes ahead, it's no longer colliding, even if it did before.
However, if you put the vertical code first - the logic and fix is identical to the horizontal code - and it still skips the vertical detection, then it can't be this. I bolded "fix" because if the vertical code finds that it collides but fixes it the same way the horizontal code does, it would look like the horizontal code did it.
When the horizontal detection is found, it corrects the collision by moving it so that it no longer collides.
Then, when the vertical detection goes ahead, it's no longer colliding, even if it did before.
However, if you put the vertical code first - the logic and fix is identical to the horizontal code - and it still skips the vertical detection, then it can't be this. I bolded "fix" because if the vertical code finds that it collides but fixes it the same way the horizontal code does, it would look like the horizontal code did it.
2969
General discussions / Re: SFML tutorial video
« on: August 31, 2014, 09:12:13 pm »
Actually, it was more the use of quotes for the inclusion that got me, rather than the inclusion of the entire module. Even though the use of quotes would work (when it fails, it reads it as if < and > are used), it reads as though you expect the inclusion to be from the current working directory.
2970
Graphics / Re: Tile Editor is off center?
« on: August 31, 2014, 12:52:17 am »I believe Hapax's image shows column major, if I'm reading it right.If the term means what I think it means then, yes, that's right
It was because it seemed Chay was aiming to have the vector in the order "x before y" and this makes sense as this is how we usually describe 2D.
However, I think I'd personally always use row first ("major"?) when using 2D vectors.
That said, I'd almost always use a 1D vector for tile maps as you mentioned:
store an X by Y grid by simply using a single vector of size X times Y.