|
Pages: [1]
|
 |
|
Author
|
Topic: A Long-Expected *Party* - The Road to 0.4, #4 (Read 3382 times)
|
Michael Martin
Core Team
*Smell* controller
 Offline
Posts: 387
|
This is the fourth post in "The Road to 0.4," which tracks the progression of the UQM project rather more informally than the ChangeLog does.
Previous posts: 1 2 3
It's been over two months since Update #3, and there really isn't a huge amount to report; university, employment, and other factors have claimed much of the time of the developers and core team. However, many things have happened. Thanks to the pretty wide distribution of UQM 0.3, we've had pretty broad distribution and a lot of testing from the community; almost 60 bugs were added or modified in the Bugzilla database during this time.
We haven't been totally idle, either. Here are the major changes that have actually been committed to CVS:
- Meep-Eep continues to work on the resourse and file i/o systems, and has committed some improvements and made notes for additional repairs once he gets time to develop again.
- If you're in a menu and press a meaningless direction, you'll still get menu noises in 0.3. I went and reworked how menu sounds work and there's much finer control now. Most of the menus do nothing if you press meaningless keys. (There are some places left where it still makes the wrong noises, though; the task is not yet done.)
- Mika has recently started optimizing the sound code a bit more to make it work better on Macs, and has put in workarounds so that it won't try to use external libraries in ways that don't work.
- Our tireless co-developers have provided a number of improvements to the graphics and animation, including fixes for planetary fuel displays, shipyard bay door animations, a more attractive slave shield, and an addon pack that lets you switch between PC and 3DO versions of the Vindicator's engine color.
Also worthy of note is that we've been handling threads incorrectly. We still do (see this Technical Issues thread for the gory details) but the core team has been discussing the matter and we have most of a roadmap to the elimination of this. The bug reporter who clued us in on how to trigger it, Jeff Cook, also provided a workaround. The core team has decided on a short-term fix, and we've also concluded that one of our goals should be the total elimination of multithreading from UQM. If this is not feasible, moving all graphical operations into a single thread will be the goal. Making our use of threads pthreads-compliant will definitely be in 0.4; the degree of dethreading therein is still up for grabs.
If we do manage to produce a thread-free version of UQM, then an OS 9 port becomes a possibility. I won't be making any guarantees here, though, because, first, none of us have access to OS 9, which makes making releases difficult, and second, any machine old enough to be running OS 9 probably has a pretty old video card, too. I have the, er, singular privilege to be typing this post on a Pentium 120 with a Riva 128 video card, and it will not run UQM properly - it seems to mishandle the drawing of transparent sprites. (It's also extremely slow, of course, but even without that, the screen is just wrong...) So an OS 9 port might stay forever in the "well, that would be cute, but..." pile.
If you don't really follow all the threads here, Mark Vera has reported that work continues apace on the final remix packs, and that there is not a great deal of work remaining.
And that's where we are at the moment. If I missed anything, feel free to chime in.
Until next time, I remain,
Michael Martin
|
|
|
|
|
Logged
|
|
|
|
|
|
guesst
Enlightened
Offline
Gender: 
Posts: 692
Ancient Shofixti Warrior
|
Alot of dev time seems to be spent on making UQM universally compilable for minority systems. Not to knock people who are still using an Apple IIe, but don't you think if you focued on making a fully playable version for, say, a relatively high end windows machine, which alot of people have, that the majority of people would be satisfied? Then start working on full compiles for Commodore 128s and the like.
Just my exagerated 2 cents.
|
|
|
|
|
Logged
|
|
|
|
Nic.
Guest
|
As someone who only plays UQM on said "minority systems", I take exception with this sentiment. 
There are practical reasons for wanting the game to be as portable as possible, the most notable being "resumé food". Saying "I can write code for platforms x, y and z", (and having a working example available for download) is much more useful when seeking employment than "I can write code for windows," at least at the types of places I have worked.
But I'll not presume to speak for coredev, and it is entirely possible that the reasons behind it are academic rather than pragmatic. That is fine, too, as I have a working version of the game for my Mac. 
|
|
|
|
|
Logged
|
|
|
|
meep-eep
Forum Admin
Enlightened
Offline
Posts: 2847
|
For me "resume food" has never been a reason for portability.
If you remember in the beginning of the project, Chris asked the public what we wanted, and he came back with a list of platforms uqm would be going to work on. I suspect the list was as it was because those were the platforms that SDL supports.
After the current core team took over, we found out that getting this to work on MacOS 9 would be a lot of work, as MacOS 9 isn't thread-safe at all, and since it was only a minor platform, we decided to drop it.
But now we're restructuring the code, and there might come a time when we have only one thread. If we ever get there, MacOS 9 support might not be so far away anymore.
All in all, the time spent on making this code work on multiple platforms is relatively small. Most is just a matter of writing what you write in a portable way, not making special cases for different platforms.
If you look at the code, you'll see only little platform-dependant code.
We're mostly just writing code for one platform, namely SDL.
You see people making posts about uqm on the GBA or the Dreamcast or the playstation, etc, but these usually are written by people who'd want to see them, not by people who are writing code for it.
|
|
|
|
|
Logged
|
“When Juffo-Wup is complete
when at last there is no Void, no Non
when the Creators return
then we can finally rest.”
|
|
|
Michael Martin
Core Team
*Smell* controller
Offline
Posts: 387
|
Well, SDL supports Linux-on-a-PS2 directly. I haven't heard of anyone trying it, but it ought to work "out of the box" as well as any other Linux version.
|
|
|
|
|
Logged
|
|
|
|
|
|
Nic.
Guest
|
As problem reports go, that one needs a bit of work, sir.
The add-on pack mentioned makes it so that the ship has a red engine in the outfit and starbase commander screens (where it is otherwise coloured green, much thanks to Paxtez for the artwork).
I tested it after I put it together, and I tested it again just now. It still does what it is supposed to do. Is this a matter of the add-on not doing what you expect, or is this an issue with getting add-on packs to work at all?
Marginally Off-Topic: Can anyone in coredev speak to whether or not any of the add-on packs will be "blessed" and added to the official distribution of the game?
|
|
|
|
« Last Edit: January 04, 2004, 08:17:43 pm by Nic. »
|
Logged
|
|
|
|
|
|
|
Pages: [1]
|
|
|
|
|
Deep Jiffa Owns j00!