Ambrosia Software Web Board: Antares 0.4.0 Released - Ambrosia Software Web Board

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

Antares 0.4.0 Released

#1 User is offline   Pallas Athene 

  • Lame space monkey
  • PipPipPipPipPip
  • Group: Members
  • Posts: 2,636
  • Joined: 27-February 00
  • Gender:Not Telling
  • Location:Omisha

Posted 03 October 2011 - 09:55 PM

Antares 0.4.0 has been released. This release fixes several issues:

  • Issue 18 (Briefing points clipped at edge of map)
  • Issue 20 (Smearing in third tutorial)
  • Issue 39 (Pausing via CAPS causes smearing)
  • Issue 41 (Mouse areas wrong for help and play-again screens)
  • Issue 55 (Design new replay file format)
  • Issue 57 (Mac menu bar intercepts events in full-screen)
  • Issue 60 (Minicomputer double-click threshold is proportional to time game has been open.)
  • Issue 42 (Music preferences not really respected)
  • Issue 49 (Scaled-up static is squashed horizontally.)
  • Issue 51 (Sprites unnecessarily hidden at right edge of screen.)
  • Issue 52 (At 1:16, squares clipped but other shapes disappear)
  • Issue 61 (Kinetic beams have a black contrail)
  • Issue 64 (Stars sometimes flash when leaving warp)


The sprite-drawing engine has been moved out of software and into OpenGL, hopefully providing performance improvements and certainly making Antares more maintainable in the long run. Other parts of the game are still drawn in software, however.

In addition, Antares 0.4.0 is the first release of Antares to open up its source code repository. If you're interested in helping with the game, it has a contributing page detailing ways to help.

#2 User is offline   Pallas Athene 

  • Lame space monkey
  • PipPipPipPipPip
  • Group: Members
  • Posts: 2,636
  • Joined: 27-February 00
  • Gender:Not Telling
  • Location:Omisha

Posted 04 October 2011 - 12:12 AM

BONUS: Open Terminal.app and run these commands to change your resolution:

$ defaults write org.arescentral.antares ScreenWidth -int 1280
$ defaults write org.arescentral.antares ScreenHeight -int 720

(if that's not your screen size, adjust as appropriate)

BONUS: Antares now LGPL3-licensed.

BONUS: Antares now with same amount of cowbell, no plans for more.

#3 User is offline   NMS 

  • Member
  • Group: Members
  • Posts: 64
  • Joined: 13-March 09

Posted 04 October 2011 - 09:50 AM

Oooh, nice. I like being able to set the resolution. I wrote a little applescript to make it easier:
Attached File  Set Antares resolution.zip (26.81K)
Number of downloads: 0

Performance seems better, but still not great when there are large numbers of sprites on screen, especially if the zoom level is changing. Playing in huge resolutions doesn't exactly help either. Also, the mouse input is laggy, which wasn't the case before.

I've had a few crashes. In fact the first time I tried to run it, it crashed when I tried to load a level. The level was Space Race, so that might have had something to do with it. Then it started working, but after running an old version the the formatting of the unlocked levels got screwed up and it crashed on startup. After fixing that I haven't had any problems, including with Space Race. Antares also doesn't start properly if you set the resolution to something other than a number.

I noticed on the issue tracker you were considering capping the (effective) resolution. I don't think you should choose one below 1024x768, since Ares supported that. But it might make sense to limit it to that for performance and multiplayer fairness.

This post has been edited by NMS: 04 October 2011 - 09:54 AM


#4 User is offline   Pallas Athene 

  • Lame space monkey
  • PipPipPipPipPip
  • Group: Members
  • Posts: 2,636
  • Joined: 27-February 00
  • Gender:Not Telling
  • Location:Omisha

Posted 04 October 2011 - 10:07 AM

View PostNMS, on 04 October 2011 - 09:50 AM, said:

Performance seems better, but still not great when there are large numbers of sprites on screen, especially if the zoom level is changing. Playing in huge resolutions doesn't exactly help either. Also, the mouse input is laggy, which wasn't the case before.


Is all input laggy or just the mouse? I'm not sure what introduced it, but I've felt that too at times. Do you know if it's just having large numbers of sprites, or a large battle? (though it's hard to have the former without the latter) In particular, the way Antares does the static effect for shields is kind of complicated and it could be that it's the problem.

