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

Pages: 1 [2] 3
16
SFML projects / Re: Car Racing For Beginners : Finished
« on: December 04, 2015, 04:51:31 pm »
Looks awesome! :D

17
Graphics / Re: Update function for re-drawing sprite
« on: December 02, 2015, 06:33:23 pm »
Your "drawCup1()" function has "_cup1Sprite.setPosition()" which will set the absolute position of the sprite on the window using the coordinates you gave it.

Since your function is called each time you call "drawToWindow.drawCup1()", which is also called after the "update" function, it will always negate the positions you changed inside "update" function and will have the same position on the screen.

Simply set the sprite starting position elsewhere.

Also, you don't need to move sprite like this:
        sf::Vector2f pos = this->_cup1Sprite.getPosition();
        pos.x+=10;
        this->_cup1Sprite.setPosition(pos);
 
Move it like this:
    _cup1Sprite.move(10,0);
 

By the way, loading the texture each frame is bad idea. Load it only once and keep it alive as long you need it. ;)


edit: Argh.. 20 seconds late   :P

18
General / Re: "Pure Virtual Function Called" - problem while drawing
« on: November 02, 2015, 12:35:44 am »
That didn't crossed my mind.  :-\

So, clearing entire object_for_draw deque and repopulating it with new pointers after the element has been deleted works.

Thanks.

19
General / [SOLVED]"Pure Virtual Function Called" - problem while drawing
« on: November 01, 2015, 11:04:16 pm »
Hi!

First of all, I am sorry for posting a general C++ question, but the origin of the problem made me believe that this would be the best place. I also searched the forum and web, but didn’t found satisfying solution or guideline (or I just suck at searching :-\).
Also bear in mind that I am inexperienced in C++, (but learning new things steadily  :D )

Basically, I am making use of polymorphism during drawing.
I made a abstract base class (derived from sf::Drawable and sf::Transformable) and several derived classes. The objects from derived classes are updated, but not drawn.
Then I made a special deque in which are stored raw pointers of base class. These pointers point to the objects of derived classes and are used for drawing.

So instead of writing something like this:
window.draw(object_1);  //  object of derived class 1;
window.draw(object_2);  //  object of derived class 2;
window.draw(object_3);  //  object of derived class 3;
window.draw(object_4);  //  object of derived class 4;
for (const auto& it: cont_1)  // container of X objects of derived class 5;
   window.draw(it);
for (const auto& it: cont_2)  // container of Y objects of derived class 6;
   window.draw(it);
// Now imagine that there are additional 50 more derived classes with at least one object below.
 
I can write it like this:

for (const auto& it: cont_of_pointers)  // container of X pointers of the base class that point to objects derived classes;
   window.draw(*it);
 

Neat!  ;D

When object is no longer useful and won’t be used any time soon. I need to delete it. Therefore, I need to delete both the pointer pointing to that object from the array and the object itself during runtime.

The deletion goes smoothly, but the program crashes when it starts drawing objects, with the message “R6025 – Pure Virtual function called”. The error seems to refer to a draw function inside sf::Drawable, which is the main reason why I posted topic on this forum.

The problem now is, what I managed to figure out, is that when I delete the object itself, the problem occurs. If I delete only the pointer, it works, but the object itself is still inside the memory and program takes him into account when dealing with logic, it is simply invisible because it is no longer being drawn.

(Maybe the lambda expression is the problem… I started using them just recently, thought I should point that out.  :-[ )

So my questions are:
1. What should I do in order to prevent the pure virtual function call in this method for drawing?
2. Should I even draw like this in the first place?
3. How is this error even possible? There are no dangling pointers nor calls to a pure virtual functions inside my base class constructor/destructor and the compiler won’t even run the program if there is a call to a pure virtual function somewhere else in the code, as far as I know.

Here is complete and minimal example that reproduces the problem:
(click to show/hide)

20
SFML projects / Re: Screenshot Thread
« on: October 24, 2015, 02:36:18 am »
More screenshots from my simplistic project.  :D

Basically, I am putting three games (clones of Pong, Asteroids and Breakout/Arkanoid) into one program, with functioning main, choice and options menus, and pause menus during the games.  ;D
So yeah, to me as a programming C++ novice, this is quite a big thing.

The games are far from over, the prototypes are working (except for Arkanoid clone, it is not finished yet, I need to implement more things such as substates, score, etc. and fix collision detection, because the current one is a mess  >:( ), and I will open the thread soon about it with the code. I would like to hear your opinion on it before I progress further. :)

21
Window / Re: strange issue with fullscreen mode
« on: October 24, 2015, 02:04:36 am »
By pressing the Print Screen key, you request to send the data to the clipboard, but SFML does not have clipboard support, at least not yet. Hence it will only send the data to the clipboard that was at the start of program, or more precise, when window was opened.
(Or at least I think it works that way ;D, a more experienced SFML user would answer that better than me. )

It is still possible to capture the screenshot from the window by using window.capture() function and then saving it to a file.

Also while we are at it, the SFML does not recognize the Print Screen key either, so if that bothers you, you should check this topic too. :)


22
Window / Re: High CPU usage in idle mode
« on: October 05, 2015, 03:24:05 am »

23
SFML projects / Re:creation - a top down action rpg about undeads
« on: September 17, 2015, 11:17:40 am »
@EliasDaler I have a feeling this article might be of some use to you. :)

