AGS 3.5.0 - alpha 13 - next WIP version

Started by Crimson Wizard, Wed 21/02/2018 13:52:21

Previous topic - Next topic

cdavenport

#200
Quote from: Crimson Wizard on Mon 03/12/2018 17:53:27
Quote from: proximity on Mon 12/11/2018 22:53: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?

This just happened to me too, yesterday I began working with my game in the new engine and this morning in one of the rooms the objects and Characters were showing two-or-more sizes bigger than they were created at, in the room editor pane. I took a screenshot but I don't have a different site to host it on yet so I can link it up here. It seemed to occur after I imported a bunch of sprites to create an object animation, and deleted some old ones, then running the game to test it. I think it occurred after I ran the game, and when I went back to the editor, somehow the sprites were showing in the editor enlarged like they do when you run the game and it scales them up. I checked other rooms, and the objects, ect. in those too were two to three times bigger in the editing pane as well. Then I exited, and restarted the engine and everything went back to normal for the time being.

May game's resolution is 640x360 and I've begun using the latest AGS 3.5.0 which I got from the first page in this thread.

UPDATE: It was working fine after restarting, but after I began fiddling around by moving Objects and Characters around on screen (changing X,Y, coordinates to position them here and there) and testing the game repeatedly, it happened again and now all the objects and characters are enlarged two to three times again in the editor pane making it impossible to work on.

UPDATE 12-11-2018: This bug happens consistently for me, after I import some sprites, assign them a view, and then place an object in a room using the sprites I just imported, when I return to the room editor most of the time everything is blown up in size against the background, as in previous posts. Saving the game and then restarting the engine fixes it until I have to do those steps again. It doesn't seem to happen every single time I do those steps, but quite often.

My room sizes are 640x360. The size of the object or sprite is always different, depending on what I import. Resolution of sprites is High (above 320x240). All of my rooms have Walkable areas with different scaling factors.

Crimson Wizard

#201
Hmm, so I was trying to reproduce this object scaling bug you were talking about, and so far the only time I was able to get anything similar was when I zoomed out room very far, then small objects were scaling down at first but after certain zoom threshold they became larger instead. Idk if it's the same situation as you had but hopefully there is something common there. I will investigate this now, as well as the slowdown problem.

UPD: I've fixed few errors I found so far, and will be preparing new update soon, it will contain some major stuff...

cdavenport

Quote from: Crimson Wizard on Mon 17/12/2018 17:09:57
Hmm, so I was trying to reproduce this object scaling bug you were talking about, and so far the only time I was able to get anything similar was when I zoomed out room very far, then small objects were scaling down at first but after certain zoom threshold they became larger instead. Idk if it's the same situation as you had but hopefully there is something common there. I will investigate this now, as well as the slowdown problem.

For me, the object scaling issue always occurs after importing new sprites and assigning them a view. Most of the time the sprites are large, and there's a large number of them (up to 100 at times). Whenever I do that, I have to close and restart to be able to continue to work. I log hours daily working on the engine and this is the only issue that's come up from me.

Crimson Wizard

#203
I am still looking into this scaling bug reported above, but there are two major features completed recently, and we needed to post a new update to let people test them.



AGS 3.5.0 - Alpha 8

This update include two new major features:

1) New revamped sprite import dialog. We would really like to have a feedback on this.
2) Custom room viewport & camera script commands that let you configure position and scaling of your room on game screen.


Zip archive: http://www.mediafire.com/file/6bak3fncw1dg3ef/AGS-3.5.0-alpha8.zip/file


Editor:
- Game and room templates are now by default saved in AppData/Local/AGS folder. Editor finds them in both program folder and AppData.
- New revamped sprite import window.
- Sprites that were created using tiled import can now be properly reimported from source.
- Allow room size to be smaller than the game's resolution.
- Fixed wrong game may be loaded from Recent Games list if one of them was deleted in the past.
- Fixed crash when creating room template after doing full game rebuild or just after creating new game.
- Fixed room editor working very slow after new zooming slider was introduced (should be about as fast as before now).
- Fixed room sprites did not draw scaled down with zoom < 100%.
- Fixed GUI or Room editors sometimes allowed to scroll beyond necessary limits.
- Fixed translations were not available for the test run if game was not fully rebuilt yet.
- Fixed Windows Explorer was sometimes locking the game files during compilation.
- (Probably) fixed crash on Editor shutdown.

