iPhone Port (in progress)

[Groogy]

Use Preprocessor commands to know "Am I on a PC or am I on a Wii"? Like you do for Windows and Linux.

[nfries88]

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.

[Laurent]

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:

[nfries88]

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...

[seoushi]

I've gotten a few emails about this port and it appears the thread is still active so I'll give an update.

As of right now I'm not working on the port. The differences between the way SFML currently is and how the iPhone works made me not want to develop it further. This does not mean that I won't work on it in the future it just means things need to be sorted out before I want to go any further.

The accelerometer and touch events have been mostly dealt with since it is now unofficially planed to support them sometime.
Having a window class isn't that big of a deal even though the iPhone only supports one window at a time. I would rather keep the same name and keep it cross-platform.

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.

In my mind SFML is meant for cross-platform development, code once and compile everywhere and it should just work. If an iPhone port comes into existence this would not be true, since the iPhone uses different means of input there would be a good sized chunk of code that needs to be rewritten in order to make a port of an application. I think that there are some things that port over quite well like system, audio, networking and the graphics packages but the windowing package just doesn't make that much sense to me because your code is going to be different no matter what you do. I feel that it's only reasonable to make some sort of analog to the window package and just keep the same sort of features between the packages.


The biggest reason for me not actively trying to look for a good solution is because I've already written a good engine for the iPhone that fits the hardware better.

[Gammenon]

Perhaps I am saying something absurd, but what if we change SFML's event handling model? Will it be possible to, instead of processing events "manually" (calling GetEvent() or whatever name has that function) define a callback function like "onEvent()" that will be called each time an event is in the queue, and then create also a "onTick()" function? In Windows, that onTick() function will be called as fast as it is possible, but in iPhone it will be called by a timer (it seems that this is the best way to create a game loop in this platform) at a certain interval. Of course, that structure implies a base class (something like Game, Simulation or Application) you must derive from and override theose functions.

In short, force the programmer to derive from "Application" or whatever class and to override onEvent(), onTick(), onInit(), etc functions and remove main() from his/her control.

Well, just some random thinking

[seoushi]

Thats basically what my current code (earlier in this thread) does, the windowing code externs onSetup() and onUpdate() and you have to implement those functions, they basically become your int main.

I really don't think this will fly with SFML, the iPhone makes me angry enough that it takes over the main loop and thus control from my program. Having SFML do this would likely make some other of the developers angry as well. The only way I see it working is if this way of doing it is mandatory for portability but not mandatory in general.

Edit: I thought of another idea. Have the window be able to register callback functions, I somewhat hinted at this in my previous post.

Code: [Select]


sfml::Window win;
win.addXXXFunc(&someFunc);


A more object oriented approach to this would to have a listener class.

[code]
class WindowUpdateListener
{
public:

   WindowUpdateListener();
    virtual ~WindowUpdateListener();
    virtual void onUpdate() = 0;
};


sfml::Window win;
win.addListener(new MyDerivedListenerClass);

[Gammenon]

Hi seoshi

Lest see what says Laurent about this. I like your idea about some standard that warranties absolute portability, but it is not mandatory if you just want to be portable in PC type (windows, mac and linux) platforms

[Laurent]

Such a "framework" would certainly be better for most people, but the little amount of flexibility it would remove will make a few users unhappy. I'd really like to avoid the framework approach, where you constraint people to use your design rather than simply providing the functions they need. While this way is certainly great for most higher-level engines, I think this is already too much for SFML.
Moreover, it would make writing the C binding and all other bindings based on it very hard, if not impossible.

I know SDL has a similar approach as SFML, and has an iPhone port. I should look into this one

[seoushi]

I have looked into SDL 1.3 and it does the redefining main hack and also has issues with Events not being triggered. In other words they have the same issue.

[nfries88]

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.

[Gammenon]

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?

[nfries88]

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..)

[seoushi]

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.

[nfries88]

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.