Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - starmessage

Pages: [1] 2
1
in xcode you can add an extra build step of type "copy files" that you can configure to include the dylibs or frameworks inside the screensaver bundle.

2
thanks. Your suggestion worked:
   NSWindow *windowHandle = self;

when I called it from inside the function startAnimation.

When I tried it inside the function initWithFrame, it did not work.

But in general, it behaves in an unstable way: when I reverted the changes back, it did not work.
I am checking if the exceptions are pilling up in the ScreensaverEngine when I debug, and next runs behave diffrently because of this "history".

P.S. I created a virtual mac to to test also xcode 4.

3
this error is probably due to a miss match between 32 vs 64 bit OS and/or
garbage collection Off/ Supported.

You can see a more detailed error if you run it via xcode and using the ScreenSaverEngine as the runner of your .saver

4
The error happens inside

sf::RenderWindow  sfmlWindow(wHandle);

I could debug my program, but are you suggesting to debug the SFML source files? I am not sure if I am able to suceed on that.

Can I have feedback from other member if they are creating without problems a SFML renderwindows using the window handle of an existing OS window ?

           

5
I recompiled the lastest version (RC-110) of SFML 2.0
The error when trying to create the renderWindow remains
Any ideas?

Code: [Select]
TmioanScreenSaverAbstract::initWithWindowHandle: 8590578624
memory_pressure: 0memory_pressure: 02012-12-06 20:15:00.246 ScreenSaverEngine[1451:a0f] invalid context
Error. Unable to create the context.
2012-12-06 20:15:00.250 ScreenSaverEngine[1451:a0f] invalid context
Program received signal:  “EXC_BAD_ACCESS”.

6
1)
RC 102  :)

I got that number from the download filename of the 2.0 snapshot.
At that time it was 102, now it is 110
"LaurentGomila-SFML-2.0-rc-110-g288bc87.tar.gz"

I kept it as a number of build, so I could now how much the 2.0 snapshot has advanced since then.

I will recompile the rc-110 to see if my problem has been fixed by the work already done in the SFML.

I was hoping this number is also somewhere inside the SFML as a getVersion().
I understand that only the major and minor (2.0) numbers are available in the code.

2)
I tried to supply the NSview as well but got the same error.

7
Hello,

I am making a Win/Mac screensaver.
In both platforms, the OS give you the window handle on which you must draw the screensaver.

It seem that on MAC I cannot create a SFML::RenderWindow using the native window handle.
This works Ok on windows.

As this is part of a bigger project, I do not have a minimal project and I am extracting here the code that is on the way of the RenderWindow creation. I hope you see some obvious mistake.

I am using SFML 2.0 / RC 102.

In MAC OSX you create a subclass of ScreenSaverView which is a subclass of NSView
This object is created by the OS.

In the function startAnimation you have the chance to find the window handle by using
NSWindow *windowHandle = [self window];
 
   

I eventually pass this handle to my "TmioanCanvasSFML"  class.

class TmioanCanvasSFML: public TmioanCanvasAbstract
{
protected:
        NativeWindowHandle windowHandle;
        sf::RenderWindow sfmlWindow;

public: // constructor  
       
