Messages

31

General discussions / iPhone Port (in progress)

« on: April 15, 2009, 09:51:45 pm »

I think you guys are missing the point. Yes I can redefine main and have the user take over after the window is initialized however by doing that you end up taking over the main loop and that causes apple's event callbacks not to work properly.

In that case it seems that threading is the only decent option.

Any idea how SDL did it? That might help.

32

General discussions / iPhone Port (in progress)

« on: April 15, 2009, 09:27:41 pm »

But, if I understand correctly, the problem is that you can have a main in iphone, but not process events in this functions because iphone will call some function of yours in order to notify events in a callback fashion. How to handle that without breaking SFML's model?

Oh, I see...

SFML already stores events in a queue anyway, so there's no reason that those callbacks can't add events to the queue too (might require some synchronization, but still..)

33

General discussions / iPhone Port (in progress)

« on: April 15, 2009, 12:13:12 pm »

The biggest issue I have is that the iPhone likes to take over the main loop. If you block the iPhone's main loop events don't get triggered like touches and the accelerometer. The only good way to deal with this issue is have SFML define a "main" function that the user must implement for setting up the application, then you would have to register a callback function for updating the application. Another alternative would be to have the main function threaded however I see this causing all sorts of problems. Until we figure out how to deal with this issue I won't be developing this port.

#if defined(IPHONEOS)
#define main SFML_main
#endif

If it's unavoidable for the iPhone to take over the main function, let it, and just call the user's main when it makes sense to.

Threading on the iPhone more than necessary probably isn't a good idea.

34

General discussions / SFML 2.0

« on: April 14, 2009, 11:27:17 pm »

Idk if it has been discussed before, but maybe some sort of process control would be a good addition.

Being able to spawn new processes and such. Sure would be useful to me!

I think that it goes beyond the scope of SFML. And there are already good libraries for this stuff (boost::process).

boost::process seems pretty BA, but isn't it still in the sandbox?

35

Feature requests / cross platform clipboard support?

« on: April 12, 2009, 07:30:28 pm »

Just how to add data to the clipboard and get data from the clipboard, which follows similar semantics on every system and would be a very small addition to the library.

Clipboard support is a little more complicated than that. You can have several types of data, which can be text-based or not.
Anyway, it's not the point, I still have too many things to do before thinking about a possible clipboard support.

Well, yes, there's multiple types of data.

I could write clipboard functions for Win32 and Unix/X11, but I don't have Mac OS X so I couldn't test anything for that. You don't need to do it all yourself, but if it wasn't going to be used anyway I wouldn't waste my time on developing it..

36

General discussions / iPhone Port (in progress)

« on: April 12, 2009, 07:28:20 pm »

I also agree with that, but from my experience with the iPhone [and many other handhelds] it doesn't really seem to have any "window", which makes the names sf::Window and SFML-Window misleading...

True. But I have a simple solution to that:

Code: [Select]

typedef Window Screen;
:lol:

xD

It would work at least...

37

Feature requests / cross platform clipboard support?

« on: April 12, 2009, 04:47:52 pm »

Arguably so is threading (except internally as required for seamless cross-platforming) and networking definitely is, yet SFML provides those.

Everything which is in sfml-system is not purely related to multimedia, it's more a core package on top of which every other package is built.
Network perfectly fits in a multimedia library. If a medium is a "storage and transmission tool used to store and deliver information or data" (wikipedia), then network is definitely one

x.x

Copying is used in most graphical applications, from text editors to image manipulation programs to video games to web browsers. So I would certainly say it's not at all a bad idea to provide clipboard functionality.

So as tons of features related to GUI and windowing. But I can't make SFML as rich as Qt or wxWidgets. Even if I wanted to, I couldn't, there are so many things that have to be done before thinking about such things.

Well I wouldn't want that, either. I like the freedom to develop my own GUI and have it work internally exactly how I want, and without bloat added so that everyone can have the GUI work exactly how they want.

However, clipboard is not really related to GUI at all... I'm not expecting SFML to handle copying and pasting for me, and definitely not how to use information on the clipboard (IE, rendering an image).
Just how to add data to the clipboard and get data from the clipboard, which follows similar semantics on every system and would be a very small addition to the library.