ScriptAPI:
- Implemented Viewport and Camera script classes which control how room is displayed on screen.
- Added properties Game.AutoSizeViewportOnRoomLoad, Game.RoomViewport, Room.Camera.

Engine:
- Fixed new pathfinder was crashing if target location lies beyond room borders.
- Fixed old-style string functions like StrCopy could crash the game if user managed object's member is passed as an argument into them.
- Fixed 8-bit sprites could have broken colours if game is run using Direct3D or OpenGL.
- Fixed broken colours during fade-in and fade-out in 16-bit games.



KNOWN ISSUES:
- Some weird sprite scaling bug in the room editor, described in the posts above. According to user reports it may be fixed by restarting the editor.





How to use room viewport commands in script.

This requires proper documentation, but for a short explanation:

Viewport is a place on screen where room is drawn, defined in game coordinates (e.g. 0,0 - 320x200).
Camera is a place in room which is being drawn. Camera size may be determined in two ways:
a) explicitly setting Width and Height, which tells actual rectangle in the room;
b) setting ScaleX and ScaleY properties to automatically adjust displayed room relative to the viewport's size.
For example, if you set ScaleX/Y to 2.0, then room will appear zoomed in twice as large as the viewport's size. If you set ScaleX/Y to 0.5, it will appear twice as small (zoomed out).
NOTE: you cannot set camera size larger than the room's background.

To access viewport and camera use new properties: Game.RoomViewport and Room.Camera.
Game.AutoSizeViewportOnLoad boolean value turns automatic viewport adjustment on room load. It is ON by default which corresponds to normal room view you are used to.

Old viewport functions are now deprecated, they may still be enabled if you set "Script compatibility level" to v3.4.1 or lower.
Here's correspondence between old and new functions:

* SetViewport(x, y); ===> Room.Camera.X = x; Room.Camera.Y = y; Room.Camera.AutoTracking = false;
* ReleaseViewport(); ===> Room.Camera.AutoTracking = true;
* GetViewportX(); ===> Room.Camera.X;
* GetViewportY(); ===> Room.Camera.Y;

Basically, as you may see, what was known as "viewport" earlier is now called "camera", and "new viewport" is something that was never supported before.

Crimson Wizard

Something I just realized, although the sprite limit was raised, room objects save the sprite index as 16-bit value which means you cannot assign anything above 32767 to them. This would need an extra fix.

eri0o

#205
I am testing on wine the new sprite import. It feels easier, and apparently works! I like I can by default import a ton of sprites at the same time! This is cool!!!

I like the new progress bar addition, I think previously AGS just stood there unresponsive, in a folder with too many sprites, this is nice.

On the tiled sprite import, one minor thing, it loads with a number in x,y position, I think the default should be 0,0 (imagining I have a single sheet png, with each images of the same size).

The is an option to copy a sprite to the clipboard on the sprite navigator, I don't know if that was there before, but when I click, it does nothing.

Feature requests for the sprite GUI!:

- I have Aseprite triggering as my external editor, and it opens lightning fast, but a way to view and zoom a imported sprite, in AGS, would be cool.
- sprite GUI, has all things available through the right click on white space, adding a small bar on top of the GUI, with the same functions, would easier. I prefer inside the tab instead of the main toolbar like the rest of AGS, but both would work - one favor low resolution monitor and the other bigger resolution monitors.
- totally new feature: import folder -> would import a folder with pngs, and if a folder with png is inside that folder, recreate the folder structure inside AGS. I think is unneeded as project normally evolve slowly but could enable really fast use of ready made graphics from graphic asset packages.

____

