Messages

Oh whoops. I definitely hate distorted aspect ratios too. In my mind, if there were no options to toggle it, the aspect ratio would always be preserved. The coming custom resolutions version sounds like it has a much more sensible set of options anyway.

Can we call "sideborders" pillarboxing? That's the official term.

I'd rather not, as I've never heard of that and it barely even shows up on google. I'd prefer a clear and widely-used term over an "official" one.

I don't know if that's a good test or not. I mean, try applying that test to the term "side borders". I have no trouble finding pillarboxing and letterboxing. I guess our mileage differs.

Ehh... I'm not trying to start a fight. If people love "side borders", I guess it's not that bad.

Do we even need these options? Pillarboxing is the least desirable effect. A screen that's filled with content is most desirable. Is this perhaps just a question of picking an order in which to do things and removing the configuration options?
1. Try all video modes without tolerating letterboxing or pillarboxing
2. Try all video modes tolerating letterboxing
3. Try all video modes tolerating letterboxing and pillarboxing
Similar to, but not quite that same as "Don't force letterbox, enable sideborders" under the current schema. Perhaps that's too narrow an approach. I might just not be seeing the use case for those options. If you end up with a video mode that has non-square pixels, I guess it would throw things out a bit.

Can we call "sideborders" pillarboxing? That's the official term. From what CW has posted about the algorithm, it sounds like "prefer letterboxing" or the inverse "avoid letterboxing" might be appropriate verbs.

I think I was encountering that same 0x0 error too. I'll update from your branch when I get a chance and do some more testing.

-- ignore --

No no, April Skies! I mean the music didn't play at all. Not sure what was wrong.

I tried merging this into 3.3.1, but I'm getting crashes and errors saying that a resolution of 0x0 can't be initialised when running it full screen. Running in a window is fine though.
It's probably my fault. I don't know if I did the correct thing when merging it or not.
This is my branch: https://github.com/gurok/ags/tree/331_alpha1proposal
It's 3.3.1 + the master + your branch.
I checked out your branch, edited the files that had conflicts, added them to the commit, then committed and pushed the whole thing to my branch.
I'm not asking for your help. I just wanted to cry a bit because I can't figure out what's wrong.

Short and entertaining. The music didn't work for me . The story's resolution was nice -- all loose ends tidied up. The resolution of the graphics was a bit odd. I'd have preferred pixels that were all of the same size. Nothing was particularly tough. I think the hardest puzzle was getting the cloud to move. The rest kind of happened naturally.

Streuth! This is the best flamin' you beaut, ridgy didge, dinky di (yep, you missed a few) game with a wallaby I've seen all year. I would download it right now, but I'm at work and a dingo's got my baby bandwidth. Now if you'll excuse me, I have to throw a few more shrimp on the barbie (because that's definitely what we call them here). Hooroo.

P.S. After a quick squiz, I can say you should've entered this in April's comp because this is bloody Shakespeare. What a little ripper. I'll stop now.

Hey, CW, is it possible for me to make an updated version of 3.3.1 with this resolution selection stuff in it? I might be able to help test it, but my game uses text window padding. Is there a branch or is it just a matter of grabbing the most recent commits from master?

Damn, this game is so pretty. Especially that close-up shot in the first post. I am really pumped for this game!

If rotation works the same way as it does in other Corel image editors, you could try switching to indexed colour before rotating it. I haven't used PhotoPaint for years, but maybe that will help.

Alien Time Zone! Directed by James Cameron.

[EDIT:]

I am not sure what the best course of action is here. Breaking font height handling in labels would probably break legacy code.
<...>
The ideal would be for both to use wgetfontheight(n) + line_spacing, but that would require some kind of switch between legacy<-->rational mode.

There are simple ways to deal with compatibility, that's what I explained in regards to your very first pull request - checking game data version.
(Or against GUI version - if you were adding new properties to gui class)
In this case there may be a global variable (well, "global" by scope of applicance, not in C meaning) that defines message spacing, 0 for old games and 1 (or settable) for new ones.

Well, yeah, checking against the game data version or the GUI version is what I wanted to avoid, as that would provide no way for people to obtain the legacy behaviour when compiling in a new version of AGS. I wanted to ensure things wouldn't break for people with old projects.

I think your second suggestion is probably the way to go if I understand it correctly. e.g.:

Code: ags

game.use_global_line_spacing = true;
game.global_line_spacing = 1;

And in the default game template, we could just define:

Code: ags

game.use_global_line_spacing = true;

Thus preserving old behaviour for people upgrading to 3.3.1 (or whatever). I'm sorry. I didn't mean to give you the impression that I wasn't taking note when you told me about checking against game versions. I just meant that it wasn't straightforward and I wanted to avoid complicating the API where possible. For instance, I think defining a number like:

Code: ags

game.message_line_spacing = 0;

Might be too much because then game authors would need knowledge of how message spacing works (message_line_spacing + global_line_spacing = actual_line_spacing).

EDIT: Wait... I've got confused myself. On more close examination, labels do not use usetup.textheight. They calculate their line height as

Code: cpp

TEXT_HT = wgettextheight("ZhypjIHQFb", font) + 1;

The source of confusion is that TEXT_HT is also a macro defined as "usetup.textheight", but that macro is declared only for old built-in dialogs. And, there's a second set of control classes that are created on built-in dialogs, including label (MyLabel)

Yes, sorry about that. I did get confused. I ended up looking at MyLabel last night because I think I just jumped to the first label definition I found. The principle is the same for both though. That pesky +1. I need to stop and consider things a bit more before I post sometimes though.

I have worked out what this is, Calin.

From line 229 of graphics_mode.cpp, labels use this value for font height:

usetup.textheight = wgetfontheight(0) + 1;

And regular fonts in text window GUIs use this value for font height (display.cpp, line 94):

texthit = wgetfontheight(usingfont);

I am not sure what the best course of action is here. Breaking font height handling in labels would probably break legacy code.

The ideal would be for both to use wgetfontheight(n) + line_spacing, but that would require some kind of switch between legacy<-->rational mode.

For now, I might have to stick to single line descriptions in GUIs and just add 1 to the overall font height.

Ignore this

+1

Count me in.

And my axe! (Or $100)

Sophie B. Hawkins and Ace of Base are borderline '91 and '93 respectively.

(Who ever uses a "tilde" in-game, anyway? )

I don't use it for tilde, but on a US keyboard, I find it cool to map it like so:

Tilde - opening double quote
Backtick - opening single quote
Quote - closing single quote
Double quote - closing double quote

Mods, does this advice still apply if you're using sprite fonts? If so, why?

I do. I always liked Nanny the best. Do you remember The Trap Door? Bananaman? Victor and Hugo? Danger Mouse?

Well, after watching that alpha, I wanted to see more. That's always a good sign. I think the fountain is very nicely done.