The art of enemy design in Zelda a link to the past

24
System / Re: [Newbie] How to use sf::Clock correctly?
« on: September 09, 2015, 08:24:08 pm »
The official tutorial explains enough about sf::Clock and sf::Time usage.

You should use sf::Clock only once (initialize at a start of project) and you use sf::Time to manipulate the values you receive from sf::Clock.

As said in the tutorial, the main usage of sf::Clock and sf::Time is to update the game logic:


sf::Clock clock;
while (window.isOpen())
{
    sf::Time elapsed = clock.restart();
    updateGame(elapsed);
    ...
}
 

Please note that there are other, better ways to update game logic, like using fixed time steps. But if you are just starting out, the code above should be enough.
Also in this case, it would be smart to use vsync or to set the framerate limit.

You should also read (and bookmark) this: http://gafferongames.com/game-physics/fix-your-timestep/ - it is really helpful, especially when you want to start with more complex projects. :)

25
Graphics / Re: Tiled map same sprites but diferent position
« on: September 08, 2015, 04:20:35 am »
If I understood you correctly, you want to make a 40x40 tiled map with sprites, therefore this the way to go:
Quote
should i create different sprites for each tile (talking about the same graphics tiles) with different positions??

Of course, there are other ways to make a tilled map, such as, using sf::VertexArrays, not sprites, but they are a bit tricky to use.
So if you are just starting out with SFML, the sprites should be enough.  ;D

If you wanted to ask "Why the second option isn't good?", it isn't good because you always need to keep rendering separated from rest of the code, not to mix anything with it. Doing so is a bad code design and almost always causes trouble in more serious projects. It should do only:

// Positions, sizes, colors, textures, ect... are always updated before rendering:

void Render()
{
    window.clear(sf::Color::Black);
    window.draw(sprite1);   // You can also apply transformations using "window.draw(sprite1, transformations)", but that is another story :)
    window.draw(sprite2);  
     // Or how many things you want to draw.
    window.display();
}
 

Also note that this is too a valid approach:

// Let's say we have a class (or classes) called World that has function for rendering.
// positions, textures, ect... are updated somewhere.
void World::render(sf::RenderWindow& window)   //   Passing a sf::RenderWindow by reference (&) is very important!
{
   window.draw(sprite1);
   window.draw(sprite2);
   // ect.
}

void render()
{
   window.clear();
   mWorld.render(window); // mWorld is an object of World class;
   window.display()

}
 

26
General / Re: Keyrepeatenabled not working
« on: September 07, 2015, 12:43:05 pm »
yes, as well as the sf::Keybaord::isKeyPressed(sf::Keyboard::D);

The 'window.setKeyRepeatEnabled(bool)' function works only with 'sf::Event::KeyPressed': See here.


And I am sorry, but your code and explanation is quite confusing.

My wild guess is that you have a faulty 'if' statements:

   
if (Event.key.code == sf::Keyboard::D){
    if (PlayerColor == Blue){
        BlueScore++;
        ChooseNextPlayer();
        }
    if (PlayerColor == Pink){
        GameOver();
        }

Here in this code you say to the program: "When I press the 'D' key, check whether the player is blue AND THEN check whether the player is pink."
If the player is blue, the program will then continue to execute the said statement, where you call the 'ChooseNextPlayer()' function (which apparently randomly chooses the next player).
When program randomly chooses next player, it proceeds with next 'if' statement, which checks whether the player is pink, and if that player is pink - because in previous 'if' statement you called 'ChooseNextPlayer()' function - it will then execute it's statement, which calls 'GameOver()'.

The same applies when you press 'A' key.

In order to prevent this, you need to use an 'else' or 'else if' in your second statements, so when the first 'if' statement is true, it won't proceed to check the other statements.


If there is another problem, then I can't help you further without you providing a complete and minimal code --- Go and read the post in the link.

27
SFML projects / Re: My Practice Beginner Games
« on: September 06, 2015, 12:39:09 am »
Looks good., especially the effects when the ball hits the paddle.  :D

28
SFML projects / Re: Space Invaders Clone
« on: August 28, 2015, 11:11:22 pm »
I've downloaded the source code and tried to compile it, but unfortunately my Visual Studio 2013 is sending back these errors:

(click to show/hide)

After searching a bit, I found out that it is a compiler error. So if anybody is using VS 2013 (like me), he is going to have a tough time compiling it. :(

29
sf::View is a sf::FloatRect
No it isn't; sf::View is an sf::View.
It takes an sf::FloatRect in its constructor but it doesn't store the information this way.
To get information from an sf::View, you use its getters e.g. getSize(), getCenter().

You are right. I got confused because it took sf::FloatRect as a constructor. I will shut up.  :-X

30
sf::View is a sf::FloatRect, therefore it has 4 parameters:
1. Left
2. Top
3. Width
4. Height

The first 2 parameters are used to set the starting position of the sf::FloatRect within the window.
The last 2 parameter are used to set the size of the sf::FloatRect.

So in order to get the corners of the sf::View (i.e. sf::FloatRect), the code should look something like this:

// Never mind
 

Now you have the four corners of the sf::View. ;)

Igrnore this post.  :-X

Pages: 1 [2] 3
anything