Help test new features (no limits + room layers)- experimental version

Started by tzachs, Mon 01/12/2014 01:55:02

Previous topic - Next topic

tzachs

WARNING: This is an experimental version.
DO NOT USE IT FOR ACTUAL PRODUCTION OF YOUR GAME.
If you do use it, at least BACKUP YOUR PROJECT first.


This is an experimental version with some new features, which I need help testing.

The features:

- No Limits (almost)

This feature (developed by Crimson Wizard) enables you to use walkable areas/walk-behinds/hotspots/regions
up to a limit of 256 (imposed by the 8-bitness of the area mask in AGS).
To accomodate this feature, there were UI changes that had to be made, and these are integrated in the new
room layers UI.

- Room Layers

This feature allows you to view (and edit) walkable areas/walk-behinds/hotspots/regions/characters/objects/edges
in the same time (as opposed to only seeing one of them at a time, like we've seen before).
Well, not entirely though: walkable areas/walk-behinds/hotspots/regions still can't be seen together (as
they use masks and is part of the natives dll so I skipped it for now) but they can be seen along objects, characters,
and edges.

- Visibility

Each layer can be made visible/hidden by the push of a button.
In addition, for the objects/characters/edges layers each item in the layer can also be made visible/hidden by the push of a button.
This will only affect the editor, not the actual game.

- Locking

Each layer can be locked/unlocked by the push of a button.
In addition, for each layer, each item in the layer can also be locked/unlocked by the push of a button.
A locked item cannot be moved until it is unlocked, useful to prevent mistakes when designing the room.
This will only affect the editor, not the actual game.


How to use these features:

All those goodies can now be accessed from the layers navigation bar, seen here:



The navigation bar is a breadcrumbs control and should be familiar to whoever uses Windows Explorer (from Vista onwards) or Mac Finder.
Selecting the arrow next to the "Room" label will open a drop down with all the layers.
Each one of the layers has two buttons, a lock/unlock button and a show/hide button (the "eye" image).
In the image above, the characters, objects and hotspots are visible, and the characters are also locked.


Another example, here the walkable areas and characters are visible, and the characters are also locked.

Selecting one of the layers will add it to the navigation bar, and then clicking the arrow next to the layer
will show all the items in the layer.


For example in the image above we selected the objects layer which showed us all the objects.
We can see that the piano object is hidden even though the objects layer is visible. Also,
a few of the objects are locked meaning we can't actually select and move them.

Here's an example of when selecting one of the "masked" layers:


Here we selected the hotspots layer which showed us all of the hotspots. While we can't show/hide
specific hotspots, we can lock/unlock them.
Also the last button in the drop down is "Add New..." which allows us to add more hotspots (with no limits!).
There's also a delete button appearing on the last item (hBone in this example) allowing us to delete it.


Additional points of interest:

- Selecting a layer automatically makes it visible (though it can still be hidden after selection).
- Setting one of the "masked" layers to be visible will automatically hide the rest of the "masked" layers.
- The list box in the properties pane is now redundant as we can select the items from the navigation bar. I've kept it for now, but maybe it should be removed in future versions.
- The images were drawn by me. If anybody wants to create better images, here's what required:
Eye open, eye closed, lock open, lock closed and delete. The images should be 15x15 (png with transparency).
- For the "masked" layers, we only allow to delete the last item. Allowing to delete one of the items in the middle is a problem since we
don't want to change the IDs of the items (they can be used by the game developers).
- A possible enhancement in the future is to add drag & drop support to allow changing the ordering of the layers (and have walkable areas to appear
in front of characters, for example).
- Since the navigation bar is basically a horizontal representation of a tree, it will theoretically allow us to develop a feature that will allow
us to "group" multiple items (can be useful for example, to create composite objects).

All feedback will be appreciated.

Crimson Wizard

Oh yes. :D

This covers not only area editing, but also custom layers visibility

Tzachs, is there a source code somewhere, just in case?

NOTE: I believe this is based on this 2013th experimental version: http://www.adventuregamestudio.co.uk/forums/index.php?topic=48629.0

Quote
This feature (developed by Crimson Wizard) enables you to use walkable areas/walk-behinds/hotspots/regions
to your heart desire, without any limitation on the number of the items.
There's a limit of 256 areas imposed by the 8-bitness of the area mask in AGS.

tzachs

Quote from: Crimson Wizard on Mon 01/12/2014 08:36:51
There's a limit of 256 areas imposed by the 8-bitness of the area mask in AGS.
Thanks, fixed the description.

Quote from: Crimson Wizard on Mon 01/12/2014 08:36:51
Tzachs, is there a source code somewhere, just in case?
Well, I was planning to commit once I see there aren't any critical issues.
If you're waiting for it though, I can commit now, let me know.