        TmioanCanvasSFML(const NativeWindowHandle wHandle):  
                        windowHandle(wHandle),
                        sfmlWindow(wHandle)  // THE ERROR OCCURS HERE, in the initialization list
                {
                TmioanUtils::DebugLogLn("TmioanCanvasSFML(wHandle) constructor start");
                TmioanUtils::DebugLogLn("wHandle:", (long) wHandle);
       
                       
                if (!wHandle)
                        TmioanUtils::DebugLogLn("Error: TmioanCanvasSFML(wHandle) with NIL wHandle");
                       
                };
 
   

The native window handle is defined as
#include <Cocoa/Cocoa.h>
// Window handle is NSWindow (void*) on Mac OS X - Cocoa
typedef NSWindow* NativeWindowHandle;
 

When sfmlWindow(wHandle) is called, I see in the console the error:
Code: [Select]
memory_pressure: 0memory_pressure: 02012-12-02 20:17:27.906 ScreenSaverEngine[2414:a0f] invalid context
Error. Unable to create the context.
TmioanCanvasSFML(wHandle) constructor start
wHandle: 8590489248

The debugger shows the error in this screenshot.
http://oi45.tinypic.com/2u88jcz.jpg



Thank you for any ideas on what to search for….


-----------
By the way, I have a suggestion for a new (simple) function for SFML.
sf:getVersion()
Returns the textual version of SFML, eg. "2.0.094"
I want to log this number in the program's logfile that is sent to me by users in case of problems.
I am logging there all parameters of the OS and all available versions of linked libraries.

8
Window / Re: Screensaver
« on: December 02, 2012, 08:33:11 pm »
If your screensaver is simple enough, you can use the screensaver maker tools that create automatically a new screensaver using a collection of pictures, or videos.

If you really want to build your own, both Win and Mac have functions to integrate your screensaver
In Win you include the lib scrnsave.lib and in mac, you subclass the screensaverView class and link to the screensaver framework.

win:
http://www.dreamincode.net/forums/topic/17214-write-your-own-windows-screen-saver/
mac:
http://cocoadevcentral.com/articles/000088.php

It is better to intergrate your screensaver instead of producing a standard executable that behaves like a screensaver:
- you control/select it via the OS control panel
- you define the time-out from the OS
- the native screensaver will not start during your emulated screensaver executable run.
- it will respect other programs that disable the starting of the screensavers

9
Dear Hiura, thanks a lot for your help.

I was finally able to compile OK with makefiles on mac.
The resulting screensaver, stopped having the problem with the garbage collection.

However, when I copied the .saver package to a mountain lion mac, I saw again the same error message, which probably means that mountain lion needs a different treatment for GC. That was a quick test, I cannot report more details right now. (I am working on window's part this period of time.)

Thanks again

10
Huira, thanks very much for your help and guidance.

13) Indeed, I did not use the "Makefile" generator because I would not know how to proceed afterwards with the compilation. What would be the output of CMAKE and how should I compile it?
I know how to proceed with xcode project, so I prefered to go against the warning of the tutorial instead of going to a totally unknown place (makefile generator).

14) Also, I tried to enter the garbage collection= supported in the CMAKE parameters (see attached screenshot) but I was not successful. The setting I added was removed from the configuration screen of CMAKE when I click configure or generate. So the only place I know for this setting is inside the xcode project.


I will read to learn how to accomplish these two tasks and report back here the results.

[attachment deleted by admin]

11
ok, I compiled the RC.102 with xcode 3.2.
I used cmake to create the "SFML.xcodeproj"
All ok, except one minor error when building the SFML target.


PhaseScriptExecution "CMake PostBuild Rules" /temp/xcode/sfml-build-intermediate/SFML.build/Release/SFML.build/Script-89F8B399000C4AF993DDFCB4.sh
cd /Users/cto/Documents/work/C-Proj/SFML-2.0-latest
/bin/sh -c /temp/xcode/sfml-build-intermediate/SFML.build/Release/SFML.build/Script-89F8B399000C4AF993DDFCB4.sh