Script Compatibility seem kinda broken since BASS template doesn't work anymore.

morganw

Thank you for testing this, eri0o.

Quote from: eri0o on Sat 22/12/2018 14:22:12
I like the new progress bar addition, I think previously AGS just stood there unresponsive, in a folder with too many sprites, this is nice.
To be honest, it was more a debug tool that was left in. It turns out that majority time whilst the Editor was in hung state was spent modifying the GUI control in a loop, and nothing to do with the import actions at all. This should be fixed now, so you should see a massive performance increase as well as the progress bar.

Quote from: eri0o on Sat 22/12/2018 14:22:12
On the tiled sprite import, one minor thing, it loads with a number in x,y position, I think the default should be 0,0 (imagining I have a single sheet png, with each images of the same size).
I think you are right, and just leaving it on 0,0 makes more sense in practice. I'll change it.

Quote from: eri0o on Sat 22/12/2018 14:22:12
The is an option to copy a sprite to the clipboard on the sprite navigator, I don't know if that was there before, but when I click, it does nothing.
I don't think this was modified, but it doesn't seem to work for me either, so I'll have a look.

Quote from: eri0o on Sat 22/12/2018 14:22:12
Feature requests for the sprite GUI!:

- I have Aseprite triggering as my external editor, and it opens lightning fast, but a way to view and zoom a imported sprite, in AGS, would be cool.
- sprite GUI, has all things available through the right click on white space, adding a small bar on top of the GUI, with the same functions, would easier. I prefer inside the tab instead of the main toolbar like the rest of AGS, but both would work - one favor low resolution monitor and the other bigger resolution monitors.
- totally new feature: import folder -> would import a folder with pngs, and if a folder with png is inside that folder, recreate the folder structure inside AGS. I think is unneeded as project normally evolve slowly but could enable really fast use of ready made graphics from graphic asset packages.
Personally, I'm still aiming for just having sprites on the disk, and 'importing' is just defining the import options for each image. So I would hope that the final result would just be a 'project browser' instead of a 'sprite manager', and you could choose some action on any type of file or folder, or hand-off to any external program. I think the toolbar has a lot of issues anyway, in that things magically appear there depending on what you are editing (since they also include the paint controls), and it contains functions that aren't available in any other place (probably makes sense for choosing a paint brush, but not for mask import/export).

Quote from: eri0o on Sat 22/12/2018 14:22:12
Script Compatibility seem kinda broken since BASS template doesn't work anymore.
I tried the one in the archive and it seemed to work. If it was an error for 'ProcessClick' it could have been an older copy of the template that hadn't had the fixes made. I think the plan is to release the final version of 3.5 with the templates from here.

Crimson Wizard

Quote from: eri0o on Sat 22/12/2018 14:22:12
Script Compatibility seem kinda broken since BASS template doesn't work anymore.

Script compatibility is controlled by two switches in the General Settings called "Script API version" and "Script compatibility level". What were they set to and what were the errors?

eri0o

It complained of SetViewport something, but maybe, I had some code from the first iteration of the camera functions. I will try a clean project later.

Crimson Wizard

#209
Quote from: eri0o on Sat 22/12/2018 16:38:50
It complained of SetViewport something, but maybe, I had some code from the first iteration of the camera functions. I will try a clean project later.

SetViewport is a standard AGS function, which is now deprecated. I warned about this in my recent release post: http://www.adventuregamestudio.co.uk/forums/index.php?topic=55829.msg636599086#msg636599086

You may get it back by setting script compat level to 3.4.1.

PS. By the way, I have a thought about changing it slightly once more time in the next update (have Game.RoomViewport moved to something like Screen class).

ArsCreativa

As info that might be useful, I'm testing alpha 8 with my game. I have changed the first "GetViewportX()" the compiler finds for "Room.Camera.X" (which is located in the Tween module), and then I get this message:
"must have an instance of the struct to access a non-static member".

Crimson Wizard

