| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
These appear to be default member-wise copy constructors or POD
constructors that zero all members. I suspect that quite a few
pointer-taking constructors are actually supposed to be
copy-constructors but since they don't all just do default
member-wise copies I do not feel confident in changing them without
verifying that there are not separate copy constructors in the
disassembly, and I don't have the database for this game.
|
|
|
|
|
|
|
|
and Sc2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
statics, remove unnecessary Picture allocation
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fixes Trac#10316.
|
|
|
|
|
|
|
|
|
|
graphics code
|
|
|
|
|
|
|
|
|
|
|
|
|
|
BUILD: Require 64bits integers
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
