This is great! Nice to see that the framework seems to work for you guys so far. Please let me know your opinions and ideas for improvements you'd like to see.
@Bikeman: I suggest you turn on the high quality mode to get proper anti-aliasing and the fog effect for depth perception. You can do so either in your account preferences (when using live data) or by admending your local init_data.xml (standalone use) like this:
This is great! Nice to see that the framework seems to work for you guys so far. Please let me know your opinions and ideas for improvements you'd like to see.
@Bikeman: I suggest you turn on the high quality mode to get proper anti-aliasing and the fog effect for depth perception. You can do so either in your account preferences (when using live data) or by admending your local init_data.xml (standalone use) like this:
Cheers,
Oliver
Hmm... interesting. I'm testing on a remote desktop (vnc) and it would not work on "high" (graphics program just exits). I guess this is caused by a lack of feature support by the remote desktop server, but anyway, I wonder whether it might be useful to have an automativ fallback to lower settings if the gfx engine fails to init with high settings.
Hmm... interesting. I'm testing on a remote desktop (vnc) and it would not work on "high" (graphics program just exits). I guess this is caused by a lack of feature support by the remote desktop server, but anyway, I wonder whether it might be useful to have an automativ fallback to lower settings if the gfx engine fails to init with high settings.
That's interesting indeed and most likely caused by limited hardware support. Can you please have a look for warnings and error messages on STDERR (or its file redirects respectively)? Any hint? Does it work with "medium"?
In fact, there already is minimum fallback support. The problem with an automatic fallback is that it's not always clear which feature request (size, depth, buffers, FSAA, etc.) caused the video mode request to fail. One would have to test all combinations separately, because SDL only allows you to set a video mode and test whether it worked afterwards - there's no such thing like an upfront capabilities check.
Hmm... interesting. I'm testing on a remote desktop (vnc) and it would not work on "high" (graphics program just exits). I guess this is caused by a lack of feature support by the remote desktop server, but anyway, I wonder whether it might be useful to have an automativ fallback to lower settings if the gfx engine fails to init with high settings.
That's interesting indeed and most likely caused by limited hardware support. Can you please have a look for warnings and error messages on STDERR (or its file redirects respectively)? Any hint? Does it work with "medium"?
In fact, there already is minimum fallback support. The problem with an automatic fallback is that it's not always clear which feature request (size, depth, buffers, FSAA, etc.) caused the video mode request to fail. One would have to test all combinations separately, because SDL only allows you to set a video mode and test whether it worked afterwards - there's no such thing like an upfront capabilities check.
Hmm... interesting. I'm testing on a remote desktop (vnc) and it would not work on "high" (graphics program just exits). I guess this is caused by a lack of feature support by the remote desktop server, but anyway, I wonder whether it might be useful to have an automativ fallback to lower settings if the gfx engine fails to init with high settings.
That's interesting indeed and most likely caused by limited hardware support. Can you please have a look for warnings and error messages on STDERR (or its file redirects respectively)? Any hint? Does it work with "medium"?
In fact, there already is minimum fallback support. The problem with an automatic fallback is that it's not always clear which feature request (size, depth, buffers, FSAA, etc.) caused the video mode request to fail. One would have to test all combinations separately, because SDL only allows you to set a video mode and test whether it worked afterwards - there's no such thing like an upfront capabilities check.
Thanks,
Oliver
Medium works, will check output this evening.
CU
Bikeman
I get this in stderr :
Quote:
Could not acquire rendering surface: Couldn't find matching GLX visual
Window manager could not be initialized!
All but the last line were borrowed from the science app build scripts, the last line avoided a strange build error I got in the install phase of the BOINC part of the build process.
Anyway, works like a charm on my Core Duo Mac mini, except for "high" graphics mode again. This time the "screensaver" start up ok, but doesn't display most of the layers (only constellation and observatories), and is unresponsive to keyboard input. Go figure.. I have to do more debugging here, but at least up to "med" level eveything works pretty well on my mac mini now.
Please note that the MinGW cross-compile build is currently broken (again). I already found the culprit (upstream) and will push yet another workaround into the repo in the next couple of hours...
If you want to try out the visual effect of my screensaver modification (the one from the screenshots posted earlier), here's how to do it:
The code needs some polishing here and there and some more testing under different platforms, but for those who want to have a look, here's a patch that will add some functionality to the standard starsphere code:
* inside the starsphere, there will be a graphical representation of the results (up to 10.000 of the best scoring search templates), indicating the sky position of the candidate and it's score wrt to one of the metrics collected in the output. Points closer to the surface of the sphere (more "outward", color coded red) are better than those close to the center of the sphere.
* This display can be toggled on and off using the 'u' key.
To build the modified starsphere executable, first download the original code using
FYI, for all of you who make modifications/contributions to the official code base I suggest you publish your changes using public git repositories instead of supplying patches. It's much easier to track, try and integrate changes this way. That's what's so nice about distributed SCM in general and git in particular.
If you can't host those repositories yourself, I recommend GitHub as a free (for open source software) git hosting service.
OK, prototype seems to work
)
OK, prototype seems to work under Linux:
Will try to complile under Mac OS and for Windows next.
CU
Bikeman
Hi guys, This is great!
)
Hi guys,
This is great! Nice to see that the framework seems to work for you guys so far. Please let me know your opinions and ideas for improvements you'd like to see.
@Bikeman: I suggest you turn on the high quality mode to get proper anti-aliasing and the fog effect for depth perception. You can do so either in your account preferences (when using live data) or by admending your local init_data.xml (standalone use) like this:
Cheers,
Oliver
Einstein@Home Project
RE: Hi guys, This is
)
Hmm... interesting. I'm testing on a remote desktop (vnc) and it would not work on "high" (graphics program just exits). I guess this is caused by a lack of feature support by the remote desktop server, but anyway, I wonder whether it might be useful to have an automativ fallback to lower settings if the gfx engine fails to init with high settings.
CU
Bikeman
RE: Hmm... interesting.
)
That's interesting indeed and most likely caused by limited hardware support. Can you please have a look for warnings and error messages on STDERR (or its file redirects respectively)? Any hint? Does it work with "medium"?
In fact, there already is minimum fallback support. The problem with an automatic fallback is that it's not always clear which feature request (size, depth, buffers, FSAA, etc.) caused the video mode request to fail. One would have to test all combinations separately, because SDL only allows you to set a video mode and test whether it worked afterwards - there's no such thing like an upfront capabilities check.
Thanks,
Oliver
Einstein@Home Project
RE: RE: Hmm...
)
Medium works, will check output this evening.
CU
Bikeman
RE: RE: RE: Hmm...
)
I get this in stderr :
Now, I managed to compile the
)
Now, I managed to compile the E@H screensaver under OS X "Leopard" with Xcode 3.1 , but only after setting the following environment variables:
All but the last line were borrowed from the science app build scripts, the last line avoided a strange build error I got in the install phase of the BOINC part of the build process.
Anyway, works like a charm on my Core Duo Mac mini, except for "high" graphics mode again. This time the "screensaver" start up ok, but doesn't display most of the layers (only constellation and observatories), and is unresponsive to keyboard input. Go figure.. I have to do more debugging here, but at least up to "med" level eveything works pretty well on my mac mini now.
CU
Bikeman
Hi everyone, Please note
)
Hi everyone,
Please note that the MinGW cross-compile build is currently broken (again). I already found the culprit (upstream) and will push yet another workaround into the repo in the next couple of hours...
Update: workaround deployed!
2nd Update: fixed upstream!
Sorry for any inconvenience,
Oliver
Einstein@Home Project
Hi all! If you want to try
)
Hi all!
If you want to try out the visual effect of my screensaver modification (the one from the screenshots posted earlier), here's how to do it:
The code needs some polishing here and there and some more testing under different platforms, but for those who want to have a look, here's a patch that will add some functionality to the standard starsphere code:
* inside the starsphere, there will be a graphical representation of the results (up to 10.000 of the best scoring search templates), indicating the sky position of the candidate and it's score wrt to one of the metrics collected in the output. Points closer to the surface of the sphere (more "outward", color coded red) are better than those close to the center of the sphere.
* This display can be toggled on and off using the 'u' key.
To build the modified starsphere executable, first download the original code using
then apply the patch using
where starsphere_20090318.patch is the saved copy of the file downloaded above.
You can ignore some warnings about whitespaces while performing the patch.
Feedback is welcome,
CU
Bikeman
FYI, for all of you who make
)
FYI, for all of you who make modifications/contributions to the official code base I suggest you publish your changes using public git repositories instead of supplying patches. It's much easier to track, try and integrate changes this way. That's what's so nice about distributed SCM in general and git in particular.
If you can't host those repositories yourself, I recommend GitHub as a free (for open source software) git hosting service.
Cheers,
Oliver
Einstein@Home Project