Topics

76

Graphics / GL_INVALID_ENUM at image creation

« on: June 01, 2010, 05:07:57 pm »

I have encountered a very strange behaviour. This simple code:

Code: [Select]

#include <SFML/Graphics.hpp>
#include <iostream>

int main()
{
sf::Image image;
bool created = image.Create(30, 40, sf::Color(0,0,0,0));

std::cout << "Success? " << std::boolalpha << created << std::endl;
}
leads to the following output:

Code: [Select]

An internal OpenGL call failed in image.cpp (633) : GL_INVALID_EUM, an unaccepta
ble value has been specified for an enumerated agument
An internal OpenGL call failed in image.cpp (634) : GL_INVALID_EUM, an unaccepta
ble value has been specified for an enumerated agument
Success? true
"EUM" and "agument" are not typographic errors, GLCheck.cpp contains the correct strings. I seriously don't know how that can happen. :shock:

However, the actual problem is those failed OpenGL calls. These two lines in sf::Image::CreateTexture() cause the problem:

   GLCheck(glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE));
    GLCheck(glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE));

I'm using the newest SVN revision (1523) of SFML2 on Windows 7 and Microsoft Visual Studio 2008 SP1, I just recompiled SFML. Any ideas?

77

Graphics / OpenGL: Setup perspective according to sf::View

« on: December 27, 2009, 11:39:21 pm »

Hi,

I have a question regarding OpenGL. I want to setup a perspective that represents the current sf::View. I have already experimented with gluOrtho2D(), but I am a little bit confused with the new sf::View interface (concerning viewport and rotation).

Is there an easy way to adapt the view in OpenGL?

78

Window / sf::Event::TextEntered - key repeat bug?

« on: October 30, 2009, 09:33:16 pm »

Hi,

I noticed that the TextEntered event is triggered repeatedly, even if sf::Window::EnableKeyRepeat(false) was previously called. I don't consider this behaviour intended.

Short and complete example:

Code: [Select]

#include <SFML/Window.hpp>
#include <iostream>

int main()
{
sf::Window App(sf::VideoMode(100, 100), "TextEntered Bug?");
App.EnableKeyRepeat(false);

while (App.IsOpened())
{
sf::Event Event;
while (App.GetEvent(Event))
{
if (Event.Type == sf::Event::TextEntered)
std::cout << "TextEntered!" << std::endl;
else if (Event.Type == sf::Event::Closed)
App.Close();
}
App.Display();
}
}

79

Graphics / Still artifacts

« on: June 30, 2009, 01:48:02 am »

Hi,

Recently I have read this and this thread and I think I've got a similar problem. I tried nitram_cero's SVN patch, but it didn't really help. I am not quite sure if I applied the patch right since my SVN version is a little bit newer. I just downloaded the newest SVN version some hours ago, adapted my code and tried it out. But the result remained the same, I still had ugly artifacts on my screen. Here you see an example:

The drawn sprites look like A or B. The source image is C, that's how it should look like. By the way, I don't use smooth images or zoomed/rotated views.

I tried a lot of things out, like aligning the view, the sprite's position or sprite's origin to integral coordinates. Some of the artifacts could be defeated, but some remain. Besides, my rounding seems to make the game less fluent.

It's quite strange, sometimes the sprites are drawn correctly. As far as I recognized this, the bigger a sprite's coordinates are, the less often it is drawn well (which would support nitram_cero's theory). But I am not very certain about this...

I don't know what to do, are there current workarounds or is this issue going to be fixed soon? I can also show my adaptation in RenderTarget.cpp if this helps (I didn't want to do it in this post since the code is quite long and maybe not even relevant)...

80

Audio / Bug in sf::Sound copy semantics?

« on: June 08, 2009, 08:10:56 pm »

Recently, I had a bug in my application concerning sf::Sound. I stored sf::Sounds in a container. When playing, they didn't show the right 3D-sound attributes. After debugging quite a while, I found out the sf::Sound copy constructor wouldn't copy the properties Attenuation and MinDistance.

In my opinion, this leads to unexpected copy semantics. I guess one would reckon those properties to be copied with the sf::Sound, too. At least I did so. Isn't this behaviour confusing and not coherent with other SFML classes like Sprite (in some way, sf::Sound is the audio equivalent of a sprite) which copy the whole object's state?

I think fixing this issue wouldn't be a big effort. You could expand the sf::Sound copy constructor with the following lines:

Code: [Select]

SetAttenuation(Copy.GetAttenuation());
SetMinDistance(Copy.GetMinDistance());
By the way, is there a reason why you duplicate code and write

