Topic: AGS 3.5.0 - alpha 13 - next WIP version

[bx83]

Okay I've tried the editor - incredibly easy and fast, very useuful for viewing several layers at once, exceptional

However, I have a suggestion for 'export' function for hotspot/walkbehind/whatever/etc; it's 90% the way there.

I'm trying to convert hotspots/walkable area masks etc. to a new size screen.
My old background was 1024x768; my new background is 1366x768 (this is the 16:9 ratio screen of the old 1024 5:4 size).
The transparent map that the .bmp (or some other format) I'm saving in is not the screen size; instead, it's edges are defined by the limits of the walkbehind/whatever
So all exported resources come out a different size, and also, a different proportion... :/ (position is for my purposes, not important).
When I open them in paint.net, and alter canvas size to be the dimensions of the screen, the eg. hotspot ends up being a different position on-screen (and different proportions).

I don't understand how the proportion problem could have happened; I only increased canvas size, not changed image size.

See my photos for proof:
the widescreen version with too-small hotspot
the original size and hotspot

A simple solution would be to print all hotspots/walkable area/etc. on to one image, that's the size of the screen it came from; and somehow, the correct proportions.

Note: I have only used .bmp images.

[Crimson Wizard]

My old background was 1024x768; my new background is 1366x768 (this is the 16:9 ratio screen of the old 1024 5:4 size).
The transparent map that the .bmp (or some other format) I'm saving in is not the screen size; instead, it's edges are defined by the limits of the walkbehind/whatever
So all exported resources come out a different size, and also, a different proportion... :/ (position is for my purposes, not important).

The purpose of the export operation is to print the actual bitmap as it is stored in the room you export from. It is only wrong if the result does not match the room it is exported from. In other words, for the test you should be able to import the same mask back into the same room and keep the original looks.

Then, if I got it correctly, you are exporting masks from the rooms which had one resolution and then trying to import them into the new rooms that have different resolution (with also different aspect ratio). Is it so, or something else?
If that's the case, correcting proportions is not what the export operation should do, but rather import operation. Because at the time of export the program has no idea what are you going to do with these images (and should not -- that's not its concern to know that).

BTW, you keep saying "screen size", do you actually mean game resolution? I was pretty confused by this earlier.

So all exported resources come out a different size, and also, a different proportion... :/ (position is for my purposes, not important).
When I open them in paint.net, and alter canvas size to be the dimensions of the screen, the eg. hotspot ends up being a different position on-screen (and different proportions).

I don't understand how the proportion problem could have happened; I only increased canvas size, not changed image size.

If you have imported the masks from the 1024x768 room into 1366x768 room without modifying the image size, then it is only logical that proportions do not match the proportions of the background picture. You'd probably need to change mask size, stretching the proportions. But, that really depends on how much your backgrounds have changed. If they are like 1:1 only with different proportions, then stretching original mask should work; maybe will require a bit of adjustment by hand to correct loose pixels.

Could you upload some room (*.crm file) you do export from for me to test it out? Actually - both rooms, a pair of old and new ones.

[proximity]

Crimson, I've been tampering 3.5.0 alpha 5 and I have a problem. How do we draw any line or fill the area in the room editor? Nothing seems to work.  I can draw a filled rectangle but it renders the rectangle too away from my click point.

[Crimson Wizard]

Crimson, I've been tampering 3.5.0 alpha 5 and I have a problem. How do we draw any line or fill the area in the room editor? Nothing seems to work.  I can draw a filled rectangle but it renders the rectangle too away from my click point.

Nothing has changed in regards to the mask drawing. The room zooming/scrolling code has changed, but I've just tested this in a random game and painting works.
Could you give more details of what you do? What's your game resolution, room size, do you use room zoom? what kind of mask mode are you in and what is the area ID?

[proximity]

I've just tried it with patch 6 and the result is the same. There is a huge offset between clicking point and drawing point. Offset amount is like a half of the screen. Drawing tools are broken for walkable areas and regions and hotspots. Walk behinds work properly.

Test resolution : 1920*1080
Room resolution : 1920*1080
Tried with zoom : 100%
Broken modes : Walkable areas, regions. hotspots (ID 1,2,3)
Working modes : Walk behinds

[proximity]

Check this image. The blue line on the roof is mouse position and the other lines below are actual drawn lines. There is a huge gap between them.

https://ibb.co/ct02YL

[Crimson Wizard]

Yes, this is technically because in hires games all masks except Walk behinds are 2 times smaller than the room size (has 2 times less resolution/precision).
Probably the coordinate conversion is broken at some point, I am looking into this now.

[proximity]

Understood. I can test it after fix if you need me.

[Crimson Wizard]

Understood. I can test it after fix if you need me.

Please try following build (copy over latest 3.5.0 installation):
https://www.dropbox.com/s/zune9gln285sozt/AGSEditor-3.5.0.2--roompaintfix.zip?dl=0

There is also one strange issue I noticed, when the editor's scroll position is not 0, the rectangles you paint end up shifted by 1 pixel right/down. Not yet sure if this was also caused by recent changes in this version. This may also be related to coordinate rounding.

[proximity]

I pasted them to both patch 5 and patch 6. All drawing tools work now. Rectangle tool draws to 1 pixel right-down as you said. I think you should update these files on patch 6. Thanks for quick update

[Crimson Wizard]

AGS 3.5.0 - Alpha 7

This is a very small bug-fixing update, mainly  to counter recently found problems with the room editor.

Zip archive: http://www.mediafire.com/file/b0sa0425evh77p2/AGS-3.5.0-alpha7.zip/file

Editor:
- Fixed same game appeared multiple times in the "Recent games" list if the game's title was changed (regression).
- Fixed room masks drawing in the high-resolution games (regression).
- Fixed drawing operations on the room masks were sometimes off by 1 pixel (regression).

