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.

Messages - Charles

Pages: [1] 2 3 ... 9
AGI Development Tools / Re: C# AGI Interpreter
« on: October 20, 2022, 03:01:16 PM »
Agile already checks its folder the see if there is an AGI game in it, first.
Oh awesome. I didn't realize.

AGI Development Tools / Re: C# AGI Interpreter
« on: October 20, 2022, 10:35:08 AM »
Right clicking an AGI game's folder and selecting "Run with Agile". This would work as an IDE add-on where the the IDE would only have to pass a game's folder path to Agile to run it. It could work like SCI Companion's plugin system. Just drop a folder with Agile in it in the IDE's "Plugin" subfolder.

Honestly, that feature's a hard pass from me.  The amount of folder on my computer that I do not want to open in Agile far exceeds that amount of folders I do. Having a folder-browser dialog that I can paste a url into solves that ease of use problem for me.

Copying the Agile exe and DLLs to a game's folder and starting Agile from there.
That's a good one though. In fact, Agile should automatically check the folder it's run from for a valid AGI game and run it if found, otherwise prompt with the folder browser dialog.  And command-line arguments are of course good too.

AGI Development Tools / Re: C# AGI Interpreter
« on: October 19, 2022, 08:43:31 PM »
My vote?s for ZIP while you?re still in development. A faster update cycle and your target audience during such probably prefers the zip. When you get to a stable release phase the installer is nice as long at looks/acts modern. The MSI one you?re using doesn?t.

I gave it a look today, and there were two UI-type annoyances I had. I hate that folder dialog. Can you implement something like, and toggling the aspect ratio correction on and off caused the window to slowly get wider. I would expect changing the aspect ratio to only affect hight.

I can?t really speak to the technical AGI aspects. Leisure Suit Larry worked for the 30s I played it.

AGI Development Tools / Re: C# AGI Interpreter
« on: October 08, 2022, 01:44:09 PM »
What I'm not sure about at the moment is what .NET Framework version to target. By default, it seems to have set it to .NET Framework 4.8. I've read online that there is also a .NET 5 and .NET 6 available, and a .NET 7 preview, but that those are no longer the .NET Framework? Apparently new development should target .NET 6, but Microsoft says that there is no need to migrate existing .NET Framework apps to .NET 6. I've found tutorials online that cover migrating a .NET Framework Winforms app to .NET 5/6 but I'm not sure if it is worth it at the moment. As far as I can tell, .NET Framework 4.8 is available on Windows 7 upwards, so perhaps it is a good one to leave it on for now. It has been around since April 2019.

The whole .Net stuff is such a confusing mess. .NET Framework 4.8 will have the best compatibility, but it's a dead-end. Aside from a minor bugfix release 2 months ago (4.8.1), it stopped development in 2019.  Back about 6-7 years ago, MS rewrote .net from the ground up to make it more platform agnostic. They called the new one .NET Core, retroactively renaming the old one to .NET Framework. That was about the same time they released .Net Framework 4.6.2. They updated both in parallel, and continued to call the new one Core up to .NET Core 3.1. Then the next version they called .NET 5 to make it obvious it was intended to succeed 4.8. Since then .NET 6 has come out, which is the current LTS release.

It's kinda like how Windows XP was the next iteration of the Windows NT product line but still replaced Windows 9x, which was itself a dead-end.

Incidentally, not that this applies to you, but for dll applications to ease upgrading you can compile against something called .NET Standard 2.0, which is a subset of code shared by .Net Framework and .NET. Those dll's will be compatible with both .Net Framework and .Net Core applications. (Not .NET Standard 2.1 though.)

You should be able to compile most of your existing code against .NET 6, but upgrading your project from .Net Framework to .NET isn't a simple 1-click process.  I mean, it's not hard, but changing from one .Net Framework to another .Net Framework is as simple as changing the target in a drop-down; changing from .Net Framework to .NET is not that simple.  There are some pretty fundamental changes to the project files between the two.

I've been slowly moving all my personal and professional projects to .NET 6, and it's been pretty painless for the most part. The biggest hurdle for me was Visual Studio's WinForms designer is buggy on HighDPI displays.  They have a workaround, but that broke in Visual Studio 17.3.1... haven't been able to test later versions, so I've stuck to 17.2.6 for now.

(The Power Pack will only run on a native MSDOS sytem, or in DosBOX- no other platforms are supported.)

Does this mean it uses some AGI functions that are not properly or accurately implemented in ScummVM?

I didn?t realize that interpreter still supported vector pics ? or did you have to rasterize them first?

Is that the interpreter version that?s like QFG2?s but with debugging still enabled?

SCI Community News / Re: Mad dash to move Hosting
« on: September 04, 2022, 10:46:04 PM »
I?m not having any issues. I didn?t even have to re-login after the server switch.

I think that was a fantastic job switching servers especially on such short notice. This is one of the few sites that I check multiple times per day.

I've looked pretty thoroughly through the code now, and I think I know exactly what's going on. Some of this might help you fix the VGA bug, because it's probably the exact same thing going on there.

It's not effecting all spells in the rooms you've identified. It's not even actually causing problems in all the rooms you fixed, so you can scale back your fixes a bit.  That said, I think your fix is the best way to do so.  The basic problem is exactly as you found -- the (switch spell) is happening after (CastSpell spell).

