Messages

16

SFML projects / Re: SFML android port

« on: November 05, 2012, 03:55:20 pm »

I do not see any benefit from having a standard main function without using sfml window. As it means the main method runs and  the native activity still exists.Yet there is no way to get access to anything to do with the native activity or handle it's events.

also if you provide a way for the user to implement the handling of the activity startup then it creates problems for event management stuff and opengl stuff. They would not be able to use the window class. They would essentially be handling all windows events and drawing.

The only way I can think of this working is making public methods to push events and pass information needed. Which starts to get confusing cross platform wise and breaks the idea where as little public modifications as possible are made.

I doubt anyone would implement their own. The main benefit of using sfml on android would it being portable to other os's.
As if you are developing specifically for android using java would be simpler and feature full.

17

SFML projects / Re: SFML android port

« on: November 05, 2012, 01:28:11 pm »

I originally had it in sfml main. Though it manages all window management events. So it seems more natural to put it in sfml windows. as the on event calls can directly be converted to sfml window events. Linking sfml window should in theory automatically set up everything for main thread and window management.

The only way to have a main function is to create a thread for it. as all on call events must return or the activity will be considered frozen. Plus choosing on what event the main thread will be created means we can assure everything is ready for the window creation things like to set up opengl.

I have not worked on it any more yet. So i need to do more experiments.

18

SFML projects / Re: SFML android port

« on: November 02, 2012, 09:56:52 pm »

Regarding your issue with the optimized native activity: You don't have to use it or create it on your own - at least I've never done so so far. The NDK provides premade code you can link.

I do use the premade native-activity provided by android. Which is just a premade java front end which calls ANativeActivity_onCreate from shared library you provide.  That's all the glue really does except convoluted thread stuff. Which is simpler with sfml.

I actually produce a native library used in native activity from sfml cmake build with examples.
Just like you currently can build sfml with examples on windows mac and linux.

I do not use the glue code as that is not the problem. It is some how related to having the function in a static library linked to the main shared library if not referenced. The glue code gets around this through the header I think.

Unless the android mk file has an invisible flag that stops this stuff. I have found other stuff like that.


Also the glue code will not call the main thread it will call
void android_main(struct android_app* app)

my code does call main()

The idea being that you do not need to make any changes to your source and just compile for all 4 of the operating systems.

19

Feature requests / Re: Relative Mouse Movement (Mouse Capture)

« on: November 02, 2012, 09:13:55 pm »

I actually have troubles with this in source engine games.

I have 2 screens so even fullscreen(only one screen) I can still loose focus if I move the mouse really quickly to the right and left click.

It infuriates me that the source engine still has not worked that out.

This should be pretty easy to implement. I have played with this before on windows.

Here is all you need. It locks the cursor to an area. You will need to resize it with the window.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms648383(v=vs.85).aspx

XGrabPointer might work on linux. Never used it though.

With mac I have no idea.

I could make a patch for this with the go ahead on the api implementation from Laurent.(not mac. I do not own one)
Of course for the time for him to decide on the api he could implement it himself.


I suppose something like this
void Window::lockMouseCursor(bool locked)
bool Window::isLockMouseCursor()

though sfml uses set and get everywhere. So i suppose

void Window::setMouseCursorLocked(bool locked)
bool Window::getMouseCursorLocked()

20

General discussions / Re: A book on SFML -- looking for author(s)!

« on: November 02, 2012, 07:45:55 pm »

Man this sounds awesome. I would love to do this. Though at the moment there is already a lot of people. I have the time but I think too many people are involved. Well it is hardly like I can not do anything else. I got my android port sitting here.

If the target is people who have written console text games and never done graphical games. I would dumb it down a lot. Threading will not be needed.

Something I remember Making as one of my first games a long time ago was a bad ass asteroids game. It was simple and looked good.

Advantages are you do not need a scene graph just a list of entities and everything is on screen.
All collisions cause destruction. No need to work out point of intersect. With a platformer you need to worry about if you collide where should you be.

I used circular collision.  It's simple to understand and matches well to asteroids.

You can expand on it easily with black holes(with gravity pull), and picking up resources for points easily.

Multi-player real-time games are always complicated. I have spent ages studying about all the networking models. It is not simple at all to do networking suitable for the net.
For something like chess the networking with sfml would be very easy.

On some more thought I suppose I am underestimating the size of the book. 440 pages is a pretty big book.

I have an old beginning openGL book that is 260 pages and goes from setting up your window to shadow maps and vbo's.

I wish I could be involved in your discussions. Though I am sure everyone would and everyone would have access to the book before it was published. No need to buy it.

21

SFML projects / Re: SFML android port

« on: October 16, 2012, 09:09:38 am »

