Messages

I pulled the ags_shell.dll from my GeminiRue install. We need to finalize an acsetup.cfg file, and I think we're ready for a beta I can give to Wadjet? Anything else we need?

For doing one off testing, it would be VERY useful to include a BUILD_STR that's only present at the commandline (I don't see why it would be needed in game) to indicate the difference between two builds that are the same version numbers.

Sort of like how the kernel has an -AC branch and a -linus etc. Even though they're working on the same core version.

I strongly suggest advancing the build number, in some way, prior to the beta.

I think games rely on the version number. I think the easier thing to do, is just version the Linux version separately.

Ultimately the simple solution would be a BUILD_STR. Did that get rejected? I didn't get any feedback, or maybe I just don't understand how github works.

Here, autoscaling is disabled, because gfxfilter=StdScale2 is set in acsetup.conf. Also, is ags_shell.dll a Windows plugin?

Good catch I'll remove the .dll. The acsetup.cfg is direct from the Windows version. Since 90% of those options are ignored on the Linux version what SHOULD the config look like? I'm thinking ALL we need is:

[misc]
gamecolordepth=16
titletext=Gemini Rue Setup
windowed=0

Do we need any of the sound settings on Linux?

The version label built in program is "3.21.1115", although the build is technically not 3.21.1115 anymore (and for quite a long time already).
Since it is going to be used for official game releases (commercial or not), I think it would be appropriate if the version is updated.
We just have to think this out carefully and preview what consequences such change will have (if any).
I am going to investigate more on this.

Should we change this before we release?

I've packaged up GeminiRue per Wadjet's request. Here is the beta version that I'm proposing to give to them to start their Linux beta testing. Anyone care to take this package out for a test drive and give me any feedback before I send it off to Wadjet.

[link to full commercial game removed by moderator]

I'd like to get something to them tomorrow in the morning.

Not worried about the missing rain sounds, aware that that's due to platform issues. Issues noticed primarily during the introduction sequence, during the start of the game and sometimes when you switched tasks.

I did not experience any of the sound or delay problems you mentioned. I'm running Fedora 64 bit, what are you running?

Yup. Compiled today using the savegame changes, using it with the full version of Gemini Rue.

Where did you experience slowdowns? I just watched the whole intro, and walked around the first two screens for three minutes. No issues.

This is interesting. Using the game's data files with a freshly-compiled executable is giving me sound corruption/speed issues (at random it seems, for at least a couple of seconds and usually longer).

Can you provide more details? You're using an engine compiled today (after the big checkin of savegame stuff)? What game are you having problems with? Gemini Rue?

I guess so. Since it's beta test. Let's hope testers will test it good.

Well that's the intention! BigMc can you please build a new version of your ags+libraries? If you don't have time I can spin up a Debian Wheezy 32/64bit VM and build them. You already have that stuff, so it's probably easier for you. Should we need to look in to setting up a build system? Right now BigMc is our build system

Now that the savegame code is merged, are we ready to release beta test of GeminiRue? Wadjet has given me the data, we just need an engine to go along with it.

BigMc: can you do a build of your ags+libraries with the big merge that just happened? Can you give is a BUILD_STR=$(date +%F)? I'll use that binary as a basis for my Gemini Rue beta.

Still the whole savegame issue is a bit of a mess. What I mean is that savegames have a different size on all platforms, which is something that I do not at all understand.

I was under the impression that save games were not compatible across platforms.

I'd rather do the launch right. I can tell Wadjet there is minor savegame bug we're still working on, and want to hold off. I'll defer to you as to when you feel comfortable with the engine. Seeing as this would be the beta of GeminiRue on Linux, most of the savegames should be new (i.e. not from an older version of the engine) so we should be OK there?

Where do we stand on that savegame bug? I only ask because Wadjet asked me to package up a beta version of GeminiRue this morning.

Is there currently a way to do Fullscreen + Stretch on Linux? Or is your best bet to just do StdScaleX where X is as close as you can get? Does allegro offer any screen stretching modes?

Why should I do that right now? There was not a single change to the code since the last one.

I thought the savegame fix Crimson Wizard did landed. I misunderstood.

[real]

Couple quick questions:

#1) What are the default windowed/fullscreen/gfxfilter settings if no acsetup.cfg is found? I'm thinking a sane default is "-fullscreen and StdScale4" i.e. Fullscreen + stretch?
#2) Is there any real case where you want fullscreen but NOT stretch? I hate doing -fullscreen and the game loads and it's 320x200 with black border around the whole game. I'm thinking maybe we want to default to "stretch to fit" if the user selects fullscreen?
#3) Do we need a StdScale5 or maybe even StdScale6? A 1080P display is 1920x1080p. If you scale up a 320x200 game 4x (the current highest) you only get 1280x800. I'm thinking we want a full 1080P option?

Are we ready to release an official version 0.9 of the Linux engine? BigMc can you create another version of your package that includes the binary and the libs?