The basic order of things is that in Main, the glory::handleEvent procedure runs constantly, and for speechEvents (of which typing "Cast anything" is one) it tells the specific room to do what it needs to do first:
Code: [Select]
(super handleEvent: event)
If the room code has done what it needs to do, it will set (event claimed: TRUE). I.e. it did the job, stop there.

So, what should be happening is that the room specific stuff should check only for spells that do something unique in that room, and if so cast the spell (via (CastSpell), do the animations, whatever, and claim the event.

Instead, what's happening is that those buggy rooms are casting the spells first thing with a (CastSpell) call -- that improves your skill with the spell, drains your mana, and flags the event as claimed, so nothing else will try to claim the spell -- then it's checking if it should actually do anything specific with the spell.  If so, do that animation, show that text, otherwise if it's a spell we're not doing anything special with reset the event claimed flag back to FALSE, so the main script can deal with it.

But we're already cast the spell... so we're casting it twice.  Once in secret, then finally with the animation and text.

There's two ways to fix it... one, as you've already done is to swap around the switch statement and the CastSpell statement.  So you check to see which spell the player typed in, and only CastSpell if it's one this room recognizes... otherwise, leave the claimed flag as false and let the main script handle it.  You can see the original programmers already did this in some rooms, like the Stags in Rooms 77 and 78.

The other way is to add cases for all 7 spells, and don't let the main script handle any of that.  That's actually the approach done in the script.  So that room you didn't actually need to switch the order around, because it's not leaving the event unclaimed for the main script to handle.  It's not my favorite approach though, because it means needlessly copying code into all the rooms. Something the original programmers did a fair bit... there's like 5 places where they handle the Zap spell, and it does the exact same thing in each... scratch that, almost the exact same thing. They slightly changed the text for when you're not holding a weapon in all but the Main script.

Best I can figure, there were 31 separate instances that check if the user tried to cast a spell (calls to the SaidCast function), not counting the one in Main.  So to be sure, I think you'd need to check each of those rooms, and see if they're casting the spell first, then accounting for a fraction of the spells then flagging the event as not claimed.  Those would be your problems rooms, and I suspect it'll be the exact same in the VGA version.

That is really awesome!

I hope to be able to take the time and really see what’s going on. If I had to guess I’d say for the EGA one, the room-specific code isn’t claiming the Said event as finished, so it runs the room specific code first, then runs the generic code, thus double-casting the spell.

Amazing find, and fix! Great work.

Or even a way to convert from the Mac's Data1/Data2 files to PC's etc. 

I had a heck of a time just getting the game files from the Mac floppies I have -- that's actually how I stumbled across this post... I was looking for help on how to extract game data from Mac floppy images.  I'd seen the blog before (thank Omer for sharing it several months ago), but I don't check it regularly because his updates are few and far between -- Each one's fascinating when he does post though and I've re-read them several times.

Just stumbled across this new blog post a couple days ago by Chris Benshoof.

The topic's mainly about an exclusive easter egg hidden in the Mac version of QFG1.  But he also goes into some of the joys and challenges of decompiling the Mac sierra games in general and Quest For Glory 1 specifically (which was ported to Mac about 2 years after the PC release).

He also includes an attachment to bring the exclusive easter egg over to the PC version, which is neat.

The Games and other Sierra Adventure stuff / Re: Rare SCI Games
« on: May 08, 2022, 10:40:29 PM »
On the original QFG Anthology CD release in 1996 includes the french documentation for QFG4, stating in the readme file:
Question: There is French documentation for QG4 in the \DOCO
directory on the QG Anthology CD, but there is no QG4 French game
on the CD.  Why?
Answer: The documentation was printed in French, but we never released
a French versionof QG4.  We included the French documentation on the
CD in case someone needed it.

The later 1997 QFG Collection re-release also includes the french QFG4 documentation, with a slightly rewritten FAQ answer:
Question: There is French documentation for QG4 in the \DOCO
directory on the QG Collection CD, but there is no QG4 French game
on the CD.  Why?
Answer: The documentation was printed in French, but we never released
a French version of QG4.  We included the French documentation on the
CD in case someone wanted to take a look at it.

AGI Development Tools / Re: Sierra's AGI Compiler (CG.EXE) Disassembled
« on: January 12, 2022, 09:23:53 AM »
If it's the same file OmerMor posted a couple years ago, the date is August 1, 1986 (10:29:58 AM).
CRC32: 022E711B
MD5: A70C533DCBDAA58491DD09A10AC1F251
SHA-1: 4700B789548A53FBE3600ADDB55E4B1C492436E0

SCI Syntax Help / Re: SCI0 - Pic Size Maximum?
« on: December 10, 2021, 11:57:35 AM »
Hah, I was just about to say that exact same thing.  It's the sort of thing that definitely makes me cringe when i see it, but hey, it's under the size limit (you said 43MB, but I think you meant 43KB).

I ran the converter myself and I have to say, I was impressed at how accurate it reproduced the original raster image.  Of course, I'm sure it helps that the original is already limited to 16 colours.  So, really whatever helps speed up the workflow.

EDIT: Also just realized that because the dithering is baked in, ScummVM's undither option won't do anything. Which I personally find a shame (although I think I'm in the minority with that opinion). Regardless, in a project like this, I do still believe workflow and time efficiency is king.  Really solid looking background, btw. Excited for your progress.

Pages: [1] 2 3 ... 9

SMF 2.0.19 | SMF © 2021, Simple Machines
Simple Audio Video Embedder

Page created in 0.078 seconds with 21 queries.