homelightgames

This unexpected error threw when I tried to start AGSEditor.exe.  After clicking OK, the splash screen just remained until I ended its task.

I'm using Windows 7 x64.

Even still, I'm really looking forward to a limitless AGS, so thank you for your work.

visionmind


Crimson Wizard

Quote from: tzachs on Tue 02/12/2014 02:31:12
Quote from: Crimson Wizard on Mon 01/12/2014 08:36:51
Tzachs, is there a source code somewhere, just in case?
Well, I was planning to commit once I see there aren't any critical issues.
If you're waiting for it though, I can commit now, let me know.

...please don't tell there's no change history, but just one huge blob of modified code :~(
You could use a personal repository on github to keep all your work before merging it with central repository. This way anyone could also see this work and find any potential conflicts prior to the merge.



Regarding visionmind's problem, idk why, but this package includes debug version of AGS.Native.dll.
Try replacing with the one from this package: http://www.mediafire.com/download/x12ib6wi48x53vc/AGS_3_4_0_alpha2_2014jan01.7z

tzachs


homelightgames

Yes, I was able to get into the editor, so that worked (thanks Crimson Wizard).
But I then tried to create my own test game using the standard BASS template, changed the resolution to 640x400, changed from 16 bit color to 32-bit color, and changed from using DirectDraw5 to Direct3D 9. I then added some of my own backgrounds into the first room's background, replacing the template background.  When I tried to run the test, I got two critical errors (it wouldn't let me run the game)

This was the first one.


After clicking OK I got this one


Also, when I tried to change/add backgrounds it gave me another error:


Unfortunately when I tried to save my demo game the program crashed.

Sorry, I'm not sure how much that will help.

Good luck,

visionmind


Crimson Wizard

Ok, testing & fixing is a must. I must also check if the AGS.Native I suggested to use is actually compatible. I will give it a try on these weekends perhaps.

Quote from: tzachs on Fri 05/12/2014 02:11:59
Source code is here:
https://github.com/tzachshabtay/ags/commit/45010f27e6b66ecf92c30787fb7d07ed6b636946
Thank you, I'll check these too.
I don't think I will have anything to say regarding C# code, I am rather worried about overall commit contents.

tzachs

Thanks, visionmind.

Quote from: Crimson Wizard on Fri 05/12/2014 08:58:57
I don't think I will have anything to say regarding C# code, I am rather worried about overall commit contents.
If it helps, a lot of the changes are because I moved files to a different folder, and it seems that git doesn't know how to compare these changes, so it shows it as one deleted file and one added file (quite surprising actually, in TFS it knows to tag it as a "file rename" and shows the file differences as expected).

Crimson Wizard

I apologize for delay; I've got lost of things on me before the end of the year, also the approaching holiday times do have an impact :-D. Sorry.
I think I will be testing this more extensively at the beginning on the next year.


I've rebuilt AGS.Native.dll precisely for the Tzach's state of the Editor, just in case:
http://www.mediafire.com/download/rcubqj7n7k878rv/tzachs_roomeditor_AGS.Native.zip


Quote from: tzachs on Sat 06/12/2014 02:20:03
If it helps, a lot of the changes are because I moved files to a different folder, and it seems that git doesn't know how to compare these changes, so it shows it as one deleted file and one added file
Well, this is not a problem really.

Regarding the commit in general, there are few things I'd like to mention.

1. The binary files.
Some times ago we made a rule to stop uploading binaries to repository. Small resource files (like toolbar icons) are OK, but the compiled binaries (exe, libs) are not. Git system does not compress binaries very well, and if these are updated often (like AGS.Native) the accumulated size of all versions of these files become the main factor on repository size; this seem to annoy people.

I must admit that we did not make good decision on where to keep these files instead. Monkey_05_06 has a bitbucket account, which lets to store binaries separately from Git repo. That mught be an option. Another option is a shared team file hosting, like dropbox.
I suggest we think this over and come to some decision now.

2. The commit structure.
Earlier I summarized a convention on our branching and commit methology:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=50001.msg636481071#msg636481071
http://www.adventuregamestudio.co.uk/forums/index.php?topic=50001.msg636481384#msg636481384

In a nutshell, the main idea is to make a separate commits for irrelevant changes. This also may be beneficial to separate changes between two or more commits even if they are relevant in whole, but present a finished modifications on their own.
I apologize if this sounds confusing, my English is not perfect... To say this with other words, - if a some change to the code can logically exist on its own (without the rest of the changes) - it may have sense to put it in a separate commit.

I did not examine the code much, and I can't tell what is the relation between most of these changes, so I'd leave this up to you.