cp -r /Users/cto/Documents/work/C-Proj/SFML-2.0-latest/include/SFML/* SFML.framework/Versions/2.0.0/Headers
usage: cp [-R [-H | -L | -P]] [-f | -i | -n] [-apvX] source_file target_file
       cp [-R [-H | -L | -P]] [-f | -i | -n] [-apvX] source_file ... target_directory
make: *** [SFML_buildpart_0] Error 64
Command /bin/sh failed with exit code 2


 
I believe the error is because the target directory for the copy command is a relative directory and probably not found via the current working directory.
I was not able to find where this post-build step is defined inside the xcode project.
 
The other targets (sfml-Audio, sfml-window, etc) were built without errors.

11) Should I post the frameworks here (garbage collection= supported) in case other people may want them as well?

12) By the way, I am under the impression that if garbage collection= supported it would work in both cases of non supported and requiref GC. Therefore, maybe it is a good idea to have the standard compilation of SFML with GC = supported if it does not make any other harm? (I am new to MAC and SFML so you know better)

12
8 ) Indeed, my previous test did not actually disable the GC.
I had put OBJC_DISABLE_GC=YES as a user defined setting in xcode, but now I learnt this is an environment variable. Not an xcode setting.

I set it for the debuger (Executables -> myApp -> GetInfo -> Environment variables) and in this case the screensaver started Ok.

All paths seem to lead to the task of recompiling FSML with GC=supported.

10)
A last attempt to escape from that task: The above environment setting works only if run from the xcode debugger (of course).
Is there a way that an .app can define an environment variable before starting its main execution, and in particular before loading the frameworks it needs?
It does not need to change the environment variable globally, but only for its own thread (or execution space, I am not sure how to name it)

13
Some more tests:

8 )
reading at
http://stackoverflow.com/questions/9319518/is-it-possible-to-load-gced-libraries-from-a-program-that-barely-supports-it
I tried to switch off the GC requirement by adding a user defined setting: OBJC_DISABLE_GC=YES
but I did not get away from my problem (GC capability mismatch) .

9)
the file at
http://www.opensource.apple.com/source/objc4/objc4-437/runtime/objc-os.m
under the routine of
gc_enforcer
is probably the one containing the error message string.
This routine may give ideas on how to bypass the error.

I see for example
// Linked images get a free pass
    if (InitialDyldRegistration) return NULL;
 

How can I qualify the SFML dylibs as "linked images"?

14
I completely remmed out the creation of the canvas, ie the sfml::renderwindow
and the screensaver behaved the same way.

Additionally, the console captures the following error ("GC capability mismatch"), which means that is related the the Garbage collection setting of the precompiled sfml 2.0 framework.


[Session started at 2012-10-27 21:32:42 +0300.]
GNU gdb 6.3.50-20050815 (Apple version gdb-1515) (Sat Jan 15 08:33:48 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin".tty /dev/ttys001
Loading program into debugger…
Program loaded.
run
[Switching to process 1839]
Running…
memory_pressure: 0memory_pressure: 02012-10-27 21:32:43.608 ScreenSaverEngine[1839:a0f] Error loading /Library/Screen Savers/StarMessage.saver/Contents/MacOS/StarMessage:  dlopen(/Library/Screen Savers/StarMessage.saver/Contents/MacOS/StarMessage, 265): Library not loaded: @executable_path/../Frameworks/sfml-window.framework/Versions/2.0.0/sfml-window
  Referenced from: /Library/Screen Savers/StarMessage.saver/Contents/MacOS/StarMessage
  Reason: no suitable image found.  Did find:
        /Library/Frameworks/sfml-window.framework/Versions/2.0.0/sfml-window: GC capability mismatch
2012-10-27 21:32:43.613 ScreenSaverEngine[1839:a0f] ScreenSaverModules: can't get principalClass for /Library/Screen Savers/StarMessage.saver

Debugger stopped.
Program exited with status value:0.
 

6)
Does anyone happen to have compiled SFML 2.0 frameworks with the Garbage collection = supported?

7)
Maybe the DYLIBS can be used without a problem if MacOSX cannot check this setting on them?
Based on the following quote, I guess the DYLibs are loaded by macosx differently and probably less strictly.

Quote
Frameworks *are* dylibs, with some additional content (headers, resources, etc.) bundled along with them for convenience.
If you don't need the additional wrapping, then there's nothing to gain by using a framework.


15
4) to check if SFML is 32 and 64 bits:

I checked the SFML lib that is included in my bundle inside the .screensaver
there are several SFML libs there

These are the result of the various files

/Library/Screen Savers/StarMessage screensaver.saver/Contents/Frameworks/SFML.framework/Versions/2.0.0/SFML
file SFML

SFML: Mach-O universal binary with 2 architectures
SFML (for architecture i386):   Mach-O dynamically linked shared library i386
SFML (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64
 

/Library/Screen Savers/StarMessage screensaver.saver/Contents/Frameworks/sfml-graphics.framework/Versions/2.0.0/sfml-graphics

file sfml-graphics

sfml-graphics: Mach-O universal binary with 2 architectures
sfml-graphics (for architecture i386):  Mach-O dynamically linked shared library i386
sfml-graphics (for architecture x86_64):        Mach-O 64-bit dynamically linked shared library x86_64
 

/Library/Screen Savers/StarMessage screensaver.saver/Contents/Frameworks/sfml-window.framework/Versions/2.0.0

file sfml-window

sfml-window: Mach-O universal binary with 2 architectures
sfml-window (for architecture i386):    Mach-O dynamically linked shared library i386
sfml-window (for architecture x86_64):  Mach-O 64-bit dynamically linked shared library x86_64
 

And also the same file, from the computer's frameworks (not what is bundled inside the screensaver).
/Library/Frameworks/sfml-window.framework/Versions/2.0.0

Code: [Select]
file sfml-window

sfml-window: Mach-O universal binary with 2 architectures
sfml-window (for architecture i386): Mach-O dynamically linked shared library i386
sfml-window (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64

I will do the other test you suggested and report on that as well.
thanks

Pages: [1] 2
anything