Messages

We're out, sadly  (we panicked from the rising ticket prices, and as there was no response here we figured it's not going to happen so we booked our flight already).

In regards to AGS developers were constantly complaining that they have to distribute it as one big file, because it forces users to redownload gygabytes of data to fix 1 bug.

Fair, though I was actually talking about the difference between having the assets embedded in something (be it the executable, or "asset pack files") and just distributing all of the assets in their unchanged forms (i.e having your bg.png appear as bg.png in the distributed folder) so that users have the ability to change the background image of your game (for example). I imagine most developers would not want that, though it might be appealing to a few (to allow for very simple "modding").

Right. I did not add "create new game" yet mostly because I don't want to encourage people to use the editor in its current unfinished and unpolished state.
It is still very much "under construction".
If you want to see the current state, the demo game does have a project file that you can load, here (though I'm not sure the file selection dialog is currently working in the editor, I might have broken it recently).

What you'll find (if the file selection dialog is working and you're able to load the demo project):
1. The ability to play/pause the game
2. When the game is paused, the ability to select objects/characters/guis and either edit their properties via the inspector or drag/scale/rotate them directly on the canvas
3. Game settings in general can also be edited via the inspector (and you can also select and edit objects from other rooms from the tree on the top-left)
4. real-time updates in the inspector whenever you move the object/characters/guis
5. When the game is paused, right clicking on the canvas also allows you to create objects/characters/guis
6. Undo/redo keyboard shortcuts should work with all modifications
7. Pressing ctrl+s generates the code for all the changes, but currently the code is written only to the console. It also saves all the changes to json files to be used by the editor.

There's a lot of stuff that's missing, and what's there does not look polished, and is also too slow currently.

I'm currently rethinking my strategy for the editor as development is too slow. I'm considering trying to integrate with vscode and then using electron for the editor UI (or at least for parts of the editor UI).

