A nice advantage of the "separate graphics" Apps is that the computation is completely independent of the graphics, which are now a separate program instead of a thread. Nothing that happens to the graphics (error, crash, etc.) could affect the computation, and the graphics code doesn't even have to be linked (in a technical sense) to the rest of the program.
Therefore we (as the project) simply don't care about what program runs as a graphics program (if at all), and what code it is. This gives you, the participants, the opportunity to code your own graphics for Einstein@home and run it, share it with your friends, customize it for your team etc. You can make one that suits the graphical power of your computer better than the standard one does (in either direction).
A lot of the fun in running BOINC is due to some kind of competition. So let's have an open competition for the best Einstein@home graphics. Write it, publish and announce it in the forum (here in this thread) and the whole community can and will take a look. Maybe at some point we'll chose a new "official" one, or give a list to choose from (in project preferences).
Here are some technical graphics/project-specific hints and instructions that will help you writing an Einstein@home graphics program (How to get, compile and link the BOINC library is out of the scope of this description):
* The only mandantory requirement for a BOINC graphics program is that it understands and honors a comand-line option "--fullscreen". If it gets passed this option, it should display graphics on the whole (main) screen and terminate on mouse movements or key presses. If it gets called without that option, it should open a window showing the same or different graphics and might react on keys and mouse movents in its own way.
* You will probably want to display some project-related information in any way. For this purpose you will need to use some functions of the BOINC library.
(void*)boinc_graphics_get_shmem("EinsteinHS") returns a pointer to a shared memory segment into which the main Einstein@home application writes a XML document describing its current status. In current Apps (S5R3 4.25-4.27) this looks like:
<graphics_info>
<skypos_rac>%f</skypos_rac>
<skypos_dec>%f</skypos_dec>
<fraction_done>%f</fraction_done>
<cpu_time>%f</cpu_time>
<update_time>%f</update_time>
</graphics_info>
All the values (%f) are floats. The sky position is given in rad.
Future Apps will pass additional information:
<graphics_info>
<skypos_rac>%f</skypos_rac> (float) right ascension current sky-position [rad]
<skypos_dec>%f</skypos_dec> (float) declination of current sky-position [rad]
<fraction_done>%f</fraction_done> (float) progress done so far, [0.0...1.0]
<cpu_time>%f</cpu_time> (float) CPU time spent so far [sec]
<update_time>%f</update_time> (float) timestamp of this XML
<frequency>%f</frequency> (float) base frequency of the current search [Hz]
<bandwidth>%f</bandwidth> (float) frequency bandwidth [Hz] - search will range
from frequency to frequency+bandwidth
<candidate> One of current "top candidates" for a GW pulsar signal in this WU
<frequency>%f<frequency> (float) base frequency
<spindown>%f<spindown> (float) spindown
<rac>%f<rac> (float) right ascension
<dec>%f<dec> (float) declination
<hough_sig>%f<hough_sig> (float) hough significance (kind of rating)
</candidate>
<boinc_status> The current BOINC status of the task / App
<no_heartbeat>%d<no_heartbeat> (see boinc/api/boinc_api.h)
<suspended>%d<suspended>
<quit_request>%d<quit_request>
<reread_init_data_file>%d<reread_init_data_file>
<abort_request>%d<abort_request>
<working_set_size>%f<working_set_size>
<max_working_set_size>%f<max_working_set_size>
</boinc_status>
</graphics_info>,
The information contained in the XML may be extended in the future (e.g. on request) - that's why we chose XML.
A lot of data you probably want to show is passed to the App from the BOINC Core Client in a file init_data.xml. You could use BOINC functions to read and parse it:
Call boinc_parse_init_data_file() once at the beginning of your program, then boinc_get_init_data(/*APP_INIT_DATA*/ app_init_data) will get you a copy of the BOINC-internal APP_INIT_DATA structure in your variable app_init_data. The full definition of APP_INIT_DATA is in boinc/lib/app_ipc.h, it lists things like user- and teamname, total credit and RAC for host and user account etc., but also some technical stuff like the path to the project and slot directories on your disk.
A GLUT-based OpenGL event-loop is provided by BOINC as boinc_graphics_loop(argc,argv). When using this it will take care of the command-line parsing (i.e. "--fullscreen" disticntion), termination in fullscreen mode etc. Some documentation can be found in the BOINC Wiki at http://boinc.berkeley.edu/trac/wiki/GraphicsApi . The current Einstein@home starsphere uses this loop, but mainly because it's the way things were done previously and it required only minimal changes to the code. For new implementations I'd rather drop GLUT, partly because it's incompatible with the "virtual root window"-concept of xscreensaver. I'd use SDL or some other portable library to manage windows and interaction for OpenGL graphics. You could use DirectX, too, but then your graphics program is limited to MS Windows.
All the current S5R3 "separate graphics Apps" 4.25-4.27 come with an app_info.xml. To let your graphics program run with BOINC, place the program in the project directory and replace the einstein_S5R3_*_graphics_* entry in app_info.xml with your program filename (and restart the client). If all goes well, pressing "Show graphics" in the manager will fire up the graphics in a window, and the BOINC Screensaver will start it in fullscreen mode.
I intend to publish the Einstein@home starsphere sourcecode as an example soon.
Looking forward to hearing from you!
BM
BikemanForum moderator
Volunteer developer
Joined: Aug 28 06
Posts: 2056
ID: 210833
Credit: 5,079,839
RAC: 9,661
Now this sounds cool!!
Think about the possibilities, e.g. you could interface E@H with other program, like Starry night or Stellarium, as was proposed in teh "Wish List" sub-forum several times, e.g. here.
I think a nice extension to the XML interface would be a filename & path to a file containing all the current toplist candidates, so basically the checkpointing file, but probably a copy of it that is refreshed less frequently to so that the graphics and checkpointing is decoupled and would not interfere with each other.
Then you could write a screensaver that displays progress similar to the TOPCAT graphics shown in the "visualization" thread.
CU
Bikeman
____________
I think a nice extension to the XML interface would be a filename & path to a file containing all the current toplist candidates, so basically the checkpointing file, but probably a copy of it that is refreshed less frequently to so that the graphics and checkpointing is decoupled and would not interfere with each other.
One info contained in the APP_INIT_DATA is the slot directory the App is running in which contains the checkpoint file (*.cpt). You could make a copy of it for your own use periodically. I'd recommend to use boinc_copy() from the BOINC library for this (see boinc/lib/filesys.h), it will take care of platform dependencies (e.g. retry when the file is locked by the App or a virus scanner on Windows). You could keep the copy in the slot directory, it is cleaned up by the client once the task exits.
Oh, and actually also the graphics program should be started from the slot, i.e. will have the slot directory with the checkpoint file as CWD. So using "./" for the files should be fine.
We have one guy at the AEI Hannover who started working on passing the info (XML and APP_INIT_DATA) over the network, i.e. the "graphics program" is a server which the actual graphics program could connect to also from a remote machine.
BM
you could interface E@H with other program, like Starry night or Stellarium, as was proposed in teh "Wish List" sub-forum several times, e.g. here.
That's a pretty good point I didn't even think about before.
Any volunteers?
BM
This sounds really cool. Pity I suck at graphics programming ;-) but I'm curious what the cracks can do. Success to all of you who try!
I intend to publish the Einstein@home starsphere sourcecode as an example soon.
Here it is: The sourcecode starsphere.zip and some libraries (JpegLib and freeglut) precompiled for an easier build on Windows: win_adds.zip.
The Windows build should work with Visual Studio Pro 2003 and 2005; I don't think BOINC currently compiles with VS 2008 (though the files affected may not be needed for the graphics build). As for the Express editions I doubt that they will work with this setup, though someone might be able to publish a project file for this. Shouldn't be hard to collect the necessary information from the batch file.
BM
More information on how to make and test screen saver graphics, can be read on Eric Myers' BOINC Developers' Notes - Graphics site.
____________
Jord
-The BOINC FAQ Service
-CUDA/CAL Stream FAQ
More information on how to make and test screen saver graphics, can be read on Eric Myers' BOINC Developers' Notes - Graphics site.
Oh, he updated it for v6?
____________
Please use "reply to this post" instead of "reply to this thread" . See Threads
Oh, he updated it for v6?
The page was last updated in late January 2008. He lists an email address for corrections and improvement suggestions. It would appear he has every intention of keeping the page up to date.
____________
Cheers,
Gary.
(void*)boinc_graphics_get_shmem("EinsteinHS") returns a pointer to a shared memory segment into which the main Einstein@home application writes a XML document describing its current status.
Is it a null-terminated string?
With the data being text, the length of individual fields can change, shifting off all the rest. There is a possible race condition: The science app updating the contents while the graphics app is halfway parsing it. For example, say the graphics app reads <cpu_time>, and then reads a 4-digit number. At this point, the science app updates the XML contents, and cpu_time ends up having a 5-digit number. If the graphics app continues reading at the byte offset it had left off, it would get /cpu_time> (note the lost open bracket).
I don't know how you could do proper synchronization though... (hint: an "I'm currently updating" byte won't work)
____________
Please use "reply to this post" instead of "reply to this thread" . See Threads
(void*)boinc_graphics_get_shmem("EinsteinHS") returns a pointer to a shared memory segment into which the main Einstein@home application writes a XML document describing its current status.
Is it a null-terminated string?
With the data being text, the length of individual fields can change, shifting off all the rest. There is a possible race condition: The science app updating the contents while the graphics app is halfway parsing it. For example, say the graphics app reads <cpu_time>, and then reads a 4-digit number. At this point, the science app updates the XML contents, and cpu_time ends up having a 5-digit number. If the graphics app continues reading at the byte offset it had left off, it would get /cpu_time> (note the lost open bracket).
I don't know how you could do proper synchronization though... (hint: an "I'm currently updating" byte won't work)
It is a null-terminated string. And yes, it's possible that the data or part of it is outdated. I wouldn't rely on the data for calculation, in particular not when the XML is malformed (one should really use an XML library for parsing, don't use the dirty hack of the example!), but for the graphics display it should be ok to throw a possible update away.
An "I'm updating" byte would work if it's the first byte, wouldn't it?
Filling the whole shmem with zeros before writing something in there should at least cause a XML parsing error when it has been incompletely written.
Do you agree?
BM
It is a null-terminated string. And yes, it's possible that the data or part of it is outdated. I wouldn't rely on the data for calculation, in particular not when the XML is malformed (one should really use an XML library for parsing, don't use the dirty hack of the example!), but for the graphics display it should be ok to throw a possible update away.
Note BOINC uses dirty hacks instead of real XML parsers almost everywhere :( strstr(line, "<tag>") is not a valid substitute for an XML parser, is it?
An "I'm updating" byte would work if it's the first byte, wouldn't it?
If the science app sets the byte starts updating between the graphics app reading the byte and starting parsing. ie: graphics app reads byte and it's 0, science app sets byte to 1 and updates XML, graphics app starts parsing since the byte was 0.
Re-reading the "is it updating" byte before parsing each tag may not work either due to compiler optimizations, it could notice you're just reading the same thing repeatedly and optimize out all but one read.
Filling the whole shmem with zeros before writing something in there should at least cause a XML parsing error when it has been incompletely written.
I don't think it can be done really safe without using proper locking facilities from the OS. In theory, the graphics app could remain preempted during both the zero-filling and the useful-writing...
Of course some could call that a "worst case", but if it's possible, the race condition is there.
Using a binary format with fixed-size fields wouldn't solve the race condition, but the consequence would be reduced to having half the data updated and half not at some point; the data would never become "unreadable" (as it is with invalid XML).
____________
Please use "reply to this post" instead of "reply to this thread" . See Threads
Hmm wait, a possible simple solution: add a checksum somewhere. If the checksum doesn't match, read the whole thing again.
Or maybe even easier: have some integer ("version number" updated on each data refresh, preferably in binary so that there aren't field-length problems here too) before and after the XML data. If they don't match (and/or if the XML parsing fails), data was updated halfway, so it should be considered inconsistent, and needs to be read again.
____________
Please use "reply to this post" instead of "reply to this thread" . See Threads
BikemanForum moderator
Volunteer developer
Joined: Aug 28 06
Posts: 2056
ID: 210833
Credit: 5,079,839
RAC: 9,661
Hmm wait, a possible simple solution: add a checksum somewhere. If the checksum doesn't match, read the whole thing again.
Or maybe even easier: have some integer ("version number" updated on each data refresh, preferably in binary so that there aren't field-length problems here too) before and after the XML data. If they don't match (and/or if the XML parsing fails), data was updated halfway, so it should be considered inconsistent, and needs to be read again.
Hi!
So maybe it's a good idea to split the buffer into n slots of fixed length, update slots in a cyclic manner and include a checksum AND sequence number in the messages in the slots.
Most of the time, even for n=2, at most one message will be corrupted because of a race condition. A special indicator (say first byte of the buffer) can indicate the front end of the cyclic buffer to make things easier.
____________
So maybe it's a good idea to split the buffer into n slots of fixed length, update slots in a cyclic manner and include a checksum AND sequence number in the messages in the slots.
Most of the time, even for n=2, at most one message will be corrupted because of a race condition. A special indicator (say first byte of the buffer) can indicate the front end of the cyclic buffer to make things easier.
I thought of that too. However, now I have found some interesting stuff about mutexes, which would give *proper* locking... Apparently, I'd just need to do a wrapper around pthreads or Windows API to use mutexes (just like BOINC currently wraps shared memory functionality).
I'll try to write some code doing that, later; I'm currently busy on something else (coincidentally, writing a screensaver for another project!).
____________
Please use "reply to this post" instead of "reply to this thread" . See Threads
... Re-reading the "is it updating" byte before parsing each tag may not work either due to compiler optimizations, it could notice you're just reading the same thing repeatedly and optimize out all but one read. ...
Well at least in C/C++ is keyword volatile.
Directly from C/C++ reference:"The volatile keyword is an implementation-dependent modifier, used when declaring variables, which prevents the compiler from optimizing those variables. Volatile should be used with variables whose value can change in unexpected ways (i.e. through an interrupt), which could conflict with optimizations that the compiler might perform."
Might be a solution fvor this way.
But other ways can be more efficient or more stable than this one.
Mutexes are the proper way to do this. But they introduce some complexity that just for passing a bit of information just for the graphics looks like a bit of overkill to me. I'd rather wanted to keep things as simple as possible for the graphics hackers. It doesn't really matter to throw an update away or if one information gets passed and is displayed wrong for a fraction of a second. With the data curently communicated the worst thing that could actually happen is that some of the data is one update older than ome other part. With the data currently passed I don't see how that could do any harm worse than missing an update.
A reasonably easy thing to do would be to move the "timestamp" tag (<update_time>) to the beginning and write it (with a different tag name) at the end again. You can parse the XMl and if the don't agree, throw the information away and display that of the last update.
BM
Mutexes are the proper way to do this. But they introduce some complexity that just for passing a bit of information just for the graphics looks like a bit of overkill to me. I'd rather wanted to keep things as simple as possible for the graphics hackers. It doesn't really matter to throw an update away or if one information gets passed and is displayed wrong for a fraction of a second. With the data curently communicated the worst thing that could actually happen is that some of the data is one update older than ome other part. With the data currently passed I don't see how that could do any harm worse than missing an update.
My idea was giving the "graphics hackers" some code that would handle shared memory, mutexes, and even the XML parsing for them. Just give out the data.
____________
Please use "reply to this post" instead of "reply to this thread" . See Threads
I'm downloading an update to Xcode for the Mac so I can try compiling things. Boinc says to have Xcode 2.4 or higher. It seems like getting the starsphere programs compiled should be a good little project. Getting all the correct libs will probably take a little work though since I have never worked with the Boinc framework before. Should be interesting to try.
I just spent all of last week installing MySQL and getting replication going between two of my home pc's. Replication is a great thing. Now it looks like this thread may set me on many more late nights at the computer. Nothing ever is easy when it comes to programming computers. At least not when you are starting something you haven't done before. Better make sure I have lots of coffee around.
(How to get, compile and link the BOINC library is out of the scope of this description):
Ah, well ... it seems alot of the gory bits is in that part. :-)
That is, to establish & destroy a graphics context ( canvas ) for OpenGL to have a crack at rendering upon. This part is rather platform dependent, and I'd appreciate any pointers/hints/corrections/suggestions/criticism if available. My research seems to indicate:
- find the BOINC 'graphics_2' or similarly named *.h and *.lib for the relevant platform. Wandering around here seems to be fruitful.
- ditto for the glut stuff ( gl.h glu.h glut.h ) - grab the 32 bit lib for Windoze say, plus any other platform appropriate libs.
- you'd want to declare/include/link the above in a sensible/traditional fashion to the *.c / *.h files enacting 'main' and the interface callbacks etc ..... as per Mr Myers.
- sensibly name your product executable. Put it in the right directory ie. BOINC's.
- edit the app_info.xml to inform your installation of that executable ( exit & restart Boinc ... )
[ That is I'd like to try the OpenGL + GLUT + BOINC_graphics_API approach ]
I'd like to create a template for my own artistic efforts ( cough, cough .... ) and if successful let the basic code ( +/- platform variants ) on the loose for others to substitute their own . As usual I'll be hopelessly optimistic of success in my efforts .... :-)
Cheers, Mike.
____________
"I have made this letter longer than usual, because I lack the time to make it short." - Blaise Pascal
Hi Mike,
I just want to let you know that there's a refurbished version of the original Eintein@Home graphics application (starsphere) about to be released around next week. It uses SDL in conjuction with Open GL and, more importantly, provides a small but useful framework which encapsulates the following important functionalities:
- Window management
- 3D context management
- Event handling
- BOINC interfacing
- Einstein@Home interfacing
- Self-consistent build script (Linux, Mac OS, Windows/MinGW)
- Full doxygen documentation
I encourage you to have a look at this framework because it should reduce your work significantly and let's you concentrate on the actual "artistic" implementation.
Stay tuned,
Oliver
Hi Mike,
I just want to let you know that there's a refurbished version of the original Eintein@Home graphics application (starsphere) about to be released around next week. It uses SDL in conjuction with Open GL and, more importantly, provides a small but useful framework which encapsulates the following important functionalities:
- Window management
- 3D context management
- Event handling
- BOINC interfacing
- Einstein@Home interfacing
- Self-consistent build script (Linux, Mac OS, Windows/MinGW)
- Full doxygen documentation
I encourage you to have a look at this framework because it should reduce your work significantly and let's you concentrate on the actual "artistic" implementation.
Stay tuned,
Oliver
You the man! I will indeed hold fire and eagerly await. This is terrific. :-)
It is/was my stumbling block, and probably has averted others too.
OpenGL seems to be, dare I say, fairly intuitive ( state machine etc .. ) and seems to require 'only' a modicum of skill to flip around with it. I've got the "OpenGL Programming Guide" 5th Ed by the board that designed it. I've been boring through that and have roughed out a 'solar system plan' with an 'orbiting viewpoint/platform' visualisation of it + elements linking to the current task state. I'll have to be careful not to overchug the graphics engine though .... :-)
[ standard famous last words .... ]
Again thanks.
Cheers, Mike.
( edit ) and I'll go and find out what a doxygen is ...
( edit ) Ah. 'Source code documentation generator tool' - nice one.
____________
"I have made this letter longer than usual, because I lack the time to make it short." - Blaise Pascal
Finally our new framework for BOINC graphics is ready for release! This should make it much easier to build an own Einstein@home graphics application, as it encapsulates all the communication with BOINC or the science App. It still requires programming the actual graphics, though.
To get it, follow this link to the entry page of the documentation and see the section "Source Code Access".
The new graphics applications built from that framework will honor the new "Graphics settings" you may have noticed in your "Einstein@Home preferences".
The new Arecibo Binary Pulsar search applications were already delivered with this new graphics applications, while the S5R5 "Hierarchical Search" Apps still come with the old graphics you're used to. So consider it the first field test for the new graphics code to build your own graphics binaries and run them with the existing S5R5 workunits.
We are happily awaiting your contributions.
BM
I have no clue of writing programs for anything dealing with computers. Besides, I don't have an artistic ability. Good luck to everyone that tries and, hopefully, succeeds. As for myself, I think I will wait to see what comes out of this good spirited contest and then choose from what is offered.
Hi
I would like to build a starsphere for windows with MinGw.
There is a dead link for downloading "gcc-core-3.4.5".
I can't access to http://umn.dl.sourceforge.net/sourceforge/mingw/gcc-core-3.4.5-20060117-1-src.tar.gz
I have downloaded gcc-core from sourceforge. The problem may be here ?
I add gcc-core in 3rdparty/mingw/packages/. The build of MinGW is OK.
During the build of libxml2, I had some errors :
3rdparty/libxml2/python/libxml.c -o libxml.o
1)
/usr/include/python2.5/pyport.h:257:24: sys/select.h: No such file or directory
2)
/3rdparty/libxml2/include/libxml/encoding.h:28:19: iconv.h: No such file or directory
The headers files, iconv.h and select.h, are absent in /install/include/ directory.
I think, MinGW can't build libxml2 because he haven't all tools for that.
libxml2 tool need to be patched for MinGW ?
Under linux (./build.sh --linux) the build is OK, I can run the graphic app.
Thank you for your help
Romain
Hi Romain,
Thanks for trying the framework and spotting this issue! Your're right, the MinGW build is broken right now. This is due to the fact that the MinGW project released new versions of its GCC, Win32 API, binutils and runtime packages - unfortunately they changed the package naming conventions without amending their cross-compile toolset (xscripts). I already notified them about that issue and I'll try to come up with a workaround in the next couple of days.
Stay tuned and thanks for your patience,
Oliver
Update: I pushed a workaround (tested on Debian Lenny) into the framework repository. Please update your sources (via git or download) and try again. This workaround fixes the MinGW issue which was, by the way, not at all related to libxml2. Hopefully the MinGW project will fix their scripts accordingly...
Cheers,
Oliver
Some notes as I go, which may be of interest to others. Maybe not. :-)
Downloaded the recently posted MingW workaround ( 15/02/09 ).
Using a machine with Suse Linux 11.0 distribution. Closest to Ubuntu apparently, but read on. Found using the build.sh script that I needed to install a couple of things - lacking items in the prerequisite toolchain. Ok, so use the package manager that came with Suse. However :
- 'cvs' wont install in the presence of Subversion. Un-install Subversion then install 'cvs'. Then re-install Subversion! Fine now.
- 'svn' in the script but known as 'subversion' to the shell, hence in '.profile' ( hidden in my home directory ) put :
alias svn='subversion'
- need 'lex' but Suse only has 'flex' ( faster lex ), so install that instead and again in the .profile :
alias lex='flex'
- need 'yacc' but Suse's closest is 'bison' ( ha ha ... ), so whack that in and also :
alias yacc='bison'
Now on Suse 'g++'/'gcc' may not be known as such, or aliased appropriately, so you'd might want ( in .profile again ) :
CC='gcc-4.3'
CXX='gcc-4.3'
export CC # for good measure
export CXX # for good measure
that is version 4.3.1 actually ( use 'g++ -v' on a command line to reveal that ). In the 'build_linux()' function [ line 468 of build.sh ] I see a note re. 'gcc/g++ 4.0.3' - OK to exceed that, or is that exact version preferred?? I look in /usr/bin for the actual executables/links.
With a logout/login cycle to scoop all those up with a profile re-read.
If the build script says 'this may take a while' - it means it!! Clearly downloading, un-compressing, renaming etc. Note all this stuff gets lobbed into (sub) directories that branch from wherever you unzipped the original framework to.
Haven't completed a build yet ( trying 'build.sh --linux' ), still in the 'prepare_generic()' function, as at present seems to be timing out on the repository for 'libxml2' retrieval. Will keep re-trying and get back on that ...
[ And I'm having fun learning about bash scripting! I'll be doing a course in unix/bash/perl/python over the next 3 months, so that's dandy timing. :-) ]
Cheers, Mike.
( edit ) Ok, for 'libxml2' I managed to use ftp on a Windows machine to get 'libxml2-sources-2.6.32.tar.gz', as per line 143, no problem. Then executed lines 142 - 148 ( bar line 143 ) manually to get the unzip/structure in the '3rdparty' subdirectory. Then rem out those lines and retry the build script. Has now gone through start of 'build_linux()' and hence start of 'build_generic()' as we speak ...
SDL, Freetype2, OGLFT and BOINC retrievals no problems. Since 'wget' for the Freetype2 worked OK, but not for 'libxml2' then that suggests a problem at xmlsoft.org .........
( edit ) Oh dear, it's vomited on the SDL build - a blizzard of errors. Here's the relevant section of the log file.
____________
"I have made this letter longer than usual, because I lack the time to make it short." - Blaise Pascal
BikemanForum moderator
Volunteer developer
Joined: Aug 28 06
Posts: 2056
ID: 210833
Credit: 5,079,839
RAC: 9,661
Funny, I'm developing under Suse Linux 11 as well, and I do get svn as an executable , not subversion. I've cvs and svn installed.
The problem I had under Suse 11.0 with the screensaver framework was that I could find no libaudio lib, neither installed nor in the repository. Same for you? I don't think it#s actually used, just needed because of dependencies, and borrowing a libaudio from another minux box fixed it.
CU
Bikeman
____________
Some notes as I go, which may be of interest to others. Maybe not. :-)
- 'cvs' wont install in the presence of Subversion. Un-install Subversion then install 'cvs'. Then re-install Subversion! Fine now.
- 'svn' in the script but known as 'subversion' to the shell, hence in '.profile' ( hidden in my home directory ) put :
alias svn='subversion'
That's strange - even for Suse ;-) Interestingly Bikeman's installation doesn't expose that problem.
- need 'lex' but Suse only has 'flex' ( faster lex ), so install that instead and again in the .profile :
alias lex='flex'
- need 'yacc' but Suse's closest is 'bison' ( ha ha ... ), so whack that in and also :
alias yacc='bison'
I intentionally used lex and yacc because they're the original "incarnations" of these tools. Of course they're usually replaced by flex and bison (also true for my system) but the distributions I know all put symlinks to lex and yacc in place (for backwards compatibility).
In the 'build_linux()' function [ line 468 of build.sh ] I see a note re. 'gcc/g++ 4.0.3' - OK to exceed that, or is that exact version preferred?? I look in /usr/bin for the actual executables/links.
There is no preferred version as long as you use gcc 4.x. The reference in the build script only states what we use for the official build.
If the build script says 'this may take a while' - it means it!! Clearly downloading, un-compressing, renaming etc. Note all this stuff gets lobbed into (sub) directories that branch from wherever you unzipped the original framework to.
Yep, and a "./build.sh --distclean" cleans up everything again.
Haven't completed a build yet ( trying 'build.sh --linux' ), still in the 'prepare_generic()' function, as at present seems to be timing out on the repository for 'libxml2' retrieval. Will keep re-trying and get back on that ...
Sad but true. As all of the dependencies are downloaded automatically it may happen that sometimes they're simply not available :-/ But I think that's still better than relying on the user/developer to prep his/her system manually. In my experience sourceforge.net as well as the BOINC repository are the most unreliable sources...
[ And I'm having fun learning about bash scripting! I'll be doing a course in unix/bash/perl/python over the next 3 months, so that's dandy timing. :-) ]
Great! Please keep in mind that the build script came into existence to ease my local build process. Therefore there's much potential for improvements that make it more intelligent and robust. Of course I'm happy to accept your contributions (e.g. automake/autoconf) :-)
Cheers,
Oliver
( edit ) Ok, for 'libxml2' I managed to use ftp on a Windows machine to get 'libxml2-sources-2.6.32.tar.gz', as per line 143, no problem. Then executed lines 142 - 148 ( bar line 143 ) manually to get the unzip/structure in the '3rdparty' subdirectory. Then rem out those lines and retry the build script. Has now gone through start of 'build_linux()' and hence start of 'build_generic()' as we speak ...
SDL, Freetype2, OGLFT and BOINC retrievals no problems. Since 'wget' for the Freetype2 worked OK, but not for 'libxml2' then that suggests a problem at xmlsoft.org .........
That's the "download availability issue" once again. However, it never occurred that often when I built the screensavers the last couple of times...
( edit ) Oh dear, it's vomited on the SDL build - a blizzard of errors. Here's the relevant section of the log file.
That's an easy one: your system misses the libdirectfb-dev package (or similar on Suse, look which package contains directfb.h).
I guess I have to revise the list of dependencies in the documentation as SDL requires a couple of development packages I obviously haven't yet mentioned.
Best,
Oliver
@ Oliver : Thank you, you've been very helpful. I'll look into all of that. :-)
@ Bikeman: No, I can't find libaudio either! But Google immediately indicates a number of sites to obtain it from.
Cheers, Mike.
( edit ) It seems that 'pulseaudio' is used in more recent Linux distros.
____________
"I have made this letter longer than usual, because I lack the time to make it short." - Blaise Pascal
Ok, got annoyed with the sound business. SUSE didn't have the required version for ESD ( >= 0.2.8 ), the sound driver. Nothing has been written for this distro that would satisfy the SDL build. Found the esd 0.2.8 package to compile with but my Suse isn't an accessible host/target for the script, written ~ 2004.
So who needs sound for a screensaver?? Not me ..... :-)
Looking in 'build.sh' at 'build_generic()' function at around line 214+ the configure for SDL build can be altered to remove building of the sound aspects. If you go to :
your_project_root_directory_here/3rdparty/sdl/
and type
./configure --help
you'll get the options for the SDL build that appear below. Now replace lines 214 to 221 in 'build.sh' with these :
which as far as I can tell eliminates all sound components. Then rebuild. Worked a treat for me, have done a --linux build with no problems. :-) :-)
if [ "$1" == "$TARGET_MAC_INTEL" -o "$1" == "$TARGET_MAC_PPC" ]; then
$ROOT/3rdparty/sdl/configure --prefix=$ROOT/install --enable-audio=no \
--enable-oss=no --enable-alsa=no --disable-alsatest \
--enable-alsa-shared=no --enable-esd=no --disable-esdtest \
--enable-esd-shared=no --enable-pulseaudio=no \
--enable-pulseaudio-shared=no --enable-arts=no --enable-arts-shared=no \
--enable-nas=no --enable-diskaudio=no --enable-dummyaudio=no \
--enable-mintaudio=no \
--enable-shared=no --enable-static=yes --enable-screensaver=yes \
--enable-video-x11=no >> $LOGFILE 2>&1 || failure
else
$ROOT/3rdparty/sdl/configure --prefix=$ROOT/install --enable-audio=no \
--enable-oss=no --enable-alsa=no --disable-alsatest \
--enable-alsa-shared=no --enable-esd=no --disable-esdtest \
--enable-esd-shared=no --enable-pulseaudio=no \
--enable-pulseaudio-shared=no --enable-arts=no --enable-arts-shared=no \
--enable-nas=no --enable-diskaudio=no --enable-dummyaudio=no \
--enable-mintaudio=no \
--enable-shared=no --enable-static=yes --enable-screensaver=yes >> $LOGFILE 2>&1 || failure
fi
Oh, and the libdirectfb-dev came in just fine.
Cheers, Mike.
( edit ) Of course this implies that one does not later do this :
SDL_Init(SDL_INIT_AUDIO);
and like sound functionality.
____________
"I have made this letter longer than usual, because I lack the time to make it short." - Blaise Pascal
BikemanForum moderator
Volunteer developer
Joined: Aug 28 06
Posts: 2056
ID: 210833
Credit: 5,079,839
RAC: 9,661
Hi!
Sounds great (no pun intended :-) ). I suppose that the best way to keep track of all the modifications is to prepare patch files (e.g. for eliminating the audio from SGL in the build script) and post it here and/or sent it to Oliver directly.
Should we do this?
CU
Bikeman
____________
Here it is ...
Cheers, Mike.
( edit ) The only other 'optional' components for SDL operation [ ie. those that aren't initialised regardless on using SDL_Init() ] for our purposes would be CDROM I think. Of course we need video and I expect the timer too ....
( edit ) --win32 build successful ( and ran on a windows machine ) :-)
____________
"I have made this letter longer than usual, because I lack the time to make it short." - Blaise Pascal
Hi Mike and Bikeman!
So who needs sound for a screensaver?? Not me ..... :-)
Who uses Suse? Not me ;-)
To be honest, Bernd and I discussed this a couple of months ago and I wanted to keep all of SDL's nice features in the framework because you just never know. There could be someone out there who comes up with a screensaver that makes use of audio (hopefully optional) or even a joystick. The build dependencies "only" affect potential developers after all because we use fully static builds...
Oh, and the libdirectfb-dev came in just fine.
Great!
I suppose that the best way to keep track of all the modifications is to prepare patch files (e.g. for eliminating the audio from SGL in the build script) and post it here and/or sent it to Oliver directly.
As stated above, I'd like to keep this particular feature in "mainline" but we should certainly retain all "optional" patches in this thread. I think it would be even better to have some sort of a wiki for this kind of content (hm, will BOINC's upcoming Drupal CMS support that?)... If you are familiar with git you may of course clone our repository, make your personal changes and publish (e.g. at github) your repository - that's how distributed SCM works :-)
Best,
Oliver
Fair enough. I wasn't wanting to change the framework, I was just so pleased to localise my problem and get a successful build. :-)
.... and enjoying the scripting. So now the framework is in place I can get cracking on the content! :-)
Cheers, Mike.
____________
"I have made this letter longer than usual, because I lack the time to make it short." - Blaise Pascal
Thinking out loud. :-)
So for an initial/minimal stab at this, I'll use :
screen-size = 800 x 600
bits-per-pixel/color-depth = 16
( nominal ) frames-per-second = 20
and worry about other modes/options for later.
I'll also seek double-buffering if available, as with SDL you can attempt to set this with SDL_GL_SetAttribute(SDL_GL_DOUBLEBUFFER) and then use SDL_GL_GetAttribute() to see if you got it - maybe set a flag, and then only swap at end of redraw accordingly. All alternately not check the success of the setting but just call SDL_GL_SwapBuffers() anyway, as it does nothing if double buffering is not about.
Cheers, Mike.
( edit ) Here's a useful wiki for all of this stuff.
( edit ) Blush ..... well a clever bloke would look at and notice the framework already written! To wit, the WindowManager class .... and others. :-)
____________
"I have made this letter longer than usual, because I lack the time to make it short." - Blaise Pascal
BikemanForum moderator
Volunteer developer
Joined: Aug 28 06
Posts: 2056
ID: 210833
Credit: 5,079,839
RAC: 9,661
This is fun!
Mostly sticking to the existing code (I'm not good in computer gfx ), I'm trying to visualize the ongoing computation similar to the TOPCAT visualizations I've posted here earlier. Before completing the code that actually reads the checkpoint file, I used some static example data to see what the visual effect would be like. This is a screenshot showing this prototype with constellation and star features toggled off to reduce the clutter
What do you think? BTW,in the finished thing, the crosshair marker would always be at the edge of the rainbow pattern, "dropping" new rainbow-color-map pixels into the sphere as it (very slowly) moves across the sky.
Bikeman
____________
This is fun! ......
What do you think? BTW,in the finished thing, the crosshair marker would always be at the edge of the rainbow pattern, "dropping" new rainbow-color-map pixels into the sphere as it (very slowly) moves across the sky.Bikeman
Beautiful! I think it's precisely these sort of ideas that are being sought to include using the framework. Nice idea to 'paint' the pattern on, in real time, so to speak.
I'm ( ambitiously ) working/designing a basic solar system model - to be inserted within the sphere's volume, while the sphere's radius size is pushed out to some large size. I think I'll keep the starfield but drop the constellation lines/connectors. Instead of rotating the sphere I'll shift the viewpoint ( which is equivalent really in OpenGL terms anyway ) - try some 'manoevring' using the keyboard, orbits etc. I'm also thinking of a decal-like pixellated picture/texture ( on the inner/distant celestial sphere in the background ) of that famous picture of Einstein poking this tongue out! :-) The resource coding assistance part of the framework will be invaluable for that.
Cheers, Mike.
____________
"I have made this letter longer than usual, because I lack the time to make it short." - Blaise Pascal
BikemanForum moderator
Volunteer developer
Joined: Aug 28 06
Posts: 2056
ID: 210833
Credit: 5,079,839
RAC: 9,661
.
I'm ( ambitiously ) working/designing a basic solar system model - to be inserted within the sphere's volume, while the sphere's radius size is pushed out to some large size. I think I'll keep the starfield but drop the constellation lines/connectors. Instead of rotating the sphere I'll shift the viewpoint ( which is equivalent really in OpenGL terms anyway ) - try some 'manoevring' using the keyboard, orbits etc. I'm also thinking of a decal-like pixellated picture/texture ( on the inner/distant celestial sphere in the background ) of that famous picture of Einstein poking this tongue out! :-) The resource coding assistance part of the framework will be invaluable for that.
Cheers, Mike.
Wow!! That's far more complex than what I think I could do in a reasoable time span. I'm looking forward to see Albert Einstein's portrait in the screensaver, nice idea!
CU
Bikeman
____________
BikemanForum moderator
Volunteer developer
Joined: Aug 28 06
Posts: 2056
ID: 210833
Credit: 5,079,839
RAC: 9,661
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! 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:
<project_preferences>
<graphics fps="25" quality="high" width="800" height="600"/>
</project_preferences>
Cheers,
Oliver
BikemanForum moderator
Volunteer developer
Joined: Aug 28 06
Posts: 2056
ID: 210833
Credit: 5,079,839
RAC: 9,661
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:
<project_preferences>
<graphics fps="25" quality="high" width="800" height="600"/>
</project_preferences>
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.
CU
Bikeman
____________
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
BikemanForum moderator
Volunteer developer
Joined: Aug 28 06
Posts: 2056
ID: 210833
Credit: 5,079,839
RAC: 9,661
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
____________
BikemanForum moderator
Volunteer developer
Joined: Aug 28 06
Posts: 2056
ID: 210833
Credit: 5,079,839
RAC: 9,661
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 :
Could not acquire rendering surface: Couldn't find matching GLX visual
Window manager could not be initialized!
____________
BikemanForum moderator
Volunteer developer
Joined: Aug 28 06
Posts: 2056
ID: 210833
Credit: 5,079,839
RAC: 9,661
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:
export LDFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk -Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk -arch i386 $LDFLAGS"
export CPPFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 $CPPFLAGS"
export CFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 $CFLAGS"
export CXXFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 $CXXFLAGS"
export SDKROOT="/Developer/SDKs/MacOSX10.4u.sdk"
export MACOSX_DEPLOYMENT_TARGET=10.4
export MKDIRPROG="mkdir -p"
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 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
BikemanForum moderator
Volunteer developer
Joined: Aug 28 06
Posts: 2056
ID: 210833
Credit: 5,079,839
RAC: 9,661
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
git clone git://git.aei.uni-hannover.de/shared/einsteinathome/graphicsframework.git
then apply the patch using
git apply starsphere_20090318.patch
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 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
Hi Bikeman,
... but for those who want to have a look, here's a patch ...
The link to your patch is broken (local URL)... Use a public repo ;-)
Best,
Oliver
BikemanForum moderator
Volunteer developer
Joined: Aug 28 06
Posts: 2056
ID: 210833
Credit: 5,079,839
RAC: 9,661
Hi Bikeman,
... but for those who want to have a look, here's a patch ...
The link to your patch is broken (local URL)... Use a public repo ;-)
Best,
Oliver
Uppps... cut and paste error. I've repaired the link for the time being, I'll set up a public git repo later.
____________
Uppps... cut and paste error. I've repaired the link for the time being, I'll set up a public git repo later.
Sweet! One minor thing: please omit the part of the patch that modifies build.sh, it's been obsolete since commit 38b320f9 (please update your repo).
Update: please commit your changes in atomic, topic-based commits. This way people can then cherry-pick the changes they want and ignore others (e.g. the RA/DEC label change).
Oliver
BikemanForum moderator
Volunteer developer
Joined: Aug 28 06
Posts: 2056
ID: 210833
Credit: 5,079,839
RAC: 9,661
One minor thing: please omit the part of the patch that modifies build.sh, it's been obsolete since commit 38b320f9
Done, but actually I liked the idea of specifying the exact revision/date of mingw (probably also boinc) to download in the build.sh, makes the build process much more reproducible and will avoid repetition of the problem where changes in the downloaded tools/libs will break the patches that are included in the starsphere repos. Just like it's done in the Einstein@Home build script for the apps wrt. LAL and BOINC.
____________
Update: please commit your changes in atomic, topic-based commits. This way people can then cherry-pick the changes they want and ignore others (e.g. the RA/DEC label change).
Yeah, unlike BOINC! :)
____________
Please use "reply to this post" instead of "reply to this thread" . See Threads
Done, but actually I liked the idea of specifying the exact revision/date of mingw (probably also boinc) to download in the build.sh, makes the build process much more reproducible and will avoid repetition of the problem where changes in the downloaded tools/libs will break the patches that are included in the starsphere repos. Just like it's done in the Einstein@Home build script for the apps wrt. LAL and BOINC.
I agree with you as long as we're talking about projects that do have a working release/maintenance process :-) In general the GFX build script only uses fixed release tarballs or (even better) branches, hence only bug-fixes should be added to those branches which, in general, shouldn't break stuff. In case of BOINC and LAL the release processes have some considerable deficiencies which sometimes lead to problems unfortunately. However, using fixed date-based checkouts means that you don't get those bugfixes unless you monitor all 3rd party packages and update your build script on a regular basis. In addition to that, LAL is a very specific case and, as it isn't used by the GFX framework, we don't have to make provisions for correct/reproducible builds of it...
WRT MinGW, the problems we've experienced over the past few weeks were either caused by internal issues of the MinGW project (using date tags wouldn't have prevented that) or by their preparations of the 1.0 xscripts release. As soon as that's done I'm going to use their release branch. By the way, the package versions of MinGW as such have been, in fact, constant all the time - we simply used fresh copies of the MinGW cross-compile harness (xscripts).
Cheers,
Oliver
BikemanForum moderator
Volunteer developer
Joined: Aug 28 06
Posts: 2056
ID: 210833
Credit: 5,079,839
RAC: 9,661
Hi!
I'm encountering a strange problem under Windows (Windows XP Home, SP 2).
If I minimize the starsphere graphics window, most of the time the mouse pointer gets corrupted (it's set to a random pattern), and stays that way.
Anybody else seeing this?
CU
Bikeman
____________
If I minimize the starsphere graphics window, most of the time the mouse pointer gets corrupted (it's set to a random pattern), and stays that way.
Just to be sure, what exactly did you do? Do you mean minimizing a given starsphere window or changing it from fullscreen to windowed mode? The latter action involves changing the mouse pointer's visibility setting (hide/show) but none of the actions mentioned above change its appearance... Strange...
Update: I tried it myself using a Win XP Pro SP3 VM image, nothing unsusual though. However, I noticed that SDL seems to change/invert the mouse pointer's appearance as soon as one hovers the window's client area, but I don't see how this could be related to the issue you observed when minimizing the window.
Oliver
BikemanForum moderator
Volunteer developer
Joined: Aug 28 06
Posts: 2056
ID: 210833
Credit: 5,079,839
RAC: 9,661
Just to be sure, what exactly did you do? Do you mean minimizing a given starsphere window or changing it from fullscreen to windowed mode?
The former.
I've updated to SP3 now and will try again.
EDIT: My modifications are now hosted here, as suggested by Oliver:
http://wiki.github.com/Bikeman/eah_gfx_ext
CU
Bikeman
____________
Hi folks!
How are you doing?
I have a question related to (I think so anyway) the open source characteristic attached to BOINC software and projects:
I use sometimes cyrillic fonts (Russian alphabet) for some of my posts, since I am a Russian language learner.
I have realized some months ago that there´s no way to read and write correctly using russian fonts, because some little funny looking signs appear and make reading texts quite annoying. I bet you have found now and then somewhere those signs when viewing pages of other not so common visited countries/webpages.
I thought maybe some changes have been made in some folders related to those fonts.
This might be a question for programmers and webpage developers.
What do you think? Any experiences with unusual signs on your screen before?
Thanks for your help.
Cheers!
____________
Madrid 2016: Yes, we can!
Hi folks!
How are you doing?
I have a question related to (I think so anyway) the open source characteristic attached to BOINC software and projects:
I use sometimes cyrillic fonts (Russian alphabet) for some of my posts, since I am a Russian language learner.
I have realized some months ago that there´s no way to read and write correctly using russian fonts, because some little funny looking signs appear and make reading texts quite annoying. I bet you have found now and then somewhere those signs when viewing pages of other not so common visited countries/webpages.
I thought maybe some changes have been made in some folders related to those fonts.
This might be a question for programmers and webpage developers.
What do you think? Any experiences with unusual signs on your screen before?
Thanks for your help.
Cheers!
Please explain me in what way this is related to "writing your own Einstein screensaver".
____________
Please use "reply to this post" instead of "reply to this thread" . See Threads
BikemanForum moderator
Volunteer developer
Joined: Aug 28 06
Posts: 2056
ID: 210833
Credit: 5,079,839
RAC: 9,661
I'd also say that this is completely off-topic. To answer the question nevertheless, in the forum it's perfectly possible to post in cyrilic, see this message for example.
If you have further questions, please open a new thread in the Problems section, as this thread is exclusively dedicated to the screen savers :-)
Happy ćrunching
CU
Bikeman
____________
Hi folks!
How are you doing?
I have a question related to (I think so anyway) the open source characteristic attached to BOINC software and projects:
I use sometimes cyrillic fonts (Russian alphabet) for some of my posts, since I am a Russian language learner.
I have realized some months ago that there´s no way to read and write correctly using russian fonts, because some little funny looking signs appear and make reading texts quite annoying. I bet you have found now and then somewhere those signs when viewing pages of other not so common visited countries/webpages.
I thought maybe some changes have been made in some folders related to those fonts.
This might be a question for programmers and webpage developers.
What do you think? Any experiences with unusual signs on your screen before?
Thanks for your help.
Cheers!
Please explain me in what way this is related to "writing your own Einstein screensaver".
I explained it and gave some reasons for posting here, but I will try to be more simple:
I´m affraid, there´s a bug error hidden in the code used for the profile webpage on E@H.
Why? Well, in S@H I do not have this problem (the characters, fonts and links used for my profile in S@H are the same as for E@H: I just copied + pasted them).
I thought maybe someone skilled on screensavers development and with a proficient level of encoding languages should be able to understand my issue.
If the profile webpage, which can be edited with the simplest and basic elements by just common members, shows some bugs like these,
I might wonder how complex it might be to write your own screensaver with E@H tools.
Thank you.
____________
Madrid 2016: Yes, we can!
I'd also say that this is completely off-topic. To answer the question nevertheless, in the forum it's perfectly possible to post in cyrilic, see this message for example.
If you have further questions, please open a new thread in the Problems section, as this thread is exclusively dedicated to the screen savers :-)
Happy ćrunching
CU
Bikeman
Thank you very much!
I will have a look and say hello to this russian member.
My Russian is still basic, but better than screensavers encoding!!
Cheers!
____________
Madrid 2016: Yes, we can!
I'm having another run at the screensaver. Again. :-)
I'm looking hard at this factory paradigm in the framework. May I summarise to check if I'm thinking right?
- the GraphicsEngineFactory class can instantiate objects which create AbstractGraphicsEngine's. That is GraphicsEngineFactory::createInstance() returns a pointer to an AbstractGraphicsEngine.
- the AbstractGraphicsEngine class is, obviously, abstract or virtual so you have to subclass to get concrete instances. There are currently two subclasses : StarsphereS5R3 and StarsphereRadio. I select which one when I call GraphicsEngineFactory::createInstance() by indicating in it's parameter list one element from each of the enumerations GraphicsEngineFactory::Engines and GraphicsEngineFactory::Applications ( sensible combination thereof ).
- Starsphere class is derived from AbstractGraphicsEngine, but is still virtual.
- now StarsphereS5R3 class and StarsphereRadio class each multiply inherit ( subclass ) from both Starsphere and m_EinsteinAdapter classes?
[aside]Where does m_EinsteinAdapter get defined - in the BOINC library or somesuch?[/aside]
- thus StarsphereS5R3 and StarsphereRadio can be returned from a GraphicsEngineFactory::createInstance() call as they ( amongst other things like being an m_EinsteinAdapter ) can be considered of type AbstractGraphicsEngine.
- presumably one could/would/should add an enumeration constant to the GraphicsEngineFactory::Engines enum within GraphicsEngineFactory.h to indicate a new type - that I will write, call it the HewsonSphere class for this discussion.
- HewsonSphere need not derive from Starsphere, as my design for a screensaver may have no interest in the particular interface that Starsphere offers.
- HewsonSphere class could remain virtual, but probably doesn't need to be ( unlike Starsphere ). But it, or a concrete class derived from it if I leave it virtual, also needs to inherit from m_EinsteinAdapter too.
- ( assuming all of the above ) I would leave alone the GraphicsEngineFactory::Applications enumeration as it's none of my business, as I don't write science applications.
- but I need to chose an application within that GraphicsEngineFactory::Applications enumeration so that my HewsonSphere, being of type derived from m_EinsteinAdapter, can respond to do the BOINC communication thingy via.
Cheers, Mike.
____________
"I have made this letter longer than usual, because I lack the time to make it short." - Blaise Pascal
BikemanForum moderator
Volunteer developer
Joined: Aug 28 06
Posts: 2056
ID: 210833
Credit: 5,079,839
RAC: 9,661
Hi!
I don't have the code in front of me atm, but the stuff that is named m_.... is a member variable, not a class name. If memory serves me right, the "Sphere" classes are responsible for drawing and (key) event handling, and they have a member variable that points to an "Adapter" object that basically handles the interface to the science app and Boinc.
CU
Bikeman
____________
Yeah, whoops my brainfade. Saw
Starsphere(EinsteinS5R3Adapter::SharedMemoryIdentifier),
m_EinsteinAdapter(&m_BoincAdapter)
{
m_CurrentTime = "";
}
and thought "multiple inheritance". But that would be :
{
// stuff
}
When I did C++ they told me never to multiply inherit. Course failure, voodoo, nasal daemons etc .... :-)
So I never learnt it.
Cheers, Mike.
____________
"I have made this letter longer than usual, because I lack the time to make it short." - Blaise Pascal
Yeah, whoops my brainfade. Saw
StarsphereS5R3::StarsphereS5R3() :
Starsphere(EinsteinS5R3Adapter::SharedMemoryIdentifier),
m_EinsteinAdapter(&m_BoincAdapter)
{
m_CurrentTime = "";
}
This is a constructor initialiser list. Thus the Starsphere constructor is called, being the base/super-class of StarsphereS5R3. Plus the EinsteinS5R3RadioAdapter constructor too, as m_EinsteinAdapter is an EinsteinS5R3RadioAdapter. It's because you don't have direct access to the private data members of the base/superclass, or to the sub-object type represented by m_EinsteinAdapter.
Cheers, Mike.
____________
"I have made this letter longer than usual, because I lack the time to make it short." - Blaise Pascal
Hi Mike,
Yeah, whoops my brainfade. Saw
StarsphereS5R3::StarsphereS5R3() :
Starsphere(EinsteinS5R3Adapter::SharedMemoryIdentifier),
m_EinsteinAdapter(&m_BoincAdapter)
{
m_CurrentTime = "";
}
This is a constructor initialiser list. Thus the Starsphere constructor is called, being the base/super-class of StarsphereS5R3. Plus the EinsteinS5R3RadioAdapter constructor too, as m_EinsteinAdapter is an EinsteinS5R3RadioAdapter.
That's right. This is how you conveniently instantiate member objects that are not kept on the stack - otherwise you could/would use the "new" operator to do that but then you'd need to "delete" them manually in the destructor. I wanted to avoid that because it just adds complexity (without guarded pointers) while it doesn't get you anything.
I agree what you said about multiple inheritance, but sometime it just comes in handy when "unexpected needs" arise :-)
Oliver
PS: I'll comment on your previous questions soon!
Hi Mike,
Yeah, whoops my brainfade. Saw
StarsphereS5R3::StarsphereS5R3() :
Starsphere(EinsteinS5R3Adapter::SharedMemoryIdentifier),
m_EinsteinAdapter(&m_BoincAdapter)
{
m_CurrentTime = "";
}
This is a constructor initialiser list. Thus the Starsphere constructor is called, being the base/super-class of StarsphereS5R3. Plus the EinsteinS5R3RadioAdapter constructor too, as m_EinsteinAdapter is an EinsteinS5R3RadioAdapter.
That's right. This is how you conveniently instantiate member objects that are not kept on the stack - otherwise you could/would use the "new" operator to do that but then you'd need to "delete" them manually in the destructor. I wanted to avoid that because it just adds complexity (without guarded pointers) while it doesn't get you anything.
Neat.
I agree what you said about multiple inheritance, but sometime it just comes in handy when "unexpected needs" arise :-)
Oliver
PS: I'll comment on your previous questions soon!
No hurry, you're doing the CUDA stuff no doubt!! Take your time ..... :-)
I'm trying to belt Suse linux into submission regarding installing GCC. It's pretending not to find the standard libraries, maybe I'll try Debian as you developed on that.
Cheers, Mike.
____________
"I have made this letter longer than usual, because I lack the time to make it short." - Blaise Pascal
I'm trying to belt Suse linux into submission regarding installing GCC. It's pretending not to find the standard libraries, maybe I'll try Debian as you developed on that.
Cheers, Mike.
Go to software.opensuse.org, state your version and install what you need. I am using 10.3 and it works. I've compiled mplayer and other tools.
Tullio
____________
I'm trying to belt Suse linux into submission regarding installing GCC. It's pretending not to find the standard libraries, maybe I'll try Debian as you developed on that.
Cheers, Mike.
Go to software.opensuse.org, state your version and install what you need. I am using 10.3 and it works. I've compiled mplayer and other tools.
Tullio
Ah, well. I have Suse 11.1 so maybe I ought to slide back to 10.x ......
Cheers, Mike.
____________
"I have made this letter longer than usual, because I lack the time to make it short." - Blaise Pascal
Ok, here we go...
- the GraphicsEngineFactory class can instantiate objects which create AbstractGraphicsEngine's. That is GraphicsEngineFactory::createInstance() returns a pointer to an AbstractGraphicsEngine.
I would phrase it differently, but in principle this is correct!
- the AbstractGraphicsEngine class is, obviously, abstract or virtual so you have to subclass to get concrete instances. There are currently two subclasses : StarsphereS5R3 and StarsphereRadio. I select which one when I call GraphicsEngineFactory::createInstance() by indicating in it's parameter list one element from each of the enumerations GraphicsEngineFactory::Engines and GraphicsEngineFactory::Applications ( sensible combination thereof ).
Correct. The whole notion of a "GraphicsEngine" stems from the idea of different visualization "plugins" - Starsphere being only one of them, coming in two different styles (one each for S5 and ABP).
At some point I want(ed) to implement the different engines as true plugins that are loaded dynamically during GFX startup. Which visulization engine/plugin gets used could be set by the user in the project specific preferences for example... In order to prepare for this I had to provide a common interface for all future implementations - that's what AbstractGraphicsEngine is all about.
- Starsphere class is derived from AbstractGraphicsEngine, but is still virtual.
Yep, it's one specific engine but in two different styles/flavors. One's used for S5Rx and one for ABP. Thus Starsphere contains the common parts of both flavors.
- now StarsphereS5R3 class and StarsphereRadio class each multiply inherit ( subclass ) from both Starsphere and m_EinsteinAdapter classes?
Nope, but we already discussed that :-) Both classes contain the respective application-specific parts. Don't be confused by the somehow outdated naming: S5 always refers to the hierarchical search and Radio/ERP/ABP refer to the radio pulsar search - the usual historical reasons ;-)
[aside]Where does m_EinsteinAdapter get defined - in the BOINC library or somesuch?[/aside]
That's an instance of EinsteinS5R3Adapter and a member of StarsphereS5R3. This is the interface to the BOINC client and the shared memory segment used to pass real-time search information from the science application to the graphics application. As this information is different for S5 and ABP, there're two implementations of the abstract class BOINCClientAdapter.
- thus StarsphereS5R3 and StarsphereRadio can be returned from a GraphicsEngineFactory::createInstance() call as they ( amongst other things like being an m_EinsteinAdapter ) can be considered of type AbstractGraphicsEngine.
Yes, both are implementations of AbstractGraphicsEngine (but forget about "being an m_EinsteinAdapter").
- presumably one could/would/should add an enumeration constant to the GraphicsEngineFactory::Engines enum within GraphicsEngineFactory.h to indicate a new type - that I will write, call it the HewsonSphere class for this discussion.
Correct!
- HewsonSphere need not derive from Starsphere, as my design for a screensaver may have no interest in the particular interface that Starsphere offers.
Also correct. That's the reason why there's a framework. You don't have to care about anything in the "starsphere" folder (almost, see next topic), just create your own and use what's in "framework". Starsphere should only serve as an example of how to use the framework.
- HewsonSphere class could remain virtual, but probably doesn't need to be ( unlike Starsphere ). But it, or a concrete class derived from it if I leave it virtual, also needs to inherit from m_EinsteinAdapter too.
HewsonSphere should be abstract/virtual only if you have one or more children that specialize it. Otherwise it's a single concrete class implementing AbstractGraphicsEngine.
Considering the Einstein[APP]Adapter classes: it's not inheritance, it's a composition. But I suppose that's clear by now, isn't it? So this is the only part of the "starsphere" directory that could be of interest to you. When you want to use the information provided by the science apps mentioned above, you need the Einstein[APP]Adapter classes.
Background: the framework is meant to be useful for all BOINC projects, therefore it doesn't contain anything project-specific. Unfortunately this is not 100% true, however, because of the intended plugin concept that's not yet implemented. So for the time being GraphicsEngineFactory contains these tiny project-related bits :-/ A working plugin-concept would let the factory query all available plugins for their identifiers (engine/application) dynamically, so that this information would not have to be stored/maintained manually in its header as it is today (see below).
- ( assuming all of the above ) I would leave alone the GraphicsEngineFactory::Applications enumeration as it's none of my business, as I don't write science applications.
- but I need to chose an application within that GraphicsEngineFactory::Applications enumeration so that my HewsonSphere, being of type derived from m_EinsteinAdapter, can respond to do the BOINC communication thingy via.
No, right now you need to specify both, an "engine" and an "application". Both are are needed to identify a specific graphics application (can be the same in your case). The "application" IDs are meant to differentiate between separate implementations of the graphics code for, say, SxRx and ABPx.
I hope all this makes some sense to you. Let me know if you have more questions. BTW, are you aware of the available documentation (doxygen)?
Best,
Oliver
Ok, here we go...
- the GraphicsEngineFactory class can instantiate objects which create AbstractGraphicsEngine's. That is GraphicsEngineFactory::createInstance() returns a pointer to an AbstractGraphicsEngine.
I would phrase it differently, but in principle this is correct!
- the AbstractGraphicsEngine class is, obviously, abstract or virtual so you have to subclass to get concrete instances. There are currently two subclasses : StarsphereS5R3 and StarsphereRadio. I select which one when I call GraphicsEngineFactory::createInstance() by indicating in it's parameter list one element from each of the enumerations GraphicsEngineFactory::Engines and GraphicsEngineFactory::Applications ( sensible combination thereof ).
Correct. The whole notion of a "GraphicsEngine" stems from the idea of different visualization "plugins" - Starsphere being only one of them, coming in two different styles (one each for S5 and ABP).
At some point I want(ed) to implement the different engines as true plugins that are loaded dynamically during GFX startup. Which visulization engine/plugin gets used could be set by the user in the project specific preferences for example... In order to prepare for this I had to provide a common interface for all future implementations - that's what AbstractGraphicsEngine is all about.
I see now. In true OO flavour. Very much like a Java interface.
- Starsphere class is derived from AbstractGraphicsEngine, but is still virtual.
Yep, it's one specific engine but in two different styles/flavors. One's used for S5Rx and one for ABP. Thus Starsphere contains the common parts of both flavors.
- now StarsphereS5R3 class and StarsphereRadio class each multiply inherit ( subclass ) from both Starsphere and m_EinsteinAdapter classes?
Nope, but we already discussed that :-) Both classes contain the respective application-specific parts. Don't be confused by the somehow outdated naming: S5 always refers to the hierarchical search and Radio/ERP/ABP refer to the radio pulsar search - the usual historical reasons ;-)
Got that.
[aside]Where does m_EinsteinAdapter get defined - in the BOINC library or somesuch?[/aside]
That's an instance of EinsteinS5R3Adapter and a member of StarsphereS5R3. This is the interface to the BOINC client and the shared memory segment used to pass real-time search information from the science application to the graphics application. As this information is different for S5 and ABP, there're two implementations of the abstract class BOINCClientAdapter.
Ditto.
- thus StarsphereS5R3 and StarsphereRadio can be returned from a GraphicsEngineFactory::createInstance() call as they ( amongst other things like being an m_EinsteinAdapter ) can be considered of type AbstractGraphicsEngine.
Yes, both are implementations of AbstractGraphicsEngine (but forget about "being an m_EinsteinAdapter").
Yup.
- presumably one could/would/should add an enumeration constant to the GraphicsEngineFactory::Engines enum within GraphicsEngineFactory.h to indicate a new type - that I will write, call it the HewsonSphere class for this discussion.
Correct!
- HewsonSphere need not derive from Starsphere, as my design for a screensaver may have no interest in the particular interface that Starsphere offers.
Also correct. That's the reason why there's a framework. You don't have to care about anything in the "starsphere" folder (almost, see next topic), just create your own and use what's in "framework". Starsphere should only serve as an example of how to use the framework.
Mind you, there are a couple or seven things I will pinch from the Starsphere area. Those star co-ordinate lists for one. But I'll chop and trim them into my own interface.
- HewsonSphere class could remain virtual, but probably doesn't need to be ( unlike Starsphere ). But it, or a concrete class derived from it if I leave it virtual, also needs to inherit from m_EinsteinAdapter too.
HewsonSphere should be abstract/virtual only if you have one or more children that specialize it. Otherwise it's a single concrete class implementing AbstractGraphicsEngine.
Yup, I'll keep it simplest pro-tem. Can always generalise later.
Considering the Einstein[APP]Adapter classes: it's not inheritance, it's a composition. But I suppose that's clear by now, isn't it?
Got that.
So this is the only part of the "starsphere" directory that could be of interest to you. When you want to use the information provided by the science apps mentioned above, you need the Einstein[APP]Adapter classes.
Background: the framework is meant to be useful for all BOINC projects, therefore it doesn't contain anything project-specific. Unfortunately this is not 100% true, however, because of the intended plugin concept that's not yet implemented. So for the time being GraphicsEngineFactory contains these tiny project-related bits :-/ A working plugin-concept would let the factory query all available plugins for their identifiers (engine/application) dynamically, so that this information would not have to be stored/maintained manually in its header as it is today (see below).
So quite general. There may be all sorts of weird and wonderful science apps in the future. Weird and wonderful BOINC projects ....
[ 'Hello factory! I'm a HewsonSphere and I work with the EinsteinS5R3 ....' ]
We never did the factory paradigm either. But I can see the difference between concrete factory class objects producing object instances that are ultimately derived from virtual classes vs. an abstract factory class per se. ( I spent half a day up the wrong street on that one ). Phew! 'Virtual' really does mean "to be defined later in a class ultimately derived from this one". Let me guess - somewhere in the world someone has written a factory that creates other factories ....... :-)
- ( assuming all of the above ) I would leave alone the GraphicsEngineFactory::Applications enumeration as it's none of my business, as I don't write science applications.
- but I need to chose an application within that GraphicsEngineFactory::Applications enumeration so that my HewsonSphere, being of type derived from m_EinsteinAdapter, can respond to do the BOINC communication thingy via.
No, right now you need to specify both, an "engine" and an "application". Both are are needed to identify a specific graphics application (can be the same in your case). The "application" IDs are meant to differentiate between separate implementations of the graphics code for, say, SxRx and ABPx.
Got that.
I hope all this makes some sense to you. Let me know if you have more questions. BTW, are you aware of the available documentation (doxygen)?
Blush .... :-) Well caught. I read it after I posted. Today's lesson is : Read The Fine Manual !! :-)
Looking at the resource compiler ( orc.cpp ) - you want better filename checking? I'll make that a side project. Shame standard library C++ doesn't do regex. Mind you if the wrong filename is given it'll fall over pretty quick anyway. And you're likely to be invoking from a makefile, so if the filename is wrong you'd have rather bigger problems.
Cheers, Mike.
( edit ) For that matter, I'll pinch your comment/documentation style too. It could be Doxygen'ed later!
____________
"I have made this letter longer than usual, because I lack the time to make it short." - Blaise Pascal
Thinking out loud. No need to answer. :-)
There's considerable freedom with the resource compiler. A nifty deal. For example :
- pick an image, say, that you want to use in some way within the screensaver animation.
- think of the form you'll need it in when it will be called/used by some Open GL functionality. Like an array of RGBA values ( three colors plus alpha - the blending/transparency factor ).
- but there are many choices, primarily related to how quick/efficient you want the rendering and in what manner - vertex series, a raster image, a texture map, even a line stippling pattern perhaps. Whatever floats your boat. Mentally I work from an idea of the proposed rendering technique ( so you need to study OpenGL!! ) back through to the best/suitable format to have it stored within the executable.
- give the data a symbolic name ( as a C++ string ) that you will use programmatically to represent it. The resource compiler will associate that string with the C++ type vector<unsigned char>. That's essentially a byte array, but with STL vector functionality to call upon ( in particular it's resizable and all that memory management stuff entailed therein ).
- in a '*.orc' file ( 'resources.orc' currently ) supply the association, as described, between the above symbolic name and the actual file name from which the bytes will be retrieved. Excepting comments, denoted by '#" at line start, the lines in this file are of type 'TheSymbolicName|TheFileNameToGetByteDataFrom'.
- this association is kept in a map ( associative array ResourceCompiler::m_ResourceFileMap ) which is used by the ResourceCompiler to drag the data in when called to do so ( ie. the ResourceCompiler::compile() member function ).
- this creates another file of style 'SomethingOrOther.cpp' which then joins your compilation. That name would/should/could be provided in a makefile. Currently :
line 49 :
'RESOURCESPEC = resources'
lines 101 - 104:
# resource compiler
$(RESOURCESPEC).o: $(STARSPHERE_SRC)/$(RESOURCESPEC).orc
$(STARSPHERE_INSTALL)/bin/orc $(STARSPHERE_SRC)/$(RESOURCESPEC).orc $(RESOURCESPEC).cpp
$(CXX) -g $(CPPFLAGS) -c $(RESOURCESPEC).cpp -o $(RESOURCESPEC).o
so this keeps the 'resource cache' naming coherent across the project.
- now there's another map ( ResourceCompiler::m_ResourceDataMap ) correlating the symbolic name you chose originally and the actual byte data ( as a vector<unsigned char> ) that you want to be using during your rendering process(es). ResourceCompiler::m_ResourceCodeFile keeps track of the source code file that contains the C++ code produced during ResourceCompiler::compile().
- note the 'SomethingOrOther.cpp' file now contains data from possibly many files : as many as were specified in the '*.orc' file initially.
Phew!! :-)
- NOW the programmatic method for accessing the data is to have a ResourceFactory.
- it picks up on the following members within 'SomethingOrOther.cpp' : c_ResourceIdentifiers, c_ResourceIndex and c_ResourceStorage. These array names were declared as 'extern' when ResourceCompiler::compile() wrote the file ( 'extern' lets you define a symbol in one compilation unit/file but refer to it from another ). See lines 90 thru 107 of ResourceCompiler.cpp .... in other words the ResourceCompiler class actually writes C++ code with 'hard' data declarations.
- the ResourceFactory instance returns pointers to instantiations of type Resource. And Resource has these two public member functions :
- Resource::data() to return a const vector< unsigned char > * ( the data from the original file )
- Resource::identifier() to return a string ( the name you chose to represent it )
- but note well : when you invoke ResourceFactory::createInstance( const string identifier ) then identifier has to be the same as the one specified in the *.orc file used to compile the resources.
- all the identifier's have been kept coherent with the content of their respective initial data files throughout the construction chain. A really nifty job Oliver!! :-)
Cheers, Mike.
( edit ) and there's const-ness about liberally all the way through, but you can cast around that if you dare.
( edit ) And I'll have to dust off my Josuttis. Again. :-)
____________
"I have made this letter longer than usual, because I lack the time to make it short." - Blaise Pascal
Hi Mike,
Phew! 'Virtual' really does mean "to be defined later in a class ultimately derived from this one".
Just to clarify the terminology differences between Java and C++: Java uses the standard terms "interface" and "abstract class" while C++ (IMHO just being C with an OO add-on) does it differently.
In C++ an abstract class is a class that contains at least one abstract method (declared as "pure virtual" (see below), not defined) that's to be defined in an implementing child in order to be instantiated - just like Java but with a different declaration. However, an interface is again just declared as a class but this time it contains only abtract methods.
Be careful when you notice the keyword "virtual": virtual just means that this (declared and defined) method is allowed to be overwritten/substituted by a child class. However, if a virtual declaration ends with "= 0" then this method is an abtract method, or "pure virtual" in C++ terms. Have a look at XMLProcessorInterface.h and AbstractGraphicsEngine.h as an example.
Looking at the resource compiler ( orc.cpp ) - you want better filename checking? I'll make that a side project. Shame standard library C++ doesn't do regex. Mind you if the wrong filename is given it'll fall over pretty quick anyway. And you're likely to be invoking from a makefile, so if the filename is wrong you'd have rather bigger problems.
Right, the focus was to embed safely any kind of resource (e.g. fonts, images) in the final executable. ORC's file name checking is, say, sufficient. It might indeed just lead to a build problem that's triggered immediately when there's an error in the Makefile.
( edit ) For that matter, I'll pinch your comment/documentation style too. It could be Doxygen'ed later!
Recommended :-)
Best,
Oliver
Thinking out loud. No need to answer. :-)
Just one comment required: you got it!
Oliver
Just to clarify the terminology differences between Java and C++: Java uses the standard terms "interface" and "abstract class" while C++ (IMHO just being C with an OO add-on) does it differently.
In Java everything is a class/object, but no multiple inheritance. In C++ maybe/maybe not.
In C++ an abstract class is a class that contains at least one abstract method (declared as "pure virtual" (see below), not defined) that's to be defined in an implementing child in order to be instantiated - just like Java but with a different declaration. However, an interface is again just declared as a class but this time it contains only abtract methods.
Be careful when you notice the keyword "virtual": virtual just means that this (declared and defined) method is allowed to be overwritten/substituted by a child class. However, if a virtual declaration ends with "= 0" then this method is an abtract method, or "pure virtual" in C++ terms. Have a look at XMLProcessorInterface.h and AbstractGraphicsEngine.h as an example.
Thank you kindly. I stand corrected. Yes the C++/Java terminology difference is significant. Hey, I'm learning stuff! :-)
Cheers, Mike.
____________
"I have made this letter longer than usual, because I lack the time to make it short." - Blaise Pascal
In Java everything is a class/object, but no multiple inheritance. In C++ maybe/maybe not.
Nope, in Java an interface is an interface, not a class. Java provides an explicit entity (and a keyword) while C++ doesn't.
Oliver
Be careful when you notice the keyword "virtual": virtual just means that this (declared and defined) method is allowed to be overwritten/substituted by a child class. However, if a virtual declaration ends with "= 0" then this method is an abtract method, or "pure virtual" in C++ terms. Have a look at XMLProcessorInterface.h and AbstractGraphicsEngine.h as an example.
Thank you kindly. I stand corrected. Yes the C++/Java terminology difference is significant. Hey, I'm learning stuff! :-)
Also note that in Java, all methods are virtual, and you can't change that. In C++, you get to choose.
____________
Please use "reply to this post" instead of "reply to this thread" . See Threads
Thanks guys for the corrections! That is really very, very helpful. :-) :-)
[aside]
Some textbooks, tutors, and authors really don't have sufficient precision .... they're not all saying quite the same thing. Even within a given topic/language. And OO abounds with terminology, a minefield of words. No wonder students of such languages, like myself, get confused at times. Many no doubt give up, or move along quickly from the trickier bits leaving a fuzzy patch in their understanding - perhaps thinking they do understand when they don't. Possibly later the products of their work fail, blow up or fall over in some important ways. ( Sorry for the waffling, I often teach medical students how to approach & interact with sick people. Over the years I have made a bit of a study of the idea of 'understanding'. )
[/aside]
Right. Back to screensaver development.
Cheers, Mike.
____________
"I have made this letter longer than usual, because I lack the time to make it short." - Blaise Pascal
One tiny query : in the ResourceCompiler class we have a virtual destructor. I assume this might indicate the possibility of allowing subclassing later on, in the sense of further development of the ResourceCompiler idea? And/or a good habit to get into generally?
I think, in the general case : so that you'll get the right destructor(s) on a delete call ( or if an automatic goes out of scope ). It is both common and legal to use a pointer to a derived class when a base class pointer is expected. A derived class object is also a base class object aka polymorphism. So if the base class destructor is virtual then the derived class destructor will also be called in addition to the base class destructor. That is, no potential for memory leaks happening due to not cleaning up whatever the derived class constructor may have allocated?
I don't want to totally turn this thread into a tute for Mike Hewson's C++ Boners, but have I expressed this right? :-) :-)
Cheers, Mike.
____________
"I have made this letter longer than usual, because I lack the time to make it short." - Blaise Pascal
One tiny query : in the ResourceCompiler class we have a virtual destructor. I assume this might indicate the possibility of allowing subclassing later on, in the sense of further development of the ResourceCompiler idea? And/or a good habit to get into generally?
I think, in the general case : so that you'll get the right destructor(s) on a delete call ( or if an automatic goes out of scope ). It is both common and legal to use a pointer to a derived class when a base class pointer is expected. A derived class object is also a base class object aka polymorphism. So if the base class destructor is virtual then the derived class destructor will also be called in addition to the base class destructor. That is, no potential for memory leaks happening due to not cleaning up whatever the derived class constructor may have allocated?
You are correct. If you have a class A with a virtual function foo() (and will be used in a polymorphic way), and a class B that inherits from it, and maybe adds more dynamically-allocated members, then there is a really bad problem here: http://pastebin.com/f47c0b06f
As you say, there would be a memory leak because the destructor of the derived class wouldn't be called. The solution is making the dtor virtual. That way, destructing a B via an A* pointer would call the overridden dtor ~B. (note that ~A is also called, but that's because ~B implicitly calls ~A at the end, just like B constructor implicitly calls A constructor at the beginning).
The C++ FAQ Lite (a great C++ resource, btw) says:
Here's when you need to make your destructor virtual:
* if someone will derive from your class,
* and if someone will say new Derived, where Derived is derived from your class,
* and if someone will say delete p, where the actual object's type is Derived but the pointer p's type is your class.
Confused? Here's a simplified rule of thumb that usually protects you and usually doesn't cost you anything: make your destructor virtual if your class has any virtual functions.
____________
Please use "reply to this post" instead of "reply to this thread" . See Threads
You are correct ..... if your class has any virtual functions.
Thank you kindly again! :-) The sources I had made a lot of talk of cost ( time/space ), but that's not really relevant here. Better to be correct, of course. Implementation dependent anyway ( virtual tables et al ), and it's the wrong end of the process to be optimising also. What is the speed of a wrong design? : zero, when measured along the axis of interest ..... :-)
Cheers, Mike.
____________
"I have made this letter longer than usual, because I lack the time to make it short." - Blaise Pascal
Some thoughts and excavations ( upon OpenGL® Programming Guide: The Official Guide to Learning OpenGL®, Versions 3.0 and 3.1, Seventh Edition ) if you'll suffer it. Me thinking out loud again. :-)
An example of how one might work backwards from a proposed visual feature implemented in a certain OpenGL manner, back through to what data/format you'd want presented to the Open Resource Compiler of Oliver's. That way you can hook up hard-coded data in the executable to an actual rendering function call. The rubber has to meet the road eventually. :-)
Texture time:
- broadly a texture is a mapping of a pattern/image to a geometric object/polygon. Glue a picture onto something.
- the smallest elements of the texture are called 'texels'. These ultimately are mapped to pixels via the OpenGL rendering engine.
- a key texture function in OpenGL seems to be :
void glTexImage2D(GLenum target, GLint level, GLint internalFormat,
GLsizei width, GLsizei height, GLint border,
GLenum format, GLenum type, const GLvoid *texels);
[ There is no shortage of other functions to pay attention to, like what do you do if you get to the edge of the texture but there's more polygon to go : do you repeat? etc ... ]
For what I currently have in mind ( a picture of dear Albert's face overlaid upon a filled ellipse representing the Earth's orbit ) :
target = GL_TEXTURE_2D. Believe it or not, there are 1D and 3D textures.
level = 0. Indicates only a single resolution of the texture map will be used.
internalFormat = GL_RGBA. Answers the question : which of the possible components of a texel ( RGBA, depth, luminance, or intensity ) will I be using when rendering occurs? A blizzard of options specifying how you want to use your texture. Alot regarding whether it's normalised ( to range [0,1], or range [-1,1] ) , fixed-point, floating-point ........
width & height. Apropos to the texture size.
border = 0. No border.
format = GL_RGBA. Answers the question : which of the possible components of a texel ( RGBA, depth, luminance, or intensity ) have I provided in my bit store? Again a snow storm of options, but I'm going to supply 3 colors and an alpha value ( per texel ).
type = GL_UNSIGNED_BYTE. The ResourceCompiler will ultimately lead, as discussed earlier, to access to a const vector< unsigned char >. This and format says we'll be accessing red, green, blue and alpha values ( in that consecutive order ) each as 8-bit quantities ( 0 - 255 decimal ).
texels = &yourBitStore. ( Pass the address of your bit store ). Note the const GLvoid so your store won't be altered and can contain any type of data. But a successful interpretation of this store depends on you correctly specifying it's implicit structure via the above parameters.
Clearly it's possible to provide a particular bit store and use it in different ways with different calls. In effect there is some 'cast'-ing going on. Thus the parameters internalFormat and format. In my case I'll be providing exactly what I want used, GL_RGBA, no more and no less. NB - there are important OpenGL version differences with these two parameters.
So here is the picture:
This is a 24 bit colour-depth bitmap file, but is not yet Resource Compiler ready. I have to :
- trim irrelevant stuff out like BMP File Header, Device Independent Bitmap Header, Color Palette.
- keep the height and the width.
- keep the bitmap! ( NB this has a varied offset into the file )
- add an alpha value for each pixel.
Also I want to 'clamp' the darker pixels to black ( RGB = {0,0,0} ) and/or give them an alpha of 0 ( fully transparent ). Pixels brighter than 'dark' ( threshold yet to be decided ) should be unchanged RGB wise but given some constant alpha. ( Alpha is a blending value, and there are more than a few modes of blending ).
Why? Well I want to paste Albert's features only, partially transparent over some underlying color ( of the filled ellipse ), and I don't want the dark background clearly indicating that I got it from a rectangular image. A non-zero alpha for the 'dark' pixels ( well texels now ) will give a ( fainter ) rectangle over the underlying polygon color, with Albert's face in the middle.
I'm using the fact that the picture has great contrast between his head and the background, so the final result will effectively look like a 'cut-out' around his outer hairline and lower face. I've already painted out his shoulders, suit and tie. This roughly follows how it's done for the green/blue screen technique for movie CGI. Better watch the ellipse color though - do I want his eyes purple? :-)
I'll have to experiment with different combinations of Albert in the foreground, transparency levels and some background colors. :-)
To this end I'm writing a tool to suck up a *.bmp file, do those changes as above and spit out a binary file to be specified in a *.orc file. I figure that texturing of objects in the 3D viewpoint will be quite a useful skill to manage. For instance I'd like to have an Earth which actually shows continents, or a Sun with sunspots. Time will tell .... :-)
The closer one can present the data to the engine in the form of it's ultimate use ( as efficiently as desired ) then the less runtime fiddling. No doubt OpenGL could be arm-wrestled to provide a whole chain of texture/image alteration on the fly. Rather avoid that.
Cheers, Mike.
( edit ) GLenum, GLint, GLsizei, GLvoid .... are typedefs that map/correspond to more 'basic' types on a per OpenGL implementation/library basis. These are reasonably defined. But use these rather than explicit C++ types wherever possible to retain portability. As we are effectively cross-compiling to lots of system target types with the E@H supplied screensaver graphics framework, this is quite important.
( edit ) And BMP is an older & simpler ( uncompressed ) format, likely to be readily available for conversion from some other image format into it, by even basic image software. I worked with the above image purely within M$ Paint, starting with a jpeg.
____________
"I have made this letter longer than usual, because I lack the time to make it short." - Blaise Pascal
Hi Mike,
I'd like to comment on your intended image resource handling. IMHO it's much easier to simply add your favourite images "as is" using ORC, so don't strip them down to the bare naked pixel data. The reason for this is that SDL provides methods to import a variety of image data which can then be turned into an OpenGL texture! This way you (almost) don't have to care about the individual image file formats.
The first step is to create a SDL_Surface from a Resource. You'll find an example in the framework's WindowManager::setWindowIcon() that's being called in starsphere's main().
In the second step you use the SDL_Surface you just created and turn it into an OpenGL texture. You can find one example of this procedure here.
Edit: BTW, I like your idea and I'm very curious to see a first picture of how Einstein looks like!
HTH,
Oliver
I'd like to comment on your intended image resource handling.
Comment away! Many hands make the blinkin' light work .... ;-)
IMHO it's much easier to simply add your favourite images "as is" using ORC, so don't strip them down to the bare naked pixel data.
Hmmmm ..... for some reason I've evidently acquired the idea that I have to stuff everything into the one executable with maximal efficiency. Not so. Ah, that makes life easier. :-)
I honestly can't say why that assumption snuck in! I'm solving the wrong problem. No kidding, my first programming experience ever was assembler on an 8088. The old habit of crawling on hands 'n knees. Just can't get away from the bit twiddling, shaving them bytes 'n cycles. 'Spelunker' anyone? :-)
The reason for this is that SDL provides methods to import a variety of image data which can then be turned into an OpenGL texture! This way you (almost) don't have to care about the individual image file formats.
Neat, so for my plans I'll still need a format with per pixel alpha's. Can do ( reaches for PhotoShop ..... ) and I can set the eyeball/pupils to no-blend. I think I'd focussed on the bit about OpenGL per se not loading image files, but if SDL_Image is written to do so then one can easily go that route.
The first step is to create a SDL_Surface from a Resource. You'll find an example in the framework's WindowManager::setWindowIcon() that's being called in starsphere's main().
In the second step you use the SDL_Surface you just created and turn it into an OpenGL texture. You can find one example of this procedure here.
Thank you so much for taking the time ! And thanks for those links. :-)
Edit: BTW, I like your idea and I'm very curious to see a first picture of how Einstein looks like!
Well, I originally thought of using the photo where he pokes his tongue out. But I thought I'd stay more conservative for a first attempt. :-)
Since I seem to be doing a spot of trailblazing here, I'll keep the commentary up. Might be useful to others, and ought be entertaining for y'all to watch. :-)
[ Certainly helps me. ]
Cheers, Mike.
( edit ) Here's an interesting challenge. Easy to shade the Earth, right? Just specify a light source at .... the Sun! Get a nice shadow effect on the dark side. Be nice to have a 3D effect for the Sun though, so it doesn't just look like a flat circle. Texture helps, yes. However it would look a tad odd having a light source off the ecliptic and causing the Sun to cast a shadow on the orbit ellipse! Not to mention the Earth having two shadows from two sources. Maybe wrap a texture around the sphere object that will be the Sun, then apply 'limb darkening'. This is a real astronomical effect where the outer area of the Sun's disc appears darker than the middle of the face. Depth of photosphere etc. Try a mask of sorts b/w the Sun and the viewpoint/camera? Needs work ....
____________
"I have made this letter longer than usual, because I lack the time to make it short." - Blaise Pascal
Here's my first try at massaging the framework ( sorry, only a Linux executable today ) :
- no constellations drawn
- supernovae and pulsars have some transparency
- a new list drawn up of some 250 stars with their visual magnitudes and spectral type employed, such that brighter stars are rendered larger and in the rough color of their spectral class.
To do / wish list :
- expand the diameter of starsphere dramatically
- start rendering a solar system at the centre
- default viewing position nearby the solar system
- default 'lazy orbit' / 'tour' when unattended
- 'fly-by-wire' using keypad ( speed, pitch and roll ), with some basic kinematic model
- switching of graphics complexity ( low/medium/high )
A key efficiency is using openGL display lists ( create once, use many times ).
Cheers, Mike
____________
"I have made this letter longer than usual, because I lack the time to make it short." - Blaise Pascal
Here's my first try at massaging the framework ( sorry, only a Linux executable today )
You are using Einstein screensaver framework code as a base, which is GPL. So if you release an executable, you have to release the corresponding code.
____________
Please use "reply to this post" instead of "reply to this thread" . See Threads
Here's my first try at massaging the framework ( sorry, only a Linux executable today )
You are using Einstein screensaver framework code as a base, which is GPL. So if you release an executable, you have to release the corresponding code.
Whoops .. thanks for that. :-)
Here it is. Very much a work in progress, lacks full commenting etc. However some main points are:
- you have to fiddle with the build script alot. Slot in yourprojectname for starsphere where mentioned mutatis mutandis. Here is the build script that I use, BUT as I've had to massage it for my Linux system, it's very specific.
- you need to fiddle with the makefiles alot ( I now see Oliver's earlier point about automake et al .... ). Only the Linux makefile is valid, yet.
- my SolarSystem class directly derives from AbstractGraphicsEngine ( so no starsphere and subsequent variants ), thus trimmed the relevant files and other entries. Mind you, I've pinched the Starsphere interface/code and re-named to suit, but deleted some aspects ( additional observatories, constellations ).
- you have to fiddle with the GraphicsEngineFactory class. Insert an enumeration constant for your variant and have the code able to select that.
- a small change to main.cpp too.
- the underlying Starmap data structure is a fudge/kludge around the fact that you can't have array style initialisation of the std::vector class ( which I'd prefer to use ). Otherwise you'd have to load the vector from an array ( do-able, but it double handles stuff ), or not bother encapsulating at all ( retaining the original C style array and extern ).
Cheers, Mike.
( edit ) Here is the source of the star data from which I derived the Starmap entries. I included in the Starmap class, but have not yet utilised, the star names.
( edit ) Might extract some commonalities and make Starmap a base class ......
____________
"I have made this letter longer than usual, because I lack the time to make it short." - Blaise Pascal