For each engine:
- Make a new folder detection
- Move detection-related files inside the folder
- Add a new module "enginename/detection"
- Add DETECT_OBJS here
- Adjust the normal engine module to remove detect_objs
- Adjust every file for the new changes.
Eden game object now contains a graphics object with which to
delegate graphics operations and store states of the graphics.
Much of the video playing is done in the graphics class
so I have moved a lot of the video state into there.
Some graphics related variables were moved out of eden and into
graphics, but many are still in eden.
Since they are still coupled there are lots of getters and setters.
For example both eden_graphics and eden share a handle to the same
video object.
I have made a few more things public than desirable.
I changed graphics to eden_graphics since it is specialized to eden
and not just cryo.
- Add missing default switch cases
- Specify packing for structs with pointers to complex objects
- Change literal suffixes to uppercase
- Replace uses of malloc() with new []
These occurred while compiling in Raspberry Pi Raspbian latest and
appear to be due to char being interpreted as unsigned by default,
rather than signed in two data structures. Have replaced with explicit
types to avoid this issue.
Some of the debug statements in the engine compute values or sizes of
various items by pointer subtraction (which is probably not recommended;
I am not sure if this is why some of the structs were previous packed as
noted and removed by snover).
In any case, the subtractions should result in relatively small integer
values, but using these into debug() calls with printf style format
strings can cause warnings from the compiler with the format specifier
depending on the underlying pointer sizes.
To avoid these, have recast these to int. If this does cause any issues,
they should be limited to debug() value changes and thus not a
functional issue with the engine, which can be corrected by the engine
developers.
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.
Torbjörn Andersson
Eugene Sandulenko
aryanrawlani28
mataniko
Paul Gilbert
Bastien Bouclet
Cameron Cawley
Tarek Soliman
D G Turner
Henrik "Henke37" Andersson
sluicebox
David Fioramonti
Filippos Karapetis
Adrian Frühwirth
Colin Snover
Strangerke
Willem Jan Palenstijn