1
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
2
AGI Development Tools / WinAGI Version 3.0.0-alpha11.1
« 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.
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.
3
AGI Development Tools / Re: WinAGI Version 3.0.0-alpha8.0
« on: December 21, 2024, 03:46:17 PM »
OK, here's Progress Point 9.0:
https://github.com/AGKorson/WinAGI-GDS/releases/tag/v3.0.0-alpha8.0
The character map dialog is now complete and integrated into the logic editor.
I also updated the v2.3 logic conversion function to make backup copies of logics before conversion. That makes it easier to revert back to WinAGI 2.3
https://github.com/AGKorson/WinAGI-GDS/releases/tag/v3.0.0-alpha8.0
The character map dialog is now complete and integrated into the logic editor.
I also updated the v2.3 logic conversion function to make backup copies of logics before conversion. That makes it easier to revert back to WinAGI 2.3
4
AGI Development Tools / Re: WinAGI Version 3.0.0-alpha8.0
« on: December 20, 2024, 01:22:43 PM »WinAGI v2.x wont open a project if the wag states it's v3, but changing back to 2.3 allows it to open again. I assume things would break if you've updated the extended characters in logics. Otherwise, are v2 and v3 projects really incompatible or does WinAGI 2 just not expect a version 3 to be valid?As of right now the change in extended character support is the only incompatibility. Changing the version property back to 2.3 is the correct way to revert the WAG file.
But you are correct in that if you updated your logic source files to v3 any extended characters will display incorrectly in v2. You will need to manually correct them inside WinAGI v2 to revert them.
I'm not planning on creating any standalone converters. But I can add a feature so the v2 logics get archived/backed up prior to being updated to v3. I probably should have included that from the beginning.
5
AGI Development Tools / Re: WinAGI Version 3.0.0-alpha8.0
« on: December 20, 2024, 02:31:06 AM »I was wanting to take a look at the code. NuGet provides the dependencies. I did get it to retrieve the FastColorBoxes package, but not Microsoft.VisualStudio.OLE.Interop nor NAudio.Yeah, I remember now - NuGet is for managing libraries and such that you can add to your projects. It's been a while since I have had to deal with that. Weird that those two won't load.
6
AGI Development Tools / Re: WinAGI Version 3.0.0-alpha8.0
« on: December 18, 2024, 05:13:37 PM »graphics.DrawString("Hello world!", someFont, Brushes.Black, rectangle)
Most of their examples are no better than a 'Hello World' which doesn't help understand details and nuances.
LOL!
7
AGI Development Tools / Re: WinAGI Version 3.0.0-alpha8.0
« on: December 18, 2024, 05:10:28 PM »I am having trouble with the NuGet packages. I have never had a problem with them before. It is throwing 404 errors for all three of the packages.I'm not sure what you are referring to. Are you talking about the release installation files? There's only two - setup.exe and WinAGI.Installer.msi. If you're having trouble downloading I can provide a shared file link.
I don't know much about NuGet - I did some reading on it years ago but it never made sense. And I've been able to continue coding without seeming to need to know...
8
AGI Development Tools / Re: WinAGI Version 3.0.0-alpha8.0
« on: December 17, 2024, 06:07:15 PM »Cool to finally get a look at the new version. I see the logic files need to be updated if they use extended characters. Was that a significant change?Not really. In the current version, I chose to store all characters as single bytes, reading the bytes as the desired DOS code page when loading. This seemed like a good idea until I realized it required a lot of extra code to manage cutting and pasting.
With C#WinAGI I just simplified things - store the text in Unicode, work the editors with Unicode and only convert to DOS code page bytes when compiling. It's significantly easier to manage now.
9
AGI Development Tools / Re: WinAGI Version 3.0.0-alpha8.0
« on: December 17, 2024, 06:00:58 PM »Having done graphics editors in both VB Classic and C#, I can tell you this much: it's not that hard to use System.Drawing.
I hope you're right. The biggest paradigm shift I've had to make is that the inherent simplicity of VB Classic graphics came at the expense of flexibility and feature-depth. C# gives you access to EVERYTHING but then you have to learn how to wrestle all the options and syntax to get what you want out of it. That requires a lot of learning about all the objects, methods, properties and events. And a lot of the 'official' documentation is woefully inadequate, often glossing over or ignoring important concepts, or burying them behind a chain of hyperlinks that are nearly impossible to navigate. Most of their examples are no better than a 'Hello World' which doesn't help understand details and nuances.
I probably spent a full day trying to figure out how to print text to a picture box. In VB Classic, you just did "picturebox1.Print("msg"). Not quite that simple in C#... But I did finally figure it out.
I tried to check out your code sample to see some better examples but the link is broken (do you work for Microsoft?
)
10
AGI Development Tools / WinAGI Version 3.0.0-alpha8.0
« on: December 17, 2024, 02:52:07 AM »
Here's a very early look at the new and improved WinAGI Game Development System, written in C# using VS2022.
https://github.com/AGKorson/WinAGI-GDS/releases/tag/v3.0.0-alpha8.0
The repository is public if you want to peruse the source. Keep in mind this is a very rough pre-production release. This version does support all game-level functions (opening, importing, creating new from blank or template, managing setting and properties, rebuilding/compiling, etc) and basic resource management (adding/removing, renumbering, exporting, importing, previewing). The only functional editor is the Logics editor. It is mostly complete- integration with the other editors and tools are the only incomplete features.
As of this progress point, I plan on taking a break from coding this for awhile, but I would still welcome any feedback if anyone wants to offer it.
The learning curve to create robust applications in C# has been steep, and I've still got a long way to go to get to the top. I expect the graphics based editors to be especially difficult. But I do plan on making an attempt later in '25.
Enjoy.
https://github.com/AGKorson/WinAGI-GDS/releases/tag/v3.0.0-alpha8.0
The repository is public if you want to peruse the source. Keep in mind this is a very rough pre-production release. This version does support all game-level functions (opening, importing, creating new from blank or template, managing setting and properties, rebuilding/compiling, etc) and basic resource management (adding/removing, renumbering, exporting, importing, previewing). The only functional editor is the Logics editor. It is mostly complete- integration with the other editors and tools are the only incomplete features.
As of this progress point, I plan on taking a break from coding this for awhile, but I would still welcome any feedback if anyone wants to offer it.
The learning curve to create robust applications in C# has been steep, and I've still got a long way to go to get to the top. I expect the graphics based editors to be especially difficult. But I do plan on making an attempt later in '25.
Enjoy.
11
AGI Development Tools / Re: Any AGI engine upgrade projects? Looking for better graphics.
« on: November 29, 2024, 07:41:20 PM »
If you want to have something that would run in MSDOS, there is no practical way to expand the resolution. First hurdle is reformatting all resources to use words instead of bytes, then rewriting every graphics function (drawing functions and commands that manipulate graphics). It would be a complete rewrite of the AGI engine. If you're going to do that, then just create something new. (Which is what Sierra did with SCI.)
In the Power Pack mod I developed, AGI is modified to use the MSDOS graphics mode that provides 80 column text. That was relatively easy and doesn't involve any changes to resource formats. As I was working on that, I had to wonder why Sierra never did it. I think AGI games look significantly better when using 80 columns for text instead of 40. But it doesn't address screen resolution for graphics- 160x200 is all you're going to get out of AGI.
The second hurdle is memory management. AGI uses a single 64K segment of memory (allowing easy memory access with just a word value as the offset). Doubling the screen width from 160 to 320 would effectively double graphics resource sizes. It might not seem like a lot, but it is! For anything other than simple fan games, AGI is already severely memory-restricted. You want more graphics? Then you get less scripting and less detailed word dictionaries to make it all fit. Just take a look at some of the late AGI games from Sierra and see what kinds of tricks they had to perform to make everything fit.
In the Power Pack I was also able to create a separate segment to hold text resources, which frees up a substantial amount of memory. But there's no way to easily expand that to cover other resources - most of the game's functions need to be able to address graphics and the overlay resources from within the same segment. (Which is why available memory is even less than 64K- the overlays have to be in the same segment and take up ~7K or 8K depending on version).
As far as forking the source, Lance is correct that original source is not fully known. But that's a trivial matter- The program is a very simple MSDOS EXE file. It disassembles quite easily, and source code is not difficult to create that provides 100% compatibility. The NAGI engine is exactly that. (It probably wouldn't be that difficult to fork NAGI and create a version that outputs an MSDOS program file if you really wanted to do it - time consuming I imagine, but not difficult).
Bottom line is that AGI is inherently limited in graphics due to its memory model and resource formats. To get more resolution you have to go beyond AGI. Just like Sierra did. Like you though, I really dislike their move to the LISP syntax. Frankly, it's the primary reason I never had much interest in studying SCI.
Probably not what you were hoping to hear. But if you did want to poke around in AGI internals, I have fully disassembled all AGI versions, with detailed annotations. I'd be happy to share that with you if you want. I would also suggest looking at NAGI's source. As I said, it was created from disassembled AGI. And you could take a look at the fragments of source that are available. And I'd be happy to answer any specific questions you might have.
As far as a practical implementation of 'Hi-Res AGI', I agree with Lance that something like his AGILE engine (which is currently under active support) along with an editing suite to handle the resources (WinAGI potentially, but I'm not currently interested in adding support for custom resources) is your best option.
In the Power Pack mod I developed, AGI is modified to use the MSDOS graphics mode that provides 80 column text. That was relatively easy and doesn't involve any changes to resource formats. As I was working on that, I had to wonder why Sierra never did it. I think AGI games look significantly better when using 80 columns for text instead of 40. But it doesn't address screen resolution for graphics- 160x200 is all you're going to get out of AGI.
The second hurdle is memory management. AGI uses a single 64K segment of memory (allowing easy memory access with just a word value as the offset). Doubling the screen width from 160 to 320 would effectively double graphics resource sizes. It might not seem like a lot, but it is! For anything other than simple fan games, AGI is already severely memory-restricted. You want more graphics? Then you get less scripting and less detailed word dictionaries to make it all fit. Just take a look at some of the late AGI games from Sierra and see what kinds of tricks they had to perform to make everything fit.
In the Power Pack I was also able to create a separate segment to hold text resources, which frees up a substantial amount of memory. But there's no way to easily expand that to cover other resources - most of the game's functions need to be able to address graphics and the overlay resources from within the same segment. (Which is why available memory is even less than 64K- the overlays have to be in the same segment and take up ~7K or 8K depending on version).
As far as forking the source, Lance is correct that original source is not fully known. But that's a trivial matter- The program is a very simple MSDOS EXE file. It disassembles quite easily, and source code is not difficult to create that provides 100% compatibility. The NAGI engine is exactly that. (It probably wouldn't be that difficult to fork NAGI and create a version that outputs an MSDOS program file if you really wanted to do it - time consuming I imagine, but not difficult).
Bottom line is that AGI is inherently limited in graphics due to its memory model and resource formats. To get more resolution you have to go beyond AGI. Just like Sierra did. Like you though, I really dislike their move to the LISP syntax. Frankly, it's the primary reason I never had much interest in studying SCI.
Probably not what you were hoping to hear. But if you did want to poke around in AGI internals, I have fully disassembled all AGI versions, with detailed annotations. I'd be happy to share that with you if you want. I would also suggest looking at NAGI's source. As I said, it was created from disassembled AGI. And you could take a look at the fragments of source that are available. And I'd be happy to answer any specific questions you might have.
As far as a practical implementation of 'Hi-Res AGI', I agree with Lance that something like his AGILE engine (which is currently under active support) along with an editing suite to handle the resources (WinAGI potentially, but I'm not currently interested in adding support for custom resources) is your best option.
12
The Games and other Sierra Adventure stuff / Re: KQ6AGI - Complete after 18 years of development!
« on: August 23, 2024, 12:53:06 PM »Strange they didn't use the most recent interpreter version.The amount of free memory (heap space) is actually slightly smaller in v2.936 and all thee v3 interpreters (except v3.002.149, which gained a few bytes by dropping string storage from 24 to 12). So unless you really need the few commands added in v2.936 and/or v3, you actually get a few more bytes of available heap space by using 2.917. In AGI, 'a few bytes' can be a LOT of memory.
v3 interpreters are less desirable because you have to modify the executable file with your game's id. If you don't mind that hassle, then 3.002.149 is the best choice for maximum heap size, if you don't mind the smaller string space.
13
The Games and other Sierra Adventure stuff / Re: KQ6AGI - Complete after 18 years of development!
« on: August 22, 2024, 11:09:56 PM »The readme.txt says:There are no modifications. It's v2.917 (from KQ1). He just renamed it from agi.exe to kq6agi.exe.Code: [Select]It is highly recommended that this game be run using
the interpreter that is supplied with it. KQ6AGI is very
resource demanding, and has been tailor-made to operate using
the supplied interpreter.
It would be interesting to know what's been modified in the interpreter.
It is big, but not the biggest. It's got 1,485,268 bytes of resources in two VOL files, uncompressed. Goldrush had 1,652,765 bytes of resources (compressed to 1,185,381 bytes as a V3 game).
14
AGI Development Tools / Re: Original AGI Interpreter
« on: July 02, 2024, 08:34:22 AM »
The assembler program that was bundled with their C compiler, Let's C, was named 'as.exe'. This is what the manual has to say about it:
Is it just a coincidence that this file is named as.exe?
Quote from: Let's C Manual
as is a multipass assembler that will assemble functions written in i8086 assembly language. as will assemble programs into either SMALL or LARGE model, and will generate an object module in MS-DOS object format. It also supports i8087 opcodes, and it allows you to write functions in a model-independent manner.It says it doesn't support user-defined macros, but it will expand macros. But then it goes on to say that files must be named *.s or as won't run.
as is not intended to be used for full-scale assembly-language programming; therefore, it does not include some of the more elaborate features found in full-fledged assemblers. For example, it has no facility for conditional compilation or user-defined macros. However, Let?s C allows you to use preprocessor instructions to perform conditional assembly and expand macros. In addition, as optimizes branches to take advantage of short addressing forms, where the span of the branch permits.
Is it just a coincidence that this file is named as.exe?
15
AGI Development Tools / Re: Original AGI Interpreter
« on: June 22, 2024, 11:41:11 PM »
After more reading, it looks like 'Let's C' will use their internal assembler if the source file ends in '.s' and it will use MASM if the source file ends in '.asm'. Since all the assembly source files end in '.asm', it looks like Sierra wasn't using the MWC built in assembler. So I guess that theory is debunked.
SMF 2.0.19 |
SMF © 2021, Simple Machines
Simple Audio Video Embedder
Page created in 0.04 seconds with 20 queries.