Messages

16

General / VS2013 linker problems

« on: October 06, 2014, 03:31:06 pm »

Hi

Using the latest SFML built with VS2013, when I link my game project I get lots of unresolved externals, stuff like this:

Error   3   error LNK2001: unresolved external symbol __imp__glBindTexture@8   C:\Projects\game\sfml-graphics-s-d.lib(Texture.obj)

Error   7   error LNK2001: unresolved external symbol __imp__glGetIntegerv@8   C:\Projects\game\sfml-graphics-s-d.lib(Texture.obj)

Error   139   error LNK2019: unresolved external symbol __imp__timeGetDevCaps@8 referenced in function "void __cdecl sf::priv::sleepImpl(class sf::Time)" (?sleepImpl@priv@sf@@YAXVTime@2@@Z)   C:\Projects\game\sfml-system-s-d.lib(SleepImpl.obj)


...I have built the SFML libraries as static....so I think this is a problem with the libraries I've build rather than the game. What have I missed.....?

Thanks
Ed

17

General discussions / Re: SFML 3 - What is your vision?

« on: May 08, 2014, 05:14:09 pm »

I think this thread is going a bit OT (probably my fault in a lot of ways) but its a good debate to have.

If the SFML community can get its heads together and decide what it wants, with some solid reasons *why* it wants it and what it needs (both in time and money) to achieve the goals, then I can certainly look to get some funding in place.

..and no, buying everyone a new tablet isn't an option. Buying core developers one, however, certainly is.

18

General discussions / Re: SFML 3 - What is your vision?

« on: May 08, 2014, 10:22:42 am »

Just out of curiosity, if you're allowed/willing to tell us. Which company do you work for? In what kind of kiosks does SFML get used?
I mean in the end, one could always discuss/think about something like a partnership - libraries that are backed by companies often gain in popularity and over all code quality. Not that this is in any way my decision to make, just thought I throw it out there.

I'm the CTO of Betdigital in the UK. We're a small team - 5 coders (inc myself) and 4 artists. We develop casino style games for gaming terminals and online casinos, etc. Google us

We would almost certainly support SFML financially on a more permanant basis. Laurent and I have kind of discussed this in the past, and it's something I have on my list to sort out this year, especially since we are moving towards mobile games more and more. With the port to Android and iOS, it makes SFML even more attractive for commercial use, and so we have an obligation to support it as best we can.

19

General discussions / Re: SFML 3 - What is your vision?

« on: May 07, 2014, 01:08:43 pm »

As such a move to C++11 will enforce the "S" even more.

..and people who don't use C++11 will have to go and learn a whole new set of skills. A good thing, but you're only going to get questions from people who don't know it inside out. Allow it, but don't enforce it.

To be honest, it's not SFML's concern at all, how a company spends their money and whether it's too expensive to upgrade or not.

Indeed. But there are real people who want to make games or whatever using SFML, who maybe don't have much money, and so buying new hardware also isn't an option.

Overall, you should not forget that everything we do here, is done for free.

I know, but also remember that there are companies and individuals who donate hundreds, if not thousands of Euros every year to allow the purchase of hardware, etc, which also allows the project to continue...

20

General discussions / Re: SFML 3 - What is your vision?

« on: May 07, 2014, 11:00:39 am »

slotdev, those applications sound really interesting. Do you see other SFML modifications that could affect the mentioned systems, such as moving from C++98 to C++11?

Maybe in general, are there many people bound to compilers that don't even support basic C++11 (i.e. VS <2010, g++ <4.6)?

There are for sure, in more industrial/commercial environments, a lot of people still use VS2008. Personally, I still use VS2005 for "systems" development and VS2010 for actual application (game..) development. So, enforcing C++11 could be a problem.

I worry we will lose the "S" in SFML.

Talking about industrial applications; you have to remember that replacing many thousands of PCs is very expensive - not only in the cost of the hardware, but the time and people required to do it. That is why it takes many years to update. Our oldest system we have to support is an Intel Celeron II based PC with 32mb VRAM. This is a nightmare, but we must do it.

