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

Pages: 1 ... 3 4 [5] 6 7 ... 16
61
Graphics / Re: Move the view if the entity's out view.
« on: June 11, 2018, 04:49:27 pm »
Right now you are just setting the view's center to be the same position as the player every update. You just need to change that to only setting the view's center if the player is farther away from the center than you want.

For example, here is one way you could handle it
playerBoundary = 100
if (mPlayer->getPosition().x > mDrone.getCenter().x + playerBoundary)
{
   newViewCenter = {mPlayer->getPosition().x - playerBoundary, mDrone.getCenter().y}
   mDrone.setCenter(newViewCenter);
}
 

This would handle the player moving too far to the right. Just repeat something similar for the other 3 directions.

62
Graphics / Re: Loading Images and Textures Failed
« on: June 11, 2018, 04:21:56 pm »
Just based on what you said, my first guess is that GetOpenFileName() changes the current working directory (CWD) of your program, presumably to the directory of the file you selected to open. You will then see these errors if that new location doesn't have folders called "images" or "fonts".

63
Graphics / Re: Inheriting from sf::Drawable
« on: June 06, 2018, 12:31:15 am »
One problem your code has is that you are creating the sf::Font object locally in your constructor. The font will go out of scope and be destroyed when your constructor returns. The draw() function will then try to draw your text with a non-existent font.

From the SFML documentation:
Quote
The font argument refers to a font that must exist as long as the text uses it. Indeed, the text doesn't store its own copy of the font, but rather keeps a pointer to the one that you passed to this function. If the font is destroyed and the text tries to use it, the behavior is undefined.

64
Graphics / Re: How to check if a sprite is touching a line
« on: May 23, 2018, 05:36:46 pm »
You are essentially asking how to check for collisions between a line and a rectangle (the sprite's bounding box). This is a common thing in many games, which means you can probably find several good tutorials by just searching the internet for those terms. Here is the first result that came up for me when searching, which may be what you want.

65
Graphics / Re: Creating a background image
« on: May 16, 2018, 11:14:42 pm »
This snippet from the official tutorials may be useful:
Quote
The loadFromFile function can sometimes fail with no obvious reason. First, check the error message that SFML prints to the standard output (check the console). If the message is unable to open file, make sure that the working directory (which is the directory that any file path will be interpreted relative to) is what you think it is: When you run the application from your desktop environment, the working directory is the executable folder. However, when you launch your program from your IDE (Visual Studio, Code::Blocks, ...) the working directory might sometimes be set to the project directory instead. This can usually be changed quite easily in the project settings.
You said you put your images folder next to your main.cpp, but that might not be your working directory. Make sure to double check that.

If you tried an absolute path (something like "C:/a/b/c/images/city.png") make sure you either used forward slashes or backslashes with proper escaping. Other than that if things are still not working then your image may be malformed or in a format SFML doesn't understand. Could you try a different image and see if that one works?

66
General / Re: Program for making 2D Textures
« on: May 09, 2018, 04:02:49 pm »
From the SFML documentation
Quote
The supported image formats are bmp, png, tga, jpg, gif, psd, hdr and pic. Some format options are not supported, like progressive jpeg.

The best image editor to use kind of depends on what art style you want your game to have and your personal preferences. Photoshop would probably work fine. Alternatively there's GIMP, Krita, mspaint, Aseprite, or the many others out there.

67
As mentioned, you may get better help on a different forum, but I'll see if I can help get you started. Note that I'm just inferring what each variable means based on what I saw while glancing through the article. Let's start with only the x component in the ray
Quote
Ray X = r_px+r_dx*T1
The first "ray" that the article creates is a line which begins at some starting point and goes to where the mouse cursor is. Therefore, we know what r_px and r_dx are. For example, let's say our light exists at (5, 6) and our mouse is at (12, 14). What the article calls distance is the vector from the mouse to the starting point, so (12-5, 14-6) = (7, 8 ). That gives us
x = 5 + 7 * T1
 
This formula lets us get any x value of our "ray" depending on what we plug in for T1. If T1=0, then x=5 which is our starting point. If T1=1, then x=12 which is our ending point. If T1=0.5 then x is in the middle of those two, 8.5. If T1 is greater than 1, then we're at a point beyond the mouse (which is allowed for rays, but segments do not extend beyond their ending point). The article then shows similar formulas for the Ray's y component, and the segment's x and y components.

The article then says that if a ray and a segment are intersecting, that means they both must have an X and Y component that matches each other. So setting the Ray's X formula equal to the segment's X formula (and likewise for the Y component) gives us
Quote
r_px+r_dx*T1 = s_px+s_dx*T2
r_py+r_dy*T1 = s_py+s_dy*T2
As explained above, you know what (r_px, r_py), (r_dx, r_dy), (s_px, s_py), and (s_dx, s_dy) are. The only thing you don't know is what T1 and T2 are. However, there should exist numbers we can plug in for T1 and T2 such that both sides of the equals sign are, well, equal to each other for both equations. That is what we're trying to solve.

The rest of the article is simple algebra to solve for those 2 numbers. Once you have T1 and T2, you can check if the numbers make sense for an intersection. If so, plug them back into your x and y formulas to see where exactly the ray and segment intersect.

68
Is there something specific you didn't understand about that linked article? Right now it sort of sounds like you would like someone to rewrite the whole thing in a way that might be more understandable to you. That's something that would be hard to do concisely in a forum post. What specifically did you not understand?

If you search these forums you might find some posts that could be helpful to you, such as this one.

This question, though, is more about general game design techniques and not so much about SFML. You may get better answers on places like StackOverflow or other game development based forums.

69
General / Re: SFML Pixel Perfect Collision limited to a view?
« on: April 27, 2018, 07:28:59 pm »
In my opinion, you'd have a hard time finding a multimedia library that was more intuitive than SFML  ;)

Can you describe at a high level what you are trying to achieve in your game? It seems so far that you may be trying to use a sf::View in a way where other techniques could be better. It seems curious that you want your car and wall to be in different views, yet interact in this manner.

If you do want to continue using views, you need to be aware of the 2 different coordinate systems. There is the world's coordinate system and the screen's coordinate system. Moving the view changes the object's screen coordinates, but does not change where it exists in the world. This is why your car is stopping. Even though they are not colliding in the screen's coordinate system (which is what you see), they ARE colliding in the world coordinate system. SFML provides functions to map between these 2 coordinate systems.

This separation of world and screen coordinates enables things like split-screen multiplayer, or to easily layer a HUD interface on top of your game without impacting collisions and other things. You may need to step back and investigate if using a sf::View is really the right tool to solve whatever it is your game needs to do.

70
General / Re: Self Contained project + text box input + Image resizing
« on: April 27, 2018, 03:54:56 pm »
1. How do I create a text box?

This is kind of a broad question. Is there something specific about making a text box that you are unsure of? Why not start with looking at the Window and Graphics module tutorials. Once you have the basics down, you'll probably want to draw a sf::RectangleShape to represent the text box, sf::Text to show the text inside of the text box, and use events to know when the textbox has been clicked on (for focus) and to know when the user is typing something. Alternatively you could use an existing GUI library like Imgui, TGUI, or SFGUI.

2. How do I make the project "self contained"?

How exactly are you planning on distributing the project? Are you giving out the source code, or are you planning on compiling it and giving out the final executable? If you are compiling it, then the includes don't matter. Your users don't need the include files to run your program (though, they will need the SFML dlls if you are linking dynamically). If you are giving out the source code, is there a reason you are using full directory locations and not relative path locations?

3. Can I resize images?

SFML doesn't really have many image manipulation functions built in. Someone can correct me if I'm wrong, but if you want to use SFML for this I think the best workaround would be to load your initial image as a texture, create a sprite from it, zoom the sprite to your desired resolution, draw that to a RenderTexture, and then copy that back to an image.

I'm not sure what you mean by "use windows file explorer". Do you mean that you want to drag files from windows file explorer and drop them into the SFML window? If so, no I don't think that functionality has been added to SFML, though there has been some discussion on it in the past.

71
Graphics / Re: sf::text and vectors help
« on: April 20, 2018, 04:06:45 pm »
Also, just a heads up, these forums are more intended for SFML discussion. General C++ questions, such as how to use a vector, are usually better asked elsewhere. Getting a good book on C++ and reading through it would be the best option. I recommend trying to learn C++ a little better before diving into a library like SFML.

Having said that, if your question is how to put additional elements in the vector "dynamically", a basic example could be something like the code below.
std::vector<sf::Text> myVector;

sf::Text myNewText;
// configure myText however you want to here

myVector.push_back(myNewText);
 

Just be aware that this example is copying myText into the vector, which is fine, but you probably won't want to do exactly this for other things like sf::Font or sf::Texture. I'll leave that as an exercise for the reader  ;)

