Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Snarky

#141
Quote from: Looka_998 on Wed 03/05/2023 13:59:56I make games with my girlfriend, who works with me on gameplay and story and makes the graphics, while I'm on coding duties. Together, with my brother on sound/music duties, we have formed "Daedaleia Games".

Welcome, and good luck to you! One thing you might want to consider is that there is already a pretty prominent adventure game studio called Daedalic Entertainment. Do you want to risk being confused with them?
#142
@Khris, just thought you might want to be aware that this module causes Perfect Tides to crash when run in debug builds of the engine and the OpenGL renderer, due to it attempting to create DynamicSprites with 0 or negative sizes.

https://github.com/adventuregamestudio/ags/issues/1973
#143
Quote from: Peegee on Sat 29/04/2023 17:17:39PS: I could never put the code in black! I can't find the info.

Try quoting one of Khris's posts with embedded code. That way you can see how he does it.
#144
This is what I would call a lucky first guess:

Wordle 679 3/6*

⬜🟨🟨🟨🟨
🟩🟨🟨🟩⬜
🟩🟩🟩🟩🟩

Spoiler
FARCE, CREAM, CEDAR
[close]
#145
AGS is not really designed for HD resolutions. It can be done, as Old Skies demonstrates, but you'll start to run into limitations (like the problems with downscaling that Crimson Wizard mentions) and performance issues. Dave Gilbert is an old hand at AGS and probably knows what he's doing, but without that experience I would recommend against it.

So your best options are to either go with a compromise resolution, e.g. 720p as Khris recommends, or use a different engine that is more suited for HD games. Godot + Escoria, Visionaire, Unity + Adventure Creator, and Ren'Py are engines/frameworks you might want to check out.

In any case, a higher resolution inevitably means larger file size (unless you were to use something like vector graphics), though some of these other engines can use graphics that are better compressed than AGS offers—for example, Ren'Py supports the webp format, which offers very high image compression.
#146
Backgrounds cannot have multiple layers. For additional layers, you may use room objects.

(However, depending on what you want the additional layer for, you could perhaps just use a walkbehind area instead.)
#147
Quote from: Crimson Wizard on Fri 21/04/2023 15:13:27No, the line breaking chars do not need to be reversed, that makes no sense whatsoever. The `\n` (escaped 'n') is not treated as two characters, it's processed as a  single special character called LF (ascii code 10).
Converting '[' to ']' will only make sense if that's a displayed character, but won't if it's a special break character, in which case it must retain its code.
Both '\n' and '[' are treated by AGS during wrapped string drawing (I think it converts one to another for consistency, but I forgot the details); if they will be reversed, then nothing will work.

If you think I meant to turn '\' into '/' and '[' into ']', then I certainly agree that makes no sense whatsoever. That was merely me not remembering which symbols are actually used.

As for the rest, it depends on which character code is actually stored in the string at string manipulation time. If it is always LF, then things are simple and it is clear what to do. However, you say that the conversion happens "during wrapped string drawing," and my recollection is also that you do sometimes have access to strings with '[' (and "\n"?) not yet parsed. In that case we have to ensure that we are handling them correctly. It might be that the '[' is a linebreak and should be treated as such in our logic, or it might be that it really is a '[' character, and should simply be kept and wrapped as any other character.

And because we are dealing with reversed strings, with "\n" it becomes a question of whether it was inserted before or after the reversing. If it was before, it might conceivably appear as "n\" (though if correctly converted from a proper bidirectional text, I believe it shouldn't). Since AGS at no point accepts that as a linebreak, we might even need to do a replacement.
#148
A linebreak function would be useful to have in general. I'm interested in having a crack at it. One question: how will manual linebreaks made using "/n" appear in the reversed "RTL" string? As "/n", as "n/", or already converted to a newline code? (Actually, it might be best to optionally support all of these as well as the old ']', using some kind of configuration bit field.)
#149
You can't. If you want a different UI, you will have to make it yourself.
#150
BTW, the latest Quordle redesign a couple of weeks ago screwed me out of a 50-game streak that I would have completed today. When it updated, it somehow failed to zero out my game from the day before, so that I had to start off with 8 rows pre-filled with irrelevant guesses and no way not to lose.  :~(
#151
Quote from: Matti on Tue 18/04/2023 19:02:06I got it in four today. Funny enough I started with "stare" which i seldomly do  ;)