Tank - the problem is more of a support one. If there is a major bug discovered, who is going to fix it? There is no incentive for people to work on 2.1 or whatever when 3.0 is the focus.

21

General discussions / Re: SFML 3 - What is your vision?

« on: May 06, 2014, 11:18:37 pm »

If you watch Valve during the Steam Dev Days their hardware survey shows very little legacy hardware out there. Unless you are dealing with Intel cards that are pre 2012 then you'll have core profile support.

But this is SFML, and unless I am mistaken (I hope that I am!), it is not used for high end games such as you would get from proper game studios?

Why wouldn't it work to just use SFML < 3.0 for legacy stuff?

Because the maintainance of the library becomes an issue - who is spend time fixing bugs on 2.1?

It's also been stated that SFML 3.0 is a ways out. Are you saying that by the time 3.0 comes out you are still going to be dealing with a "huge" number of people who can only run OGL 2.1?

Yes, on nearly 63,000 systems to be precise. Some very old systems (Intel Extreme Graphics!) can only use OGL 1.0! We use SFML commercially, and need to support these legacy systems. Sure, they will be phased out over time, but we are talking maybe 3 years from now - minimum.

I realize right now there is probably a lot of people with pre 2012 Intel GPUs, but we are talking the future. It would be naive to think people won't ever upgrade their hardware, let alone people who play games.

There are a heck of a lot. You're forgetting that SFML lends itself very well to automated systems, and I know for a fact that it is used in kiosk, ATM & vending applications.

22

General discussions / Re: SFML 3 - What is your vision?

« on: May 06, 2014, 08:35:34 pm »

I'm just getting started with SFML but I'll put in my 2 cents so far.

C++11 required
OpenGL 3.2+ Core Profile (for desktop OGL).

Both of those offer performance improvements right off the bat. Mesa already has OGL 3.3 support so I think it's getting to that time when we drop legacy OGL and compatibility profiles.

I disagree - there are still a huge number of PCs out there with "legacy" OGL. Implement the new features of 3.3+ by all means, and allow people to use them, but don't break it for people who don't have modern systems.

23

General discussions / Re: SFML 3 - What is your vision?

« on: May 06, 2014, 08:32:48 pm »

My vision is: not breaking the codebase on which I have done many, many projects which need maintaining

24

Graphics / Re: Texture Update memory wierdness

« on: April 02, 2014, 04:16:21 pm »

I will do - but more testing with a newer version of SFML does not show this problem, so for this (old) project I am working on, I have to check the difference between the two SFML versions.

EDIT: Do you remember why this line was added (Texture::Update line 1252)

// Make sure that the current texture binding will be preserved
        priv::TextureSaver save;

?

25

Graphics / Re: Texture Update memory wierdness

« on: April 02, 2014, 01:28:00 pm »

Nexus, its just another SFML window, which is cleared & redrawn every frame in time with the main window.


More background: I use Berkelium, an "off screen" web browser which copies pixel data to a buffer, and then posts a callback telling us the buffer is updated. I then copy this buffer to the SFML texture and display on screen. This works 100% OK but I just get this strange memory problem.

26

Graphics / Texture Update memory wierdness

« on: April 02, 2014, 01:20:33 pm »

Hi

I've got a strange bug where when I call "update" on a texture, with a pointer to my pixel buffer, then draw the texture, it displays correctly on the target window but *also* displays in stretched & smeared form on another window, positioned directly below the main (target) window.

It seems like a memory problem, or as if the update function is just running over the end of something....

Does anyone have any ideas??

Thanks
Ed

27

General / Linker errors on latest SFML..

« on: March 12, 2014, 10:14:21 am »

Hi

Just downloaded and compiled latest SFML version. I am getting loads of unresolved externals when I build the game. What has changed that I've missed (I did a search of the forums, and found nothing). Do I need a later version of CMAKE??