I would be happy and honored if it even slightly helped with the official port.

It needs a little cleaning up and my cmake cross compile script is very window targeted. It has the windows ndk in the folder and generates a build cmd to make building it easy.

Yah I was thinking that multi-touch would be needed. I think your first touch could just be considered a mouse click as it makes less work when cross compiling an app. Plus I have a multi-touch  laptop and there is never a time when I would need to use the touch screen and mouse simultaneously.

Though second touch needs to be added. That could just be a new event type.

The naming of the first one will be misleading as mouse.

We could use the name pointer as that is what android seems to use to represent it's input. It would still represent mouse and touches.
like sf::pointer::getPosition().x and  sf::pointer2::getPosition().x

Though it starts to get a little confusing.

22

SFML projects / Re: Zloxx II - An action Jump'n'Run

« on: October 16, 2012, 06:46:33 am »

Looks good from the pics.
Would be good if you could upload a video. Sometimes I can not download stuff.
Also I am downloading it and half an hour and it is not halfway yet><
I have unreliable net and it is a surprisingly large file and 50mb compressed.

Do you think you will incorporate any other sf mods like "let there be light"?

You know what this would look great on.... Android. I'll volunteer you

Though honestly I do not know if it can live up to your airport game.

I played that for hours. It had perfect graphics, great game play. You really outdid yourself on that project.


Edit

I played it and the animations are great very smooth and nicely done in the menu and ingame. I also like that if you click out of the window it automatically pauses. I have always wondered why commercial games do not do that.

That being said I got to the sign your jump height varies based on how long you hold it.
the special environment things were pretty good and of course animated as well.
Though it does not live up to airport.

23

SFML projects / SFML android port

« on: October 16, 2012, 04:50:43 am »

Thought i would give a quick demo of my progress.

The goal is to have all the gui_apps in the examples projects folder in sfmls cmake folder run. Preferably with as little or no changes if possible.

Below is a quick example of sfml system and sfml window parts. It simply makes the entire screen a color.
The green color is controlled by a timer and reset every second and can be reset when your finger touches the screen. The red color is controlled by your fingers last x position and blue by your fingers last y position.

all the same as normal sfml except using gles. There is one part at the top which is driving me nuts. If i have that function where I wanted in sfml window then when it is statically linked the compiler optimizes it out ><. If you have any ideas. I would appreciate it.

/*
stupid peice of code here. The android activity handling stuff would be completely unnoticed.
Though because it is adding a static library and if the ANativeActivity_onCreate entry point is in it. it seems to get Optimised out. >< joy.
*/

#include <android/native_activity.h>
extern void ANativeActivity_onCreate2(ANativeActivity* activity, void* savedState, size_t savedStateSize);

void ANativeActivity_onCreate(ANativeActivity* activity, void* savedState, size_t savedStateSize)
{
        ANativeActivity_onCreate2(activity, savedState, savedStateSize);
}



////////////////////////////////////////////////////////////
// Headers
////////////////////////////////////////////////////////////
#include <SFML/Window.hpp>
#include <GLES/gl.h>





////////////////////////////////////////////////////////////
/// Entry point of application
///
/// \return Application exit code
///
////////////////////////////////////////////////////////////
int main()
{
    // Create the main window
    sf::Window window(sf::VideoMode(640, 480, 32), "SFML Window", sf::Style::Default, sf::ContextSettings(32));

    // Create a clock for measuring the time elapsed
    sf::Clock clock;

    sf::Vector2u size=window.getSize();

    // Start the game loop
    while (window.isOpen())
    {
        // Process events
        sf::Event event;
        while (window.pollEvent(event))
        {
            // Close window : exit
            if (event.type == sf::Event::Closed)
                window.close();

            if (event.type == sf::Event::MouseButtonPressed)
                clock.restart();

            // Resize event : adjust viewport
            if (event.type == sf::Event::Resized)
            glViewport(0, 0, event.size.width, event.size.height);
       }
           
        float x =  sf::Mouse::getPosition(window).x;
        float y = sf::Mouse::getPosition(window).y;

               
        x /=size.x;
        y /=size.y;

        float val=clock.getElapsedTime().asSeconds();

        if(val>1)
            val=clock.restart().asSeconds();
           
        glClearColor(x, val, y , 1);
        glClear(GL_COLOR_BUFFER_BIT);

        // Finally, display the rendered frame on screen
        window.display();
    }

    return EXIT_SUCCESS;
}
 

below is a video. unfortunately it is not very clear on when i am clicking which is mean to represent my finger on the screen.



I also use extra stuff not shown. Like threads, mutex's and locks. It was required to get the main thread working.