Wordle 668 4/6*

⬜⬜⬜⬜⬜
⬜⬜🟩⬜⬜
⬜🟩🟩🟩🟩
🟩🟩🟩🟩🟩

Spoiler
STARE
PLUMB
FOUND
HOUND
[close]

Congrats. It seems to me that it's really PLUMB that is doing the heavy lifting here, in that unlike STARE (a perfectly reasonable starting word) it would normally not be a good guess, but in this case it actually ends up ruling out about half the possibilities for the final letter (POUND, MOUND, BOUND).

Quote from: cat on Wed 19/04/2023 08:21:40Who else guessed

Spoiler
THUMB
[close]
before
Spoiler
THUMP
[close]
today?

Not me, but I did guess
Spoiler
THUNK
[close]
#152
Wordle 668 X/6*

⬜⬜⬜⬜⬜
🟨⬜🟨⬜🟨
⬜🟩🟩🟩🟩
⬜🟩🟩🟩🟩
⬜🟩🟩🟩🟩
⬜🟩🟩🟩🟩

I kind of blame myself. I should have seen what I was setting myself up for on the third row and avoided locking in four letters (though with three yellow I didn't have many options, and probably couldn't have played all that much more efficiently in any case).
#154
Quote from: Stupot on Sat 15/04/2023 10:38:25I happened to refresh the page while you were in the middle of changing the URLs and they briefly showed up.

Ah, they weren't showing for me because they were being blocked by the PrivacyBadger extension.
#155
It has to be a direct link to the image file, not to the webpage that Dropbox creates. Dropbox makes it kind of awkward to do so, but you can edit the URL to change the ?dl=0 at the end to ?raw=1 and it will link directly to the image file.

Edit: However, it seems like Dropbox doesn't like embedding images on other sites. At least, when I tried to edit your post to embed the links, they still didn't show up:



