Nevertheless a textureless version (and with a bitmapped console, i know i'm just being overly retro) would be a fine option...
Actually, a texture-light version is possible to implement:
If there is a real demand for it, I suppose I could implement this, but it would be several days work in an area I'm not enthusiastic about. What do other people think?
Definitely no, us old Eliters have yearned for better graphics, it would be a retrograde step to go backwards............forward onward and upwords is the route to take.
I doubt if a new graphics card for low end users would cost very much and anyway technology is improving all the time, just tell em to upgrade!!
Your valuable time would be much better spent on other things in your Todo list.
The Grey Haired Commander has spoken!
OK so I'm a PC user - "you know whats scary? Out of billions of sperm I was the fastest"
collision detection in particular. Unlike classic Elite implementations, Oolite runs a fully-detailed simulation of everything going on in the system, which can easily result in hundreds of objects being tracked, with tens of thousands of possible collisions to check; I doubt classic Elite often got above ten, with a hundred potential collisions.
Classic Elite only detected collisions between the player and other objects - so really only a handful of potential collisions (I think the most objects that could exist simultaneously was something like 14, and as soon as an object was outside of scanner range it ceased to exist). Non player ships could pass through each other with impunity. Non player ships could also shoot through each other (this is of course really referring to 8-bit Elite, I know ArcElite had much more collision detection and much more advanced AI than all the other classic Elites, I don't know about things like Amiga Elite).
The maximum number of objects in classic Elite was also extremely limited. This is why most Thargoid battles happened in witch space - three fewer objects meant three more Thargons could fly.
Oolite's collision detection can probably be made more efficient, the algorithm is I think O(n^2), but don't ask me how to make it O(n) because I've not got the faintest idea (and in any case, I think Giles is working on reducing the collision detection overhead). I did Systems Analysis, not computer science
When Fedora Core 5 is out, I'm also going to see what (if any) difference using fast-objc-dispatch makes on Oolite-Linux (apparently, the GNUstep Objective-C runtime isn't the most efficient in the world, and fast-objc-dispatch will probably help older hardware).
According to gmemusage and top the 190M is pretty much all for Oolite, with a small shared componant. I guess the architectural differences are greater than I thought.
Possibly because your IRIX system for the main uses IRIX shared libraries, and GNUstep is the only thing using glibc et al. On GNU/Linux, the stack is GNU so everything propping up GNUstep is also propping up the rest of the system too and so is shared.
Well, surely the most interesting thing about Oolite is its expandability. The fact that this is achieved through a scripting system is without doubt a pro.
But i've lways linked Elite (talking about the original) to some hardware hack value. 3D on a 2mhz 6502 or on a z80 was a breakthrough achievement. So i have a sort of compultion to keep it simple. On the other hand i try out all the OXPs i find, so this seems to be a little controversial.
Probably the fault is more MacOSX's than oolite's, today's OS seem to eat ram by the cartload.
Oolite's collision detection can probably be made more efficient, the algorithm is I think O(n^2), but don't ask me how to make it O(n) because I've not got the faintest idea (and in any case, I think Giles is working on reducing the collision detection overhead). I did Systems Analysis, not computer science :-)
We just had a nice thread on that. :-)
winston wrote:
When Fedora Core 5 is out, I'm also going to see what (if any) difference using fast-objc-dispatch makes on Oolite-Linux (apparently, the GNUstep Objective-C runtime isn't the most efficient in the world, and fast-objc-dispatch will probably help older hardware).
Giles and I went through collision detection reducing method calls a while back, but depending on the library call overhead of the ABI fast-objc-dispatch might shave off a few percent. It’s off in Oolite-mac for pre-Tiger support.
I'm getting quite good at pitched battles @ 7-9FPS, (aka slideshowfighting, heh) but still...
That's not a performance bottleneck, that's a feature! Following on from Max Payne and the various matrix games/ripoffs, comes Oolite... now with bullet-time!
Now that's funny. Originally I had written bullet-time battles, but changed that, because I don't like The Matrix much.
(Edit: though I liked the Matrix XP, esp. The end of the movie... )
i'd like to post a follow up on my minimal system, i'm still stuck w/ ibookg3 128 mb 10.3.9 and 1.62. I've scaled colour depth down to 16 bit and the game runs much smoother, it doesn't hang anymore (i even staged a major battle with 14 laser kills with no problem. Then a pirate cove spawned a couple of offenders that chased me straight away, the game stumbled and i'm back in with no sound and no docking computers. the only thing missing are those two, but why? what's the relationship?