Code: [Select]

ALCheck(alSourcei (mySource, AL_BUFFER,   myBuffer ? myBuffer->myBuffer : 0));
ALCheck(alSourcei (mySource, AL_LOOPING,  Copy.GetLoop()));
ALCheck(alSourcef (mySource, AL_PITCH,    Copy.GetPitch()));
ALCheck(alSourcef (mySource, AL_GAIN,     Copy.GetVolume() * 0.01f));
ALCheck(alSource3f(mySource, AL_POSITION, Copy.GetPosition().x, Copy.GetPosition().y, Copy.GetPosition().z));instead of

Code: [Select]

SetBuffer(Copy.GetBuffer());
SetLoop(Copy.GetLoop());
SetPitch(Copy.GetPitch());
SetVolume(Copy.GetVolume());
SetPosition(Copy.GetPosition());? This would be easier to maintain, too. The same applies to the other constructors which could call the set functions as well.

81

General discussions / Copy semantics of resources

« on: May 18, 2009, 05:05:38 pm »

Hi, a recent bug of mine led me to think about the resource classes in SFML. I intended to write something like this:

Code: [Select]

const sf::Image& Image = Blabla.GetImage(3);
sf::Sprite Sprite(Image);
Unfortunately, I forgot the reference.

Code: [Select]

const sf::Image Image = Blabla.GetImage(3);
sf::Sprite Sprite(Image);
You can imagine the massive loss of performance. That confused me a little, I thought SFML's big resource classes like sf::Image and sf::SoundBuffer wouldn't support copy constructors. Were those already there in older versions? Or did the resource classes once inherit from sf::NonCopyable? By the way, the same applies to assignment operators.

In my opinion, the copy constructor at such huge classes is a source of error which shouldn't be underestimated. Implicit conversions happen so fast in C++, for example in the context of function parameters. I agree, experienced C++ programmers must be aware of that (nevertheless, I had to debug several minutes).

But the important point is, I don't see a real use case of the copy constructors. Resources are rarely completely copied. In the few cases they are, functions like sf::Image::Copy() should be sufficient - and are much safer. Wouldn't deriving the SFML resource classes from sf::NonCopyable be a suitable option?

82

General discussions / sf::Rect<> design question

« on: April 28, 2009, 10:56:01 pm »

Hi,

Is there a special reason to store the coordinates of the right and lower edge inside the sf::Rect class template? In my opinion width and height might be more intuitive. For example, you could use unsigned types for both and wouldn't have to assure that the right/down coords are bigger than the left/top ones. Additionally, the (from my point of view) often used width and height can be accessed faster. I know, performance of a subtraction is not really relevant, but consider more complex classes being used as template-argument T. Offset would be easier to calculate, too, and the effort of changing raw literals of image subrects would shrink.

I know, changing the sf::Rect structure is not possible at all, since it would break most SFML code up to now. That's not very tragic, one can easily build wrapper classes or utility functions. Nevertheless, I am wondering what was the crucial point for this design choice.

83

Feature requests / Fix inconsistent identifiers

« on: January 16, 2009, 02:01:57 pm »

Hi, half a year ago I posted in this thread (the second page is relevant). My concern was to clean some of the inconsistences in member function names and to make the interfaces more uniform.

For example, sf::String and sf::Sprite are somehow accessed quite differently, although they have many functionality in common.
- sf::Sprite::GetSize() returns a sprite's width/height.
- In contrast, sf::String::GetSize() returns the character size. I would appreciate something like the font's method GetCharacterSize(), in my opinion that was clearer.
- Instead of GetSize(), there is a GetRect() function at strings, but not at sprites. I'd prefer a GetSize() method like at sprites.

Or sf::View:
- GetRect() to get the rectangle on the screen
- GetCenter() and GetHalfSize() to get two 2D-Vectors which contain the same information as the rect.

Accessing the width and height:
- sf::RenderWindow, sf::Rect, sf::Image have got GetWidth() and GetHeight() functions.
- sf::Sprite has got a GetSize() method.
Here I think that is quite okay, since sprites are used in coordinate systems of the screen. But the sf::Rect seems to me sometimes a little bit questionable (for example at sf::String or sf::View), especially when they can easily be replaced by 2D-vectors. In my honest opinion, sf::String should get a GetSize() method and lose the GetRect() method instead. There is no loss of information as long as there are GetCenter(), GetPosition() and GetSize().

What do you think about those identifiers?

84

General / Separation of logics and graphics

« on: November 21, 2008, 10:17:14 pm »

