Author Topic: AGI extended character support  (Read 762 times)

0 Members and 1 Guest are viewing this topic.

Offline ZvikaZ

AGI extended character support
« on: April 02, 2022, 02:21:00 PM »
This topic was mentioned at https://sciprogramming.com/community/index.php?topic=2051.msg15257#msg15257, but it's off topic for that thread, and it already got many interesting topics, so I'm replying at a new thread...

AGKorson discussed what's possible with the original Sierra AGI interpreter, running on Dos/Dosbox.

However, with ScummVM we have more flexibility. Actually, I have translated PQ1 to Hebrew - https://sciprogramming.com/community/index.php?topic=2001.0.

For instructions, please see https://github.com/adventurebrew/HebrewAdventure/tree/master/tools/agi.
I admit that these instructions were phrased mainly as a reference for myself in the future, but I will gladly help if you want.

Also, maybe some minor modification need to be done to ScummVM to support AGI French, but I can do this as well.



Offline AGKorson

Re: AGI extended character support
« Reply #1 on: April 05, 2022, 03:08:15 AM »
Good observation ZvikaZ. ScummVM might be the best way to go.

The original NAGI (version 2.06 for windows/2.07 for Linux IIRC) does not support extended characters.  If a message has an extended character, NAGI prints garbled data.

Nick made the source code for NAGI publicly available, so back in 2006, I ported it to VC7, and modified it to support extended characters and changing color palettes. It was actually pretty easy to get support for extended characters (changing the font file loader to load 256 characters instead of 128) and then modifying the font files (*.nbf) that are included with the executable. I'm attaching NAGI v2.09 here if anyone is interested. (I also tried to recompile it in VS 2019, but I can't get it to work; if anyone wants to try that, I'd be happy to share my source to see if you can figure it out.)

If you don't like the glyphs that I include in NAGI v2.09, you can edit them. I created an app called NFEdit that you can use to easily modify the font files. I explain it in another thread (https://sciprogramming.com/community/index.php?topic=1766.msg11533#msg11533) if you are interested.




Offline Collector

Re: AGI extended character support
« Reply #2 on: April 05, 2022, 07:21:26 AM »
One thing that always annoyed me about NAGI was that the window close button did not work. You didn't perhaps fix that, did you?
KQII Remake Pic

Offline AGKorson

Re: AGI extended character support
« Reply #3 on: April 05, 2022, 10:36:38 AM »
One thing that always annoyed me about NAGI was that the window close button did not work. You didn't perhaps fix that, did you?

LOL, no I didn't. But I wish I had. I was doing some checks last night to make sure it does what it's supposed to, and I know I silently cursed that 'feature' at least ten times...

Offline doomlazer

Re: AGI extended character support
« Reply #4 on: April 07, 2022, 07:22:32 AM »
For instructions, please see https://github.com/adventurebrew/HebrewAdventure/tree/master/tools/agi.

This information was extremely helpful. Thank you.

Edit: Need to do more testing before I ask questions - some of my assumptions were incorrect.
« Last Edit: April 08, 2022, 12:54:27 AM by doomlazer »

Offline doomlazer

Re: AGI extended character support
« Reply #5 on: April 09, 2022, 02:21:08 PM »
AGKorson, your string hack for extended character support in DOSBox from this post is awesome. Still in the testing phase, but this will surely be used in Threepwang's SQ1 French Translation.

This, along with the ScummVM font information from ZvikaZ's Hebrew translation, have been invaluable. Thank you both! I'm truly standing on the shoulders of giants.

Offline AGKorson

Re: AGI extended character support
« Reply #6 on: April 09, 2022, 08:09:37 PM »
Glad to hear you found it helpful!

Since I posted that, I've continued working on the code for that hack, and can now add extended character support (and a ton of other features) to any MSDOS version of AGI by just running a special logic at the start of the game.  I plan on releasing a full set of logic scripts (I'm calling it the AGI Power Pack) very soon that anyone can just drop into a game to open up a whole new world of capabilities for AGI games.

In the meantime, if you need any help with the extended character script, feel free to PM me and I'd be happy to help.

Offline doomlazer

Re: AGI extended character support
« Reply #7 on: April 25, 2022, 03:29:42 PM »
For the SQ1 French translation we've been struggling with the extended characters in DOSBox. I've come up with a hack to create and use a custom codepage which allows us to modify the extended characters, but because AGI handles standard and extended chars differently, it's still using a mix of system glyphs and our custom codepage in-game.

The details of what we are trying to accomplish and where we are currently at can be found in this Vogons thread: https://www.vogons.org/viewtopic.php?p=1061173#p1061173

Looking at AGK's post here. I'm wondering if it would be possible to trick the AGI interpreter to use our custom codepage for the "7 bit ASCII" pointer INT 43h?

If it's possible to get AGI to reference all glyphs from the custom codepage I believe it would allow AGI fan games to use a completely custom 8x8 font in DOSBox.
« Last Edit: April 25, 2022, 03:37:16 PM by doomlazer »

Offline AGKorson

Re: AGI extended character support
« Reply #8 on: April 26, 2022, 12:35:56 AM »
The reason your characters aren't showing correctly when printing black-on-white is because of the approach Sierra used to deal with how EGA handles character drawing when in graphics mode - it's not the same way characters are drawn in text mode.

In text mode, the character attributes allow you to independently set background and foreground colors. When a character is drawn to the screen the EGA card will replace pixels at the character location based on the glyph bitmap.

But in graphics mode, the 'background' attribute doesn't work the same. Basically, only the high bit of the 'background color' value matters. If it's clear, you get a black background, and the character draws the same as on the text screen. If that bit is set, the character is XORed onto the screen with the existing pixels. So, in a nutshell, you can't (easily) draw black characters on a white background in graphics mode. (This applies to ALL graphics modes on the EGA card, and it's a 'feature' of the EGA card, and not an MSDOS thing.)

Sierra decided to solve the problem by inverting the glyph bitmap, and then drawing it as white-on-black; since the glyph is inverted, it gets drawn as if it were a 'black-on-white' character. To invert the glyph, they copy the glyph bitmap from the standard character interrupt location. And since this is hard-coded into the AGI character drawing function, extended characters don't work.

The hack that I wrote to address this checks the value of the character, and if it's extended, it grabs the glyph from the extended character interrupt instead of the standard interrupt.

I don't know much about how MSDOS handles fonts and code pages. I think it's updating the interrupt values to point to the correct glyphs (which is why the extended characters are displaying correctly). But since AGI is hard coded to the location of the default glyphs, and not the current glyphs, it's not working for standard characters.

I think this might be an easy fix. The hack just needs to modify the location used for standard character glyphs from the default (F000:FA6E) to whatever value is actually located at INT 43h. But I'd have to do some testing.


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

Page created in 0.113 seconds with 24 queries.