#81 build scalers as plugin or as dll
Here is a very BIG patch... This may be the first step,
to share the
scaler code between fuse and scrconv without creating
new lib or
something other. And its may a framework to make
pluginified UI and
sound code...
OK. Because it is very big, I think its need a big
explanation...
I use the libtool ltdl library for wrapping around the
different run
time module loading methods
(Linux/BSD/HP-UX/MAC/Win/etc...).
The first thing, is the configuration:
We try to search the lt_dlopen in the libltdl library
and the
ltdl.h header file. There is a configuration option
to disable
plugin building (--disable-plugins). Either
--disable-plugins
or no ltdl found, 'plugins' statically built into fuse.
The static scaler code always incorporate the Null
expander (see later)
and the Normal scaler. So, if somehow fuse can't
reach any usable
scaler and expander plugins the basic Normal one is
working :-).
The scalers:
This patch NOT touch the scalers, but heavily change
the scaler handling
code and concept. The scaler list is now arbitary,
and NOT the UI
'register' anymore the "usable" scalers. There is a
'scaler_init'
function which called at the startup. This function
scan the plugin
dir and try to register all found expander and
scaler. If no plugins
this function register the 'standard' builtin
expander and scaler
pack.
The scaler_info is slightly changed:
-it is transparent from the 'outside world'
-the 'scaler_type' enum disappeared only the 'const
char* id' identify
the scaler
-there is an 'expid' member to know which expander
needed for this scaler
-the scaling factor is changed to int and defined
some macro:
SCALER_FACTOR_0_5 .. SCALER_FACTOR_3_0 and a
SCALER_FACTOR_SHIFT
so now scaled size computed by pure integer
arithmetic:
scaled_size = original_size * factor >>
SCALER_FACTOR_SHIFT;
-there is a member 'expander' to store the expander
function
-the flags is changed to indicate scaler properties:
e.g. SCALER_FLAG_COLOR -- need smooth color space,
SCALER_FLAG_TIMEX,
etc.
-a next member, to store the address of the next
scaler in the chain
There is an expander_info struct to store expander
properties:
-name,
-id (refered by th scaler_info expid )
-fn the function
-and the 'next' field
There is several function to reach the scalers data:
scaler_get_id, ...name, ...scaler16, scaler32,
expander, scaling_factor,
flag,
There are two function to find scaler, one search by
id and an other
by properties: factor and flag must and flag must
not have...
so the UI can search the stored scaler by id, or a
suitable
scaler for the current screen size and color abilities.
The rest for managing the plugins...
Every plugin can include several expander or
scaler, and export
a plugin name, init function and a version number
struct to
the loader code. The init function register all the
included
expander or scaler.
The load code first register the expanders then the
scalers.
The scalers and the expanders splitted up. The normal
scaler and
the new 'null' expander which is a simple return
incorporated
the scaler.c as an always exist scaler (and expander).
Scalers go to the scaler_pack.c and expanders to the
expander_pack.c, the plugin info structures go to the
blahblah_info.c files (because the double
compilation of
scalers). Theese files compiled differently depend on
pluginifying... as runtime loadable library or
static code.
The changes of UI code:
every xxxdisplay.c no include an
uidisplay_scaler_is_usable
function and a setup_scaler function (similar to the old
register_scaler). The setup_scaler try to find a
suitable
scaler for the actual image/display size...
the reference to the actual display scaler data not
stored in the
scaler.c variables, but in the display_scaler global
variable
which defined in the display.c. The expander and
scaler functions
reached with the scaler_get_xxx fn-s.
The menu:
there are two menu definition to select scaler one in the
widget system and one in the gtk. All this changed
paralell
and get closer to eachother. no the widget menu
system remember
the last plugin and check it on the select box (i
hope :-).
Scan the scalers and (scaler_get_next) and ask
uidisplay_scaler_is_usable
to include the list... Ok later the
uidisplay_scaler_is_usable
function may generalised and from some data
(image/display size,
machine, color cap/gfx hotswap cap) can make this
decision, and
we not need UI specific functions...
End....
Notes about the scalers/displays:
I think we need some redesign ....
First some summation on the current state:
There are essentially 3 type scaler :-)
- can use native spectrum paletted colors -- e.g.
normal16
- only can use 565 or 555 colors -- e.g. supereagle16
- only can use 888 colors -- e.g. sai32
There are three type display:
- can do 16 color palette: svga, xlib
- can do 565, 555: sdl
- can do 888: gtk
So, the paletted systems do:
spectrum (16) => scaler (16) => palette lookup (??)
=> display
it can use only the first type scalers
sdl do:
spectrum (16) => palette lookup (555/565) => scaler
(555/565) => display
can use first and second scalers
gtk do:
spectrum (16) => palette lookup (888) => scaler
(888) => display
can use first and third scalers
So, with not so much work, and some new concept we can
make all
display type can use all scaler.
= First:
UI must care on display depth (and endiannes?)
= Second:
scalers will work with only one depth!!! may 555 or
565 or ( or 444 )
is suitable
The new pathway should:
spectrum (16) => paletta lookup ( 555 or 565 or 444
) => scaler (same
depth) => display
ok. the spectrum to scaler is trivial and we do it
before. The change
is only that: palette is common not UI provided !!!!!!!!
the scaler do the work and we need some mangle to
display it... in some
system (sdl/gtk/xlib) we give this work (all or
partly) to the
underlaying API but may better to handle it by own
hands :-)
ok to step up is not so problematic, 555/565/444 =>
555/565/888 is
very easy just shift (and OR)...
the 555/565/444 to palette is not so trivial but...
I think the good pathway is:
555/565 => 444, and make a 4096 length lookup table
is not so painfull
to lookup the closest palette color from the 256 (or
16!!!) palette.
The new pathway include only one addition step, but
this step not always
plus, because the sdl and gtk may do it, under the
surface :-)
This step is easy and fast compared by the other color
mangling steps
inside a scaler (supereagle, sai). BTW the normal
scaler do a lot of
useless work with 'paletted' systems (copy the data
and then the ui copy it
once more) So if we avoid this step we gain a lot of
time :-)
If scaler know the display depth and get a callback
function, it can
'insert directly' to the display the points.. so that
way we could
avoid the double cycle and copy...
With the first type scalers if we provide a 'display
palette lookup fn'
could do shortcut from spectrum to display depth :-)
Ok. If we use the scaler16 set we can make 'run time
switching' between
565/555/444 scaler depth to avoid the 565->555,
565->444, 555->565,
555->444 conversion steps...
SUM:
-------------------------------------------------------------
PAL(16) => 444 => PAL16[444] => disp
PAL(256) => 444 => PAL256[444] => disp
COL(555) sp(16) => 555 => scaler => disp
COL(565) => 565 => disp
COL(888) => 555 => shift888 => disp
-------------------------------------------------------------
Gergely
scalers can compiled as plugins
Logged In: YES
user_id=57243
Sorry, the last table is look so ugly...:
PAL(16) | sp(16) => 444 => scaler => PAL16[444] => disp
PAL(256)| sp(16) => 444 => scaler => PAL256[444] => disp
COL(555)| sp(16) => 555 => scaler => disp
COL(565)|sp(16) => 565 => scaler => disp
COL(888)| sp(16) => 555 => scaler => shift888 => disp
scalers can compiled as plugins updated
Logged In: YES
user_id=57243
Here is an updated patch.
Now "select_bitformat" (scaler_get_setcdepth(scaler)
(cdepth) do this job now) is OK! /But sdl not working
because the "native key" patch.... /
... and some tidy up...
Logged In: YES
user_id=11017
SDL 'native key' support is in patch 1152497, I think we are still waiting to
see whether we use Darren's or Phil's approach. My opinion leans more
towards the approach that is checked in, but modified to use
INPUT_KEYS for Speccy keys, and UNICODE values for the widget UI
(keypress only). A problem would be where would fonts covering
international symbols come from? Maybe it's OK to ask international users
to use the GTK+ (or similar) UI till there are answers to these questions.
I am still building up to looking at your patch in any detail. My initial
thoughts are that I would rather you don't use runtime loaded scalers as
the native version of Fuse for Mac OS X is not built with libtool, making
libtdl support a portability problem.
I am sceptical that anyone who will produce a scaler plugin will not be able
to integrate the lot with Fuse, or what the benefits of that would be, and
using conventional dynamic linking will make my life easier (as far as I
know I am the only person maintaining Fuse scalers outside the main
distribution, as the HQ2X and HQ3X scalers' use of C++ was too
controversial for use in Fuse).
Logged In: YES
user_id=57243
> >Comment By: Fredrick Meunier (fredm)
> Date: 2005-04-16 10:45
>
> (keypress only). A problem would be where would fonts
covering
> international symbols come from? Maybe it's OK to ask
> international users
> to use the GTK+ (or similar) UI till there are answers to
these
> questions.
I think it is not so big problem (the UNICODE chars > 127 )
because the spectrum is mainly pure English (ok, the G chars
??? but for it NO good solution :-) ). I think, if spectrum
is English than not painfull if the menu of the emulator is
"just" English too :-) .Only one point is "critical" when we
"OPEN" or "SAVE" a program, a screen$, etc... But I think
not so badly needed to use too much language specific
character in (host) filenames (hmmm, the Spanish era may
...?? ). I think 99.9+% of "archived" games"s and others"s
name is pure ASCII...
>
> I am still building up to looking at your patch in any detail.
> My initial
> thoughts are that I would rather you don't use runtime loaded
> scalers as
> the native version of Fuse for Mac OS X is not built with
libtool,
> making
> libtdl support a portability problem.
Ok, its anyway can be builded as static link too... BTW,
whats the problem with libtool? libtdl say: its support Mac
OS X, isn"t it?
>
> I am sceptical that anyone who will produce a scaler
plugin will
> not be able
> to integrate the lot with Fuse, or what the benefits of
that would
> be, and
> using conventional dynamic linking will make my life
easier (as far
> as I
> know I am the only person maintaining Fuse scalers outside
the
> main
Ok, the main goal is: we can share the plugin code between
fuse and scrconv some better way, than cut some code from
fuse and insert it into scrconv. Ok. There are two way, 1.
dll; 2. plugin.
1.: Philip was not so enthusiastic when we talk about a new
library to fuse depend on... So the 2. idea is that:
- scrconv could use the binary scaler plugins if found
- if not, scrconv build up this plugins, and use... (as
plugins, or as statical link), but this source code is a
one-by-one copy of the apropriate fuse version...
- the scaler code must be quite independet from fuse, so
now is not true... Inside the scalers there are some tricky
thing...
> distribution, as the HQ2X and HQ3X scalers' use of C++ was
too
> controversial for use in Fuse).
Hey if we use runtime linking... :-) You may make C++ plugin
"package" without disturbing the main C-line conception of
fuse :-)
OK. the only benfit at present state: when someone want to
make changes on scaler code, than not need to compile the
whole fuse again and again... :-)
But have some other little..: I think, the new code is more
straight and "tricky free", the jobs are mixed up at a
lower grade between scalers and UI(*), the scaler selection
done by properties instead of "hand selected" IDs. I know
most of, just "cosmetical" change but :-) it is done... So
Why not use ?-)
The other changes what I suppose are more easily done with
the new code than with the old... Yes. I know theese are not
came from the "pluginifying" procedure, but this code is
working if we link as static (or as dll).
SUMM()=
This is a good solution (I think) to make "better" and more
easy code share between scrconv and fuse without make a new
dependency for fuse (need by Philip :-)
Gergely
(*) I want to move the "old" register_scaler code from the
XXXdisplay.c to scaler.c ...
some bugfix
Logged In: YES
user_id=57243
New updated bugfix patch...
- the common part of uidisplay_scaler_is_usable moved to
uidisplay_check_scaler (uidisplay.c)
-sdl scaler factor handling fixed :-)
-the widget system remember the last scaler :-)
Logged In: YES
user_id=57243
Hi Fred!
>The single biggest problem is
>that the autotools don't support
> Objective-C or Objective-C++
> which are used in the construction
> of the native Mac OS X GUI.
on this link, there are some discussion about autotools + obj-c
http://sources.redhat.com/ml/automake/2003-04/msg00103.html&e=10053
Gergely
P.S.: Sorry if I just waste your time :-(
Logged In: YES
user_id=57243
Here is an updated patch, now the plugins could builded as a
shared library [libfuse_scalers.so], as plugins and static
link, just use the --enable-scaler-dll or --enable-plugins
with configure :-)
Gergely
dll + plugins + static
Logged In: YES
user_id=57243
oops, the correct link is:
http://sources.redhat.com/ml/automake/2003-04/msg00103.html
ok with automake-1.6
Logged In: YES
user_id=57243
Here is a new patch. Now (I hope) everything working with
automake-1.6 too :-).
Please, Fred make an another try with this patch :-)
Logged In: YES
user_id=29214
OK: taking a step back on this one.
* What we want to do is get it such that scrconv can access
the scaler code.
* Another dependency for Fuse would IMO be a bad thing. I
don't think it matters whether that dependency is loaded at
run-time startup (aka a shared library) or dynamically at
run-time (aka a plugin).
* scrconv is pretty much a Fuse-specific utility (as in it's
not going to be very much use to people using emulators
other than Fuse).
* I can't see many other utilities also needing access to
the scaler library.
Given all that, by far the simplest solution to me seems to
be to put scrconv into the Fuse build tree itself, rather
than the fuse-utils build tree, and just statically link it
with the scaler library. Comments, objections?
Logged In: YES
user_id=294680
Putting scrconf in fuse rather than fuse-utils feels wrong
to me. I'd put it in fuse-utils and build the scaler code as
a DLL: scrconv can load it if needed and if installed.
Logged In: YES
user_id=11017
Like Darren, I'd prefer to keep scrconf as part of fuse-utils rather than
Fuse, but I'd prefer this static linking over run-time loaded.
My preferred option is a normal dynamic linking, but I'd take the static link
if it's all we could agree on :)
Logged In: YES
user_id=57243
Philip wrote:
* Another dependency for Fuse would IMO be a bad thing. I
don't think it matters whether that dependency is loaded at
run-time startup (aka a shared library) or dynamically at
run-time (aka a plugin).
So, I not think this shared library or plugin is really a
dependency because builded with fuse itself. So, at compile
time always present... OK strictly it is a dependency, but
no any case when it absend...
OK! At run time, if we remove the dll (but it is really a
problem???) we got trouble... At the case of plugin we
always have a fall-back normal scaler...
There are three solution (I think):
1. We think that: the dll is not a really dependency
(because tide to fuse source)...
2. We build fuse link statically to scaler code and build
dll too, to use scrconv
3. We build fuse as in 2. point and use the fuse source code
to built a statically linked scrconv ...
BTW, Philip why problematic, if we just copy code from fuse
to fuse-utils? We may make such a code what we can use --
without change -- in two cases (fuse and scrconv).
I think, to move scrconv to fuse minimum as bad as we move
scaler code to libspectrum...
Logged In: YES
user_id=57243
OK. to make the things easy:
Is there any objection to change the scaler code to the new
form?
Because from the new code, there is no essential changes to
build as static or dll or plugin. The static and dll is only
some config changes (Makefile.am/configure.in), the
pluginifying is only two new function (call plugins
initialization) and little change in two other function
(find plugins instead of directly register...) controlled by
som #ifdef (configure.in)...
So, if we now aggre the new scaler functions (perfectly the
new scaler supplying functions), later we discuss again
about static/dll, code sharing between scrconv and fuse, etc...
If we comment out the appropriate code in configure.in
scalers ALWAYS build as static link...
I make a SUMM of changes, if we leave out the pluginifying
or dll...
1. The scaler list is now arbitary, and NOT the UI
'register' anymore the "usable" scalers. There is a
'scaler_init'
function which called at the startup.
2. The scaler_info is slightly changed:
-it is transparent from the 'outside world'
-the 'scaler_type' enum disappeared only the 'const char*
id' identify the scaler
-there is an 'expid' member to know which expander needed
for this scaler
-the scaling factor is changed to int and defined some
macro: SCALER_FACTOR_0_5 .. SCALER_FACTOR_3_0 and a
SCALER_FACTOR_SHIFT, so now scaled size computed by pure
integer arithmetic: scaled_size = original_size * factor >>
SCALER_FACTOR_SHIFT;
-there is a member 'expander' to store the expander function
-the flags is changed to indicate scaler properties: e.g.
SCALER_FLAG_COLOR -- need smooth color space,
SCALER_FLAG_TIMEX, etc.
-a next member, to store the address of the next scaler in
the chain
3. There is an expander_info struct to store expander
properties:
-name,
-id (refered by th scaler_info expid )
-fn the function
-and the 'next' field
4. There are two function to find scaler, one search by id
and an other by properties: factor and flag must and flag
must not have...
so the UI can search the stored scaler by id, or a suitable
scaler for the current screen size and color abilities.
5.The changes of UI code: every xxxdisplay.c no include an
uidisplay_scaler_is_usable function and a setup_scaler
function (similar to the old register_scaler). The
setup_scaler try to find a
suitable scaler for the actual image/display size...
6. The reference to the actual display scaler data not
stored in the
scaler.c variables, but in the display_scaler global
variable which defined in the display.c. The expander and
scaler functions reached with the scaler_get_xxx fn-s
7. There are two menu definition to select scaler one in the
widget system and one in the gtk. All this changed paralell
and get closer to eachother. no the widget menu system
remember the last plugin and check it on the select box.
Scan the scalers and (scaler_get_next) and ask
uidisplay_scaler_is_usable to include the list...
Ok, there are some unusable changes (if we do only static
link), for example: the normal "scaler" in the scaler.c, or
splitting the scalers and expanders up to 6 source file, but
i think theese are not so painfull changes and if we make a
final decision to tidy up will be an easy job...
The benefits of the new code (with static build):
1. I think it is more clear
2. more easy to add some new scaler or change something
3. not mixed up the jobs as high grade as the in the current
code between UI and core and scalers
(4. one step toward to make a multi-UI-fuse :-) => UI
selection at runtime instead of compile time)