Quote

I've had a few crashes. In fact the first time I tried to run it, it crashed when I tried to load a level. The level was Space Race, so that might have had something to do with it. Then it started working, but after running an old version the the formatting of the unlocked levels got screwed up and it crashed on startup. After fixing that I haven't had any problems, including with Space Race. Antares also doesn't start properly if you set the resolution to something other than a number.


Do you have a crash report from the first run? I'd be interested in looking that. I'm not interested in the latter two cases.

Quote

I noticed on the issue tracker you were considering capping the (effective) resolution. I don't think you should choose one below 1024x768, since Ares supported that. But it might make sense to limit it to that for performance and multiplayer fairness.


That's Issue 93, for those of you following along at home. The reason that I picked 800x600 was because it's more likely to yield nice multiples. The two monitor sizes I had in mind were 1280x800 and 1920x1200 (the 16:10 equivalents of the 16:9 720p and 1080p). Adopting 800x600 turns 1:1 into 4:3 and 2:1. Adopting 1024x768 turns 1:1 into 25:24 and 25:16.

#5 User is offline   NMS 

  • Member
  • Group: Members
  • Posts: 64
  • Joined: 13-March 09

Posted 04 October 2011 - 10:52 AM

All input is laggy actually. It's only a small fraction of a second, but it's obvious now that I'm paying attention to it. I expect the results of some key presses to be slightly delayed or not immediately apparent, which is why I didn't notice before. But things like turning and firing should be instant and aren't. It's very obvious with the mouse though. It seems to be a constant amount, independent of frame rate/lag.

Unfortunately, I didn't save my crash report because I thought I had done something abnormal that might be responsible. Apparently I hadn't though. My best guess is that the unlocked levels formatting was screwed up during the first run. Then I edited it to remove 26, which made it usable but not entirely correct. So it worked until I ran an older version, which messed it up and inserted it's own version at the beginning. After fixing it again, both versions can read it and not mess it up.

I see what you mean about the ratios, but I'm not sure I see the advantage of what you're proposing over the existing system, i.e. the user picks a resolution (which could be limited to a range) and it's scaled to fill the monitor preserving aspect ratio (or possibly displayed in windowed mode). I think you're suggesting scaling the sprites individually but having other things, like lines and instrument panels remain the same size in pixels. Would that improve performance, or look better?

#6 User is offline   Pallas Athene 

  • Lame space monkey
  • PipPipPipPipPip
  • Group: Members
  • Posts: 2,636
  • Joined: 27-February 00
  • Gender:Not Telling
  • Location:Omisha

Posted 04 October 2011 - 11:16 AM

View PostNMS, on 04 October 2011 - 10:52 AM, said:

Unfortunately, I didn't save my crash report because I thought I had done something abnormal that might be responsible.


It's not still in ~/Library/Logs/CrashReporter?

Quote

I see what you mean about the ratios, but I'm not sure I see the advantage of what you're proposing over the existing system, i.e. the user picks a resolution (which could be limited to a range) and it's scaled to fill the monitor preserving aspect ratio (or possibly displayed in windowed mode). I think you're suggesting scaling the sprites individually but having other things, like lines and instrument panels remain the same size in pixels. Would that improve performance, or look better?


One point is that it's advantageous to stay below 1:16 zoom and see real sprites and not LR symbols. At 1:4, you can see more with a large monitor than a small monitor. I'm suggesting that you should see same scene in higher resolution, rather than seeing a larger scene. Similarly, zoom to hostile is guaranteed not to zoom below 1:1, so during a close flyby, a smaller screen is more of a handicap.

#7 User is offline   NMS 

  • Member
  • Group: Members
  • Posts: 64
  • Joined: 13-March 09

Posted 04 October 2011 - 12:25 PM

View PostPallas Athene, on 04 October 2011 - 11:16 AM, said:

It's not still in ~/Library/Logs/CrashReporter?

Um, yes of course it is. Seems to suggest it was in the middle of displaying the starmap, which matches my memory.


View PostPallas Athene, on 04 October 2011 - 11:16 AM, said:

I'm suggesting that you should see same scene in higher resolution, rather than seeing a larger scene.

