SFML community forums
General => General discussions => Topic started by: seoushi on January 21, 2009, 11:43:51 pm
-
As I've hinted in another thread I've been working on getting SFML on the iPhone but I need some feedback on design decisions due to the nature of the device.
So far the following has been ported over complete but largely untested
SFML-System
SFML-Audio (minus libsnd)
SFML-Network
I'm currently working on SFML-Window and it is partially working. You can create a window, draw with OpenGLES and swap the buffers, here is the sample code that works.
/*
* test.cpp
* SFML-iPhone
*
* Created by Sean Chapel on 1/20/09.
*
*/
#include <SFML/Window.hpp>
#include <SFML/Window/UIKit/UserMain.h>
int main(int argc, char** argv)
{
sf::Window App(sf::VideoMode(320,480,32), "title");
sf::Clock Clock;
const GLfloat squareVertices[] =
{
-0.5f, -0.5f,
0.5f, -0.5f,
-0.5f, 0.5f,
0.5f, 0.5f,
};
const GLubyte squareColors[] =
{
255, 255, 0, 255,
0, 255, 255, 255,
0, 0, 0, 0,
255, 0, 255, 255,
};
while (App.IsOpened())
{
App.SetActive(true);
sf::Event Event;
while (App.GetEvent(Event))
{
}
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
glOrthof(-1.0f, 1.0f, -1.5f, 1.5f, -1.0f, 1.0f);
glMatrixMode(GL_MODELVIEW);
glRotatef(3.0f, 0.0f, 0.0f, 1.0f);
glClearColor(0.5f, 0.5f, 0.5f, 1.0f);
glClear(GL_COLOR_BUFFER_BIT);
glVertexPointer(2, GL_FLOAT, 0, squareVertices);
glEnableClientState(GL_VERTEX_ARRAY);
glColorPointer(4, GL_UNSIGNED_BYTE, 0, squareColors);
glEnableClientState(GL_COLOR_ARRAY);
glDrawArrays(GL_TRIANGLE_STRIP, 0, 4);
App.Display();
}
return 0;
}
The only real difference is that I needed to include "SFML/Window/UIKit/UserMain.h". The reason for this is that inorder to run a UIWindow application it requires that the UIWindow handles the main loop, thus taking over control. I really hate that it does this so I used a hack like what SDL does and it redefines main to UserMain and when the UIWindow starts it calls UserMain, it works but it's not ideal.
So the next thing I want to get done is input. Touching the screen acts like a mouse, you have a press/release/drag and it has x,y coordinates however you can have multiple touches at once and SFML doesn't look like it support multiple mice. A solution would to use a joystick however it seems a bit odd.
The other thing the iPhone has is the accelerometer, which can act like a joysticks analog stick movement but it has no buttons.
Given the touch input and the accelerometer, where do you think these two things fit the best? I would like to avoid creating new devices for portability reasons (not everyone has a mac to develop with and developing iPhone games on linux and window seems appealing to my company).
Right now my idea is to make joystick 1 the accelerometer and joysticks 2-? the multi-touch inputs. I'm not sure how many touches you can do at once tho, I initially thought it was only two but I've heard some people talk about handling more.
The last thing is that the iPhone doesn't have a keyboard in the normal sense. It has the onscreen one and it does work properly over OpenGLES however it doesn't mesh well with games. I don't plan to support the built-in keyboard, it's easy enough to make your own and there is a lot of other work to be done however if enough people want it I will consider it.
I will be releasing this code and hopefully it can be included in SFML someday but until I get the SFML-Window lib ported over properly I don't see a reason to release the code.
Any thoughts and suggestions would be great.
-
Hi
That's really amazing, I'm excited to see an iPhone port :)
I think the support for touchscreen and accelerometer should be added, those kind of interfaces will be widely used in the future. I'll have to think more about it.
If you need some help from me, you can send me an e-mail so that we can discuss more about the technical details.
-
I went ahead and added some event types (Accelerometer and Touched) and wrote the implementation behind them. Here is some example code of it working.
/*
* test.cpp
* SFML-iPhone
*
* Created by Sean Chapel on 1/20/09.
*
*/
#include <SFML/Window.hpp>
#include <SFML/Window/UIKit/UserMain.h>
int main(int argc, char** argv)
{
sf::Window App(sf::VideoMode(320,480,32), "title");
sf::Clock Clock;
const GLfloat squareVertices[] =
{
-0.5f, -0.5f,
0.5f, -0.5f,
-0.5f, 0.5f,
0.5f, 0.5f,
};
const GLubyte squareColors[] =
{
255, 255, 0, 255,
0, 255, 255, 255,
0, 0, 0, 0,
255, 0, 255, 255,
};
while (App.IsOpened())
{
App.SetActive(true);
sf::Event Event;
while (App.GetEvent(Event))
{
if(Event.Type == sf::Event::Accelerometer)
{
printf("%f,%f,%f \n", Event.Acceleration.X, Event.Acceleration.Y, Event.Acceleration.Z);
}
else if(Event.Type == sf::Event::Touched)
{
switch (Event.Touch.Type)
{
case sf::Event::TouchEvent::Began:
printf("Started touch %d at %f,%f \n", Event.Touch.TouchId, Event.Touch.X, Event.Touch.Y);
break;
case sf::Event::TouchEvent::Ended:
printf("Ended touch %d at %f,%f \n", Event.Touch.TouchId, Event.Touch.X, Event.Touch.Y);
break;
case sf::Event::TouchEvent::Canceled:
printf("Canceled touch %d at %f,%f \n", Event.Touch.TouchId, Event.Touch.X, Event.Touch.Y);
break;
case sf::Event::TouchEvent::Moved:
printf("Moved touch %d at %f,%f \n", Event.Touch.TouchId, Event.Touch.X, Event.Touch.Y);
break;
default:
break;
}
}
}
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
glOrthof(-1.0f, 1.0f, -1.5f, 1.5f, -1.0f, 1.0f);
glMatrixMode(GL_MODELVIEW);
glRotatef(3.0f, 0.0f, 0.0f, 1.0f);
glClearColor(0.5f, 0.5f, 0.5f, 1.0f);
glClear(GL_COLOR_BUFFER_BIT);
glVertexPointer(2, GL_FLOAT, 0, squareVertices);
glEnableClientState(GL_VERTEX_ARRAY);
glColorPointer(4, GL_UNSIGNED_BYTE, 0, squareColors);
glEnableClientState(GL_COLOR_ARRAY);
glDrawArrays(GL_TRIANGLE_STRIP, 0, 4);
App.Display();
}
return 0;
}
Files I've had to change are as follows :
Window/Input.h
Window/Input.cpp
Window/Event.hpp
I've added the following files under Window/UIKit :
EAGLView.h
EAGLView.mm
UIKitAppDelegate.h
UIKitAppDelegate.mm
VideoModeSupport.cpp
VideoModeSupport.hpp
WindowImplUIKit.mm
WindowImplUIKit.hpp
UserMain.h
As promised I am releasing the source code/project since the SFML-Window is mostly working. http://seoushi.com/dev/SFML-iPhone.tar.bz2
The archive contains a project to build a static lib and a simple test program.
The only bug I know of at the moment is touch move events sometimes don't seem to spawn until a touch is released, I'm unsure what is causing this perhaps it doesn't like the way I'm polling for events. I might have to make the poll events threaded.
Anyways I'm going to see if I can't fix that bug then start on the graphics package port.
@Laurent - if you could comment on my code that would be great. Basically I just want to know if I did something odd in my port that doesn't fit in well with SFML.
-
Everything looks fine so far :)
Just a few questions:
- What is a "touch cancelled" event?
- What is the accelerometer?
- Why are you using a framebuffer object?
Regarding the public API changes, you shouldn't modify too much stuff (except for your own tests), as I'll change it anyway ;)
Porting the graphics package may be a hard job (or not). If iPhone uses OpenGL ES 1.x it should be ok, but if it's using OpenGL ES 2.0 you'll basically need to abstract the whole rendering pipeline (2.0 is purely based on shaders, there's no FFP).
-
The touch canceled event is when the iPhone for whatever reason decides to stop the touch event, I could combine touch ended and touch canceled as they are almost the same thing.
The accelerometer is sorta like a gyro, it tells how much the phone has accelerated in the certain direction when moved.
As for the framebuffer, that is the only way to get an opengl context on the iPhone. Basically you create a framebuffer and then do all the opengl es commands you want then render the opengl to a framebuffer and tell the UIView that a new framebuffer is up to render.
Also, I've looked more into the touch events and it turns out even SDL 1.3 has this issue because if you interrupt the main application loop bad things happen. I have a solution where basically in the int Main you register an Update callback function and the main loop from the main application calls it however it is a bit different from how a normal SFML application runs.
The iPhone uses OpenGL ES-CM 1.1, so the graphics package shouldn't be too bad to port over.
If you have a few moments, I'll like to talk over IM or IRC about some of these changes (Im PM'ed you my contact information).
edit:
I've uploaded a newer version which fixes the Touch Inputs however users are no longer in control of the main loop, unfortunately this is the only fix.
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.
While I'm thinking about SFML-iPhone and if it really should be seperate I started working on SFML-Graphics. PostFX will not be able to be used (no shaders as far as I know) and font rendering will be a bit different since freetype is not accessible for the iPhone unless I was to include it statically (don't think the license allows this however). GLEW isn't usable on the iPhone (i tried). The rest of it should port over fine however. I already have it compiling however a lot of it is commented out so it won't work.
Anyways the link is in the same place. Hopefully I can make some design decisions by the end of the weekend and have a beta release.
-
Great :)
Just one thing: you can statically link FreeType, it has a BSD-like license in addition to the GPL one.
-
Hi,
We were discussing about language used for iphone development on another forum (this thread precisely (http://www.developpez.net/forums/d685339/technologies-divers/developpement-2d-3d-jeux/faire-jeux-iphone/)), and while I though Obj-C was used (with official SDK), Laurent pointed out your project using C++.
So, I was wondering if the official SDK supports C++, or are you using an unofficial SDK, thus restricting the use of your port to Cydia and alike distribution models ?
-
You can use Objective-C++.
-
How is the porting going ?
I would like to help since im interesting in using in my projects :)
-
Hi!
I'm really excited with that port, what it's its current state?
Currently I'm using cocos2d for iphone to develop my games, but it uses objective-C and also draws sprites one by one, I mean, it doesn't batch sprites by texture, for example. SFML does this, or batches sprites by texture, state and so on?
I'll keep an eye in this port, because I am very interested in using SFML for commercial projects.
Thanks :)
-
SFML does this, or batches sprites by texture, state and so on?
SFML is just a low-level library, not a 2D engine. So no, no automatic batching.
-
Thanks for your answer, Laurent.
Anyway, with a fast look over how SFML draws sprites I think it would be possible to render things batched with just a small layer over SFML. For example grouping draw calls in function of returned pointer of function Sprite::GetImage(). What do you think?
Thanks :)
-
Yes, of course you can do that :)
-
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?
-
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.
-
Use Preprocessor commands to know "Am I on a PC or am I on a Wii"? Like you do for Windows and Linux.
-
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... :P
@up: Don't think you quite understood what he was saying.
-
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:
typedef Window Screen;
:lol:
-
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:
typedef Window Screen;
:lol:
xD
It would work at least...
-
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.
-
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 :)
-
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.
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);
-
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 :)
-
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 :)
-
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.
-
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.
-
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?
-
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..)
-
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.
-
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.
-
sdl redefines main and has the event issues I describe. Threading might be an option however I'm not sure if apple allows it and it would be a pain to do.
-
sdl redefines main and has the event issues I describe. Threading might be an option however I'm not sure if apple allows it and it would be a pain to do.
iPhoneOS is pretty much a stripped-down OS X, isn't it?
I'd assume it'd allow threading...
-
sdl redefines main and has the event issues I describe. Threading might be an option however I'm not sure if apple allows it and it would be a pain to do.
iPhoneOS is pretty much a stripped-down OS X, isn't it?
I'd assume it'd allow threading...
I think iPhone OS allows threading, but perhaps apple does not allow an application that uses threads this form.
-
Well, what about this?
You can use the following to force the processing of events (useful also if your drawng code is taking too much time):
BOOL processedEvent = [[ NSRunLoopcurrentRunLoop] runMode: NSDefaultRunLoopMode beforeDate:[NSDatedistantPast]];
Extracted from https://devforums.apple.com/message/55119#55119
Perhaps we can call this inside SFML's GetEvent function :D
-
Bump!
-
Any news on this port? I'm developing a few things and want to get them on the iphone, so I'd love to use this if I could (since I really like SFML).
I tried out the attachment demo, and it does run in the simulator, but I couldn't get any input working (I thought it was working, albeit intermittenly or unreliably).
Still, I really like how much it's gone so far, I'm going to start integrating this into my local SFML files. I don't mind if it needs to have its own main redefinition, I don't see that being a huge problem as long as I can get some of the touch information.
Thanks!
-
Has anyone out there worked on this lately?
I've tried using it as is in my own project, with just trying to use the test.mm (as a starting point to understanding how to port my own app), and I keep on getting errors. First it was because I was using a different MainWindow.xib than the demo, but now I get errors about the gl context when creating the framebuffer.
Can anyone provide a simple tutorial for porting a regular SFML app to using this, for those who have little iPhone programming experience?
Edit: Also, can anyone tell me what preprocessor define definitely means that the system is iphone or iphone simulator? The above mentioned files didn't change config, so I've added SFML_SYSTEM_IPHONEOS specific stuff throughout the library, but in Config.hpp, I can't seem to find a set of defines that would point towards iphone. So, for now, I'm just hacking it to always enable IPHONEOS. There's got to be a way to do this, since people might have code for MacOSX and the iPhone in their program or something. I've seen posts online about this, but they never seem to work.
-
Is there any improvement in this topic?
-
I wish there would be myself, but I think it's probably been sidelined or something for now. It'd be really awesome to have the iphone be officially supported in SFML (and for other systems like the pre or something).
-
Any more updates on this? Does anyone know if this iphone port is going to be making it into the SFML 2.0 branch? I'm eager for any news that iphone/ipodtouch targets will be more officially supported soon (even though 2.0 isn't officially out yet :P). I'd love to start bringing over my engine to that platform soon if I could :)
-
Nothing on my side. So far I still have no plan for supporting iPhone (and other mobile platforms) in SFML 2.
-
Ah, ok then. Well, I guess I'll try to get the stuff that was already written working. Hopefully it will work with 1.6, or can without too many changes :P
-
It should work. 1.6 will just be a bug fix release.
-
Ok, I need a little help with something iphone/osx specific. I got everything to compile and build, but apparently the MainWindow.xib file is having some problems locating a variable defined in the UIKit dir? It causes the iphone simulator to crash.
I get this:
iPhone Simulator 2.2 (77.4.9), iPhone OS 2.2.1 (5H11)
*** Terminating app due to uncaught exception 'NSUnknownKeyException', reason: '[<UICustomObject 0x523e80> setValue:forUndefinedKey:]: this class is not key value coding-compliant for the key window.'
Looking it up online, it says that I'm not defining a IBOutlet or something. But looking at the UIKitAppDelegate.h file in UIKit, it is being defined, along with glView. All this is pretty confusing to me since I have very little interface builder experience or objective c experience. It's probably a very simple fix, but I can't figure this out, and I figured maybe someone here could give me a hand?
Edit: Nevermind about that, I think I fixed it. Apparently these xib files are just xml, and it had a wrong path being set for the UIKit files.
Also, for anyone's information, the list of files that were stated as being changed on the first page is a bit off, there are a lot more changes to SFML than the three listed in Window (Event.hpp and the two Input files). And I found the answer to my original question on how to programmaticly determine whether xcode is compiling for iphone or regular macosx.
-
I've run into another stumbling block in this that I hope someone else can help with. I ran into mysterious crash problems when attempting to run a basic example on the iphone simulator, when I was sure that the original example provided in the link works (the test.mm file).
Well, it only half works it seems :( If you download and build-run, yes it does work fine, but I think something is amiss with the project file. If you clean the project, something that is necessary to running gets deleted (still figuring what thing exactly), and any future attempts at building the project and running end up in an error over GetEvent or something else. This isn't the same error that I was getting, but I would think that the example could work regardless of having previous object data there (like if you make a new opengl es project and then copy the source files over, it should work).
Could someone with some macosx experience try this out on their end? I just reformatted and reinstalled 10.5 and I still get it here. I tried deleting and then readding the SFML libs dir and I still get the same thing. I don't know much objectivec/uikit so its a bit difficult to debug where this is failing, but my guess is maybe its some initialization thing?
-
Is this still being worked on? No posts in months...
-
Is this still being worked on? No posts in months...
I think someone might be but I'm not sure. It might be in the works in the svn branch, but unfortunately it might be a while. Of course, there is this existing code, which technically works, but has some bugs so we might be able to fix it. But I think I might end up just using some custom code for what I need...
-
Hello , i'm looking for SFML-iPhone.tar.bz2 .
Is someone can tell me where can i find it .
thanks , and sorry for my very bad english .
-
Hello , i'm looking for SFML-iPhone.tar.bz2 .
Is someone can tell me where can i find it .
thanks , and sorry for my very bad english .
Thanks for necroposting. This project is dead, so I highly doubt the file still exists.
-
I haven't touched this in a really long time but for those that are interested (seems there is at least one) the tar ball is here http://seoushigames.com/dev/SFML-iPhone.tar.bz2
-
I haven't touched this in a really long time but for those that are interested (seems there is at least one) the tar ball is here http://seoushigames.com/dev/SFML-iPhone.tar.bz2
Thanks very much . i will study it ;-)
Laurent