Messages

961

General discussions / SFML 1.3 and OS X

« on: November 30, 2008, 07:40:42 pm »

I can't test it on Tiger, but it's built for it.

At the time I'm writing this, I'm even trying to see whether I can get it to work with the 10.3.9 SDK. It's supposed to, but there seems to be missing files in the SDK...

And also at the time I'm writing this last sentence, the tutorial is almost done. Just checkin' a few last things..

962

General discussions / SFML 1.3 and OS X

« on: November 30, 2008, 04:13:43 pm »

That's what I'm about to write. The installation tutorial also explains how to get started in using SFML ^^.

More exactly :
 - how to install SFML
 - how to use SFML in Xcode (from my Xcode project templates or from scratch)
 - how to compile SFML

963

General discussions / SFML 1.3 and OS X

« on: November 30, 2008, 02:33:02 pm »

Tell me when you are done with the install. I'll write a tutorial for the SFML Tutorials and send to Laurent.

Uh.. I don't understand. Which tutorial do you wish to write ?

964

General discussions / SFML 1.3 and OS X

« on: November 28, 2008, 07:52:49 pm »

Some news !

No change in the todo roadmap.
But some improvements with full screen mode : when you hide a SFML application that is displaying a full screen window, it will automatically switch back to the desktop display mode (resolution). Same when unhiding the app.

The frameworks are now built in sfml/lib/xcode.


And... as you may know, the SFML 1.4 release is coming soon. But an important point is that until I find an really important issue and can't fix it, the Mac OS X port will come with this release. I'm currently working on the installation tutorial and the Xcode project templates.

965

General discussions / SFML 1.3 and OS X

« on: November 28, 2008, 03:37:16 pm »

1. Because I did not update the Xcode projects for the samples. I could do so quite quickly if you wish. I just didn't care of it.
2. Because I never thought of doing so. Till now, I let Xcode put the frameworks in the default build directory. I'm going to fix this now.
3. Nop, because you would no more be able to use <SFML/...> as include paths. That is the only point.

966

General discussions / SFML 1.3 and OS X

« on: November 08, 2008, 06:55:06 pm »

Okay, thanks !

967

General discussions / SFML 1.3 and OS X

« on: November 08, 2008, 04:12:10 pm »

Some news...

I added a fade operation for the resolution switching in full screen mode.

So, now the current roadmap (high priority, low priority):

To do:
- joysticks handling

To fix:
- SFML windows cannot be used properly in common Cocoa applications without messing up the event loop
- there are missing keys (as an Apple keyboard does not have the same keys as an PC's one)
- for the sf::Event::KeyPressed events, only the main keys are keyboard layout independant. sf::Event::TextEntered events are not affected.
- characters needing several followed keys are not handled
- the Shift, Control, Option (Alt) and Command key do not produce repeated events

968

Feature requests / sfml equivalent of GetMessage()

« on: November 03, 2008, 07:58:42 pm »

First of all, there is absolutely no gaurantee that the operating system will clean up your mess (show me in the C++ standard where it says it will and I'll buy you each a car).

Yes there is, for any modern operating system. And it does not depends on a programming language.

If there was, you wouldn't see languages like Java implementing automatic garbage collection.

Except if it was to allow lazy programmers not to take care of memory handling.

What you just said is the same thing as a pilot saying he can just jump out of his plane instead of landing it safely because his parachute will keep him from falling to his death.

But here there is no plane crashing :].

Definitions are, by definition (har har), inflexible.

But interpretations are not. That is the point here.
You have your way of seeing the things, which does not always mean it is the good one.

I don't feel like we're fighting since nothing off-topic or personal has been said.  I'm just not the type to acquiesce when I know I'm right.

Lol . *sorry for the useless comment*

969

Feature requests / sfml equivalent of GetMessage()

« on: November 03, 2008, 01:23:36 pm »

Popularity and quality should be the same thing (unless one desires to only be popular among users who don't know any better...I wouldn't if it was my library).

Nop, because it you care about everyone, you won't force users to take care of thread safeness (that may indeed improve performances).

If window events are that coupled to rendering (who says your current render-target has to be the back buffer?), then your architecture is flawed.  If such a blocking call existed, then it should be possible to call it on a separate thread than the one swapping the frame buffers.  There is no "polling loop" in that scenario.  "Polling" is akin to constantly asking the question "did anything happen yet?", while a rendering loop is constantly stating "draw this".

Okay. I was only thinking of the common event and drawing loop :

Code: [Select]


while(running) {
    // get all events
    // draw
}

This would prevent from drawing if you use blocking events.
Now... I do not know enough about multi-threading issues to tell whether you can safely call for buffer swaping from a separate thread.

[...]  It is ALWAYS possible for a program to free memory it has allocated.  [...]

But what for ? If it was to be freed, it would be just before the program exits. Therefore it is useless.

970

Feature requests / sfml equivalent of GetMessage()

« on: November 02, 2008, 11:28:36 am »

Hm.. yeah, as soon as I know a bit more about the topic :lol: .

971

Feature requests / sfml equivalent of GetMessage()

« on: November 01, 2008, 11:27:06 pm »

Waiting for crashes in order to fix the problems just does not seem to be a good idea to me.

972

Feature requests / sfml equivalent of GetMessage()

« on: November 01, 2008, 10:19:53 pm »

But on the other side you can't wait for crashes...

973

Feature requests / sfml equivalent of GetMessage()

« on: November 01, 2008, 10:00:22 pm »

That's basically what I meant
But it's impossible for me to test every single combination of possible multi-threaded situations. So I need feedbacks, but I get only very few of them.

Then why not protect everything you can ?

974

Feature requests / sfml equivalent of GetMessage()

« on: November 01, 2008, 09:42:59 pm »

This sounds somewhat approximative to me...

975

Feature requests / sfml equivalent of GetMessage()

« on: November 01, 2008, 08:09:36 pm »

I meant thread safeness (safety ?).

But... I don't know much about this topic. Doesn't the main thread need to be thread-safe in order to allow the use of threads "on top of SFML" ?

And by the way, any Mac OS X application already uses multi-threading for the event handling. Do I need to take care of this ?