Messages

16

Feature requests / Rotating views

« on: April 23, 2008, 11:13:36 pm »

Currently, SFML does not have rotatable views. This feature has been suggested before; http://www.sfml-dev.org/forum/viewtopic.php?t=311.

I'd say if you just want to rotate your scene, do it with custom OGL calls. If you want something more complex you could always add it to SFML yourself.

17

D / DSFML (a port to the D language)

« on: April 20, 2008, 03:33:34 pm »

Looks good. I'm looking forward to trying it out.
Regarding the linking, what benefits other than being able to use the library without an import library does the first build option give, if any?
In what way was dynamic loading of symbols easier to handle? Personally I don't mind creating an import library or a bit of more hassle if that gives me better functionality.

18

D / DSFML (a port to the D language)

« on: April 15, 2008, 10:26:32 pm »

BTW: Do you know any good D IDE (offering code completition etc.)?

Code::Blocks support D to an extent but unfortunately lacks support for code-completion for it.

Although I haven't used it, Poseidon seem to be still developed on and have quite a following. http://www.dsource.org/projects/poseidon
AFAIK it supports code-completion.

19

D / DSFML (a port to the D language)

« on: April 15, 2008, 10:22:04 pm »

I see, so you are wrapping the C interface with classes? This is what I wanted to avoid, hence the port.

As you said there don't seem to be a good solution until D 2.0 is stable enough. May I ask how you were thinking of linking with the C++ code on 2.0? I haven't really looked at 2.0 yet since I'm just starting out.

But your way is probably the best one for now as it's easier to maintain when going from one SFML version to another.

I think I'll keep my version though, since I only need the Windows package for now. And the interfaces seem to be identical.

At least it's good to see that there's an interest in maintaining a D binding.

Edit: Did you consider how to create a shared sf namespace for all the packages? Not that it's a big of a problem but it would help creating a consistent interface with the other bindings.

Edit2: You mentioned you use Derelict to load symbols from the DLL. How does this affect the license? Isn't Derelict licensed as LGPL? This was also one of the reasons I decided to port SFML.

Edit3: Ah sorry I probably should have looked that up. Looks like the Util library uses a modified zlib/libpng license?

20

D / DSFML (a port to the D language)

« on: April 15, 2008, 08:56:19 am »

Ah, I'm too late then.
I'm very interested in seeing how a bind is made possible.

21

D / DSFML (a port to the D language)

« on: April 15, 2008, 12:40:51 am »

Hi!
I've recently picked up on the D language (http://www.digitalmars.com/d/) and wanted to start developing some games for it. But D can only directly link to C object files and not C++ and because of that the only multimedia libraries availiable have C bindings.

Therefore I decided to create a port of the SFML library with the goal of providing an interface as close to the C++ version as possible. I use version 1.2 as the reference since I wanted a stable interface to port so that the interface wouldn't change as I ported it.