Also any experienced OpenGL ES 2 users around? I suppose this is really not the place where they would be.  Having worked on mobiles which are not really related to SFML. Restructuring the graphics library will be hardest. plus compiling it's libs for android. Hopefully I can offload that work onto you guys

24

Window / Re: Why so many glContexts?

« on: October 15, 2012, 10:19:54 am »

Ok. well I have simply made it so if a shared context is given it will not bother to make it's own context and just copy the values for context from the shared one. as there is always one and only one window open on a native android activity.

The only other way I could think of is by creating pbuffer. Though I do not think there is any need for that.

25

Window / Why so many glContexts?

« on: October 14, 2012, 03:50:29 pm »

I have been trying to port sfml to android.

I have worked out the cmake toolchain stuff aswell as getting sfml_system going and some fun with gles aswell.

I have been trying to get sfml_window working(even though the models of android and sfml_window do not match)

Though I have been very confused with some strange results. I noticed that it seems to be coming from having many GLcontexts.

So far the only sfml_window object i use is sf::window yet 2 contexts exist before the windows constructor even gets called.

It appears the first one is created by GlContext::globalInit()

the second is created by by sf::priv::GlContext* getInternalContext()

the third appears to be created by the window constructor which is really the one I thought that makes sense.

26

Feature requests / Re: sfml for android(already started on)

« on: August 05, 2012, 07:13:58 am »

Thanks eXpl0it3r. I will look at it more closely the most interesting thing about his tree is it looks like he can generate an apk in there.
So far I have been generating a shared library and manually copy pasting it into an existing android project before generating the apk.

27

Feature requests / Re: sfml for android(already started on)

« on: August 04, 2012, 03:34:53 pm »

Your very right. I didn't expect to come up with a perfect design and have it integrated into sfml 2(I know all public api is in lock down until it's release and that is the least of the issues). This was going to be me plodding a long by myself. With the potential best scenario that the tool-chain and adding support for gles might be a little helpful.

The worst that will happen is it will be a great example of what you should not do.

Considering it is for just for me and I do not plan to use sfml on top of anything else. I may just go with a nativeActivity  handler that gets the activities information and holds it for you until you construct your window.

It's a bit messy. but it allows me to use it for all my uses.

It would be an easier issue to solve if this were just a gaming engine. As you could assume there will always be an window available before hand.

Though I prefer SFML as it is. It means I can create a server app if needed with no gui just to help with NAT punch through(not for android of course).

Also I'm not planning to get it all converted in a month. If i can just get system,window and graphics working in some form by new year I would be pretty happy.

28

Feature requests / sfml for android(already started on)

« on: August 04, 2012, 12:24:48 pm »

I have started working towards getting sfml on android by using the ndk.

I have built a cmake tool-chain that compiles for android and tested it with android.(only tested this through windows)

I have also made something similar to SFML_Main for android. As there is no main function in android to try and replicate it. While ndk works by java making natives calls which would mean the calls could be whatever you want and not having a standard way to make a native activity. Fortunately android has an existing activity called nativeActivity(http://developer.android.com/reference/android/app/NativeActivity.html) which exposes the core functions called during the life cycle of an android activity. Which is what SFML_Main uses.

This is kind of where it goes all to hell. An activity is already a window that calls native code. Which makes the structure of sfml with creating a window after code has started a bit useless. Including all the events and things related to that.



A way around  to have code that  does net need any modifications when using pure sfml between platforms would be to have my sfml_main  store away information about the activity that is needed by the window. Then whenever sfml window is created it could grab all this information. You could then send the activities events through the windows including onPause and all that.

Down side is you would be required to use sfml with sfml main and will not be able to use it with your own custom java front and not using NativeActivity. Which realistically probably isn't that likely.

So I have no idea what the goal should be. And my head is hurting from fighting with cmake ><.

Any suggestions or help would be appreciated. Especially a word from Laurent.

29

SFML projects / Re: Parabola Engine is now on Android!

« on: August 04, 2012, 04:29:47 am »

It does not seem to look anything like the sfml source tree. I also do not see any cmake files.

So is it more like once upon a time it resembled sfml?

Just asking to know if this port can be moved into the current sfml2 tree.

I have been playing with getting cmake projects to build for android. Which is working. Not with sfml yet. Was wondering if someone else had been doing it before I try to go down this painful path.

30

SFML projects / Re: SFML2 V8 JavaScript Binding

« on: June 24, 2012, 07:34:44 am »

Rogof I am interested to hear how you managed to get V8 built on mingw. I have tried before but the new v8 build system doesn't seem to support it. I tried a hack someone suggested for the old build system but it would not build either.

Any chance of a compiled version of this project being available? would love to test it but I am just a bit buisy to be trying to compile and link things.