| Age | Commit message (Collapse) | Author |
|---|
|
|
|
The commit message of 2739d8fa2 says this is for the French version. The
language was set to English by mistake.
Ref#6548
|
|
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.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fixes #7018
|
|
|
|
|
|
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.
|
|
Fix undefined behaviour in variadic functions
|
|
|
|
|
|
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.
|
|
|
|
Previous patches that removed shifts of constant negative values
to eliminate UB were valid, but did not correct all places where
this engine was potentially bit shifting negative values. There is
no reason to not just use multiplication and division and let the
compiler make the right choice for optimisation for an
architecture, so that is what this patch does.
|
|
|
|
|
|
LURE: Stop taking address of unaligned pointer
|
|
|
|
|
|
|
|
|
|
While usage of these pointers was technically safe because they
were read through an alignment-aware API, taking the address of an
unaligned pointer was generating warnings in Clang, and is not
strictly necessary here. This change solves the warning and also
protects this code from any future change that might cause it to
start reading unsafely.
|
|
|
|
|
|
|
|
|
|
|
