Oolite Bulletins

If you do start looking into getting away from AppKit/GNUStep's GUI layer, I'd reccomend looking at http://thor.acedragon.co.uk/viewcvs/branches/hid/ , where I've already started on splitting off input event management into a separate class, InputController, and a category PlayerEntity(FlightControls).

If built with -DUSE_BASIC_INPUT_CONTROLLER, the project will use MyOpenGLView's input events. If built without, it'll use my under-development SCInputManager framework (part of that branch). Unfortunately, the SCInputManager code that's there is out-of-date, and the up-to-date code is on a machine which is now horribly broken. :-/

Anyway, the point is that if you do start refactoring the event handling and such, it'd be silly for us to be working at cross-purposes.

How platform-agnostic is the new input controller going to be?

The InputController class essentially abstracts the existing input code; instead of PlayerEntity asking MyOpenGLView whether the T key is down and then checking a flag to see if it was down the last frame, it asks the InputController whether it should target a missile. The "basic" input controller then checks its own flag and asks MyOpenGLView in the same way PlayerEntity does now; as such, no new dependencies are added.

The "new" input controller exports exactly the same interface as the "basic" input controller, but checks controllers through the SCInputManager framework. This in turn provides abstractions for multiple input devices based on Foundation Kit objects.

The input devices themselves are implemented as subclasses of SCInputDevice and SCInputDeviceElement; these subclasses are platform-specific. Porting the generic keyboard and mouse devices to other platforms on top of GNUStep would probably be easy; they use three Carbon functions, GetKeys(), GetMouse() and Button. The third set of device classes are for general HID device support, and use a lot of platform-specific code (talking to the IOKit). These classes can't be considered portable, but writing new classes (based on SDL, DirectInput or whatever is appropriate for joystick support under Linux) shouldn't be too hard. However, since the structure of SCInputManager is in a state of flux this isn't worth trying now.

Additionally, there is an SCInputConfiguration framework which provides a set-up interface in the form of an NSView. This is implemented entirely in terms of AppKit and SCInputManager, and would probably be easy to port. The interface is based on loadable panels; intention is that classes of device (mouse, joystick, analogue gamepad) and individual device types will have their own panes. These won't need to work very intimately with the input device classes; the idea is that they'll be based entirely on the public interface of SCInputManager. Again, though, flux is happening. Especially if I have to redo the last couple of weeks' work due to computer buggering itself. :-(

Well, I hope you recover your data!

It sounds like that'll probably be the best way to do it - provide an SDL backend for your input controller.

The end result is I only want a dependency on the GNUstep base and try and lose the dependencies on GNUstep AppKit. As far as I can tell, Base is in really good shape, but there's an awful lot of unimplemented stuff in GNUstep AppKit. SDL runs on Win32 as well as Linux (and provides abstractions fro things like sound and entering full-screen mode) so I think it's probably best in the long term to move the non-Mac versions to using SDL to do the actual work.