1>sfml-graphics-s-d.lib(RenderTarget.obj) : error LNK2019: unresolved external symbol __imp__glClear@4 referenced in function "public: void __thiscall sf::RenderTarget::clear(class sf::Color const &)" (?clear@RenderTarget@sf@@QAEXABVColor@2@@Z)
1>sfml-graphics-s-d.lib(RenderTarget.obj) : error LNK2019: unresolved external symbol __imp__glClearColor@16 referenced in function "public: void __thiscall sf::RenderTarget::clear(class sf::Color const &)" (?clear@RenderTarget@sf@@QAEXABVColor@2@@Z)
1>sfml-graphics-s-d.lib(RenderTarget.obj) : error LNK2019: unresolved external symbol __imp__glDrawArrays@12 referenced in function "public: void __thiscall sf::RenderTarget::draw(class sf::Vertex const *,unsigned int,enum sf::PrimitiveType,class sf::RenderStates const &)" (?draw@RenderTarget@sf@@QAEXPBVVertex@2@IW4PrimitiveType@2@ABVRenderStates@2@@Z)
1>sfml-graphics-s-d.lib(RenderTarget.obj) : error LNK2019: unresolved external symbol __imp__glTexCoordPointer@16 referenced in function "public: void __thiscall sf::RenderTarget::draw(class sf::Vertex const *,unsigned int,enum sf::PrimitiveType,class sf::RenderStates const &)" (?draw@RenderTarget@sf@@QAEXPBVVertex@2@IW4PrimitiveType@2@ABVRenderStates@2@@Z)
1>sfml-graphics-s-d.lib(RenderTarget.obj) : error LNK2019: unresolved external symbol __imp__glColorPointer@16 referenced in function "public: void __thiscall sf::RenderTarget::draw(class sf::Vertex const *,unsigned int,enum sf::PrimitiveType,class sf::RenderStates const &)" (?draw@RenderTarget@sf@@QAEXPBVVertex@2@IW4PrimitiveType@2@ABVRenderStates@2@@Z)
1>sfml-graphics-s-d.lib(RenderTarget.obj) : error LNK2019: unresolved external symbol __imp__glVertexPointer@16 referenced in function "public: void __thiscall sf::RenderTarget::draw(class sf::Vertex const *,unsigned int,enum sf::PrimitiveType,class sf::RenderStates const &)" (?draw@RenderTarget@sf@@QAEXPBVVertex@2@IW4PrimitiveType@2@ABVRenderStates@2@@Z)
1>sfml-graphics-s-d.lib(RenderTarget.obj) : error LNK2019: unresolved external symbol __imp__glPushMatrix@0 referenced in function "public: void __thiscall sf::RenderTarget::pushGLStates(void)" (?pushGLStates@RenderTarget@sf@@QAEXXZ)
1>sfml-graphics-s-d.lib(RenderTarget.obj) : error LNK2019: unresolved external symbol __imp__glMatrixMode@4 referenced in function "public: void __thiscall sf::RenderTarget::pushGLStates(void)" (?pushGLStates@RenderTarget@sf@@QAEXXZ)

Loads of others like ___glewDeleteFramebuffersEXT, __imp__alSourcei, __imp__inet_ntoa etc etc

Thanks

28

General discussions / Re: Android and iOS ports available for testing

« on: March 11, 2014, 02:41:30 pm »

Which version of the Android NDK should I be using for this? r9d, and (I assume) 64 bit given I'm on a 64 bit Windows 7 system. I have VS2010 too.

29

Feature requests / Re: VideoMode taking XY positions

« on: March 11, 2014, 01:17:46 pm »

Sounds good to me!

30

Feature requests / VideoMode taking XY positions

« on: March 11, 2014, 12:40:39 pm »

Hi

I'd like to request that a VideoMode's constructor be modified to take an xy position, with a default parameter of 0,0 (?). On certain hardware platforms we use, we cannot open a window, and then move it using setPosition. So we have had to modify SFML to create a window at its final position, which others may find useful too.

e.g. in VideoMode.cpp

VideoMode::VideoMode(int xPos, int yPos, unsigned int modeWidth, unsigned int modeHeight, unsigned int modeBitsPerPixel) :
XPos            (xPos),
YPos            (yPos),
width       (modeWidth),
height      (modeHeight),
bitsPerPixel(modeBitsPerPixel)
{
}
 

and in WindowImplWin32.cpp constructor:

    int left   = mode.XPos;
    int top    = mode.YPos;