Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
I'm starting this thread as simply a log of Antares releases. There's a release to go with it.
Antares 0.1.1 has just been released. You can download it from Antares' Google Code page. This release resolves the following issues:
Good progress. There seem to be some issues with the results display though. The par time is missing the colon and the bottom right corner doesn't fill in with the background color. And it disappears automatically after only a few seconds. It should remain until the player clicks or presses a key.
Also, I had a crash trying to start chapter 17. It may have been caused by extraneous text in the prefs file, put there by a previous version or my editing it manually. I fixed the prefs and it hasn't happened again.
Edit: Removed crash report which was messing up page width.
This post has been edited by NMS : 07 December 2009 - 04:49 PM
QUOTE (NMS @ Dec 7 2009, 01:27 AM) <{POST_SNAPBACK}>
Aha, it appears to be that I lack some code intended to support the printing of "N/A" for tutorials too. That code path is effectively unreachable, since the debriefing doesn't display after a tutorial. The auto-disappear behavior I implemented intentionally,} but I can see now that I was misguided (there is some code to support it, but it was also unreachable). And the problem with the bottom right corner I knew about, just wasn't that concerned. I have in mind a trivial fix for it now.
Filed as issues 24, 25, and 26.
QUOTE
Also, I had a crash trying to start chapter 17. It may have been caused by extraneous text in the prefs file, put there by a previous version or my editing it manually. I fixed the prefs and it hasn't happened again. ...
You're sure you didn't mean chapter 16? There's a slight problem with the Audemedon and Human portraits, the former of which displays in the prologue to Hornet's Nest. I've filed it as Issue 27.
Ah. I guess it was 16. Now I'm not sure how I got past that level. Maybe before I got to it I edited the prefs, so I didn't notice the problem.
Antares 0.2.0 has just been released. You can download it from Antares' Google Code page. This release resolves the following issues:
The full-screen graphics code is almost entirely rewritten, and I don't know if it currently performs at the same level. I'm interested to know if the game remains playable on older machines (e.g. ppc boxes on 10.4). In addition, at least two bugs are known to have been introduced or exposed in this release:
I tested it on a MacBook running Leopard and an eMac G4 and iMac G5 running Tiger. It works on all 3, but performance was considerably worse than the previous release. Frame rate was low and inconsistent on all 3 systems.
Also, there are some issues with monitor resizing. When launched while in 640x480 resolution, it works properly, but in most other resolutions the quality is reduced, as though it has been rescaled-
Wait! Are you just scaling the game's output to the monitor's current resolution instead of changing the resolution? That's a terrible idea and would explain the poor performance and the quality loss, as well as the way it stretches to fill a widescreen monitor unless I switch to an unstretched 4:3 resolution before launching.
Ares runs at 640x480, 800x600, or 1024x768. For larger resolutions, it uses the 1024x768 output, centered on a black screen. Is there a problem with the code that prevents you from making Antares work the same way? An even better solution would be to allow the user to pick one of these resolutions (perhaps with a startup dialog that would have the option of remembering your choice), but I don't know how difficult it is to add that kind of code.
A couple minor notes:
I figured out how to reproduce the key sticking issue (which is fixed in 0.2.0): Press and hold one or more maneuvering keys (keypad 4, 5, 6, and/or 8), press and hold command, then release the first key(s). The game will continue to act as though they are pressed until you release command, then press and release the stuck key(s).
On pre-Intel systems, the ammunition counters are very dark, almost invisible against the black. This isn't a new issue, but I just noticed it.
QUOTE (NMS @ Mar 8 2010, 09:00 PM) <{POST_SNAPBACK}>
Yes, it's what I'm doing (because it was the quickest thing to get off the ground). However, I don't think that explains the performance loss itself–I'm still pushing a 640x480 image to hardware, and the rescaling is happening there.
There are internal architectural changes that are complete as of 0.2 that should permit me to start actually improving the graphics engine beyond the current state (which is essentially a series of hacks that somewhat resemble the old QuickDraw API). The 0.3 release is going to be mostly focused on sound, but I think it should not be long before I can really start improving performance (which is, I think, gated almost entirely on the graphics).
That's basically my intended resolution of issue 19. It's not going to happen soon, though, especially since I think the game could barely run at a higher resolution at the moment.
Yeah, I just noticed it myself but forgot to file a bug against it. It's filed now as issue 32.
Congratulations on your latest release!
Well, whether it affects performance or not, the scaling looks bad. Until you improve the graphics code and implement resolution selection, could you just force the monitor to 640x480 on launch?
Anyway, I'm glad to hear you're making progress behind the scenes and it's nice to have all the keys work properly. I look forward to doomtroopers not failing to unite.
QUOTE (NMS @ Mar 8 2010, 11:19 PM) <{POST_SNAPBACK}>
You mean stretching, not scaling, right? Switching the monitor to 640x480 would still cause the graphics to get scaled up, but would replace the stretching with black bars. It would also be blurry instead of blocky; I kind of prefer the pixelated aesthetic
I would prefer black bars to stretching, but that's not what I was talking about. Currently, the way it looks when I run it in higher resolutions is blurrier and more distorted than the way it looks when I switch to 640x480 first. Maybe this depends on your monitor or graphics card? I'll attach screenshots. To compare them at full screen, put them both in the Preview sidebar, start a slide show and click "Fit to Screen".
Admittedly, 800x600 is a particularly bad resolution. At the monitor's native resolution, it looks almost as good as at 640x480 (despite being stretched). But that's my point: how it looks depends on which resolution you choose, whereas if you switch the monitor to 640x480, it will look as good as it's possible for your monitor to make an image of that size look in fullscreen.
This post has been edited by NMS : 09 March 2010 - 12:22 AM
Antares 0.2.1 has just been released. You can download it from Antares' Google Code page. This release resolves the following issues:
This is a bug-fix release, fixing problems introduced or identified in 0.2.0. No bugs are currently known to have been introduced by this release. Also, the game is scaled up more smoothly, adding black bars.
This post has been edited by Pallas Athene : 31 March 2010 - 10:02 PM
Nice work with the graphics, the aspect ratio and scaling distortion issues are fixed. Performance feels slightly better too, though still worse than 0.1.1.
There don't seem to be any new issues, but I did notice a couple more old ones:
- Movies don't play.
- Results display after tutorials is weird.
You posted this in response to my comments on 0.1.1:
QUOTE (Pallas Athene @ Dec 7 2009, 08:51 AM) <{POST_SNAPBACK}>
Aha, it appears to be that I lack some code intended to support the printing of "N/A" for tutorials too. That code path is effectively unreachable, since the debriefing doesn't display after a tutorial.
That seemed wrong to me, but I didn't follow up on it at the time. Now I wish I had, because my eMac won't boot up properly, so I had to download a fresh copy of Ares and run it in Classic on the iMac G5. I managed to complete a tutorial and the behavior was the same as in Antares. This isn't what I remember, so I think this is a bug that was introduced in a more recent version of classic Ares than I had been playing. I seem to recall that the results did display after a tutorial, but the score line in the "you" column and everything in the "par" column read "N/A".
In the latest version of Ares and Antares 0.1.1 or later, par numbers for tutorials 2 and 3 are -1 (which I think should convert to N/A, but doesn't for the kills and losses lines), but the par numbers for tutorial 1 were changed to match those of mission 1 for some reason. I suggest you revert to the old behavior, which I think is to display N/A in the par column if par is -1, and N/A in your score box if par for all 3 categories is -1, as well as changing par for tutorial 1 back to -1 for all categories.
QUOTE (NMS @ Apr 5 2010, 09:11 PM) <{POST_SNAPBACK}>
This is wontfix. The movies were alright for a 640x480 screen, but when we start using native monitor resolution, they'll either be too tiny or too pixelated to watch. I might consider movie support, but post-1.0, if at all.
I think I deduced from the code that tutorials should not have any stats displayed. That behavior seems to desirable to me, since there's no point in displaying a bunch of statistics if they're all N/A. And yes, N/A is indicated by par of -1.
It looks like Ares Scenarios gives the first tutorial the same par as Easy Street, as you indicate. The duplication goes further; the "Mission Status" is the same too, despite there not being five transports in the tutorial. However, this is a bug in the Ares data, not in Antares. I'll look at it at some point, but it's not a high priority.
Antares 0.2.2 has just been released. You can download it from Antares' Google Code page. This release resolves the following issues:
This is a bug-fix release, fixing problems introduced or identified in 0.2.1. Encountering this problem necessitated a force-quit, which is why it was put at the front of the queue.
Antares 0.3.0 has just been released. You can download it from Antares' Google Code page. This release resolves the following issues:
In addition, it moves to a new model of distributing the Ares data. In previous versions of the game, the data was packaged with the application download. As of version 0.3.0, however, Antares does not include the data, and the first time you open it several files will be downloaded and converted. This system has been designed to be stable across releases: if Antares's data format changes, it will need to convert the data again, but will use the same downloads as before.
Expect the first run to take a few minutes (or longer if you've got a slow connection). Subsequent runs should only take a few seconds to verify the data.
Hey, nicely done. Something to take for a test drive over the weekend
Wow, suddenly it's just like playing Ares. Of course, it helps that I bought a new i7 MacBook Pro since the last release, which makes the performance acceptable. Optimizing the graphics code is your next goal though, right?
I don't have access to an OS 9 machine at college, so I can't check Antares' behavior against classic Ares except by comparing with my YouTube videos, but I noticed one more difference. The mission results screen fills in about twice as fast in Ares as Antares. I'm not sure whether this is a performance issue or due to it being synced with the sound, or something else.
Is the new data distribution method due to Nathan Lamont not having the rights to all the sounds? I seem to recall that he wrote somewhere that if someone created a sufficiently complete and accurate port of Ares, he would allow it to be released as "Ares" instead of some other name, which might allow you to include the media intended for Ares that he couldn't release. I'm not sure if you're quite at that point yet, but when you are, you might want to contact him about it.
This post has been edited by NMS : 19 September 2010 - 01:44 AM
QUOTE (NMS @ Sep 19 2010, 02:41 AM) <{POST_SNAPBACK}>
Yes. There are a number of auxiliary tasks (reinstating the loading screen, displaying mission stats, etc.) that need to happen before 1.0, but that's the first order of business. Some of the side projects will probably happen in parallel, since I expect working on the graphics engine to be tedious.
It shouldn't be the sound, and I'm pretty sure I copied the timing constant (0.05 secs) from the original code. I did notice that the debriefing is displayed differently (filed as issue 37), and I could imagine that the typing cursor and the character are both supposed to take up 0.05s. I'll try to remember to investigate further when I look into that bug.
Yes, that's the reason. I don't think certification as "Ares" solves the problem, though. Frankly, I'm actually quite happy with the current solution, as it allows for a lot of flexibility in terms of improving the data format without forcing the data to be re-downloaded.
You mean this has been happening without my knowledge? Awesome!
-K
EDIT: Oop, gravedig.
This post has been edited by Kasofa1 : 20 October 2010 - 01:39 PM