| Age | Commit message (Collapse) | Author |
|---|
|
When the Ex memory regions are close to full, it is possible for
the game to fail to purge objects and then crash with an OOM error
even if it isn't actually out of memory. This patch calculates the
amount of free memory truly needed when allocating to Ex memory to
allow exactly the entire frame & text regions to be used, instead
previously where a hard-coded amount of free space to maintain was
used, which guaranteed that the entire memory region could not
actually be used by the game.
This change may be masking some underlying memory leak, or it may
just be that near the end of the game the game naturally comes
close to reaching the maximum memory region size. For the moment,
I am assuming the latter.
This commit also adds some assertion checks to the memory transfer
functions to make sure the regions don't quietly overflow in other
cases, since pickupConts performs transfers in a manner that
doesn't ensure enough free memory exists for them to be successful.
Fixes Trac#6820.
|
|
Fixes Trac#6272.
|
|
|
|
|
|
|
|
|
|
Currently translated at 100.0% (960 of 960 strings)
|
|
Since lua_pushlightuserdata and lua_touserdata operate on (void *)
values, it is tricky to fix these warnings "correctly" without looking
at invasive changes to a significant amount of Lua internal code.
Since these pointers to consts are already being recast to drop the
const qualifications, then removing the const on the underlying value
declaration does not further expose this to change and stops the
compiler warnings associated with this.
Anyone with a better fix for this can restore the const
qualifications later.
|
|
|
|
Port of the fix from 0d8afad55.
|
|
Thanks to garethbp for discovering the issue and providing a fix.
Fixes Trac#6468.
|
|
|
|
Due to the need to calculate the audio duration with millisecond
precision from the file size, it is possible to overflow a 32-bit
integer in games with long background audio loops, like RAMA,
during the calculation of the duration.
It is also not necessary to give some framerate here, so eliminate
the unnecessary explicit Timestamp construction with the second
argument.
|
|
|
|
|
|
The game reads until it sees 0xFF, which is not until frame 14 for
some animations in the first interactive room of the game. This
happened to work previously because the struct is packed so it
would read into the b31.. members, but this was still technically
an out-of-bounds read.
|
|
|
|
|
|
|
|
Currently translated at 100.0% (960 of 960 strings)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fixes #7018
|
|
|
|
Myst ME uses such cursors.
|
|
|
|
FSNode::getName returns a String object, not a reference, so the
pointer from c_str is valid only until the end of the statement.
|
|
FSNode::getName returns a String object, not a reference, so the
pointer from c_str is valid only until the end of the statement.
|
|
We were already doing it for SDL1.2, but with SDL2 the SDL_RLEACCEL
is not passed to SDL and instead we need to call SDL_SetSurfaceRLE.
|
|
backends
Since those GraphcisManager initialize the cursor position to (0,0) when
created the cursor was jumping to the top left corner and then moving
back to its initial position as soon as the mouse was moved. Now it
stays at its initial position.
There are still some issues with it when changing between OpenGL and
SurfaceSDL at the same time as toggling fullscreen. But it is not worse
than before.
|
|
If we do not update the area below the message, it is just blitted on top
of itself again and again and gets progressively less transparent. It also
causes artefacts when the mouse pass below the OSD message.
|
|
Fix undefined behaviour in variadic functions
|
|
|
|
|
|
On the OpenPandora handheld, the OSD message would not render unless you
moved the cursor in the area where it was supposed to show.
Additionally, the OSD message was not transparent like in v1.8.
This commit fixes both these issues.
|
|
|
|
Currently translated at 100.0% (960 of 960 strings)
|
|
Currently translated at 100.0% (960 of 960 strings)
|
|
Currently translated at 100.0% (960 of 960 strings)
|
|
|
|
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.
|
|
If an early file in the game's signature list has a hash/size
mismatch, it is still necessary to continue to check the rest of
the candidate files for existence, since the non-existence of
candidate files is supposed to disqualify a game description as
matching a game to an unknown variant.
By quitting the file check early, the detector had been allowing
descriptions to randomly match if there happened to be an early
file in the detection list with the right name but wrong hash/size,
even if some of the other signature files did not exist at all.
|