Ah, well, that's not "one for mobile, one for desktop". That's one for loading from the file system and one for loading resources embedded in the project (which is not necessarily for mobile -> most developers would probably prefer to embed their assets on desktop too, so they won't need to distribute all of their assets in separate files).

[Resolver]

When you call AddComponent<> the engine uses the Resolver class to resolve all the dependencies that the component has in its constructor.
The resolver itself it is tied to the device's file system by default. You can, however, override it with your own file system implementation if you want. To do that, you'll create your own implementation of the IFileSystem interface and then tell the resolver to use your implementation instead. Here's an example of how you'd do something like that.

If you want, you can also create the component yourself and pass a file system explicitly, and then call AddComponent with your component:

Code: csharp

var view = new FilesView(AGSGame.Device.FileSystem, ...);
_filesView = rightPanel.AddComponent(view);

p.s The files view is not a complete implementation (I stopped mid-development as I started questioning some design choices I made- so this goes to the back-burner until I figure out what's the next step for the editor).

It's done twice: One for the mobile file system, and one for the Desktop file system.

Not sure what you mean here. The file system is passed once afaik.

Are you assuming here that screen_height and screen_width equal the bitmap's height and width?
Did you verify that?

You can do:

Code: cpp

int srcWidth, srcHeight;
engine->GetBitmapDimensions(src_a, &srcWidth, &srcHeight, NULL);

And compare srcWidth/Height to screen_width/height (and also I'm assuming here that src_a and src_b are the same size, otherwise the code doesn't make a lot of sense).

EDIT: Ah, nvm, you solved it, cool.

You're increasing x & y in the loop, but you're also increasing the pointers (pixel_a and pixel_b) inside the loop, so you're increasing twice instead of once.
Try removing pixel_a++ and pixel_b++.

Hopefully when the editor is ready it will allow you to share the sprites without having to work so hard for it.

For me it is not a question of working hard to set up the folder structure, but of "don't repeat yourself". If I have the same sprite in various folders and want to change it, I have to take care to replace every instance of it. Also, with high-res games, this could increase size (granted, not with my three mouse sprites, but you get the idea).

By "working hard" I meant writing all of that code that you wrote in order not to duplicate the sprites. The editor will generate that code for you.

Okay, setting the pivot of each sprite to 0.5 did it.

Great to hear!

I reuse some sprites for various animations and making separate folders for it would be unnecessary overhead. I'll stick to manual sprite creation for now.

Sure.
Hopefully when the editor is ready it will allow you to share the sprites without having to work so hard for it.

And why does flipping the animation also flip the pivot?

It doesn't. The problem is that the FlipHorizontally function, instead of flipping the texture, it flips the scale on the horizontal axis.
Scaling is done from the pivot point. So a -1 scale (on x) when the pivot is 0 will shift the entire sprite to the other side.

There is an item in the backlog for changing this behavior and just flipping the texture, which should make flipping work regardless of the sprite's pivot.

For your previous issue, I believe you changed the character's pivot point. Note that you can change the pivot on the character but also on each individual animation frame (sprite) as well. So not sure, but it might work having the character's x pivot be 0 (for your previous issue: keeping the same co-ordinates as AGS) and your sprite's x pivot to be 0.5 (for flipping to work in the current scheme).
If it doesn't work, let me know, and I'll work on the texture flip item now.

How do I load the outfit/animation from the factory?

The factory methods assume that each animation loop is in its own folder.
So for example, you can setup your files in the following structure:
mortimer/
    -> walk/
         -> left/
             -> mouse_walk1.png, mouse_walk2.png
    -> idle/
         -> down/
             -> mouse_walk1.png
    -> speak/
         -> down/
             -> mouse_speak.png

And then you can load the entire outfit with:

Code: csharp

var baseFolder = "mortimer";
var outfit = await game.Factory.Outfit.LoadOutfitFromFoldersAsync(baseFolder, walkLeftFolder: "walk/left",
				idleDownFolder: "idle/down", speakDownFolder: "speak/down");

Or alternatively you can load directional animations with "game.Factory.Graphics.LoadDirectionalAnimationFromFoldersAsync" and construct your outfit from the directional animations like you did in your code.

We were thinking of an extended weekend in late august in Berlin. Does that work for you guys?

You need to center your sprites (they're using lower-left by default):

Code: csharp

walkSprite1.Pivot = (0.5f, 0f);
walkSprite2.Pivot = (0.5f, 0f);

Note that if you load an outfit or directional animation from the factory, it does it for you automatically, i.e if you only supply the left animation it will flip and center it to create the right animation (or vice-versa).

We're still interested. We can do Europe, either in the beginning or end of August (we'll be in Israel mid august).

Maybe you're using an older version of AGS (from before the fix)?

It might be possible to fix this without actually changing the engine code.
You might be able to convert the binary from Win32 to UWP using the Desktop App Converter.
I'm not sure if it will work, though, the game needs to meet all of these conditions specified here, I don't know if AGS breaks any one of them.
If it works, then the UWP application would come with a manifest file which you can just edit and set the dpi awareness flag, one of the links erloo put has this example.
If it doesn't work, then maybe modifications can be made to the engine to allow this conversion to work (having a UWP app also allows you to put your game on the Windows Store, which is another reason for wanting to support this in the engine).

Anyway, regarding an engine fix and the links erloo put, there are different APIs to be used depending on the Windows version, see here.

How does it decide on whether application needs it or not?

Just a guess here, but I'm guessing (wildly) the reason it works fine with DirectX but not with OpenGL, is that you're using an old version of OpenGL (I remember CW mentioned that you're using immediate mode which was deprecated a long time ago), and so Windows assumes it's need the scaling?

You can test eriOo's hypothesis by disabling the rescaling: https://answers.microsoft.com/en-us/windows/forum/windows_10-start/how-to-disable-display-scaling-on-high-dpi-setting/c546cd4c-c4b9-4cb0-8e7b-52fb8906ef70

I'm getting the same "Cannot read property 'pasteHTML' of null" when clicking on the "quote" button from chrome.
I debugged it a little bit. getRange in forums/themes/default/scripts/editor.js (line 916) returns null.
getRange calls getSelect, and the oSelection object is returned empty (i.e rangeCount == 0) which is why it returns null.
In getSelect itself both bWantText and bWantHTMLText are undefined, so it goes to line 898 ("this.oFrameWindow.getSelection") which returns the empty selection.

At this point, I thought, I didn't select any text, I just clicked the quote button, why should it call getSelection at all?
Unless maybe there's another piece of code that is supposed to select the text before calling this and the problem is that it didn't?

So I tried again, only this time I selected some text before clicking the quote button, but it didn't seem to help, getSelection still returns an empty selection.
I also tried this.oFrameDocument.getSelection (instead of oFrameWindow) but it also returns an empty selection even when text is selected, so not sure what to think.

(I'm assuming the game in the video doesn't have voices, the computer I'm currently using doesn't have speakers).

It does have voices (admittedly not very good ones though, so maybe he skipped because he was irritated).

Also, I'd like to reiterate. Are we sure people are simply forgetting that there's a right mouse button?
Does anyone else have any anecdotal evidence?

Same game, different reviewer. He didn't right click at all. He actually sounded about 30 years old, so you would assume he would know about right clicking.
But he got stuck a few times, and STILL didn't right click. I mean, I can understand why some people choose not to look at things during normal gameplay, but if you're hopelessly stuck to the point that you try everything on everything, you would try looking at things if you knew it was an option.

Note though that when you send a message there's a checkbox at the bottom that you need to check: "Save a copy in my Sent Items", otherwise it will not be saved at all.
You can set it to be checked by default in Preferences -> "Save a copy of each personal message in my Sent Items by default."

But what if they never attempt a right click, and they quit the game thinking it doesn't work?

That will totally happen.
I remember that I quit my first verb coin game because it hadn't occurred to me to click & hold, so I thought the game was broken.

Speaking of young modern players. Are there any young modern players actively playing adventure games?

Young enough for you?
Note that he never right clicked once in that video (not to mention the obsessive dialog skipping which you can't really design a solution for unless you're going Machinarium style).