StarShipView BackSpace Module (For NeXTstep 3.0 or higher) 1. Compiling: I wanted a module that could be completely built with PB. Double click the PB.project file. In Project Builder, simply do a build with install in the Args field for NextStep 3.0. If you are compiling under 3.1, select install from the target pull down menu and choose the appropriate cpu type from the options button. It should install the StarShipView.BackModule in the ~/Library/BackSpaceViews in your home directory.If you want to include the Warp1 module, drag and drop the Warp1.bproj subproject onto the subprojects suitcase in ProjectBuilder and then do the compile. Important Notes: I am submitting a 3.0 and a 3.1 fat binary version. They need to be run with the compatible version of BackSpace. I have been told that doing the build install will not do the right things under 3.2 so when I know what the changes are, I will update. 2 Internals: StarShip tries to simulate going through space in a starship. I had a idea to design a backspace module that would set up an environment that others could write modules for and that would be loaded in dynamically at run time. I include two separate modules called Celestial and Warp1. Celestial is really the main module and Warp1 was a quick module to show how other modules can be loaded and unloaded. I include Warp1 in the sources but I don't include it in the project. StarShipView really doesn't unload modules. At start time it builds a list of all the bundle objects that are in the StarShipView.BackModule folder(bundle). It instantiates all the classes that it finds up front. I do provide a message to the freeResources method that is to be used to get rid of memory gobblers like tiff images and sounds that are just used for your module. There is a StarShipProtocol.h that includes the methods that must be implemented. I really should test the modules to see if they conform to the protocol but I haven't added that yet. The other "should be there", is to have a separate button on the inspector panel that fires up a separate info panel from the different modules. That way when your module is active the user could get specific info about your module. I do however provide a way to see on the inspector what module is currently running. If anyone could tell me the easy way to do this with a nib file, please let me know. I couldn't figure out how to free a loaded nib when the next module is being loaded. The other way I thought of was to build the scrollView from scratch. I didn't like that either. Another thing I thought of was that the slider labels in the inspector should be dynamic. That way each module could label the sliders any way they wanted. The Module that you write will be sent the outlet for the stars so that your module has control over starting and stopping them. You even have control over turning them off altogether. See the HideStars method in NewSpaceView. The border around the viewscreen actually moves 9 pixels back and forth to prevent screen burn in. I have defined variables to allow you to custom tailor the program. I've included them here. NewSpaceView.m SCREENMOVE 1000 how often the screen border resizes LIGHTMOVE 10 how often the lights below the viewscreen move Celestial.m MAXMULTBODY 10 maximum mutiple objects - randomly generated up to TiffManager.m MAXIMAGESIZE 150 maximum size the scaled images will be SIZEINC 2 each animation frame is incremented by this amount in pixels - starting at 1 pixel The smaller, the more images are built into memory but also the smoother the animation CelestialCommon.h MAXANIMATIONS 4 maximum number of animations to be built for each cycle - on larger memory machines you can up this 3: The Celestial Module When the Celestial module is activated it starts building tiff images in memory(tiffManager object) and adds them to a list that is put in a storage object. The Celestial object acts as the controller and then takes the info in the storage object and creates and frees body objects as they fly through space. To do mutiple objects, it just creates more of them. The tricky part is for each body to set an avoidance rectangle in a storage object. That storage object is passed off to the stars object(NewSpaceView) who avoids drawing or erasing any stars there. 4: The Warp1 Module I wrote this module very quickly without too much thought as to how good it looked. It really only serves as a second module to demonstrate how the modules can be switched between. 5: Thoughts I strip out all alpha from the tiff images coming in. This makes everything go faster. It's ok to have alpha in your own tiff images cause I composite to a black background. I did discover a way to have the starShipView get running faster but it involved generating the animations to a single tiff image ahead of time. Since I use lists of tiff images and don't internally build a single tiff image (which could be done), it would have taken a bit more work to build that functionality into it. Also I didn't like the fact you would have all these huge files sitting around just to launch faster. Currently they would range from .5 meg to 1.2 meg each depending the the scheme to put all the images into one tiff image. Besides, the idea of a screen saver isn't really to sit and watch it, or is it? Anyways, I do hope someone will write some others to go along with these. If you have any questions, feel free to contact me. Enjoy! R.S. Brown rsbrown@nosc.mil
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Netfuture.ch.
