SQ4/CD/Windows uses a simiar interpreter to the KQ6 one, minus the hires
graphics support. It has the same upscaling to 640x440 (or 320x220 for small
windows) and also support the same 16 colors mode.
Also removed some whitespace...
I have attached the SQ4 Windows variant to the gfx drivers I made for KQ6.
The 16 colors mode now requires the SCIWV.EXE executable, though. I had
hard coded the 512 bytes color pattern table for KQ6, since I thought it
would remain the only one necessary. But SQ4 has a different table. So I now
load them from the executable.
There might be more Windows games like that, I just currently don't know
about it (probably other SCI_VERSION_1_1 titles). Adding support would be
super easy. But it will not work right out of the box, since I explicitly check
the game IDs in customizeGuiOptions(), to avoid any nonsense to happen.
16 colors and 8 colors modes for the SCI0 and SCI1
PC-98 games.
The 8 colors modes are new, the 16 colors mode is
basically the pre-existing mode, just with some
minor fixes (palette, font drawing, etc.).
The final goal is to get rid of the upscaling inside the
engine, but that will require more work on the other
game versions that depend on it.
This adds the existing GAMEOPTION_HIGH_RESOLUTION_GRAPHICS option to
Mac games with native fonts. Default is enabled. If disabled, then the
low resolution Mac fonts are used and the game isn't upscaled.
High-resolution native Macintosh fonts are now supported in the
following games when the game's executable is present:
- Castle of Dr. Brain
- Freddy Pharkas
- King's Quest 6
- Leisure Suit Larry 1
- Leisure Suit Larry 5
- Space Quest 1
And in these games when classicmacfonts.dat is present:
- Leisure Suit Larry 6 (floppy)
- Quest for Glory 1
Many PQ2 Japanese strings contain escaped newlines ("\n") which we have
not been handling. We have been handling these in getSciLanguageString()
when returning Japanese text but that's not where SSCI does this work.
PQ2's Print procedure in script 255 parses Japanese text itself and our
getSciLanguageString() is never involved.
Now Japanese newline handling is done in the core text measuring and
drawing functions, which is closer to where SSCI did it, but without the
hack of having GetLongest() patch out Japanese newlines like in SSCI.
Fixes bug #13154
This avoids an issue with MSVC where if (non-SCI) "graphics/font.h" is
included through another include file from the SCI engine root, it finds
"sci/graphics/font.h" first and uses that instead.
This may come back in the future to deduplicate some gfx code,
but SCI32 had two different inlined ways of doing coordinate
conversions with different rounding methods, so CoordAdjuster32
didn't get used when the graphics system was rewritten.
At the moment, SCI32 code uses the mulru/mulinc methods from
helper.h for scaling up/down coordinates.
On some systems, passing signed chars to macros like isspace() etc. lead
to a runtime error. Hence, mark these macros as forbidden by default,
and introduce otherwise equivalent alternatives for them.
athrxx
sluicebox
Hubert Maier
Eugene Sandulenko
Orgad Shaneh
Paul Gilbert
Torbjörn Andersson
wonst719
Walter van Niftrik
Zvika Haramaty
D G Turner
Colin Snover
Lars Skovlund
Martin Kiewitz
Johannes Schickel
Max Horn
Littleboy