Messages

2971

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 audible

I 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).

2972

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).

2973

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.

2974

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.

2975

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.

2976

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.

2977

Graphics / Re: Tile Editor is off center?

« on: August 30, 2014, 07:47:20 pm »

Does this help?
It's similar to what Ixrec posted but aimed at describing the specific case you are using in your program...



You should still follow Ixrec's advice 

2978

Graphics / Re: Tile Editor is off center?

« on: August 30, 2014, 07:11:53 pm »

I don't want to use them. My program is going to have a lot more than just tile editing features. Besides, If I thought any of the other tile editors were any good, I wouldnt go to all the trouble of building my own now would I

I know what you mean. I like to work on the creation tools myself too. However, if your reason for making it is to use it rather than the actual making, then go with pre-made stuff. I'm not sure what you are going to be adding to your tile editors that others' cannot do - I like the fact they just give me the tile map numbers, for example - but if you want your editor to do more than that, good luck. Oh, and let us all use it!

Here is a drawing I did in MS paint of what I think a 2d vector would look like visually:
http://oi60.tinypic.com/11ifg2o.jpg

Most important thing to remember is that they start at 0, not 1.

2979

Graphics / Re: Tile Editor is off center?

« on: August 30, 2014, 01:54:59 pm »

I never would have figured that out

It's just making sure that both indexX and indexY they are within the range of their respect vectors i.e. from 0 to size - 1. (you can do indexX <= (GridSizeX - 1) or indexX < GridSizeX. They are equivalent here.)

How do you think I could do it?

From your current way, you'd need to go through the entire vector of sprites, see which textures they use, and create a new vector representing which tiles they are. This other vector is usually int or unsigned int and is just an index of which tile that should be displayed. "Normally", this is the main vector and the display is created from this information. A 2D vector of ints is much easier to save 

Also is there a picture representation of a 2d vector? I've been looking for one and I cant find one. If I can see a visual reprisentation a lot, if not all of the confusion will be cleared up.

I'm not sure what you mean. You need help visualising how it's stored?

im not doing this editor for fun, i'm building it to use and a map editor that cant save the map is useless, I mean it is fun building it and learning how to do 2d stuff but its not just for those reasons.

As Jesper has already shown, there are tile map editors out there already that have this functionality so that you can create and use tile maps in your programs easily. Other than Tiled that has already been mentioned, there is another called Mappy that you may also want to consider.

2980

General discussions / Re: SFML tutorial video

« on: August 30, 2014, 01:43:13 pm »

Thought I'd give it a bit of a chance. Wondered if we were all missing something awesome later on.
By 5 minutes in, however, you'd commented about a render window constructor. You say it takes 2/3 arguments. Actually, it can take 4. No biggy; you can miss that out with no consequences. But then:

the third one I forgot, I think it takes something inside sf::Style

You're giving a tutorial on something you don't remember how to use.
You follow that with:

You can look it up on the documentation.

You can find complete examples there too. I'm not sure what your tutorial is for.

2981

Graphics / Re: Tile Editor is off center?

« on: August 30, 2014, 04:04:51 am »

That's because you've moved the code that changes it to a blank tile into the left mouse button block so it's just setting to the new tile, and then removing it instantly.

In your original code, you have it doing things based on left and right buttons. Keep it there and test all four of the boundaries in both of the ifs.

Can I do that like this?

I guess you can. You'll need to go through them all and work out which texture they have, then decide on which tile it is based on that.

EDIT:
I caved and decided I was going to give you the answer 

In your original code where you had the following code twice:

if(indexY <= Grid.size())

replace each of them with

if ((indexY < GridSizeY) && (indexY >= 0) && (indexX < GridSizeX) && (indexX >= 0))

2982

General discussions / Re: SFML tutorial video

« on: August 30, 2014, 03:57:58 am »

__YOU_ARE_WELCOME__

2983

Graphics / Re: Tile Editor is off center?

« on: August 30, 2014, 03:55:26 am »

 

GridSizeX instead of Grid.size()
GridSizeY instead of Grid[0].size()
They're the same values.

You should be testing to see if they (indexX and indexY) are less than the size, not greater than.
Also, test to make sure they're zero or higher. It can crash when they're below zero. (obviously e.g. Grid[-1]  )

This is just a vector of sprites with different textures, you know. The actual map isn't stored anywhere. How will you be saving this? 

2984

Graphics / Re: Tile Editor is off center?

« on: August 30, 2014, 03:43:25 am »

        if(indexY <= Grid.size())

As I mentioned earlier, these should never be equal.
Also, the size of "Grid" is the x size. For y, you need Grid[0].size(). Better still, just use GridSizeX and GridSizeY 

I see that you copied my code. You should've typed it; you may have noticed the error I fixed it now though; see if you can see what I changed 

I fixed most of the problems

Lies! I fixed them 

2985

Graphics / Re: Tile Editor is off center?

« on: August 30, 2014, 03:13:15 am »

Much better now that I can see it with the right images 

I'm going through your code (for fun ) and I'm noticing a few things here and there that should be fixed before it causes your problems later on.

Your grid iteration is mixed.

   Grid.resize(GridSizeY);
   for (int x = 0; x < GridSizeX; x++)//Column
   {
      for (int y = 0; y < GridSizeY; y++)//Row
      {
         Grid[y].push_back(blankGridSprite);
         blankGridSprite.setPosition(x * 32, y * 32);
      }
   }

That makes no sense as you are resizing the grid to hold rows and then go through them as columns. Then, when you're iterating the "y", you're pushing the new y's based on the y. That was not a very good explanation of what I mean. However, in your code-style, I think it should be this:

        Grid.resize(GridSizeX);
        for (int x = 0; x < GridSizeX; x++)//Column
        {
                for (int y = 0; y < GridSizeY; y++)//Row
                {
                        blankGridSprite.setPosition(x * 32, y * 32);
                        Grid[x].push_back(blankGridSprite);
                }
        }

You should replace all of your usage (you used it 6 times) of rint (as I found that it's rounding to the nearest integer, which is upwards when it hits halfway) with floor. Try it. Trust me 

Cases in a switch statement don't need block braces. Just so you know 

You should probably handle the failures when loading textures. Returning from the application seems to make sense since you can't use it without them.

Your outputting of row and column are incorrect. Row should be y and column should be x.

You mix up X and Y access again in the Grid vector here:

Grid[indexY][indexX].setTexture(tileTexture);

and here:

Grid[indexY][indexX].setTexture(blankGridTexture);

You are only testing to make sure that Y is within boundary (the bottom of the grid). You aren't testing for the top, or testing the x for the sides. Also, if y equals Grid.size(), it's accessing an element that is not there.

You are loading in your images and creating your textures and sprites on every cycle. Take them outside the main window loop and load them just once.

As for the problem you mentioned about it drawing on the bottom and missing the last tile off, it's because you're setting the position of the temporary variable after assigning it to the grid, so each tile is getting the position of the previous one (the first two have the same position).

You'll need to swap them to this:

                        blankGridSprite.setPosition(x * 32, y * 32);
                        Grid[x].push_back(blankGridSprite);

and then remove the +1 from indexY.

After making these modifications myself, it works perfectly and never crashes