(There's an embedded image above here of https://www.dropbox.com/s/op9r9f3qg0j73ha/Zniw%20Adventure%20-%20Top.jpg?raw=1)

I would recommend uploading the images to a proper image host, like imgur.
#156
Quote from: Crimson Wizard on Fri 14/04/2023 15:18:25Well, then someone will have to help with these script functions, or write a module...

At least in case of a speech one would have to comply to the undocumented width calculations of the speech overlays. Or write completely custom speech to not depend on that.

The SpeechBubble module already has a version of this calculation (for LucasArts speech).

(Edit: The SpeechBubble calculation differs a little from the engine calculation, in order to accommodate the border around a speech bubble. Example modified to match engine.)

Code: ags
int lecSpeechWidth(Character* c)
{
  int vpWidth = Screen.Viewport.Width;
  Point* cp = Screen.RoomToScreenPoint(c.x, c.y);
  int cx = cp.x;
  int w = vpWidth/2 + vpWidth/6; 
  if(cx < vpWidth/4 || cx > vpWidth - vpWidth/4)
    w -= vpWidth/5;
  return w;
}

So, assuming a String.BreakRtl(int width, FontType font) extender function, SayRtl() could be implemented like so:

Code: ags
function SayRtl(this Character*, String message)
{
  String rtlMessage = message.BreakRtl(lecSpeechWidth(this), Game.SpeechFont);
  this.Say(rtlMessage);
}

I think in each case all the helper functions would be a one- or two-liner.

Quote from: Crimson Wizard on Fri 14/04/2023 15:18:25If the game was already done when you realized that you want such translation, then you'll have to edit all the text assignments and Say calls in script.

Is this really a problem in practice, though? If this situation were to occur, there are two options:

1. Edit all the relevant calls and string assignments and rebuild. Most of that can probably be done by search-replace.
2. Do the linewrapping manually in the translation file.

Keep in mind that we're talking about support for a hacky workaround as a stopgap solution.

I don't know, man. You do what you want. It's not like I can stop you. But you do periodically bemoan how you keep getting distracted by patching up and making minor additions and tweaks to the current, out-of-date code instead of focusing on a forward-looking architecture.
#157
Quote from: Crimson Wizard on Fri 14/04/2023 12:43:52I guess you may try that, except you will have to then apply this everywhere throughout the game, for each existing string that may be wrapped:

Easily done with a few helper functions: DisplayRtl, SayRtl, DrawStringWrappedRtl, Label.SetTextRtl...
Yes, you might have to implement custom dialog options rendering, but again, this seems like an edge-case of an edge-case.

Quote from: Crimson Wizard on Fri 14/04/2023 12:43:52Actually, if we have the font render that can account for direction control chars, as eri0o mentioned, maybe we won't need RTL setting in the engine at all (rather than for backwards compatibility).

We might want a way to do RTL text input, but it should probably be a setting per TextBox rather than game-wide. (Though if the input box was made fully bidi-compatible, the only effect of this setting might be that the caret would start off right-aligned rather than left-aligned.) And in the mean time, the TextField module could relatively easily be modified to do so.
#158
Quote from: Crimson Wizard on Fri 14/04/2023 12:30:42Afaik this is what Mehrdad is currently doing: he puts linebreaks himself, everywhere where necessary.

Right, that's the simple solution, but what I meant was that one could also just write a "reversed-pRTL" (pseudo-right-to-left) linebreak algorithm in script (measuring line widths from the end of the string, and reordering the lines so that the end of the string is at the top), rather than implement it in the engine.

Because to me this seems like cruft: special-case code that isn't useful for 99% of users, and adds complications to the engine while not really being the "right" solution to the problem.

(Right-alignment as an option in more GUI Controls would be useful, but shouldn't be tied to a RTL setting.)
#159
Quote from: Crimson Wizard on Fri 14/04/2023 01:32:42The case I'm trying to resolve is the "incorrect" unicode RTL text, which is stored in memory in reverse way compared to what it should normally be
Quote from: Crimson Wizard on Fri 14/04/2023 01:32:42The proper solution would require at least a replacement of a font renderer to something modern (I guess that's "Harfbuzz" that you mentioned). But until then users of these languages have to resolve to this hack, whether that is ags3 or ags4.

In that case, I would strongly urge you to consider how much effort to put into a stopgap solution built on a hack (and introducing even more hacks). Because if I understand correctly, this is not a regression or really even a bug: it's just that the very limited hacky support AGS has long had for RTL scripts imposes some inconveniences on devs that makes text formatting difficult (e.g. not being able to rely on automatic wrapping, which simply means they'll have to do so explicitly). So is it really worth it, or would it be better to devote that energy to a proper solution down the road?

Is it possible that some of the inconveniences can even be solved in script without any engine changes, simply by reversing the strings, doing any manipulations on them (including, potentially, finding the linebreak points, reordering the lines and inserting explicit linebreaks), and re-reversing them? (Or not re-reversing them, in the case of some GUI Controls apparently.)
#160
Maybe it would be useful to make a table, to keep track of how AGS treats text that is:

-LTR (we know this works)
-RTL (Unicode)
-bidirectional (Unicode)
-pseudo-RTL (reversed, non-Unicode?)

In the case of text that is:

-Copied into IDE from an external editor
-Entered/edited in IDE
-Entered in translation file (Unicode)

For:
-Display in IDE
-Display in-game

As well as:
-Text entry in game (TextBox)

With AGS set to:
 -RTL mode
-"Normal" mode

Edit: And by "how AGS treats," I mean:
-Do the characters appear in the right order/direction?
-Are lines of text correctly aligned?
-Are ligatures displayed correctly?
-Are string operations performed correctly? (.Append(), .Substring(), etc., as well as string substition tags like %s)
-Does editing work correctly? (in IDE and TextBox), i.e. caret movement on entering/deleting a character
SMF spam blocked by CleanTalk