Oh, I see. It avoids the sprites being scaled down (because you're zoomed out) and then scaled back up again (because the game is scaled to your monitor). So I guess you'd still scale up the instrument panels and game windows. Can you scale up the lines though? Actually, looking at them in a high resolution, it looks like they do have thickness, so maybe that would be OK. How would running at higher resolutions impact performance, assuming the viewable area is the same? Does the software have to do more work, or is just the graphics card? If it's done by the hardware, it seems like a good idea.

Still, wouldn't you have to be able to handle arbitrary ratios? People might have external monitors with weird resolutions like 1344x1008 and there are Macs with native resolutions like 1024x768 and 1680x1050. Is it that much easier to scale by fractions of 32:25 or 42:25 than an arbitrary amount?

Attached File(s)



#8 User is offline   Pallas Athene 

  • Lame space monkey
  • PipPipPipPipPip
  • Group: Members
  • Posts: 2,636
  • Joined: 27-February 00
  • Gender:Not Telling
  • Location:Omisha

Posted 04 October 2011 - 12:34 PM

View PostNMS, on 04 October 2011 - 12:25 PM, said:

Um, yes of course it is. Seems to suggest it was in the middle of displaying the starmap, which matches my memory.

Hmm, odd. That's definitely not a place I'd expect to see a crash. Reported as Issue 96. Also filed Issue 97 for the input lagginess. Both for a hotfix release, though if I can't reproduce the former, I'll probably drop it.

Quote

Oh, I see. It avoids the sprites being scaled down (because you're zoomed out) and then scaled back up again (because the game is scaled to your monitor). So I guess you'd still scale up the instrument panels and game windows. Can you scale up the lines though? Actually, looking at them in a high resolution, it looks like they do have thickness, so maybe that would be OK. How would running at higher resolutions impact performance, assuming the viewable area is the same? Does the software have to do more work, or is just the graphics card? If it's done by the hardware, it seems like a good idea.

Still, wouldn't you have to be able to handle arbitrary ratios? People might have external monitors with weird resolutions like 1344x1008 and there are Macs with native resolutions like 1024x768 and 1680x1050. Is it that much easier to scale by fractions of 32:25 or 42:25 than an arbitrary amount?

We can handle arbitrary scales just fine—I'm mostly thinking of 1:1 zoom, where it could potentially look odd for the game to be scaled by a weird fraction.

#9 User is offline   NMS 

  • Member
  • Group: Members
  • Posts: 64
  • Joined: 13-March 09

Posted 04 October 2011 - 12:44 PM

That's about what I thought. I don't think it's worth dropping support for the largest resolution Ares allowed just to get better ratios. Maybe the user could select "small", "medium", or "large", corresponding to the original sizes. That would determine viewable area and then things would be scaled to their resolution.

#10 User is offline   NMS 

  • Member
  • Group: Members
  • Posts: 64
  • Joined: 13-March 09

Posted 04 October 2011 - 01:45 PM

Just had another crash. Apparently due to transferring control. Possibly my escape pod expired at the same time?

Spoiler


#11 User is offline   Pallas Athene 

  • Lame space monkey
  • PipPipPipPipPip
  • Group: Members
  • Posts: 2,636
  • Joined: 27-February 00
  • Gender:Not Telling
  • Location:Omisha

Posted 04 October 2011 - 01:47 PM

Can you post the crash report to the issue tracker?

#12 User is offline   Two Jacks 

  • internet poet
  • PipPipPipPipPipPip
  • Group: Members
  • Posts: 3,661
  • Joined: 09-January 05
  • Gender:Male
  • Location:A hole in the kitchen wall.

Posted 04 October 2011 - 04:10 PM

\o/

Hmmm can't seem to get mouse controls to work...

#13 User is offline   Pallas Athene 

  • Lame space monkey
  • PipPipPipPipPip
  • Group: Members
  • Posts: 2,636
  • Joined: 27-February 00
  • Gender:Not Telling
  • Location:Omisha

Posted 04 October 2011 - 10:48 PM

View PostTwo Jacks, on 04 October 2011 - 04:10 PM, said:

Hmmm can't seem to get mouse controls to work...


Can you give a little more detail? Maybe try the tutorial where mouse control is introduced? (2nd, I think)

Share this topic:


Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users