Code: [Select]

std::string text = sf::clipboard::getData();
...
sf::clipboard::addData(text);
It really just needs to be that simple.

38

General discussions / iPhone Port (in progress)

« on: April 12, 2009, 04:37:41 pm »

I agree completely with the reason for separating it from traditional computers, but the name should be more generic... SFML-handheld maybe?

That sounds a good idea, but what about people who want to make games for both PC and handheld devices? It would be better if they could use the same package with some tweaks, rather than having to use two different packages.

I also agree with that, but from my experience with the iPhone [and many other handhelds] it doesn't really seem to have any "window", which makes the names sf::Window and SFML-Window misleading...

@up: Don't think you quite understood what he was saying.

39

General discussions / SFML Q/A

« on: April 12, 2009, 04:34:24 pm »

Hi

1) For now, only X11 / OpenGL is supported for Linux. I don't know much about what Android uses, but I'd be glad to help you I you want to try porting SFML to this OS

2) Probably in the future, but right now it's not in the roadmap.

3) This is an interesting feature, and I guess it's mandatory for multi-touch devices like the iPhone. So yes, SFML will support it one day.

1) From what I understand it uses Linux framebuffer, but all I have to support that is what I've found with google.

2) OK

3) Good, although I'd also have a use for it with computer gaming [multiplayer] too.

About Android. If I remember right, Google uses a modified version of Gnome Mobile for the Android System so I recommend that you use that API to work with the Mobile in order to get a good and compatible interface with the cellphone. Though it was long ago I read about Android so I might be wrong about GNOME.

Anyway I do know that Android hands a SDK specifically to develop applications for the Android OS. I think that is much more powerful than SFML or SDL if you want to develop for Android.

Thing with that is I'd also want to develop the same thing for the iPhone (which someone is already porting SFML too) and probably a prettier version for the computer. So simply using the system's own API instead of SFML would only make my project bigger than it needs to be.

And the Android SDK is for Java developers, and Android's default Java VM does not JIT compile; so if I want to make an application that demands at least decent performance then that is definitely not the right path for me. Besides that, I haven't touched Java since I first started learning how to program, and I don't really want to touch it again as developing in it was not fun to me.

40

Feature requests / cross platform clipboard support?

« on: April 11, 2009, 08:12:13 pm »

I think clipboard support is clearly out of scope for a multimedia library.

Arguably so is threading (except internally as required for seamless cross-platforming) and networking definitely is, yet SFML provides those.

Copying is used in most graphical applications, from text editors to image manipulation programs to video games to web browsers. So I would certainly say it's not at all a bad idea to provide clipboard functionality.

41

General discussions / SFML Q/A

« on: April 11, 2009, 06:59:00 pm »

Being as I'm a C++ developer with most of my programming experience being with Object-Oriented code, I really like [the idea of] SFML, but have yet to use it and am not really interested in switching from SDL until I have a few questions answered:

1) Does SFML support multiple graphics backends on Linux? Specifically I'm interested in porting SFML to Google Android to develop programs for smartphones using Android, but I know nothing about using linux fbcon so if this backend already exists in SFML it makes that much easier.

2) Is there any plan in the future for SFML to support multiple displays, like is planned for SDL 1.3 and already present in libggi?

3) Does SFML, or will it ever, support multiple mice and detect when mice are attached or detached? From my understanding SDL 1.3-SVN already has this, and it's a feature that I personally would have a purpose for.

42

General discussions / iPhone Port (in progress)

« on: April 11, 2009, 06:36:43 pm »

The accelerometer is sorta like a gyro, it tells how much the phone has accelerated in the certain direction when moved.

G1, Blackberry storm, and some other smartphones have accelerometers too. Wiimotes also have one.
So, adding accelerometer support to SFML is good for porting to other systems in the future as well.

I've been thinking and since the iPhone device is so different from the computer I think that I shouldn't even use SFML-Window but rather make a new package called SFML-iPhone which would represent the iPhone better. Over half of the functions that are currently in SFML-Window don't even apply to the iPhone.

I agree completely with the reason for separating it from traditional computers, but the name should be more generic... SFML-handheld maybe?