3. The redundant changes
I would question if you really need Editor/AGS.Native/NativeDLL.sln in this commit?

monkey0506

Quote from: tzachs on Sat 06/12/2014 02:20:03git doesn't know how to compare these changes, so it shows it as one deleted file and one added file (quite surprising actually, in TFS it knows to tag it as a "file rename" and shows the file differences as expected).

In my experience, once I actually commit a renamed file (and git permanently tracks that particular change), then git should be able to detect that the file is 95% the same (or what-have-you) just with a different name, and it can properly track it as a rename. I used a git repo for my final project at school, and this was the behavior that I observed.

I've also noticed that recently (new computer) I have a lot of superfluous changes to solution files (namely, AGSEditor.sln). I've tried to keep a closer eye on the changes I'm actually making and when I have a diff that I didn't make then I don't add it to the commit. From what I recall, the AGS.Native assembly also changes frequently, even without source code changes.

tzachs

The NativeDll.sln and the binaries were added by mistake, they will not be a part of the actual commit.

Regarding the commit structure, I agree completely. It's a little late for this commit, but I'll do this for future commits.

Quote from: monkey_05_06 on Mon 22/12/2014 19:27:01
In my experience, once I actually commit a renamed file (and git permanently tracks that particular change), then git should be able to detect that the file is 95% the same (or what-have-you) just with a different name, and it can properly track it as a rename. I used a git repo for my final project at school, and this was the behavior that I observed.
Well, it is committed though, isn't it? It's committed to my personal repository, so it is tracked by git and should exhibit the same behavior, or am I wrong?
Anyway the files were not only renamed, but moved to a different folder, so maybe that's why it didn't detect that it's the same file.

Gurok

I am sorry for bumping this really old thread. I was wondering what the status of this room layer patch is now. I had a partially complete patch a while ago to expose the locked property of GUI controls to room objects as well. When I saw this thread, I put it away, not wanting to make changes if a big patch was coming in to fix everything. Is it still coming?
[img]http://7d4iqnx.gif;rWRLUuw.gi

Crimson Wizard

Quote from: Gurok on Mon 25/01/2016 14:22:28
I am sorry for bumping this really old thread. I was wondering what the status of this room layer patch is now. I had a partially complete patch a while ago to expose the locked property of GUI controls to room objects as well. When I saw this thread, I put it away, not wanting to make changes if a big patch was coming in to fix everything. Is it still coming?

The problem is that this change was supposed to be complementary to old experimental version with object limit removal. Unfortunately that version is no longer developed or supported, and idea was to gradually move the successful of those old experimental features to "proper" branch (I partially did that in 3.4.0).

Another thing is that this feature is made as one huge commit, which goes against our convention to make clearer history of changes, and contains unnecessary (binary) files.

In short, I think that we may use your patch at the time being, and take the new interface suggested by Tzachs in some of the future versions.

Crimson Wizard

In an attempt to revive this, here is the ORIGINAL version of this Editor:
https://www.dropbox.com/s/wo75ld7oy4w2w0r/AGSEditor-NewRoomEditor-3.3.0.zip?dl=0

IMPORTANT: content-wise it roughly corresponds to AGS 3.3.0, but there may be incompatibilities. For that reason I did not add any engine executable. You may try adding any engine yourself (even one from AGS 3.4.1) but I cannot guarantee that the games made with this editor will run.

The purpose of this build is testing the Room Editor only!
Create a new project using provided templates, or open any old project made with e.g. AGS 3.2.1 or 3.3.0.

Meanwhile, I am trying to rebuild this editor feature based on up-to-date AGS.


FYI,
Original tzach's code may be found in his repository, branch called "develop":
https://github.com/tzachshabtay/ags/tree/develop
single commit: https://github.com/tzachshabtay/ags/commit/45010f27e6b66ecf92c30787fb7d07ed6b636946

My WIP branch to recreate this (currently does not compile): https://github.com/ivan-mogilko/ags-refactoring/tree/restore--tzachs-editor-features

Crimson Wizard

A new version made on top of latest master branch. This should be 3.4.1-compatible (but not necessarily vice-versa, so do not use with real game project yet).

https://www.dropbox.com/s/v51a5q7df4xrxxh/AGSEditor-NewRoomEditor-3.4.1.zip?dl=0

I only made a very quick test to see that new GUI is at least working. So expect there may be crashes, etc.

Another thing to keep in mind - this version does NOT have areas limits raised to 256, so there are still same limits as in current AGS.

Crimson Wizard

Added in the WIP release: http://www.adventuregamestudio.co.uk/forums/index.php?topic=55829.0

I would like to close this thread, because it was started years ago. Maybe create a new one for further discussion (if necessary).

SMF spam blocked by CleanTalk