Hi, up to now i let my objects derive from sf::Sprite. Like this, it was easy to iterate through containers and just write App.Draw(...) using the implicit conversion to base class Sprite.

Now I thought a stricter separation between the game logics (object's positions, velocities, further information like hitpoints, and so on) and graphics (the used image, color, source rect, ...) wouldn't be bad. Even though sf::Sprite is described as small, lightweight class, its size is 132 bytes. And besides of that it contains a lot of unused information (see next passage).

An example is a 2-dimensional sequencial container of tiles. The tiles' position is already given by their index in the container, so using a sprite would double the information. If there are 4 different tile types, it is sufficient for each tile to save the according type - like that, the source rect doesn't have to be changed for each tile. Many variables do not differ between the single elements. The same would be if I used sf::Sprite as an aggregate.

What do you think about this design? I consider it being more abstract and making changes and maintenance of the code easier. Is it a great loss of performance to create each frame lots of new sprites?

85

Audio / Audio compatibility on other computers

« on: September 14, 2008, 09:15:59 pm »

Hi,

It is always the same. On the computer where programs are compiled everything works perfectly, but as soon as I want to use them on other computers, there are problems and errors occuring. :?

In the meantime, I even managed to make programs using SFML graphics run on other systems.  Now I have got the same problem with sound. Sometimes, the program doesn't even start (windows error "... doesn't work any more" (translated)), or it starts, but sound doesn't work, and suddenly, the program is hanging. While not using sound, everything behaves well. In the cmd console window, I get the error message: "Failed to open the audio device".

Before, I just linked statically to the SFML libs and provided the CRT DLLs in the same directory. Now with SFML audio, there are two more DLLs to provide, am I right? These are libsndfile-1.dll and OpenAL32.dll. Are there other dependences?

What could be the reason for those problems? I rather don't want to force the users of my applications to install anything, that's why I provide all the DLLs. I would be glad if you didn't start a discussion about "it's no great thing to install the ... package, other apps need the .NET binding which is much bigger"
If there is a possibility to avoid any downloads, packages, redists and setups, I would like to use it. And I still think there is, since even MSVC redistributable needn't be installed anywhere.

86

Graphics / sf::WindowSettings access violation

« on: September 02, 2008, 08:59:57 pm »

Hi,
when I use the following code:

Code: [Select]

sf::WindowSettings Settings(24, 8, 4);
sf::RenderWindow App(sf::VideoMode(500, 300), "app", sf::Style::Close, Settings);or

Code: [Select]

sf::RenderWindow App(sf::VideoMode(500, 300), "app", sf::Style::Close, sf::WindowSettings(24, 8, 4));, I get the following error:

Uncaught exception at 0x00000000 in Project.exe: 0xC0000005: Access violation.   (translated)

If I set the AntiAliasing value to zero, it works just fine. Every other value leads to crash.
When running in debug mode, it stops in file "WindowImplWin32.cpp" at line 450 (function WindowImplWin32::CreateContext()). The code in this line is:

Code: [Select]

bool  IsValid = wglChoosePixelFormatARB(myDeviceContext, IntAttributes, FloatAttributes, sizeof(Formats) / sizeof(*Formats), Formats, &NbFormats) != 0;The variable myDeviceContext seems to be corrupted, myHandle too. wglChoosePixelFormatARB shows the value 0 (0x00000000), IsValid is true...

The problem is, I reinstalled MSVC++ and redownloaded SFML some days ago - before everything worked fine. I also recompiled the SFML libraries, and I think I am linking to the correct version.

Maybe it's not SFML's fault, since it always worked in past... But I can't really imagine how this can happen...?

87

General / sf::Vector2i overloading operator <

« on: August 11, 2008, 02:04:04 pm »

Hi,
I need to overload operator < for the sf::Vector2i struct because I use a std::map with it as a key value, and for the intern sort criterion I use std::less which requires operator <. Now I tried the following:

Code: [Select]

bool operator <(sf::Vector2i Left, sf::Vector2i Right)
{

if (Left.x != Right.x)
return (Left.x < Right.x);
else
return (Left.y < Right.y);
}

There are many errors. So I placed it into namespace sf:

Code: [Select]

namespace sf
{
bool operator <(sf::Vector2i Left, sf::Vector2i Right)
{

if (Left.x != Right.x)
return (Left.x < Right.x);
else
return (Left.y < Right.y);
}
}
which works.

Now I have doubts if this is the good way to solve it. Doesn't it matter if I expand the sf-namespace myself?

88

General / [Solved] Linking errors at sf::RenderTarget - new subversion

« on: July 06, 2008, 01:11:13 pm »

Hi,
I just downloaded the current SVN version of SFML. But when I try to run my program, I get the following linker errors:

Code: [Select]

1>Project.obj : error LNK2001: Nicht aufgelöstes externes Symbol ""public: class sf::View & __thiscall sf::RenderTarget::GetDefaultView(void)" (?GetDefaultView@RenderTarget@sf@@QAEAAVView@2@XZ)".
1>Project.obj : error LNK2001: Nicht aufgelöstes externes Symbol ""public: void __thiscall sf::RenderTarget::SetView(class sf::View const &)" (?SetView@RenderTarget@sf@@QAEXABVView@2@@Z)".
1>Project.obj : error LNK2001: Nicht aufgelöstes externes Symbol ""public: virtual void __thiscall sf::RenderTarget::Draw(class sf::Drawable const &)" (?Draw@RenderTarget@sf@@UAEXABVDrawable@2@@Z)".
1>sfml-graphics-s.lib(RenderWindow.obj) : error LNK2001: Nicht aufgelöstes externes Symbol ""public: virtual void __thiscall sf::RenderTarget::Draw(class sf::Drawable const &)" (?Draw@RenderTarget@sf@@UAEXABVDrawable@2@@Z)".
1>sfml-graphics-s.lib(RenderWindow.obj) : error LNK2001: Nicht aufgelöstes externes Symbol ""protected: __thiscall sf::RenderTarget::RenderTarget(void)" (??0RenderTarget@sf@@IAE@XZ)".
1>sfml-graphics-s.lib(RenderWindow.obj) : error LNK2001: Nicht aufgelöstes externes Symbol ""public: virtual __thiscall sf::RenderTarget::~RenderTarget(void)" (??1RenderTarget@sf@@UAE@XZ)".
1>sfml-graphics-s.lib(RenderWindow.obj) : error LNK2001: Nicht aufgelöstes externes Symbol ""protected: void __thiscall sf::RenderTarget::Initialize(void)" (?Initialize@RenderTarget@sf@@IAEXXZ)".
1>sfml-graphics-s.lib(RenderWindow.obj) : error LNK2001: Nicht aufgelöstes externes Symbol ""public: class sf::View const & __thiscall sf::RenderTarget::GetView(void)const " (?GetView@RenderTarget@sf@@QBEABVView@2@XZ)".

I am running in release mode, I also rebuilt the SFML version in static release configuration.

I use the CRT version Multithreaded-DLL (/MD). Additional linker dependencies are:
sfml-graphics-s.lib sfml-window-s.lib sfml-system-s.lib

The path C:\...\SFML\lib\vc2008 is added to library directories, too. I really don't know what is wrong because my previous SVN version (before release of v1.3) worked without problems. And after recompiling the SFML source it should work fine, shouldn't it? Or is the sf::RenderTarget class not ready to use yet or still bugged?

Edit: Seems to be a bug in SVN, the official SFML version 1.3 works fine.

89

General / New SVN Version

« on: June 08, 2008, 07:30:02 pm »

Hi,
Today I updated from SFML 1.2 to the new SVN version.
I see, there are many changes. Some new features are quite nice, for example the sf::Shape class. But some I can't really understand.

For example:

Code: [Select]

sf::Sprite::GetLeft();        // old
sf::Sprite::GetPosition().x;  // new

sf::View::GetWidth();    // old
sf::View::GetSize().y;   // new


The fact of typing more is not even the worst. The names of the functions seem to be quite random, sometimes there is still GetWidth(), and sometimes that GetSize().x. What's the point of making the names so inconsistent? Do you just want to have an own Getter for specific properties (position, rotation, size, scale)?

And the other thing is, everything has to be an own class now. For me, there's currently too much OOP in SFML. For example, you can't just write a normal sf::String constructor. Instead, the font has to be an own class (a string doesn't seem to be sufficient) which unfortunately doesn't own any specific constructors. The sf::WindowSettings struct is another example.

Up to now, I have been really impressed by SFML, but now I am a little bit deceived. Couldn't there be a possibility to at least add the old GetX() and GetWidth() again? And why did you change "Left" to "X" and "Top" to "Y"? Before it was much clearer.

90

Feature requests / sf::Clock Improvement

« on: May 03, 2008, 01:03:08 am »

Hi
What do you think about some more features to the sf::Clock class?
For example a function which could pause the timer would be useful. Setting the time to a given float parameter might be of advantage, too.

I think adding a Pause() and SetTime(float Time) function shouldn't be a big problem - or does it upset the whole system because you can't just take the difference between starting and current time anymore?.