[Cancelled] AGS 3.4.0 Early Alpha [many limits removed]

[GarageGothic]

Ok, might give it a run anyway. Was trying to get back into Shadowplay and hoping to do a widescreen version, hard to figure out which versions are compatible . we're aiming at a tablet port.

[Crimson Wizard]

Ok, might give it a run anyway. Was trying to get back into Shadowplay and hoping to do a widescreen version, hard to figure out which versions are compatible . we're aiming at a tablet port.

Is there a reason why you want exactly this build? Unless you really need increased object limits, I can't recommend to use it, because it is yet to be thoroughly tested.

[GarageGothic]

No, just thought the most recent alpha might have something related to resolution. Been hoping for 16:9 support since AGS 2.7 or something like that, hope to see it in a release build eventually
Would like to try the increased regions/walkable areas though. Been using betas and sometimes alphas throughout development. I understand there's some major changes in this version with the infinite limits so probably hold off until it's in beta.

[monkey0506]

Hey CW, in roominfo.cpp, around line 500, you have the following:

Code: cpp

    if (LoadedVersion >= kRoomVersion_240)
    {
        WalkAreaCount = in->ReadInt32();
    }
    else
    {
        WalkAreaCount = LEGACY_MAX_ROOM_WALKAREAS;
    }

Shouldn't that be checking against 3.4.0 Alpha, not AGS 2.4? It's really bugging me.

I'm pretty sure it was just a typo (in the multiple thousands of lines of code you've written, I can forgive a few ). Just wanted to confirm. Thanks!

[Crimson Wizard]

Hey CW, in roominfo.cpp, around line 500, you have the following:

Code: cpp

    if (LoadedVersion >= kRoomVersion_240)
    {
        WalkAreaCount = in->ReadInt32();
    }
    else
    {
        WalkAreaCount = LEGACY_MAX_ROOM_WALKAREAS;
    }

Shouldn't that be checking against 3.4.0 Alpha, not AGS 2.4? It's really bugging me.

I'm pretty sure it was just a typo (in the multiple thousands of lines of code you've written, I can forgive a few ). Just wanted to confirm. Thanks!

No, it's correct.
I transferred this code from 3.3.0 which did not have any references to 3.4.0; and the code originates from earlier versions.
You may check CJ's last engine code from SVN (acroom.h, 1838):

Code: cpp

  int num_walk_areas = MAX_WALK_AREAS;
  if (rfh.version >= 14)
    num_walk_areas = getw (opty);

[monkey0506]

Okay, no worries. I just thought it was related to your removal of the limits. Thanks for clearing that up though.

[Shane 'ProgZmax' Stevens]

This has been a long time coming but it's great to finally see it happen!

[Icey]

Yessss!!! he did it I'll wait to this is solid or rather a bit stable but be using this at some point :3

Sorry I'm so late, I just noticed this.

[Crimson Wizard]

I will probably be merging recent fixes to the editor from 3.3.0 branch soon, just want to track that evil crash on room load first, it seem to happen too often.

[Knox]

Does this build have the experimental resolution options=? Tried the widescreen variant the other day.

No.

I'm currently in the process of transferring my game to this early alpha version (hope its not "too early" to do that) since I really need to use the no-limits feature. Since I have to redo a lot of stuff (replacing old hacks to get around the limits), I figured, why not upgrade my resolution to 1280x720 at the same time (I was going to do that eventually anyways)...

I know you are super busy and all, but theoretically speaking how "hard/long" would it be to integrate the new resolutions (or atleast just one new addition of 1280x720) into this early alpha (3.4)?

[Crimson Wizard]

I know you are super busy and all, but theoretically speaking how "hard/long" would it be to integrate the new resolutions (or atleast just one new addition of 1280x720) into this early alpha (3.4)?

Thing is that I do not want to make "only one addition". I am totally against such approach. I know it is very much wanted, but it is really bad for the program, which already is cluttered with quick-additions and hacks (and these are the reason why it takes so long to add new stuff).

I started looking into the custom resolutions some time ago, but was distracted. So far I made custom display resolutions build: http://www.adventuregamestudio.co.uk/forums/index.php?topic=47344.msg636462609#msg636462609
(which still needs few fixes).
I am not that busy now, I may consider trying again; just need to gather my thoughts, as they say.

