| Age | Commit message (Collapse) | Author |
|---|
|
This fixes bug Trac #10791.
|
|
This is from Trac #10725, and the demo appears to be multilingual at
least in terms of English and German, so adding two entries.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
When a user tries to add a game expecting it to be a particular
game for a particular engine, but a detector from another engine
happens to match some files that exist in the game directory and
reports on those files instead, this can cause a lot of confusion
because the detector doesn't say what engine or game it thought it
matched.
This patch adds the name of the matching engine as well as any
matching game IDs (if applicable) to the detector's logged output.
It also provides more specific guidance about where to send the
detection information (to the bug tracker), and properly wraps the
first part of the report to 80 columns.
Refs Trac#10272.
|
|
|
|
|
|
This flag is removed for a few reasons:
* Engines universally set this flag to true for widths > 320,
which made it redundant everywhere;
* This flag functioned primarily as a "force 1x scaler" flag,
since its behaviour was almost completely undocumented and users
would need to figure out that they'd need an explicit non-default
scaler set to get a scaler to operate at widths > 320;
* (Most importantly) engines should not be in the business of
deciding how the backend may choose to render its virtual screen.
The choice of rendering behaviour belongs to the user, and the
backend, in that order.
A nearby future commit restores the default1x scaler behaviour in
the SDL backend code for the moment, but in the future it is my
hope that there will be a better configuration UI to allow users
to specify how they want scaling to work for high resolutions.
|
|
All these fall through were marked as deliberate, so again I've only
changed the comment to silence GCC.
|
|
Though since I don't have the game I can't actually test it. :-)
|
|
There were all flagged as intentional fall throughs. I simply changed
the comments to something GCC would recognize.
|
|
This demo comes with texts in English (GB), German and French.
|
|
|
|
|
|
|
|
The EGA version of Gobliiins, similar to Little Red Riding Hood,
claims a few resources are larger than they actually are. The original
happily reads past the resource structure, but we'll instead fix
the size of the resource after loading.
This fixes bug #7162.
|
|
|
|
|
|
|
|
|
|
|
|
Engines should only have to call one set of functions and not decide between the two. In fact, the 'emulation' API was documented to just call the 'real CD' API.
|
|
|
|
_singleid -> _singleId
_gameids -> _gameIds
_guioptions -> _guiOptions
|
|
It shouldn't be necessary anymore, since initOPL() cleans everything.
If, however, suddenly a piece of music sounds weird in a Gob game,
this is the place to look for.
This fixes a race condition between OPL::reset() and the callback
timer.
|
|
|
|
|
|
This is what the original game does too, and the scripts query for
all-uppercase CD track names.
Interestingly, this being wrong has been mostly inconsequential. It
does, however, manifest in one bug in the underwater wreck level of
Gobliins 2. After calling the Moray Eel by lighting the lamp with
Winkle, speaking to said eel has the scripts wait for the currently
playing background track to end before playing the voice lines,
instead of ending the audio track forcefully. The track is only about
a minute long, so it's "only" annoying, not a game-stopper.
The scripts also try to compare the CD track name with some different,
all-uppercase names, so this is possibly relevant in some other places
as well. No such bug report exists at the moment, though.
See also the forum post with the bug report:
http://forums.scummvm.org/viewtopic.php?p=81733#81733
A somewhat related bug report is #2999 "GOB2 : Moray Eel Game Freeze
(Wreck Scene)" (<http://sourceforge.net/p/scummvm/bugs/2999/>). At
that time, the script expression parser still did a stricmp for the
NEQ expression (which is wrong), and that made the bug not trigger.
Commit 5c58b9a3a4a8848474aba18c02c0da997fb138a2, which fixed that
incorrect NEQ behaviour, then made this bug here appear.
|
|
This is a left-over vestige of when the gob engine recorded the size
of each variable currently in use, because it byte-swapped all
variables on save/load depending on the machine ScummVM ran on.
The gob engine doesn't do that all anymore (instead, the variables are
always stored in the endianness of the original game), so
getAddressOff8() doesn't store "this is an 8-bit variable" anymore,
making the call a NOP.
This fixes Coverity Scan issue #1267142.
|
|
Also remove the unused AdLib::_rate member variable.
|
|
|
|
|
|
|
|
|
|
And clip to [0, width), [0, height) before drawing.
This fixes bug #6864, which is a regression I introduced in
51fd528fe56e00466255d54e1e71b19f34729bfd when I changed all
the drawing code to use the Surface class.
I thought that having unsigned coordinates makes sense, but
for some reason, Fascination sets _destSpriteX (which maps
to left in fillRect()) to -1, expecting the drawing code to
clip.
|
|
Happened while removing Draw::_vgaSmallPalette in 0f9b1364c.
Fixes Coverity issue #1230309.
|
|
|
|
Seems like that happened when I sorted them by platform
after splitting up the big detection table in 07b17f711.
This fixes bug #6676.
|
|
|
|
|
|
It's also used as a base offset for TOT strings.
This fixes a crash in the Amiga version of Bargon Attack.
|
|
Draw::_vgaSmallPalette was supposed to be a 16-color VGA
palette / EGA palette, but we've been using the first 16
entries of Draw::_vgaPalette for that for ages now.
The only parts where we didn't were codepaths never
actually taken in the gob games, so for the sake of
clarity (and fixing Coverity issues), this commit removes
those as well.
Fixes Coverity issues 1192648 and 1192649.
|
|
|
|
|
|
|
