Community
AGI Programming => AGI Development Tools => Topic started by: AGKorson on January 02, 2025, 08:51:40 PM
-
Happy New Year everyone!
My resolution this year is to finish a production version of WinAGI in C#/Visual Studio. To that end, here is the latest pre-production release:
https://github.com/AGKorson/WinAGI-GDS/releases/tag/v3.0.0-alpha11.1
The progress point I'm currently working on is the Defines Editor. In WinAGI VB this is used to manage defines that are considered global in scope. WinAGI VB's compiler automatically loads these defines (as well as defines for reserved variables/flags and resource ID labels) without needing to explicitly define them in logic source code or in a text file (like defines.txt) I thought that was a good idea twenty years ago, but since then I've come to realize it's not ideal. So I'm making a major design change to WinAGI C# that no longer assumes values for IDs, reserved and global defines.
In this release, I've completed that change. Now all define names must be declared and included either in the source file itself, or in a separate file to be accessed via an #include directive. WinAGI still provides automatic management of these features, but the code output will always look more complete because nothing is assumed inside the compiler regardless of how you configure your game for defines support.
There are now three new game properties, IncludeIDs, IncludeReserved and IncludeGlobals that you can use to tailor the coding experience to your own preference. Each is associated with pre-defined text file (resourceIDs.txt, reserved.txt and globals.txt) that WinAGI will automatically create and update as you make changes to your game (by adding, removing, renumbering, renaming resources, renaming reserved defines, adding, removing or renaming game-specific global defines). Logic source code is also automatically updated based on these properties to add the appropriate #include directive to every source file.
My goal is to create an experience similar to the 'using' directive in Visual Studio. It gives users the option to take advantage of WinAGI's powerful features to automatically manage naming and usage of defines (which is what WinAGI VB did) but also makes it extremely simple for those who would rather manage all game defines manually.
An added benefit of this approach is that it makes the source files much more portable. You could for example use the source code and defines files in AGI Studio without needing any modifications.
I am very interested in any opinions out there regarding this change. So please take a look at this version, and play around a bit with the auto-Include features and let me know what you think.
-
Global defines editor is done.
https://github.com/AGKorson/WinAGI-GDS/releases/tag/v3.0.0-alpha11.2
-
Progress Point 12.0:
https://github.com/AGKorson/WinAGI-GDS/releases/tag/v3.0.0-alpha12.0
Reserved defines editor is done.
-
I've made an improvement to NewRisingSun's GAL decompiler to allow sysdefs like:
%var menaceIsHere 103 ALL
%var witchGrabbed 103 21
This means that menaceIsHere is generally the name of variable 103, except in room 21, where it is called witchGrabbed. This is useful because of the crowded variable space in both GAL and AGI. Something to consider?
(I don't think menaceIsHere is a good general name anymore, btw - its uses are far too varied)
-
I've made an improvement to NewRisingSun's GAL decompiler to allow sysdefs like:
%var menaceIsHere 103 ALL
%var witchGrabbed 103 21
This means that menaceIsHere is generally the name of variable 103, except in room 21, where it is called witchGrabbed. This is useful because of the crowded variable space in both GAL and AGI. Something to consider?
(I don't think menaceIsHere is a good general name anymore, btw - its uses are far too varied)
Interesting idea - I've been thinking about ways to improve how defines are handled but haven't decided for sure what improvements to make.
When decompiling, WinAGI doesn't attempt to name variables and flags unless they are one of the reserved items. Are you saying that when decompiling, you want to assign defines that the decompiler should use for non-reserved variables? That seems like it would rarely be useful- how often would you really know what the purpose of variables are unless you already have source code, or unless you've previously decompiled and then figured out what they do?
As for creating new source code, WinAGI will already handle the situation you describe - use #define menaceIsHere v103 in globals.txt and then use #define witchGrabbed v103 in logic 21 source code. The local define will override the global define. (The hierarchy that WinAGI uses when duplicate define names are encountered is local > global > resourceIDs > reserved).
The %var keyword is currently not recognized in AGI Fan Syntax (AGI-FS) - it's only used is Sierra Syntax (AGI-SS). Adding additional functionality to it in AGI-SS isn't something I want to do- WinAGI currently supports AGI-SS to allow for compilation of Sierra source code. I want it to remain 100% compatible. But I suppose I could add %var as an additional keyword for AGI-FS in addition to #define. I'll give it some thought, but probably won't do anything with it right now- my focus is on finishing up all other editors and release an updated version that can do what the VB version does.
-
OBJECT file editor is complete.
https://github.com/AGKorson/WinAGI-GDS/releases/tag/v3.0.0-alpha13.0
-
WORDS.TOK editor is complete.
Palette editor is complete.
https://github.com/AGKorson/WinAGI-GDS/releases/tag/v3.0.0-alpha15.0
-
Wow, that's impressive. Thanks for your work on this! I've returned to AGI this year and am finishing a game I started more than 20 years ago... call me crazy. I use both WinAGI and AGI studio and am super grateful for all the great tools out there. Cheers from Germany!
-
WORDS.TOK editor is complete.
Palette editor is complete.
https://github.com/AGKorson/WinAGI-GDS/releases/tag/v3.0.0-alpha15.0
You are the man!
-
Wow, that's impressive. Thanks for your work on this! I've returned to AGI this year and am finishing a game I started more than 20 years ago... call me crazy. I use both WinAGI and AGI studio and am super grateful for all the great tools out there. Cheers from Germany!
I'm always glad to hear about more AGI efforts, even if they take a while! If you have any feedback on what you see so far in WinAGI, I'd love to hear it. If there are things missing from WinAGI that require you to go back to AGI Studio, please let me know. I can probably address those in this new version so you won't need to go back and forth between tools anymore.
-
WORDS.TOK editor is complete.
Palette editor is complete.
https://github.com/AGKorson/WinAGI-GDS/releases/tag/v3.0.0-alpha15.0
You are the man!
Thanks for the compliment! It helps me stay motivated toward completing this. I will press on...
-
Finally got back to looking at my NuGet problem. It was not liking my NuGet.Config. It had all of the right contents, but was not reading it. Deleting it and restarting VS fixed it. I suspect that it was a malformed XML issue, but with the right contents. Now I can follow the progress with the C# build.
-
Finally got back to looking at my NuGet problem. It was not liking my NuGet.Config. It had all of the right contents, but was not reading it. Deleting it and restarting VS fixed it. I suspect that it was a malformed XML issue, but with the right contents. Now I can follow the progress with the C# build.
Glad to hear you figured it out. I'm real close to releasing the next update, which will include full editing support for picture resources. Then I'll add the testing modes, before tackling the last two resource editors. It looks like I might be able to finish this project before the end of the year as originally planned.
(And please feel free to provide any feedback even on the alpha release versions!)
-
Picture editor is complete.
https://github.com/AGKorson/WinAGI-GDS/releases/tag/v3.0.0-alpha16.0
-
Right on! Gonna try it out this weekend. Thanks for your continuing work on this!
-
Making progress on view editor. Basic form structure is set. Non-graphical editing functions (adding/removing loops/cels, changing view/loop/cel properties, etc.) are done. Still need to add support for image manipulation functions.
https://github.com/AGKorson/WinAGI-GDS/releases/tag/v3.0.0-alpha16.1
-
View Editor is complete.
https://github.com/AGKorson/WinAGI-GDS/releases/tag/v3.0.0-alpha17.0
Would love to get some feedback.
Also, as I begin working on Sound Editor, if anyone has any suggestions for the interface, I'm interested. I plan on duplicating the interface in VB6 WinAGI, but if there's a better alternative, I will consider adding it as an option.
thx,
-
I haven't played with sound much in AGI, but I remember the Tandy 1000 Deskmate software had a kickass sound editor. There were probably other 3 voice sound editors from the era you could take inspiration from.
Keep up the amazing work! I don't often reply but I read every post and really appreciate the updates.
-
Sound Editor is complete.
https://github.com/AGKorson/WinAGI-GDS/releases/tag/v3.0.0-alpha18.0
I included the ability to import IT, MOD and MIDI files directly into WinAGI without needing to run a separate tool. It uses a translation of Sinus' any2agi Perl script. It's currently compatible with script version v0.2.7 (I haven't been able to keep up with his changes and improvements. At some point I will update WinAGI using his most recent version, but not until all other progress points are reached.)
With this release, WinAGI C# can now be used to create and edit all resources in an AGI game. I just have a few more tools to finish up before it's completely done.
-
I have not had the time to look at your progress for a while, but I take it that all of the main editors are are now functional.
-
Correct.
-
Layout editor loading/saving/displaying is done. Now working on editing functions. Continuing to fix bugs throughout as I find them.
https://github.com/AGKorson/WinAGI-GDS/releases/tag/v3.0.0-alpha18.1
-
Sounds like you are making good progress.
-
Nice work!
-
Layout editor is complete. Only the menu editor and text screen editor are left. Those shouldn't take too much longer.
https://github.com/AGKorson/WinAGI-GDS/releases/tag/v3.0.0-alpha19.0
-
Text screen editor is done. All code from VB6 version has been ported.
https://github.com/AGKorson/WinAGI-GDS/releases/tag/v3.0.0-alpha21.0
Now I'm working on integrating help, and doing a lot of code cleanup and refactoring. A Beta release is just around the corner.
-
Looks like you are making good progress.
-
Text screen editor is done. All code from VB6 version has been ported.
https://github.com/AGKorson/WinAGI-GDS/releases/tag/v3.0.0-alpha21.0
Now I'm working on integrating help, and doing a lot of code cleanup and refactoring. A Beta release is just around the corner.
A. Any plans on getting this working on non-Windows systems via a cross-platform GUI library?
B. I might need help on drawing AGI backgrounds later, any experts on such a thing?
C. Do you need anything specific for .MOD import, or will it just do it regardless of the instruments assigned to each channel?
-
The new version is being developed with C#. I don't know what would be involved with getting it to run on Linux or Mac if you install dotNET on your machine. If you try it, let us know.
-
If a C# WinForms application does not use any DLL calls ("P/Invokes"), it should work just fine via Mono. You wouldn't even need Wine.
Source: I have made things in C# that have been confirmed to run just fine on Linux via Mono.
-
Yeah, I had thought of the P/Invoke limitation and thought it would probably be a problem, but I have not looked that close to Andrew's source to see if he uses any. Again, something that I have not explored since I have no need.
-
There are a handful of API calls. Most were added early when I didn't have much experience with C#. I've gotten much more efficient since then. I can take a look at them to see if they can be eliminated.
-
I try to avoid them if I can, but sometimes it is the only solution
-
I believe I'm finally done with adding support for original Sierra logic syntax. I have tested it on several different sets of original Sierra source code packages and they compile as-is, with no changes needed.
https://github.com/AGKorson/WinAGI-GDS/releases/tag/v3.0.0-alpha21.3
This work required a lot of digging into CG.EXE- Sierra's compiler. CG.EXE does not do a lot of syntax rules enforcement. I guess they just assumed their programmers would write good code. To maintain 100% compatibility I had to add some of that 'looseness' to WinAGI. But it does provide you with feedback on how to write cleaner code.
The help file contains very detailed explanations of CG.EXE, OBJECT.EXE and WORD.EXE, tools used by Sierra to compile logics, OBJECT and WORDS.TOK files. You may find that interesting. Or maybe not...
Regarding DLL calls, WinAGI uses them primarily for supporting custom clipboard formats and sound generation. At this point, I'm not very interested in figuring out how to make a build that doesn't use them. If anyone else wants to take a look and make some suggestions, the code is on Github.
-
Sounds lik3e you are making good progress. I'll have to grab the latest and take a look.
When you get to the point of updating WinAGI's Wiki entry you'll need to setup an account on the new Wiki https://wiki.sierrahelp.com/index.php/Main_Page I have added all of the old AGI Wiki content to the new one and will be deleting the old one soon.