Of course I have to learn about OpenGL and SDL etc. I am working my way through the OpenGL red book at thte moment, and trying to learn all the maths I should have learned years ago (but failed to pay any attention to)... (the latter part probably isn't that important to just porting Oolite, but I do want to tinker with it too)

This all sounds like a good idea, in terms of portability.

The nice thing about OpenGL is that all the glXXX() functions will work just fine in SDL, it is only the location of the code that sets up OpenGL context that will change (probably not the code itself).

I think the input side of NSXXXView is the more important and difficult part to replace and this is already being looked at.

The other reason to get rid of GNUstep's AppKit is it wants to start a couple of daemons (as root). That's no big deal if your desktop is GNUstep, but hardly anyone is - everyone runs Gnome or KDE. It's just too much of a nasty dependency to have to start two daemons as root just for one game. And as we've been discovering, there's a lot of things we want that just aren't implemented in GNUstep AppKit.

I think once the music is running in oolite-linux and we've got a bit of test time on it, it can be called 'production' with the caveat that once the new input support is in there will be another upheaval as AppKit gets replaced by SDL. At least the game runs at the moment even if there are dependencies we don't like.

Mine seems to get by without running them as root:

[ian@localhost ~]$ ps -AF x|grep gdomap
ian 6802 1 0 809 832 0 19:09 ? Ss 0:00 /home/ian/GNUstep/System/Tools/gdomap
ian 6840 6768 0 930 640 0 19:10 pts/2 R+ 0:00 grep gdomap
[ian@localhost ~]$ ps -AF x|grep gdnc
ian 6804 1 0 2087 3844 0 19:09 pts/1 S 0:00 /home/ian/GNUstep/System/Tools/gdnc --daemon
ian 6842 6768 0 930 648 0 19:10 pts/2 R+ 0:00 grep gdnc

Don't know what the difference is between my machine and everyone else's. GNUstep installed in my home directory using gnustep-startup-0.10.2.tar.gz. Fedora Core 3.
I suspect it's not relevant, but I haven't added . /home/ian/GNUStep/System/Library/Makefiles/GNUStep.sh to my profile, instead I've put it in ~/GNUStart.sh and do . ~/GNUStart.sh whenever I want to use Oolite.

I'm all for SDL though.

Mine also start when running as user, even though I've installed GNUstep as root.
Also, I'm running them on demand only, using a simple script: If it does matter, I'm on gentoo Linux, gcc-3.4.4 and using the latest GNUstep (gnustep-startup-0.11.1) from:
http://www.gnustep.org/
My machine is an Athlon-tbird 1Ghz, 512Mb, GeForce2 Gts 64Mb, nvidia drivers 1.0.7174
I know, meanwhile there are newer drivers available, but they don't support my card anymore.

Just a warning to gentoo users: Don't waste your time with the GNUstep ebuilds (from gnustep-env).
This version is way too outdated and also a pain to install: it even wants to install an older version
of gcc, as an dependancy. But the ebuild is still useful, as it probably will show you what other
programms are missing yet. I don't know whether the install script from the original sources
(InstallGNUstep) is able to find all missing stuff on your system (though it should).
If you're unlucky (as I was), you have to recompile gcc with objc and (IIRC) gcj support (via use-flags).

A last question (for now): what are gdnc/gpbs/gdomap good for?

They're not good for anything, for our purposes. One of them is the sound daemon which we don't use, one is the inter-app pasteboard for copy/paste operations, and one is the IPC switchboard so GNUstep apps can communicate with each other.

But now I'm really confused!
When you look at my little script above, in my first days with Oolite it had to be like this:
starting oolite with proceeding 'openapp' and running demons gdnc and gpbs, otherwise I got related
error messages. But suddenly I don't need that anymore! I can directly start the binary like this and that's it! I also double checked that the demons aren't running with e.g. So, has this behavior changed in the latest svn tree (which I'm using since 02.07.05)?
Also, and that's actually no complain, I never had any crash with Oolite since I started with
the official sources (I also played the binary for a short time) on 30.06.2005.
That means I'm playing for almost a full week now with several versions and several hours a day!
It's really strange you still (?) get crashes while it runs so perfectly here...

Oolite doesn't need them anymore because we're reducing its dependency on GNUstep AppKit.

We use SDL for sound so the sound daemon doesn't need to be running, and hopefully the changes being made to get Oolite to be a "tool" rather than an "application" (a ridiculous distinction) mean the others might not be needed anymore either.

GNUstep is a necessary evil, but we're reducing its awful influence as much as possible.

As for being surprised it runs better for you... don't be. This is GNU/Linux we're talking about. I get weird graphic glitches that no-one else gets (I even thought it was a feature of the scanner I didn't understand at first!)... at the beginning Winston could run my code but not his own... font weirdness... the list goes on. The number of variables from one system to another is countless, and all seemingly important.

I think the Win32 version is going to be a LOT more consistent, once the current bugs are nailed.

I still use a similar script which I found to be nessesery, for saving my commander

I see you're using the svn code, too.
Did you ever try to just start the binary (w/o 'openapp' and the demons)? Works perfectly here.
In any case, you don't have to start gdomap explicitely: it's loaded by one of the demons gdnc or gpbs.
Killing it afterwards is still a good idea (probably). Just look whether it's still in memory after killing the demons.

I did try the binary but it came up with errors impling textures(or something) were missing from some ship I can't remember which one. I feel more comfortable with missing mac libs. I added ./gdomap as I had real problems saving a commander its now better(I can save without changing directories or commander name) and wasn't sure which dependency got it working.

It does crash far too often esp if I browse the net while playing. Although you can't argue with any game working on Intel extreme 2(Onboard rubbish)

I think I can help with the texture problem, look here:
https://bb.oolite.space/viewtopic.php?t=794
But if that's actually your problem, you hardly can have the latest svn code, cause meanwhile it's fixed there.

Btw, I'm not sure whether your line
'svn checkout svn://svn.berlios.de/oolite-linux/trunk' is correct.
I'm just using 'svn checkout svn://svn.berlios.de/oolite-linux'
(w/o the ending /trunk).