#211
Quote from: ArsCreativa on Mon 24/12/2018 06:41:48
As info that might be useful, I'm testing alpha 8 with my game. I have changed the first "GetViewportX()" the compiler finds for "Room.Camera.X" (which is located in the Tween module), and then I get this message:
"must have an instance of the struct to access a non-static member".

This is true, AGS has a bug that it cannot correctly parse long sequence of "x.x.x" if the second x is a static attribute or function. This is irritating and I am planning to look into fixing this if possible. If not, maybe I even move camera and viewport and make them global variables as a last resort.

For the moment workarounds is:
Code: ags
Camera *c = Room.Camera; something = c.X;

It's possible to write new version of "GetViewportX":
Code: ags
int GetCameraX() { Camera *c = Room.Camera; return c.X; }



Also I am planning on adding few extra functions to camera and viewport which will speed up typing most common commands, like setting X&Y position at once.

eri0o

#212
moved camera questions here

@morganw , the new tiled import GUI is amazing, did the below characters import to view in less then 10 min (find sprite in open game art, import sprite, view, assign view to characters), before importing tiled was a real pain.

Spoiler


[close]

Crimson Wizard

#213
AGS 3.5.0 - Alpha 9

WARNING: there was a major internal modification to the Rooms code. Although I did a lot of testing with existing games and created ones for the test to make sure that everything is working like before, still please make a full backup of your project before upgrading to this version and report if you notice anything wrong with how your rooms are saved and loaded in the editor and run within the game.

WARNING 2: There was a change to recently added Viewports & Cameras script API, with some of the properties REMOVED and some moved to other struct and/or renamed. Keep in mind that you might have to edit your scripts once again. I apologize for this inconvenience.


Zip archive: http://www.mediafire.com/file/xnwsm03opg0g10t/AGS-3.5.0-alpha9.zip/file


Changes since 3.5.0 alpha 8:


Editor:
- Improvements and fixes to the new sprite import dialog. Allowed to drag the tile selection in the up-left direction.
- Added context menu command to open sprite's source file location.
- New sprite export dialog that lets you configure some export preferences, including remapping sprite source paths.
- Display audio clip length on the preview pane without starting playback.
- Fixed room mask export was saving masks as 8-bit PNGs instead of indexed bitmaps (which made them impossible to import back to the room as-is).
- Fixed MIDI audio preview was resetting all instruments to default (piano) after pausing and resuming playback.
- Fixed MIDI audio preview had wrong control states set when pausing a playback.
- Fixed Debug build failed if no Compiled/Windows folder exists (regression).

Script API:
- REMOVED ScaleX and ScaleY properties from Camera.
- Introduced new managed struct Point describing (x,y) coordinates.
- Implemented new Screen struct featuring static Width and Height properties and ScreenToRoomPoint() function.
- Moved AutoSizeViewportOnRoomLoad and Viewport from Game to Screen struct.
- Deprecated System.ScreenWidth, ScreenHeight, ViewportWidth and ViewportHeight in favor of Screen.Width/Height and Viewport.
- Added new functions to Viewport struct: GetAtScreenXY(), SetPosition(), ScreenToRoomPoint(), RoomToScreenPoint().
- Added new functions to Camera struct: SetAt() and SetSize().

Engine:
- Fixed graphic artifacts looking like thin vertical lines around sprites when running OpenGL renderer (aka "texel leaking").
- Fixed a new crash issue with the legacy InventoryScreen() command (appeared in somewhere around 3.4.1).
- Fixed some compilers (e.g. gcc 6.0 on Linux) could instigate a crash in the on_event callback with no loaded room.
- Fixed screen-to-room conversion not updated if viewport's location was changed but size remained the same.
- Fixed software renderer working with 16-bit rooms (regression).
- Fixed Debug(2) and Debug(5) overlays not drawn correctly in custom room viewports (regression).
- Fixed overlays that were positioned relative to the room not displayed correctly (regression).
- Fixed software renderer crashes when switching between fullscreen and windowed modes (regression).



NOTES:

