| Age | Commit message (Collapse) | Author |
|---|
|
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 users of BitStream were in fact using a specific, hardcoded variant,
so we can hardcode that variant, removing the need for virtual calls,
and enabling inlining.
|
|
|
|
|
|
|
|
Recently we started to use this as new semantics, although in the past
we used simly <engine>_H. Now these guard defines are consistent with
rest of the files which are used in the engines.
|
|
|
|
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
|
|
Some backends like GCW0 do no support graphics >320x240 due to
the hardware limitation (downscaling is possible but it will ruin
the pixel hunting which is often part of the gameplay).
Instead of manually updating the list of engines, we now introduce
a new dependency.
I marked all relevant engines, but some, like tinsel, require more
work with putting their relevant high-res games under USE_HIGHRES
define.
|
|
|
|
|
|
also fix MT32 instrument filename (which was "fatFAT.MT" by accident)
|
|
|
|
- currently optional, to enable set milesAudioEnabled to true
|
|
|
|
|
|
|
|
|
|
This fixes most of the transparency issues in the puzzle screens.
They are still not correct, as the relevant videos play completely,
instead of showing a single frame. This also fixes issues with commit
2d42ab8
|
|
|
|
|
|
This was o_cellmove in T7G (the Microscope puzzle)
|
|
|
|
|
|
This is needed by the main menu in the 11th Hour
|
|
This removes the debugScript() wrapper, which can now be implemented
directly using the relevant debug function. This avoids the variadic
debug functions being wrapped in a second layer of variadic function
which is probably causing a significant overhead.
|
|
This is now uneeded as the GUI debugger superclass implements the same
functionality and this removes a bunch of complexity from the Groovie
engine debug calls. Also, removed groovie prefix from the debug flag
naming as unecessary as these are within the Groovie namespace.
|
|
This prevents segfault crashes in "The 11th Hour" when you open the
Gamebook palmtop from the top of the screen. The opcode needs some
work on the changes from 7th Guest, but this will prevent crashes
while this is being worked on.
|
|
|
|
Needed for alpha
|
|
They should now all decode correctly
|
|
|
|
It didn't work properly, it's not what the original did, and spooky mode needs to be implemented completely differently
|
|
|
|
|
|
|
|
|
|
|
|
|
|
RFC: Pluggable Engines #2 (No Python, just evolution of current configure shell and make code)
|
|
Each engine now only has to provide a single configure.engine file
adding the engine into the configure script, which then produces the
required other files automatically.
|
|
This is now generated automatically by the configure script from the
engine directory names.
|
|
This is the third and final commit enabling fully pluggable engines.
Now providing an engine folder contains a configure.engine, engine.mk
and engine-plugin.h file, it will be picked up automatically by the
configure script.
|
|
This is the second part of allowing engines to be added dynamically.
Each folder in engines/ which must contain a file named "engine.mk"
containing the make definitions for that engine.
|
|
This is the first part of allowing engines to be added dynamically.
They are placed into a folder in engines/ which must contain a file
named "configure.engine" to add the engine, which is pulled into the
top level configure script automatically.
|
|
This is required to support UTF-32 strings but does not make them work
automatically!
|
|
|
|
GRAPHICS: Implement JPEGDecoder based on libjpeg.
|