Engine:
- Made engine fallback to defaults if config contains invalid game scaling setting.
- Fixed crash in the Software renderer which was occuring when any other renderers are tried prior to Software one but failed to initialize for any reason.



KNOWN ISSUES:
- Editor crashes on exit. The crash takes place only after game is saved and window closing and seem to not make it loose any changes.
- New pathfinder crashes when the destination lies outside of the room: https://github.com/adventuregamestudio/ags/issues/523

[proximity]

Hello Crimson. There are serious problems with the engine:

* The Room pane gets broken over time and you can't access it, and it's too slow, nearly uneditable.
* Object or character images on the room seem bigger than original size, like two times bigger.(in the editor).
* GetWalkableAreaAt script command doesn't work anymore. The engine knows the player is on a walkable area but doesn't execute the command.
* Character.Frame property also seems broken. Whatever the character frame is, the engine thinks it is always true.

[Crimson Wizard]

* The Room pane gets broken over time and you can't access it,

Can you give any details?

and it's too slow, nearly uneditable.

Is this related to the zooming? (it's still may not be optimised for high-resolution games)

* GetWalkableAreaAt script command doesn't work anymore. The engine knows the player is on a walkable area but doesn't execute the command.

Only to make sure, are you passing screen coordinates or room coordinates in there?

* Character.Frame property also seems broken. Whatever the character frame is, the engine thinks it is always true.

Not sure what you mean here? Character.Frame is integer, so its always "true" (in boolean sense) if its above 0. How do you use it?

[proximity]

Okay. Here are details :

* The Room pane on the top of the window gets unselectable over some time. When you select it, nothing happens. Just a window frame that represents the Room window and its inside is blank, or not blank really, its inside is the screen of the last window you visited. It's like an error from Windows 98 era. Do you visualize what I described? If not, I can take a screenshot.

* It's not related to zooming because I tried it with 100% zoom. It's much slower than 3.4.1.

* GetWalkableAreaAt I just migrated my test project from 3.4.1 to 3.5.0 and it was working on 3.4.1. Coordinates are player.x and player.y. I think they are room coordinates?

* I can explain it with an easy example :

Code: Adventure Game Studio

1. if (cChar.Frame == 35) {
2. cChar.ChangeView(X);
3. }

In this simple code, the engine doesn't wait to change the view till the frame number 35. Instead, It changes the view immediately. Whatever the the actual frame number is, the engine thinks It's 35 and executes the command. And believe me, I know what I'm doing I didn't test every single script command. There may be more broken scripts like Character.Frame and GetWalkableAreaAt.

[Crimson Wizard]

* GetWalkableAreaAt I just migrated my test project from 3.4.1 to 3.5.0 and it was working on 3.4.1. Coordinates are player.x and player.y. I think they are room coordinates?

According to the manual, GetWalkableAreaAt requires screen coordinates, so in scrolling room it will require adjustment with GetViewportX()/Y().
I will test that myself soon though, I recall we had some problem with detecting walkable areas (although that could have been another version).

* I can explain it with an easy example :

Code: Adventure Game Studio

1. if (cChar.Frame == 35) {
2. cChar.ChangeView(X);
3. }

In this simple code, the engine doesn't wait to change the view till the frame number 35. Instead, It changes the view immediately. Whatever the the actual frame number is, the engine thinks It's 35 and executes the command.

But that's technically impossible if only Character.Frame is not working, it's about how "==" operator is working then, because Character.Frame itself cannot know what number you are comparing to. Either things are completely messed up in the engine, or there is something else in the script that affects that.
Could you for example log the current frame value somewhere, like print on a GUI label and see how it changes?
EDIT: I did a very simple test, which looks like this:

Code: Adventure Game Studio

1. function repeatedly_execute_always() {
2.   lblScore.Text = String.Format("Frame: %d", player.Frame);
3.   if (player.Frame == 6)
4.   {
5.     lblScore.Text = lblScore.Text.Append("+");
6.   }
7. }
8.  

This prints character's frame value on label, and adds "+" only if it's particular frame.

[proximity]

Of course, I will check the frames with label to see If they are right and share the results. May be other things cause this. Did you change something in the global script page? I don't have deep knowledge but I feel something is not right about scripting.

[proximity]

I checked the frames with GUI label and everything looks normal. Probably I messed something in repeatedly_execute. So forget about Char.Frame

[Crimson Wizard]

In theory there is only one big feature left for me to complete, so I will hopefully find more spare time soon and begin fixing all the reported problems.

[Crimson Wizard]

Hello Crimson. There are serious problems with the engine:

* Object or character images on the room seem bigger than original size, like two times bigger.(in the editor).

I am trying to replicate this now, and it does not seem to happen to me.

Does this still happen to you? Can you tell more details about this, like -
- what is the size of the room;
- what is the actual size of character or object sprite;
- if you choose sprite, what is "Resolution" field sais in its properties?
- do you have any walkable areas with scaling in the room?

[proximity]

Hello Crimson. There are serious problems with the engine:

* Object or character images on the room seem bigger than original size, like two times bigger.(in the editor).

I am trying to replicate this now, and it does not seem to happen to me.

Does this still happen to you? Can you tell more details about this, like -
- what is the size of the room;
- what is the actual size of character or object sprite;
- if you choose sprite, what is "Resolution" field sais in its properties?
- do you have any walkable areas with scaling in the room?

Sorry for the late response. The bug occured when I first create an object or a character in a room. After closing and reloading the project, the sprites look normal now. I tried small and big sprites. The room is a wide scrolling room, 13000*1080. Sprites are all "high" resolution on the properties. Walkable area scaling is 70% but the characters and objects don't stand on it.