Author Topic: AGS 3.5.0 - alpha 7 - next WIP version  (Read 19152 times)

bx83

  • Get 'Er Doooooone
Re: AGS 3.5.0 - alpha 6 - next WIP version
« Reply #180 on: 01 Nov 2018, 09:49 »
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

  • Local Moderator
  • AGS Project Tracker Admins
    • Best Innovation Award Winner 2013, for spearheading the AGS 3.3.0 project
    •  
    • Lifetime Achievement Award Winner
    •  
    • Crimson Wizard worked on a game that was nominated for an AGS Award!
      Crimson Wizard worked on a game that won an AGS Award!
Re: AGS 3.5.0 - alpha 6 - next WIP version
« Reply #181 on: 01 Nov 2018, 10:33 »
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.
« Last Edit: 01 Nov 2018, 23:26 by Crimson Wizard »

Re: AGS 3.5.0 - alpha 6 - next WIP version
« Reply #182 on: 03 Nov 2018, 17:35 »
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.
Proximity Entertainment

Crimson Wizard

  • Local Moderator
  • AGS Project Tracker Admins
    • Best Innovation Award Winner 2013, for spearheading the AGS 3.3.0 project
    •  
    • Lifetime Achievement Award Winner
    •  
    • Crimson Wizard worked on a game that was nominated for an AGS Award!
      Crimson Wizard worked on a game that won an AGS Award!
Re: AGS 3.5.0 - alpha 6 - next WIP version
« Reply #183 on: 03 Nov 2018, 17:59 »
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?

Re: AGS 3.5.0 - alpha 6 - next WIP version
« Reply #184 on: 03 Nov 2018, 18:09 »
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 Entertainment

Re: AGS 3.5.0 - alpha 6 - next WIP version
« Reply #185 on: 03 Nov 2018, 18:23 »
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
Proximity Entertainment

Crimson Wizard

  • Local Moderator
  • AGS Project Tracker Admins
    • Best Innovation Award Winner 2013, for spearheading the AGS 3.3.0 project
    •  
    • Lifetime Achievement Award Winner
    •  
    • Crimson Wizard worked on a game that was nominated for an AGS Award!
      Crimson Wizard worked on a game that won an AGS Award!
Re: AGS 3.5.0 - alpha 6 - next WIP version
« Reply #186 on: 03 Nov 2018, 18:50 »
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.

Re: AGS 3.5.0 - alpha 6 - next WIP version
« Reply #187 on: 03 Nov 2018, 19:39 »
Understood. I can test it after fix if you need me.
Proximity Entertainment

Crimson Wizard

  • Local Moderator
  • AGS Project Tracker Admins
    • Best Innovation Award Winner 2013, for spearheading the AGS 3.3.0 project
    •  
    • Lifetime Achievement Award Winner
    •  
    • Crimson Wizard worked on a game that was nominated for an AGS Award!
      Crimson Wizard worked on a game that won an AGS Award!
Re: AGS 3.5.0 - alpha 6 - next WIP version
« Reply #188 on: 04 Nov 2018, 00:28 »
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.
« Last Edit: 04 Nov 2018, 00:31 by Crimson Wizard »

Re: AGS 3.5.0 - alpha 6 - next WIP version
« Reply #189 on: 04 Nov 2018, 10:11 »
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 :)
Proximity Entertainment

Crimson Wizard

  • Local Moderator
  • AGS Project Tracker Admins
    • Best Innovation Award Winner 2013, for spearheading the AGS 3.3.0 project
    •  
    • Lifetime Achievement Award Winner
    •  
    • Crimson Wizard worked on a game that was nominated for an AGS Award!
      Crimson Wizard worked on a game that won an AGS Award!
Re: AGS 3.5.0 - alpha 7 - next WIP version
« Reply #190 on: 05 Nov 2018, 09:46 »
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
« Last Edit: 05 Nov 2018, 10:13 by Crimson Wizard »

Re: AGS 3.5.0 - alpha 7 - next WIP version
« Reply #191 on: 12 Nov 2018, 22:53 »
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.
Proximity Entertainment

Crimson Wizard

  • Local Moderator
  • AGS Project Tracker Admins
    • Best Innovation Award Winner 2013, for spearheading the AGS 3.3.0 project
    •  
    • Lifetime Achievement Award Winner
    •  
    • Crimson Wizard worked on a game that was nominated for an AGS Award!
      Crimson Wizard worked on a game that won an AGS Award!
Re: AGS 3.5.0 - alpha 7 - next WIP version
« Reply #192 on: 12 Nov 2018, 23:14 »
* 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?
« Last Edit: 12 Nov 2018, 23:19 by Crimson Wizard »

Re: AGS 3.5.0 - alpha 7 - next WIP version
« Reply #193 on: 13 Nov 2018, 12:43 »
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.
Proximity Entertainment

Crimson Wizard

  • Local Moderator
  • AGS Project Tracker Admins
    • Best Innovation Award Winner 2013, for spearheading the AGS 3.3.0 project
    •  
    • Lifetime Achievement Award Winner
    •  
    • Crimson Wizard worked on a game that was nominated for an AGS Award!
      Crimson Wizard worked on a game that won an AGS Award!
Re: AGS 3.5.0 - alpha 7 - next WIP version
« Reply #194 on: 13 Nov 2018, 13:53 »
* 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.
« Last Edit: 13 Nov 2018, 14:19 by Crimson Wizard »

Re: AGS 3.5.0 - alpha 7 - next WIP version
« Reply #195 on: 13 Nov 2018, 14:53 »
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 Entertainment

Re: AGS 3.5.0 - alpha 7 - next WIP version
« Reply #196 on: 13 Nov 2018, 15:26 »
I checked the frames with GUI label and everything looks normal. Probably I messed something in repeatedly_execute. So forget about Char.Frame :smiley:
Proximity Entertainment

Crimson Wizard

  • Local Moderator
  • AGS Project Tracker Admins
    • Best Innovation Award Winner 2013, for spearheading the AGS 3.3.0 project
    •  
    • Lifetime Achievement Award Winner
    •  
    • Crimson Wizard worked on a game that was nominated for an AGS Award!
      Crimson Wizard worked on a game that won an AGS Award!
Re: AGS 3.5.0 - alpha 7 - next WIP version
« Reply #197 on: 16 Nov 2018, 14:39 »
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

  • Local Moderator
  • AGS Project Tracker Admins
    • Best Innovation Award Winner 2013, for spearheading the AGS 3.3.0 project
    •  
    • Lifetime Achievement Award Winner
    •  
    • Crimson Wizard worked on a game that was nominated for an AGS Award!
      Crimson Wizard worked on a game that won an AGS Award!
Re: AGS 3.5.0 - alpha 7 - next WIP version
« Reply #198 on: 03 Dec 2018, 17:53 »
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?

Re: AGS 3.5.0 - alpha 7 - next WIP version
« Reply #199 on: 07 Dec 2018, 21:15 »
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.
Proximity Entertainment