Oolite Bulletins

Now it's been a long time since I did any real programming but back in the 8 bit days I used to poll the keyboard with interrupts rather than between frames, so the keyboard could be read regardless of other actions taking place.

Does the development platform allow for this? It would make fine movement easier when the frame rate starts to lag for whatever reason.

I believe ages ago , when Ahruman started posting here he said that was the first thing he'd want to change in Oolite, but it never happened, so I guess it is not at all straightforward...

That might be okay if the game ran on a single architecture.

Even then it probably wouldn't fly these days, because the OS wouldn't approve. The 8-bits didn't really have an OS or any hardware abstraction to get in the way..

Heh. My input manager got bogged down because I started on an ambitious project to do it all, so to speak. Moving keyboard polling into a thread should be relatively simple, though. I’ll take a look.

Threading in the Win32 port isn't too hot. I've tried using the SDL threads and it didn't work.

This is probably just a matter of working out what is wrong rather than being impossible, but I'd argue the current polling isn't broken and there are many things to add/improve rather than make lots of work to go nowhere.

Threading is easy enough. Just make an OOThread class that uses POSIX threads for Mac/Linux/Unix, and Win32 threads in Windows. From having written multithreaded stuff for both Unix and Windows, it's pretty easy.

What isn't easy though is the new class of bugs you get when your program goes multithreaded

I've done plenty of multi-threaded programming too (including writing my own embedded multitasking exec for an embedded micro), so I'm not concerned about the technicalities of it.

I think it is a waste of effort in the case of Oolite. Effort that could be spent on many more useful things.

I also don't feel like having to munge Win32 programming in with the GNUstep/Obj-C style of code we have at present. I know that is what MinGW is all about, but why make life harder than it has to be?

And I knew I'd read something about SDL events and threads... from the SDL doc wiki:

(SDL 1.2.9) On win32 (this wasn't observed on unix), the initial thread must be the one polling the SDL events. Otherwise, keyboard events are no longer catched. Moreover, it is recommended to use SDL_mixer and SDL blitting functions from within that initial thread as well, otherwise the system becomes unstable (also only under win32) despite the proper use of mutexes and conditional variables. This unfortunately limits a lot the usefulness of threads when the software is also expected to run on win32.

Please don't break the Win32 port for no good reason!

Is there no NSThread in GNUStep?

If I do separate the key polling into a thread, it’ll have to be implemented separately for OS X and SDL anyway. Keeping the non-threaded method around for Win32 shouldn’t be a problem.

There may well be, but it probably doesn't work on Windows.

You know, like the entire OpenGL functionality is nothing but empty functions (which is why we went SDL to being with)? Like the GUI stuff doesn't work? Like pretty much anything other than NSString, NSNumber, NSDictionary, and NSArray are completely borked? Like it can't do XML plists?

Pick ANYTHING. It probably doesn't work on GNUstep for Windows. At least not the way it should or the way we need it to!

On further consideration, the way Oolite uses keyboard input is such that threaded polling won’t accomplish much without a significant rewrite.

Now it's been a long time since I did any real programming but back in the 8 bit days I used to poll the keyboard with interrupts rather than between frames, so the keyboard could be read regardless of other actions taking place.

To check for key presses, you just have to issue an OSBYTE call to the 6502 assembler...

Now for the tricky part: porting Oolite to the BBC Micro!

dajt wrote:

Like it can't do XML plists?

I thought GNUstep Base on Win32 could do that now - or am I mistaken?

Only in my build - the standard GNUstep distro still can't do it. The problem is that only very recent versions of libxml2 can be compiled under mingw, and I don't think GNUstep for Windows is very actively maintained so this hasn't been incorporated yet.

I'm not holding my breath, and I don't like GNUstep enough to want to get involved in the project. I think they're aware it's possible so it might turn up sometime this year.

Whether it can or not, my point in this thread remains: why expend effort, make the code more complicated and break the build of the most downloaded but least maintained platform (meaing who knows when it will get fixed), for no discernable gain? It just doesn't make sense.

Yes, we're all hairy chested multithreaded programmers here who think nothing of doing a little assembler and some ISRs, but life's too short.

dajt wrote:

Yes, we're all hairy chested multithreaded programmers here who think nothing of doing a little assembler and some ISRs, but life's too short.

Hairy chested - well yes

Multithreaded - that's her indoors

Assembler - only after I've been to Ikea

ISR - Internal Service Request - YeeHaaaaa

http://acronyms.thefreedictionary.com/ISR

Well, at least it wasn't the IRS. :^)