Messages

31

Window / How to disable mouse but still read it?

« on: July 04, 2012, 02:45:16 pm »

When my GUI is in use I would like the OS cursor to be visible and work outside my window (normal).

In-game I'd like the OS pointer to be invisible and not able to be seen outside the window, just read the mouse so I can change the position of my game cursor which controls the direction of the main sprite.

Currently I'm doing this by disabling the cursor visibility and repositioning it's x & y if they go outside the window bounds. It works, but in windowed mode the OS cursor can still creep outside the window and register a click, like a right click, which then brings up the context menu. Pretty shabby and interrupts proceedings.

I've seen other games accomplish this, any help on how to do this in SFML(2RC)?

32

SFML projects / Re: Starfire - Ares Assault released.

« on: June 27, 2012, 10:35:41 pm »

Ramping is a good idea of course, so is the concept of pulling back the difficulty for a while after a new (harder) gameplay element has been introduced.

Carefully hiding learning mechanics into the actual gameplay itself is another thing that goes way back to games like Megaman and beyond.

BTW, lovely work Sui.  Your 'cloudfield' inspired me to do something similar with awesome results!

33

Graphics / Re: Lots of Objects in Game and SFML2

« on: June 25, 2012, 06:00:14 pm »

Personally, I create a std::multimap of all objects that need to be drawn to the screen. The key value is the priority level of the object (0-255). Since the multimap is auto-sorted on that key, all objects are in the correct z-order for drawing and their place in the order can be changed dynamically from frame to frame.

34

Graphics / Re: Lots of Objects in Game and SFML2

« on: June 22, 2012, 10:11:08 pm »

Using a paritioning structure is a must for good performances, both in rendering and in logic (for computing collisions, searching entities, ...).

Indeed. I made one recently and was staggered by the performance gain in collision tests.

35

Graphics / Re: sfml-graphics-d.dll Issues VS C++ 2010

« on: June 16, 2012, 08:27:19 pm »

Tried putting them in the project folder?

36

Graphics / Re: Getting object from picture, not background

« on: May 27, 2012, 10:26:18 pm »

If your ball image is there with a white rectangle around it, sounds like you need the area around the ball to be alpha level 0 (transparent). You can do this using an image editor like Gimp.

37

Feature requests / Re: Animation

« on: May 16, 2012, 11:53:22 pm »

It's not really difficult to implement your own animation class using the tools SFML provides, that and you can tailor it more specifically to your own needs.

It's important to remember that libraries like SFML insulate you from the task of learning lower level stuff like OpenGL, in detail, which in itself is a lot of research.

By comparison, an animation class created using SFML is pretty easy because, well, you don't have to think about so much stuff. Just use the library as a go-between, which is what it is.

38

Graphics / Re: Improving the scrolling text

« on: May 12, 2012, 04:48:02 pm »

I made a class called SpriteText which is similar. Each character is an individual sprite, taking its texture subrect from a sprite sheet containing all the characters.

Applying different transformations across each character sprite can yield some interesting results.

You could probably acheive the same using sf::Text, but I went with sprites because I'm more familiar with them.

39

Graphics / Re: Help with vsync and SFML on a MAC

« on: May 10, 2012, 04:38:41 pm »

I generally get the odd 'bump' in smooth movement with Vsync (PC) in windowed mode, which clears up completely in full screen. However, this odd bumping problem in a window vanishes when switched to Windows (7) basic theme, although in the basic theme CPU always reads 25% of a 4-core.

I don't really think it has all that much to do with SFML or it would have been discoverd and corrected by now.

40

General / Re: SFML Complete Game Tutorial

« on: May 03, 2012, 11:51:58 am »

Download linky is broken 

41

Graphics / Re: Smoothly rendered vertexArrays?

« on: May 01, 2012, 10:44:17 pm »

Dang, that's a nice effect! 

42

Window / Re: Unusual CPU readings relating to vertical sync/frame rate limit [solved]

« on: April 29, 2012, 06:17:52 pm »

[SOLVED]...(sort of)

I found an option in the Nvidia control panel - Threaded Optimisation.  Auto by default, switching it off seems to have helped a lot.

43

Window / Re: Unusual CPU readings relating to Vsync/rateLimit

« on: April 29, 2012, 03:20:45 pm »

Thanks for testing it, Dobbi. 

This is the second Nvidia card I have owned that does this strange thing, so I suppose it really does boil down to drivers.

44

Window / Re: Unusual CPU readings relating to Vsync/rateLimit

« on: April 28, 2012, 11:54:53 pm »

Interesting.  ISTR John Carmack saying nasty things about PC video drivers.

It would be nice if someone with an ATI/AMD card was to try this and see if the same thing happens.

I guess I should just ignore it, although it makes code testing a little ambiguous.

45

Window / Unusual CPU readings relating to vertical sync/frame rate limit [solved]

« on: April 28, 2012, 09:38:55 pm »

Wow!  Two posts in one day, that must be a record!

Today I've been learning a little about Vertex Arrays and in my testing I came across something I've noticed before, but narrowed it down to a minimal example so I can ask what it's all about (it has nothing to do with Vertex Arrays though).

Here's some code:

#include <SFML\Graphics.hpp>
#include "Random.h"

int main()
{
    sf::RenderWindow App(sf::VideoMode(1024, 768, 32), "SFML");

        App.EnableVerticalSync(true);
        //App.SetFramerateLimit(60);

        const unsigned int NOOF_DOTS = 128;

        sf::VertexArray dots(sf::Quads, NOOF_DOTS * 4);

        for (int i=0; i<NOOF_DOTS*4; i+=4)
        {
                Random gen;

                float x = gen.randomF(0,1024);
                float y = gen.randomF(0,768);

                dots[i]  .Position = sf::Vector2f( x,   y   );
                dots[i+1].Position = sf::Vector2f( x,   y+2 );
                dots[i+2].Position = sf::Vector2f( x+2, y+2 );
                dots[i+3].Position = sf::Vector2f( x+2, y   );
        }

        while (App.IsOpen())
        {
                sf::Event Event;
                while (App.PollEvent(Event))
                {
                        if (Event.Type == sf::Event::Closed)
                                App.Close();
                }

                App.Clear();
                App.Draw (dots);
                App.Display();
        }

        return EXIT_SUCCESS;
}

NOTE 1: The 'Random' thing is just a little class I made to replace the old 1.6 Randomizer, it isn't really necessary.
NOTE 2: Running SFML2 from the Release .exe
NOTE 3: The snapshot I'm using is one just prior to the naming convention change.

The purpose of this test is simply to throw lots of tiny squares on the screen as a prelude to using this new aspect of SFML2 in a particle system I'm planning to re-create.

I noticed however (something I've seen before), some odd readings from the CPU.



With Vsync enabled and running 128 dots, CPU is low.
Change up by one to 129 dots and it leaps up to 25%.

Removing Vsync and using just frame limiting at 60, I can nearly white-out the screen with thousands of dots and the CPU appears to be yawning at 0%!  Naturally, I'd prefer the VSync for smoothness, but I find this behaviour a little strange and it has confused me for some time now.

What exactly is it here that I'm not understanding correctly?

*Edit - changed title for future searches