Currently I have as good as ported the whole Window interface aswell as the Win32 implementation. (I haven't implemented joystick support yet, but it would be just a matter of converting the C++ code to D.) The interface is almost identical to the one found in C++. The only differences are the use of .'s instead of :'s and the use of modules and imports instead of header files. Which makes the tutorials still apply with some minor changes.

Some parts of the System package are also ported as they are required by the Window package. Cross-platform threads and mutexes are implemented by the D standard library so there's not much need for porting them.

Currently the Win32 implementation of the Window interface is all I need, so I probably won't be adding other packages to the port unless I find them useful in the future.

If anyone's interested in taking a look or maybe port other parts of SFML I'd happily send it over.

22

General / Recompile SFML issue

« on: March 27, 2008, 11:48:50 pm »

Ah okay.
In these times Google is your best friend. Google the errors/warnings and your bound to find similar problems.

That's as far as I can help I'm afraid.

Edit: After googling for 3 min I found this page regarding the conflicting libs: http://www.jenkinssoftware.com/raknet/manual/faq.html.

LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library

You need to select Multithreaded Debug and Multithreaded libraries in the project options.

Edit2: it looks like "nonstandard extension used : nameless struct/union" is a level 4 warning and won't make your life miserable. But you could try updating your Platform SDK to get rid of them.

Bah! Now I've done all the work for you. Good thing I don't have anything better to do.

23

General / Recompile SFML issue

« on: March 27, 2008, 11:24:28 pm »

I'm not really that familiar with Visual Studio, but you mentioned in the other thread that your version was over 5 years old. Then it's probably time to update your IDE.

You can get Visual Studio 2008 Express here.

As you've probably noticed, SFML only include project files for VC 2005/2008. So install either of them and it should compile fine.

24

Graphics / Draw on wxWidgets with double-Buffering

« on: March 27, 2008, 12:50:34 pm »

Download http://tortoisesvn.tigris.org/ and then do a SVN checkout on https://sfml.svn.sourceforge.net/svnroot/sfml

Easy as pie.

Edit: Oh I see what you're doing now. You can't checkout the https://sfml.svn.sourceforge.net/viewvc/sfml page. You need to use the checkout directory I've written above.

25

Graphics / GraphicsDevice.cpp - std::mem_fun

« on: March 26, 2008, 12:53:14 pm »

Alright, I did some more digging in the STL and I finally found it. In the SVN version you have included SFML/Window/Window.hpp which in turn includes the 'queue' STL header which in turn includes 'functional', at least in STLPort.
In 1.2 you don't include Window.hpp so functional does not get included when I compile it.

Then I don't know if 'functional' is included in other headers or why it does compile with other STL implementations.

But 'functional' should be included anyway and takes care of the problem.

26

Graphics / GraphicsDevice.cpp - std::mem_fun

« on: March 26, 2008, 02:47:36 am »

I know, that's why I thought I should mention it.
But I don't know why it compiled this time, maybe you have included the header someplace else?

I can do some more test builds with the 1.2 version to see if it produces the same error, maybe it's just me who screwed up.

27

Graphics / GraphicsDevice.cpp - std::mem_fun

« on: March 25, 2008, 11:04:04 pm »

I just wanted to add that I had no trouble compiling the SVN version I downloaded earlier today.

28

Window / Window creation (Linux)

« on: March 25, 2008, 10:58:21 pm »

There is a routine for fetching the desktop resolution (sf::VideoMode::GetDesktopMode()).

But I agree with Aszarsha, it should be handled by the user not SFML, the default behavior of the OS should be preserved.

To make it more convenient there could be a sf::Style::Centered.

29

Graphics / GraphicsDevice.cpp - std::mem_fun

« on: March 25, 2008, 12:18:52 am »

I've been following the progress of SFML for a while now and I really like the simplicity of the interface.

I recently started using STLPort instead of the STL that comes with MinGW and ran into an error when compiling SFML 1.2 regarding std::mem_fun not being found in GraphicsDevice.cpp. I've had no troubles compiling it before so I thought it was weird and looked it up. It seems like mem_fun is supposed to be defined in the STL header 'functional'. So I included it and it compiled.

I just thought you'd like to know if you weren't aware of it already.

30

General discussions / SFML but 3d

« on: March 20, 2008, 04:12:27 pm »

If you want a 3D graphics engine with a clean and simple interface, you should take a look at http://www.horde3d.org. It's still pretty early in development but has got a lot of nice features already implemented.
It is fully shader driven and has got SM2.0 as a minimum requirement. (GeForce 6600 >) It has it's own custom model format and supplies a COLLADA converter which should make it easy enough to load your assets into the engine. I can't recommend it though since I haven't used it more than messing around with the examples, but it sure looks good from what I've seen.

If you want your game to run on older hardware I would recommend Irrlicht too. It's far less bloated than Ogre3D and it's fairly simple to use, got a very unrestrictive license (zlib/libpng) and the documentation is pretty good also. We use it for one of the projects I'm currently working on, the only thing we've been having troubles with is creating/importing animations for our models.