Messages

Sorry, I don't understand what you're saying. You're saying I need to use allegro.h from libsrc\allegro\include


But I don't need to build Allegro, right? Not even that stripped Allegro? Right?

[ags4]

Trying to build the unit tests (Common.Lib.Test and Engine.app.Test, in solution Tests) of branch ags4
On windows 10 with Visual Studio 2022

Is there a help page? (I don't think so).
I think I need third-party libraries Allegro (4?)  and gtest. Anything else?


PS: Please tell me I can use a prebuilt version of Allegro and that I won't have to rebuild it myself.

EDIT: Created separate theread

Speaking of which;  these 2,3,4 argument sets caught my eye.

Me too; it does not satisfy the dev in me; but right now I'm trying to get rid of the "old" implementation (greedy parser). That, and the fact that the discovered options were applied on the spot using global variables.

When everything works I can factor together the code for 2, 3, 4 params; this was a quick copy-paste fix after realizing that the feature was missing from the new CmdLineOpts

But the default command line options of AGS engine itself requires a lot more flexibility

I simply has options that take more than one argument, I've added 2, 3 and 4 arguments to your mini library.

I've started working on that specific thing : https://github.com/adventuregamestudio/ags/pull/1749/commits

[what do I need to toggle]

I see in main.cpp that there's this main_process_cmdline function to parse command line arguments.
But I also see in cmdlineopts.cpp that the same code has been rewritten in modern c++.

Is the new code supposed to be part of AGS4, and, if yes, what do I need to toggle to enable the new code? Nothing seems to be using CmdLineOpts::Parse.

My bad. It's used by the new compiler. The Engine's startup simply hasn't been updated to use this too.

Strangely enough, this does not happen with the acwin.exe I just built directly from the Visual Studio solution.

I'm currently in a professional environment.
the acwin.exe from AGS AGS-3.5.1.19-P12 triggered the following false positive : https://www.f-secure.com/v-descs/w32_malware.shtml

I've submitted the file to FSecure (by using their dedicated form)  in the hope that their automated heuristics will learn not to flag AGS.

I'm not looking for solutions, just sharing knowledge.

[Building]

I will use this thread to detail every step, one by one -- in the "explain it to me like I'm 5 yo" spirit.


Building

1a. Go to https://github.com/adventuregamestudio/ags
1b. (Note: we will choose the "fork" approach, not just cloning) Click on "fork" in the top right
1c. Untick "copy only the master branch" (because you want branch "ags4")
1d. Let git fork the repo to your very own https://github.com/mygitusername/ags

2a. Create a folder C:\source\ags\ags4
2b. Create a folder C:\source\ags\agslibs

3a. Install Visual Studio 2022
3b. Open VS2022. On the home page, choose "clone a repository"
3c. Repository location : Pick the path that was created earlier : https://github.com/mygitusername/ags.git (you can find it on the github page if you're not sure)
3d. Let VS clone the repo

4a. Inside VS, in the bottom-right of the window, use the dropdown to switch to branch "ags4"
4b. In the "solution Explorer" panel, open Engine.sln
4c. You might get a message from Visual Studio suggesting to let you install extra tools for C++. Let it open the "Visual Studio Installer", and install "Desktop Development with C++". Later, you can still access this with menu Tools-->Get tools and Features...

5a. Clean and rebuild the solution (right-click on the solution)
5b. Do you get error "The Windows SDK 8.1 was not found"? If yes, you need to install this set of libraries, to let your modern OS (windows 10? 11?) work with older C++ for older OS's. Google "install windows SDK 8.1 visual studio 2022". Eventually you'll find this Microsoft page : https://developer.microsoft.com/en-us/windows/downloads/sdk-archive/ Look for the windows 8.1 SDK and install it (it has an installer)

6. Restart your Visual Studio entirely (all windows) -- and even your computer, preferably.

7a. Re-open solution Engine.sln
7b. Build again
7c. Do you get error "MSB8020   The build tools for Visual Studio 2015 (Platform Toolset = 'v140') cannot be found. " ?
     If yes:
    - right-click project "Engine.App"-->"Properties"-->"Configuration Properties"-->"General"-->"Platform Toolset".
    - Click on the dropdown
    - Unfortunately, VS2022 does not let you install exactly the toolset v140. You'd need to revert to an older VS, like VS2017 if I recall.
    - Instead, choose "Visual Studio 2022 (v143)".  (Note: If it says, "not installed" then open the "Visual Studio Installer" and you'll find the toolset in tab "Individual component".)
7d. Repeat for project "Common.lib"

8a. Rebuild solution
8b. do you get error "Cannot open include file: 'crtdbg.h'" ?
      If yes:
      - It means that the projects fail to find the path to the Windows 10 SDK.
      - Check that the SDK is actually installed on your system. To do so, open the Visual Studio Installer and in tab "Individual components" look for Windows 10 SDK (any version).
      - Right-click on project "Engine.App"-->"Properties". Go to "VC++ Directories" as described here.
      - In "Include Directories", dropdown, "<Edit...>"
      - Add the folder fo your latest Windows 10 kit, for example C:\Program Files (x86)\Windows Kits\10\Include\10.0.19041.0 as described here
      - REPEAT FOR PROJECT Common.lib

9a. Rebuild project Engine.App
9b. Do you get error "cannot open include file: 'stddef.h'"?
      If yes :
      - It means that yet another file from the Windows 10 SDK is in a folder where Visual Studio can't find it.
      - Similarly to previous section, add include directory to that file. for example C:\Program Files (x86)\Windows Kits\10\Include\10.0.19041.0\ucrt
      - REPEAT FOR PROJECT Common.ib

10a. Rebuild project Engine.App
10b. Do you get error "Cannot open include file 'SDL.h'" ?
        If yes:
       - It means that you don't have the SDL library.
       - It's time to install all the third-party libraries suggested by the AGS build instructions: SDL 2, theora, ogg, irrKlang, etc.
       - For each library, you'll need to do two steps : 1) get the source (for Visual Studio to find the important .h files) -- that's for compiling 2) get the statically-compiled libraries (.lib files) -- that's for linking
       - You don't need to install them one by one. AGS devs provide you with a ready-made package.
       - Get it from the address found here :  https://github.com/adventuregamestudio/ags/tree/master/Windows#build-requirements
         Direct link to package : https://github.com/adventuregamestudio/ags/releases/download/v.3.6.0.15/WinDevDependenciesVS.zip
         More links to more versions of the package : https://github.com/adventuregamestudio/ags/tags (each release has its own WinDevDependenciesVS.zip file)
       - Unzip WinDevDependenciesVS.zip into C:\source\ags\agslibs (you created that folder at the very beginning)
       - You now have folders such as C:\source\ags\agslibs\SDL2, C:\source\ags\agslibs\irrKlang, etc
       - Next section tells you how to use them

11a. Set include directories to the third-party libraries :
      - Right-click on project "Engine.App"-->"Properties". Go to "VC++ Directories" as described here.
      - In "Include Directories", dropdown, "<Edit...>"
      - Add the folder to SDL2's include files folder (probably C:\source\ags\agslibs\SDL2\include )
      - REPEAT FOR LIBRARY SDL_Sound  (probably  C:\source\ags\agslibs\SDL_sound\src )
      - REPEAT FOR LIBRARY irrKlang
      - REPEAT FOR LIBRARY ogg (contained in Xiph folder)

12a. Rebuild project Engine.App
      - Now the compilation step succeeds, but the next step (linking) fails with error LNK1104   cannot open file 'SDL2.lib'   
      - You need to tell VS where to find the .lib files. It's similar to the previous section, for include files.
      - Right-click on project "Engine.App"-->"Properties". Go to "Library Directories"
      - In "Library Directories", dropdown, "<Edit...>"
      - Add the folder to SDL2's lib files folder (probably C:\source\ags\agslibs\SDL2\lib\x86 ). Notice how you could have chosen folder x64, but I'm almost certain that you're compiling for 32-bits, not 64-bits.
      - REPEAT FOR LIBRARY SDL_Sound  (probably  C:\source\ags\agslibs\SDL_sound\build\Release )
      - REPEAT FOR LIBRARY Lib Ogg (contained in Xiph folder -- probably C:\source\ags\agslibs\Xiph )

13a. Rebuild project Engine.App
13b. Do you get error "LNK1104   cannot open file 'libucrtd.lib'"?
        If yes :
       - again, the Windows 10 could not be found, but this time it's not the .h files, it's the lib files.
       - Repeat steps from before, adding an entry to the "Library Directories" pointing to something like C:\Program Files (x86)\Windows Kits\10\Lib\10.0.19041.0\ucrt\x86 Notice how you could have chosen folder x64 or arm, but I'm almost certain that you're compiling for 32-bits.

12.a Rebuild project Common.lib
        At this point everything compiled fine for me, I didn't need to add more paths to additional include files or .lib files.


Trying it out

1a. In Visual Studio, right-click on project Engine.App and select "set as startup project"
1b. In Visual Studio, click button "Local windows Debugger" at the top of the screen, to run the AGS engine in debug mode.
1c. Do you get error "The code execution cannot proceed because SDL2.dll was not found" ?
      If yes:
     - It means that you need to copy SDL2.dll to the engine's execution folder.
     - the execution folder is where acwin.exe went after you built it.
     - Go to C:\source\ags\Solutions\.build\Debug and locate acwin.exe (If your build was successful, it is present in the folder, and the modified date matches your last build)
     - Get SDL2.dll from the SDl website : https://www.libsdl.org/download-2.0.php then SDL2-2.0.22-win32-x86.zip
     - put it in C:\source\ags\Solutions\.build\Debug

2a. In Visual Studio, click again on button "Local windows Debugger"
2b. do you get error "ERROR: Unable to determine game data"?
     If yes:
     - It means that the AGS engine started successfully, but has no game to run!
     - You need to obtain an AGS game (any game!). Usually they come as a .exe file, but under the hood they really are a .ags file that contains the game data, meant to be run by acwin.exe
     - If you don't have a .ags file handy, follow the next steps to create a dummy game to test.

3a. Create a dummy game data
    - Create folder C:\games\ags
    - Get the most recent version of AGS 3.x (preferably, the .zip file for convenience)
    - Open the Editor
    - Create a new game (e.g. the Sierra template)
    - Create it in C:\games\ags\testgame
    - Build the game
    - Open folder C:\games\ags\testgame\Compiled\Data
    - Observe how it now contains file testgame.ags That is your game for testing

4a. Copy testgame.ags to the engine's execution folder : C:\source\ags\Solutions\.build\Debug
4b. Tell the engine to use it at startup :
      - Right-click on project "Engine.App"-->"Properties"-->"Configuration Properties"-->"Debugging"
      - In "Command arguments", enter "C:\games\ags\testgame\Compiled\Data\testgame.ags" (leave the double quotes around it to avoid problems with white spaces in the path)

5a. In Visual Studio, click again on button "Local windows Debugger". The game shoudl run successfully!
5b. Stop the game. Open source file "main.cpp". Just after instruction "init_debug(...);", add the following line : Debug::Printf(kDbgMsg_Alert, "Hello from my modified engine");
5c. Put a breakpoint on that new line.
5d. Run the project again. It stops on the breakpoint. In Visual Studio, look at panel "Output". If you continue the execution now, you wil see "AGS: Hello from my modified engine" appear in that panel.

Success! You're running a modified version of the AGS engine, and you are able to debug it with breakpoints.


About changes

the steps above caused a change in each of the two project files ( Common.Lib.vcxproj and Engine.App.vcxproj ). I you ever decide to merge back your changes to the AGS main repo/branch, you might be asked to revert those changes:

    <PlatformToolset>v140v143</PlatformToolset>

EDIT - useless first post

Thanks for clarifying that there are two types of mangled names. But you got my drift: any kind of hashing (or even just numeral codes for functions) could improve performance. Thanks for listening!

[cc_instance.cpp]

I'm looking at the engine source code.
In this file ( cc_instance.cpp ), I see that the engine looks at the "actions" that have been queued, and then pops them in order to execute them (by calling the c++ function that has a matching prototype).

A function "matches" if :
- It has the same mangled name
- It has the same number of parameters.

To check that it has a known mangled name, it iterates over every known function name, and does a strncmp each time

Code: ags

if (strncmp(thisExportName, mangledName, mangled_len) == 0) { ... // line 352

Is that still a thing? If yes, that would be a spot for extraordinarily beneficial somewhat beneficial optimization. EDIT: I realize that checking on the string's length first probably removes a lot of work from the comparison. But still, just a few function overloads can add quite many loops! E.g. comparison of mangled names "Button::Animate^4" with "Button::Animate^7"
Or maybe I misunderstood the purpose of this function and it's not meant for executing one instruction but instead for linking modules (and their symbols) together, only once? Or maybe this applies only in Debug mode, and the Release code gets rid of mangled names entirely?

I closed the poll.

Ok, thanks for explaining.

[That old royal blue was giving a strong visual identity to AGS.]

I don't understand how to vote.

Unrelated : I regret that the theme is progressively moving away from the powerful blue of the old blue cup (electric blue, royal blue) and is now mostly de-saturated, grayish blue. Even the cup. That old royal blue was giving a strong visual identity to AGS.

By the way, I see in the new forums that the top banner/logo is of that grayish blue, but buttons are orange, and become royal blue when hovered; While that is all very tasteful, I will take this opportunity to share a core principle of UI: The action buttons must be of your "brand" color (i.e. royal blue); then you can choose another fitting color when hovered (e.g. orange) -- in other words : flip the theme. Every other semi-important element must be in a "trimmed down" version of your brand color -- which means that no banner should be royal blue (as seen on the Play page); that's where the less powerful grayish blue should be used.

it needs the help of someone who can both do coding, and who knows the AGS language well, to implement a new language template.  If anyone is willing to help, instructions are here: https://prismjs.com/extending.html

I'm going to have a look, but is someone else working on this? (asking for coordinated work).

In the meantime, the C-like syntax (provided natively by prism) would probably fit 99% of the need!

this is in todo list to change in AGS 4 branch

Perfection

Is there still a technical reason for the "int" value of a color to be awkward?

By awkward I mean two things :
1) The fact that R, G and B values work by increments and maintain backwards compatibility for palettes, which doesn't let us use all the values for B (see help article for DrawingSurface.GetPixel). Blessed be the innocent soul who does SetPixel 0-31.
2) the fact that int colors go roughly from 0 to 65535, which means 16 bits

Maybe there's a smart way of making those values 32 bits and getting rid of a lot of crap?

If you've already fixed that issue from a year ago (by attaching metadata to each pointer) then the discussion is useless. Problem solved! Well done and hats off to you 

Github has removed all my ties to the AGS repo? notifications, dicussions, forks, etc.
What the hell. Did the Microsoft acquisition reset everything???
Now it's impossible to search what I was referring to.