Screen.ScreenToRoomPoint returns null if there is no room Viewport under these coordinates. If there will be multiple viewports supported in the future engine simply won't know which to choose if there's none directly there.
Both Viewport.ScreenToRoomPoint and Viewport.RoomToScreenPoint have 'clipViewport' parameter which tells whether they should return null if the coordinates lie outside of the visible part of the room.



KNOWN ISSUES:

- Some weird sprite scaling bug in the room editor described in the posts above. According to user reports it may be fixed by restarting the editor. Unfortunately I was still unable to reproduce it on my own...

Dualnames

I may be missing the line/function but is there a way to change the color of a listbox (for the selected and the non selected) during run-time. If not, and sorry to ask, but you think it'd be too complicated to implement, it's okay if it is, I'll work around it, just wondering.
Worked on Strangeland, Primordia, Hob's Barrow, The Cat Lady, Mage's Initiation, Until I Have You, Downfall, Hunie Pop, and every game in the Wadjet Eye Games catalogue (porting)

Crimson Wizard

#215
Quote from: Dualnames on Tue 15/01/2019 16:18:35
I may be missing the line/function but is there a way to change the color of a listbox (for the selected and the non selected) during run-time. If not, and sorry to ask, but you think it'd be too complicated to implement, it's okay if it is, I'll work around it, just wondering.

Following was implemented in 3.5.0:
ListBox.SelectedBackColor
ListBox.SelectedTextColor
ListBox.TextColor.

Full list of script additions is under "Script API" section in the first post.

PS. You must have either v3.5.0 or "Highest" set in the "Script API version" option of the General Settings.

Dualnames

Wonderful, will update to this once it's stable!
Worked on Strangeland, Primordia, Hob's Barrow, The Cat Lady, Mage's Initiation, Until I Have You, Downfall, Hunie Pop, and every game in the Wadjet Eye Games catalogue (porting)

Dualnames

#217
Hey, I'm not sure this goes here, so I'm wondering in general, I've implemented an autosave system, but in general, because the game autosaves every time u enter a room, it's causing a 5-10 dps drop and music stutters, is there a good way around this, like the savegame part?

EDIT:

Whenever i comment the autosave code, it fixes the stutter, but the 5 fps frame drop seems to be irrelevant to that.
Worked on Strangeland, Primordia, Hob's Barrow, The Cat Lady, Mage's Initiation, Until I Have You, Downfall, Hunie Pop, and every game in the Wadjet Eye Games catalogue (porting)

cianty

First off, thanks for the continued work, CW!

I have a question: What is the state of compatibility of this version with the iOS port? I am currently using 3.4.0 which works fine and haven't switched to any of the higher versions because they aren't compatible. I think the 3.4.2 thread had an explicit mention about incompatibility but I didn't see anything in the first post here.
ca. 70% completed

Crimson Wizard

#219
Quote from: cianty on Fri 18/01/2019 08:59:04
I have a question: What is the state of compatibility of this version with the iOS port? I am currently using 3.4.0 which works fine and haven't switched to any of the higher versions because they aren't compatible. I think the 3.4.2 thread had an explicit mention about incompatibility but I didn't see anything in the first post here.

Android and iOS were broken in early 3.4.1 release because of changes to OpenGL renderer (so they could not compile). Android was since fixed, but iOS is still not. It may be that fixing iOS is as easy as copying Android fix over, but I cannot tell because I cannot build iOS port myself.

Someone needs to set up iOS building for 3.4.1 and help us find this out.

UPD. The problem was related to Tint and Light level support using shaders when using hardware-accelerated OpenGL renderer. But there's still software mode that should probably work. In the worst case we may simply programmatically exclude the newer code in ha renderer on iOS.

Mobile ports are still big issue because there is no one with good knowledge of Android or iOS to help us fixing and maintaining them.


UPD: So, I've just had a small talk with Janet Gilbert and she reminded me that her own iOS port is different now because they were developing it further separately. This complicates things in a way, because we now have 2 iOS ports and no idea how different they are.

SMF spam blocked by CleanTalk