72
Graphics / Re: sf::RenderTarget::display() not present?
« on: March 14, 2018, 08:27:08 pm »
By the way, my response to you was simply relaying answers from previous threads, such as this one and this (old) one. These are likely design decisions, not technical ones, so you may need to focus more on why a generic RenderTarget should have a display() function more so than the technical feasibility of the idea. I don't have much of the background knowledge on the topic, though, so I'll leave it to others in this thread to try and provide you more satisfying answers to your questions.

73
Graphics / Re: sf::RenderTarget::display() not present?
« on: March 14, 2018, 05:04:04 pm »
The RenderTarget display() question has been brought up on the forum several times. If you search around you can find the reasoning given for why that function doesn't exist. My attempt to summarize some of those answers:

  • sf::RenderWindow doesn't define display() directly. It gets it through inheritance of sf::Window.
  • There isn't a need for a display() function at the RenderTarget level. A RenderTarget doesn't necessarily need a call to indicate drawing is done. For example, unbuffered rendering.
  • RenderTexture::display() internally does different things than RenderWindow::display(). It just has the same name because the usage is similar.

74
General / Re: Image of Sprite Skipping on Screen
« on: February 15, 2018, 06:31:24 pm »
I'm guessing the big jump I see is actually just your gif looping? Your real problem is the slight stuttering that happens a few times between the big jumps in your gif?

Can you double check that your driver isn't forcing vsync on? What does your framerate look like?

If you try replacing your original fixed timestep with a variable delta time do you still get stuttering?



75
General / Re: Sprite is not moving
« on: January 23, 2018, 11:14:29 pm »
Your game loop has a few different issues that could probably be fixed with some better code organization. The problem you're asking about, though, may likely be due to having multiple pollEvent loops.  The first loop will pop all of the events from the event queue, so there will be no events left in the queue for when your second loop runs. You should only make one loop that calls pollEvent.

Pages: 1 ... 3 4 [5] 6 7 ... 16
anything