[Knox]

Ok that makes sense. I think I'll just wait for custom resolutions to be properly integrated into a stable build before upgrading to 1280.

[Crimson Wizard]

Hmm, I am scratching my head; I spent 30 minutes to make an experimental build with 1280x720 resolution, and haven't seen any problems except for some glitches related to zooming in the room editor. Unless I am missing something terrible, this (adding custom resolutions) might be easier than I expected.
I will return to this in a short while.

E: I used the build with free display modes I made earlier, so that could simplify things too.

[Knox]

Hmm, I am scratching my head; I spent 30 minutes to make an experimental build with 1280x720 resolution, and haven't seen any problems except for some glitches related to zooming in the room editor. Unless I am missing something terrible, this (adding custom resolutions) might be easier than I expected.I will return to this in a short while.

[Ali]

I hope adding custom resolutions does turn out to be easier than you expected!

That said, I do agree with avoiding a hack for one particular resolution (even one as desirable as 1280x720). I think it would be ideal if the designer could choose any frame size/shape (within reason) and the engine would scale it to a resolution appropriate for the player's monitor - adding letterboxing or sidebars as necessary.

[Peder 🚀]

I think the best way to manage modules would be a central database and people get the modules from there via a GUI like NuGet or the Firefox Add-on System.

This does indeed sound like a really nice solution. If the current people developing AGS would be interested in adding such a feature count me in to help any way I can .

[Ali]

Hmm, I am scratching my head; I spent 30 minutes to make an experimental build with 1280x720 resolution, and haven't seen any problems except for some glitches related to zooming in the room editor. Unless I am missing something terrible, this (adding custom resolutions) might be easier than I expected.
I will return to this in a short while.

E: I used the build with free display modes I made earlier, so that could simplify things too.

I just wanted to follow up on the progress with custom resolutions. Is there anything a non-programmer could do to support this aspect of development? I'd be keen to help test any experimental builds which appear, for instance.

Sorry if this sounds like hassling, I just want to keep encouraging this!

[Crimson Wizard]

I just wanted to follow up on the progress with custom resolutions. Is there anything a non-programmer could do to support this aspect of development? I'd be keen to help test any experimental builds which appear, for instance.

Sorry if this sounds like hassling, I just want to keep encouraging this!

Okay, here's the test build with 1280x720 resolution I made by Mehrdad's request (he wanted it really bad)
http://www.mediafire.com/download/z52tkkuynk8z3sb/AGS_3_3_0_customres_test.zip

This build is a combination of:
AGS 3.3.0 beta 7 +
Custom display resolutions build +
1280x720 resolution may be selected in the Editor.

WARNING! not thoroughly tested. Code-wise it potentially supports any resolution, but I did not have time to make a proper setup yet, so you can only set 1280x720 in the project settings. Also WinSetup displays incorrect information on resolution (this should not have any impact on gameplay).

I am working further on this in my free time, but there are few improvements to the internal engine architecture (mostly gfx filters/renderers) I want to make first, so it will take some more time.

[Ali]

Wow! I played around and found it worked surprisingly smoothly. Incidentally, I love the moveable tabs in 3.3.0!

The biggest problem I encountered was the graphics failing to initialise when running in windowed mode with the resolution set to 1280x720 or less. Would I be right in thinking recent developments should make it possible to scale the window down to fit lower resolutions?

Apart from that, the most notable problem was tearing in full screen. This was very, very distracting. I think VSync for D3D would be essential for decent looking high-res. Is that a realistic possibility? Weirdly, I didn't see any tearing in windowed mode (even at resolutions where the window virtually filled the screen).

Apart from wanting to see this develop further, it would be useful to add an export option for walkable areas / regions and hotspots to make scaling up an existing game easier. I did this using CRM tools and Photoshop for scaling. But CRM tools doesn't work properly for higher resolutions and it takes a bit of fiddling.

[Mehrdad]

Thanks again CW
on 1280x720:
I can't Quit game GUI center on screen.i seems doesn't fit.