6.2 Compatibility notes
Hollywood 9.0 API changes
There have been a few API changes in Hollywood 9.0. Most
likely you won't have to adapt your scripts to work with 9.0.
Just check the following notes to see if your script requires
any adaption.
- – On AmigaOS and compatibles, plugins installed in
LIBS:Hollywood
will no longer
be loaded automatically by all executables compiled by Hollywood. Executables compiled by
Hollywood will only load the plugins now that are stored next to the executable in its
directory. If you want your executable to load all plugins in LIBS:Hollywood
as
well, you have to set the GlobalPlugins
tag to True
in the @OPTIONS
preprocessor command or pass the -globalplugins console argument or
tooltype to the program.
- – On Windows, Hollywood's graphics engine has been completely rewritten and uses Direct2D
now. This has many advantages and also makes it possible to use the GPU when the auto scaling
engine is active. In some rare cases, however, your script might be slower with Direct2D than
before, depending on how you do your drawing. If your script runs slower with Hollywood 9.0, you
can either force Hollywood to use its old renderer, which is still supported for compatibility
with Windows versions that don't support Direct2D (i.e. all Windows versions before Vista SP2)
or adapt the way your script draws its graphics. To activate Hollywood's legacy renderer, just
set the
SoftwareRenderer
tag to True
in @DISPLAY. Alternatively, you can
also adapt the way your script draws its graphics to improve performance with Direct2D. On Direct2D,
every drawing operation will always result in a full display refresh, even if just a single pixel
needs to be drawn! Thus, your script needs to draw its graphics in a way that minimizes full
display refreshes. This can be achieved by either using a double buffer or by using BeginRefresh()
and EndRefresh(). See BeginRefresh for details.
- – On Windows, Hollywood will automatically scale your scripts to fit to the monitor's
DPI on high-DPI monitors now. This guarantees that they will appear in the correct size on high-DPI
monitors as well. If you don't want that, set the new
DPIAware
tag to True
in the OPTIONS
preprocessor command. This is especially recommended for GUI applications because they will look
much better when the program is DPI-aware.
- – Loaders and adapters are now handled in the order they appear in the string that is
passed to a
Loader
or Adapter
table argument. For example, if you pass the string digibooster|xmp
to OpenMusic(), it will first try to open the music using digibooster.hwp
and only if that fails will xmp.hwp
be asked to open the file. This also allows you to
prioritize generic loaders like Native
, Inbuilt
and Plugin
, e.g. if you want native and
inbuilt loaders to be used before plugin ones, you could pass the string native|inbuilt|plugin
to achieve that. Note that although this is an API change there are probably no scripts which
really depend on the old behaviour because the order was mostly random.
- – When a non-existing path was passed to ChangeDirectory(),
the function failed silently and didn't show an error. This has been changed now.
ChangeDirectory() will trigger an error now if a non-existing
path is passed to it.
- – When CopyFile() couldn't copy a file because the file already
existed and was write- or delete-protected, CopyFile() silently
skipped the file. This is no longer done. An error will be thrown now if an existing
file can't be overwritten. If you really need the old behaviour, use a callback function and
return
False
whenever you get a #COPYFILE_UNPROTECT
message.
- – The optional
transcolor
argument in SaveBrush() now defaults
to #NOCOLOR
instead of #BLACK
. Having #BLACK
as a default didn't really make much sense
because you wouldn't want SaveBrush() to mess with the image data
but just write it to disk.
- – SaveAnim(), BeginAnimStream() and
WriteAnimFrame() no longer support the
Transparency
and
UseAlpha
tags because they just didn't make sense. Transparency and alpha settings
are now determined solely by the format of the source data that is passed to these
functions.
- – When
KeepProportions
is active for a display and DisplayBGPic()
or ChangeDisplaySize() is called, the scaling dimensions are now
re-calculated to fit the aspect-ratio of the new BGPic or display size. This change also
affects SetDisplayAttributes() when it is called with Width
and Height
parameters.
- – If the
Monitor
tag isn't set in the optional table argument, ChangeDisplayMode()
will now always automatically detect the monitor the display is on. So if it is on
a second monitor and you call ChangeDisplayMode(#DISPMODE_FULLSCREEN)
, that monitor
will be put into fullscreen mode. Previously, always the first monitor was used (except if the
Monitor
tag was set for the display).
- – Videos handled by the operating system's native video renderer (i.e. DirectShow
and Media Foundation on Windows, AVFoundation and QuickTime on macOS) are now automatically
resized and repositioned when a display is resized by the user, even if no scaling engine
is active. This is done purely for aesthetic reasons because otherwise it looks really
ugly. You can forbid this behaviour by setting the
NoLiveResize
tag in @DISPLAY.
Note that videos managed by Hollywood's inbuilt video renderer won't be resized and
repositioned automatically, it's only done for videos managed by the OS.
Hollywood 8.0 API changes
There have been no API changes for Hollywood 8.0.
Hollywood 7.1 API changes
There have been some small API changes in Hollywood 7.1. Most
likely you won't have to adapt your scripts to work with 7.1.
Just check the following notes to see if your script requires
adaption.
- – There have been some minor changes to Hollywood's platform-independent catalog
format. Lines that start with semicolon are now considered comments and are ignored.
If you need to define a catalog string that starts with a semicolon, you need to
prefix the semicolon with a backslash. Furthermore, empty lines are ignored now and
strings ending in a single backslash are considered multi-line strings. It might be
necessary to fix your catalogs to be compatible with the new format. See Using catalogs for details.
Hollywood 7.0 API changes
New plugin and keyfile location on Windows, macOS, Linux, and Android
First of all, Windows, macOS, and Linux users should note that in Hollywood 7.0 plugins
must now be stored in a Plugins
subdirectory that must be in the same directory
as the Hollywood executable on Windows and Linux. On macOS, the Plugins
directory
must be stored inside the application bundle, i.e. inside the HollywoodInterpreter.app/Contents/Resources/Plugins
directory.
Note that HollywoodInterpreter.app
is stored inside the Hollywood.app
application bundle, namely in Hollywood.app/Contents/Resources
. On Android, plugins
must now be stored inside the Hollywood/Plugins
directory on your SD card (instead
of Hollywood/_Plugins
as in earlier versions). On AmigaOS and compatibles, plugins must
be copied to LIBS:Hollywood
as usual.
Note that executables compiled by Hollywood will still load plugins from the same directory
as the executable (except on macOS where they must be inside the app bundle's Resources
directory).
Hollywood itself, however, will now need the plugins inside a Plugins
subdirectory on Windows,
macOS, and Linux as described above.
macOS users please do also note that the file Hollywood.key
must now be copied
to HollywoodInterpreter.app/Contents/Resources
as well. It must no longer be in
the HollywoodInterpreter.app/Contents/MacOS
directory.
Important Unicode notes and other API changes
Since Hollywood 7.0 introduces Unicode support there might be some compatibility issues
with your old scripts. If you don't want to adapt your scripts, you can simply run them
in non-Unicode mode by disabling Unicode like this:
| @OPTIONS {Encoding = #ENCODING_ISO8859_1}
|
If you add this as the very first line of your script, Hollywood will run your script
in legacy mode and there shouldn't be any compatibility issues. However, your script
will run in ISO 8899-1 mode then which means that it won't run correctly on non-Western
European systems.
Thus, it is recommended that you don't run your script in legacy mode but use Unicode
mode all the time. Most scripts will probably run just out of the box without any issues
and without any need for adapting anything. If your script shows compatibility issues
with Hollywood 7.0, please read the following list of API changes in Hollywood 7.0 to
learn how to fix your scripts.
- – First of all, make sure to save all your scripts in UTF-8 encoding now. When running
your old scripts with Hollywood 7.0, Hollywood will first check if they contain only valid
UTF-8 characters. If they don't, Hollywood will assume they are in ISO 8859-1 encoding (or
the system's default encoding on Amiga) and convert them to UTF-8 automatically. Since this
automatic conversion might lead to problems with scripts using a different encoding than
ISO 8859-1 it is highly recommended to save all your scripts in UTF-8 now.
- – Since Hollywood 7.0 runs in Unicode mode by default now, the default string encoding
is set to
#ENCODING_UTF8
now as well. This means that you'll run into problems if your
script tries to use the string library functions to access the raw binary data of strings.
When the string encoding is set to #ENCODING_UTF8
, the string library functions can only
deal with strings that contain valid UTF-8 text. In Hollywood, however, strings can also
contain binary data. For example, you could download a file into a string using DownloadFile()
and then find out its length using StrLen(). This won't work when Hollywood
is in Unicode mode (i.e. when the default string encoding is set to #ENCODING_UTF8
) because StrLen()
will expect valid UTF-8 data then. To work around this problem, you have to pass #ENCODING_RAW
to StrLen() to tell it that the string you passed contains raw binary data
instead of valid UTF-8 text. Likewise, most other functions of the string library accept
an additional encoding
parameter now too which you can use to set the character encoding of the
string you pass. If your script doesn't use the string library functions to operate on raw
binary data, you won't have to worry about anything and your script should work flawlessly
in Unicode mode.
- – The default text encoding is also set to
#ENCODING_UTF8
automatically by Hollywood 7.0.
This means that functions like TextOut() and Print() will
expect UTF-8 encoded text now. This isn't a problem if you just convert your script to UTF-8
but it could lead to problems if the text to be printed is read from a file (or other external
source) that doesn't use UTF-8 encoding.
- – ReadChr() and WriteChr() may now read and
write up to 4 bytes instead of just a single byte if Hollywood is in Unicode mode. That
is because they'll now really deal with characters, just as their names imply, and in
UTF-8 a character may need up to 4 bytes for storage. If you want to read and write
single bytes, you have to use the new ReadByte() and WriteByte()
functions now.
- – ReadString() and WriteString() can no
longer be used for binary I/O because they read and write strings, i.e. a number of characters
(not bytes!), just as their names imply. If you need to read and write raw binary data, use the
new ReadBytes() and WriteBytes() functions now.
- – ReadChr(), WriteChr(), ReadString(),
and WriteString() now read and write UTF-8 characters by default.
If you use them to read data from non-UTF-8 text files, there can be problems with
non-ASCII characters. In that case, you have to tell those functions to read ISO 8859-1
characters instead by passing
#ENCODING_ISO8859_1
in the optional encoding
argument.
- – You are now discouraged from using the
OnKeyDown
and OnKeyUp
event handlers for
non-English characters. Non-English characters should be handled by the new VanillaKey
event handler instead which has full Unicode support. OnKeyDown
and OnKeyUp
will continue
to work as before but using non-English characters with them is generally unsafe. It might
work on your system but not on systems with a different locale. Only use VanillaKey
to
handle non-English characters please.
- – The IsKeyDown() and WaitKeyDown() functions
no longer support non-English keys. If you need to get the state of a non-English key,
use the
VanillaKey
event handler instead.
- – The platform-neutral format supported by OpenCatalog() now
has to be in UTF-8 character encoding, with or without BOM. ISO 8859-1 files are no
longer supported.
- – Multi-byte character constants like 'ABCD' are no longer supported because they
conflict with UTF-8 character constants supported by Hollywood 7.0. If your script
uses multi-byte character constants, you have to rewrite your script to use the
direct numeric value of the character constant instead.
- – Hollywood 7.0 introduces the FallThrough statement which
allows code to fall through to the next Case statement in a
Switch-Case statement. This addition means that it is no longer
allowed to use variables or functions which are called
FallThrough
. This will trigger
an error because FallThrough
is a reserved token now.
Hollywood 6.0 API changes
There have been some small API changes in Hollywood 6.0. Most
likely you won't have to adapt your scripts to work with 6.0.
Just check the following notes to see if your script requires
adaption.
- – Since Hollywood 6.0 comes with built-in support for vector-based
drawing, the vectorgraphics library no longer automatically uses the
first vectorgraphics plugin it can find. Instead, it will use Hollywood's
inbuilt vectorgraphics renderer by default now. If you don't want this,
you will have to call SetVectorEngine() to
tell the vectorgraphics library which plugin to use when drawing
vectorgraphics.
- – The ChangeDisplayMode() command no
longer puts all displays onto a single full screen but only the active
one is switched to full screen mode. This change was necessary because
Hollywood 6.0 introduces multi-monitor support which makes it possible
to have multiple displays in full screen mode on separate monitors.
- – Hollywood's display handler has been rewritten and does
not support the display mode
OwnScreen
any longer. OwnScreen
was a special mode that could be used on AmigaOS and compatibles
to make Hollywood open in fullscreen mode but keep the traditional
Amiga screen look, i.e. Hollywood would not open a shielding window
that covered the Amiga screen decorations. If you want to achieve
the look that the OwnScreen
display mode gave you with Hollywood 6.0,
you have to use the console arguments ‘-nobackfill’ and ‘-nostyleoverride’
together with ‘-fullscreen’. Then the appearance should be
exactly the same as the old OwnScreen
display mode which is no
longer supported by Hollywood 6.0.
- – Prior to Hollywood 6.0 display attributes specified in the
@DISPLAY preprocessor command automatically overrode
the display attributes that were specified on the command line, i.e.
if the
Borderless
attribute was set to False
in @DISPLAY
and the script was started using ‘-borderless’, then the
script would still appear with a bordered window because the specifications
in @DISPLAY were given priority over the command
line specifications. Starting with Hollywood 6.0 this behaviour has
been turned around: Display attributes set on the command line will
now override display attributes specified in preprocessor commands.
If you do not want this behaviour, compile your script using the
‘-locksettings’ mode. Then command line arguments won't be
able to override your preprocessor display settings.
- – Prior to Hollywood 6.0, command line arguments that affected
the display style were applied to all displays defined in the
preprocessor commands of your script. For example, if you started
a script that defined four displays in the preprocessor commands
with the ‘-borderless’ argument, all four displays would
be opened in borderless mode. In Hollywood 6.0, command line arguments
that modify the display style will only be applied to display number 1
by default. If you want them to affect all displays, you have to use
the new ‘-alldisplays’ argument.
- – Some command line arguments have been renamed for purely
cosmetic reasons: ‘-audiodev’ is now called ‘-audiodevice’
and ‘-depth’ is now called ‘-scrdepth’. Their functionality
hasn't changed.
- – Dropped support for
mpega.library
on AmigaOS and
compatibles. mpega.library
caused quite some trouble because
it usually recognized every file format as an MPEG stream leading to several
unwanted effects. If you need to play MP3s you can just use a plugin like avcodec.hwp
instead.
Hollywood 5.0 API changes
There have been some small API changes in Hollywood 5.0. Most
likely you won't have to adapt your scripts to work with 5.0.
Just check the following notes to see if your script requires
adaption.
- – The plugin interface has been completely rewritten and
is no longer compatible with old plugins. On Amiga systems,
plugins must always be installed into
LIBS:Hollywood
now.
The old plugin location Hollywood:Plugins
is no longer
supported by Hollywood 5.0. Alternatively, plugins can be
installed into the program's directory (especially useful when
you have to distribute plugins with executables compiled by
Hollywood).
- – Shadow and border effects on layers will look different (better!)
in comparison to previous versions because Hollywood now uses
real alpha channel compositing for this. The downside is that
the new shadow and border effects are slower than in previous
versions.
- – Shadow and border are now global settings for every layer.
This means that you can no longer have layers that have multiple
shadow or border styles (e.g. a text layer where only part of
the text has a shadow or a border). That is no longer supported.
Either the layer has a shadow/border, or doesn't have one. But
it is no longer possible to have a shadow/border for just a part
of a layer.
- – Layers with a border will be displayed differently now when
they are shown or hidden with a transition effect. Because the
border is no longer part of the main layer in Hollywood 5.0, the
transition effect for the border cannot be combined with that of
the main layer any more. Thus, Hollywood will now simply fade in/out
the border while the main layer's transition effect is being
displayed. If you do not want this behaviour, you can use the
new
NoBorderFade
tag.
- – For reasons of consistency, Hollywood no longer supports thick
layers when the fill style is set to
#FILLNONE
because the thick
layer concept clashes with the new layer border concept. Thus,
instead of a thickness setting, layers will now get a border of
the specified 'thickness' size to make them thicker. The main layer,
though, will always have a thickness of 1. If you want to increase
this thickness, just enable the layer border and set the desired
thickness size in the BorderSize
tag.
- – As Hollywood 5.0 introduces support for vector images,
CreateGradientBGPic() and
CreateTexturedBGPic() will now
create a vector BGPic for you. This means that you can no longer
modify the graphics of these BGPics using the SelectBGPic()
function. Another difference is that when a textured BGPic gets scaled
(e.g. when the user resizes a window), Hollywood will not
scale the textured BGPic but will remake it in the new resolution.
Prior to 5.0, the textured BGPic just got scaled. Starting
with 5.0, the BGPic will be completely remade.
- – Prior to 5.0, the CopyFile() and DeleteFile() functions
accepted wildcards in the filename argument. This is no longer
supported. If you want to copy/delete files selectively, you
have to use an optional argument now. See the documentation
of these two functions for more information.
- – Prior to 5.0, Hollywood used AmigaOS style pattern matching
functions in MatchPattern(), CopyFile(),
and DeleteFile(). Starting with version 5.0,
Hollywood uses platform-independent pattern matching functions
that differ from AmigaOS style patterns in some cases. See MatchPattern for details.
- – Long strings [[...]] behave differently in Hollywood 5.0
if your script was saved using carriage return plus linefeed
encoding (CR+LF encoding is the text editor default on Windows;
Amiga and Unix systems just use LF characters for line breaks).
Previously, carriage return characters ('\r') were always included
in the long string. This is no longer the case. All line breaks
will be converted to single linefeeds now ('\n'). If a carriage
return character is present, it will be dropped. This change has been
made to prevent that scripts behave differently when saved on
Windows and on AmigaOS/Unix/Mac.
Hollywood 4.5 API changes
There have been some small API changes in Hollywood 4.5. Most
likely you won't need to adapt your scripts to work with 4.5.
Just check the following notes to see if your script requires
adaption.
- – RotateLayer() will behave differently in 4.5 than it did in
4.0. This break was necessary because Hollywood 4.5 introduces
anchor points for layers. In Hollywood 4.0, RotateLayer()
rotated the layer around its center, thus assuming a 0.5/0.5
anchor point. In 4.5, however, all layers have a default
anchor point of 0.0/0.0. Thus, if you would like to replicate
the 4.0 behaviour, you need to change the layer's anchor point
to 0.5/0.5 by calling SetLayerAnchor().
- – executables compiled for macOS will now look in the
"Resources" folder of the application bundle ONLY for data
files. This change was made to comply with macOS UI
guidelines. All data files accompanying an application must
be put into its app bundle
- – when using CreateSprite() to create sprite links (i.e. source
type
#SPRITE
), you previously could also create links from
sprite links. This is no longer possible. When creating sprite
links, you always have to specify a sprite that is not linked
as the source sprite
- – when using
#VANILLACOPY
with SetAlphaIntensity(), Hollywood
previously sometimes did not draw anything at all. e.g. if
you tried to draw a brush with mask to an alpha channel using
SetAlphaIntensity() with #VANILLACOPY
set. This behaviour has
changed now: Hollywood will draw the visible mask pixels as
255 alpha intensity now and the invisible mask pixels as 0.
- – SelectBGPic() had a secret feature that was never documented
anywhere (and thus not official): If you used SelectBGPic()
with layers enabled on the current BGPic, all layers inserted
before EndSelect() were inserted as hidden layers. This
behaviour is gone now. SelectBGPic() will now insert normal
layers and draw them when EndSelect() is called. If you want
to have the previous behaviour, create your layers with
Hidden
set to True
.
Hollywood 4.0 API changes
There have been some small API changes in Hollywood 4.0. Most
likely your won't need to adapt your scripts to work with 4.0.
Just check the following notes to see if your script requires
adaption.
- – SetPointer() syntax has completely changed. It does no longer
accept a filename but requires you to call CreatePointer()
first.
- – all of the transition effects library functions as well
as PlayAnim(), the MoveXXX() functions & DisplayBGPicPart()
use a new syntax now. However, the old syntax is still
supported for compatibility reasons.
Hollywood 3.1 API changes
There have been some small API changes in Hollywood 3.1. Most
likely your won't need to adapt your scripts to work with 3.1.
Just check the following notes to see if your script requires
adaption.
- – Colon is no longer supported as a command separator. In
Hollywood 1.x the colon had to be used to separate multiple
commands on the same line, e.g.
| ; Hollywood 1.x code - NO LONGER SUPPORTED
x=100:y=200:width=50:height=50:Box(x, y, width, height, #RED)
|
The 1.x emulator inside of Hollywood emulated this behaviour
up to Hollywood 3.0. In Hollywood 3.1 it is now no longer
supported because the colon is needed for object oriented
programming. So you need to update your scripts if you are
still using colons to separate multiple commands on a single
line. Since Hollywood 2.0, you can put as many commands on
a single line as you desire, so the above code could now be
written as:
| x=100 y=200 width=50 height=50 Box(x, y, width, height, #RED)
|
This does not look very nice so you should probably refrain
from calling multiple commands on the same line altogether.
Of course, the choice is with you. Just keep in mind that
Hollywood 3.1 does not emulate the colon behaviour of 1.x
any longer.
- – The
#TYPEWRITER
transition effect is gone now. This was a
special effect which could only be used on text objects.
However, it made the font interface unnecessarily complex
so it had to go. You can emulate the #TYPEWRITER
behaviour
by just using a series of Print() calls.
Hollywood 3.0 API changes
There have been some small API changes in Hollywood 3.0. Most
likely your won't need to adapt your scripts to work with 3.0.
Just check the following notes to see if your script requires
adaption.
- – If Hollywood 3 is started without any arguments, it will open
in windowed mode. All previous versions opened full screen
in that case, but I think it is much wiser to have Hollywood
open in windowed mode because full screen mode might not work
on every system.
- – Command line arguments are now handled differently. You must
prefix them with a dash character (-). In previous versions
you would call Hollywood like this:
| Hollywood script.hws WINDOW BORDERLESS
|
This will not work any longer! You now have to use dashes.
The correct way to call Hollywood now is:
| Hollywood script.hws -window -borderless
|
This change was necessary because of the new GetCommandLine()
function which allows you to work with your own arguments.
- – The second argument of FileRequest() has changed. Previously,
it was a pattern in the AmigaDOS pattern format. Now it is
merely a filter string that specifies which files shall be
displayed by the requester. This change was necessary because
of the new cross-platform nature of Hollywood. Operating
systems as Windows and macOS just don't have such elaborate
filter pattern handlers as the AmigaOS offers.
- – In previous version the optional third argument of the
OpenFile() function fell back to
#MODE_READWRITE
if it was
not specified. This has been changed. Now the default mode
is #MODE_READ
. This is a vanity API break. I just think it
makes much more sense to open files in read-only mode by
default.
Hollywood 2.5 API changes
There have been some small API changes in Hollywood 2.5. Most
likely your won't need to adapt your scripts to work with 2.5.
Just check the following notes to see if your script requires
adaption.
- – Support for
ttengine.library
has been removed. Of course
Hollywood does still support true type fonts. The only
thing which you can do no longer is to use SetFont() on
*.ttf
files directly, i.e.
| SetFont("dh1:arial.ttf") ; this is Hollywood 2.0 code!
|
This does not work any longer. In Hollywood 2.5, you can
only use true type fonts which have been installed into
your system using FTManager or a similar tool. You open
them as if they were normal fonts, i.e.
| SetFont("Arial Narrow.font") ; OKAY in 2.5!
|
You have to do it this way because Hollywood 2.5 loads all
true types through the bullet.library compatible ft2 (OS4)
or freetype2 (MorphOS, AROS, AmigaOS3) interfaces respectively.
- – The CheckEvent() command has been removed. It did not fit
into the concept any longer. Please always use WaitEvent()
instead.
- – The Plot() command does only work with disabled layers now.
Layers of type
#PLOT
are no longer possible. It just does
not make much sense to have 1x1 sized layers. If you really
need that, you can use the Box() command to draw a pixel.
- – Due to the new text rendering engine, it is now mandatory
to use two square brackets in the strings you pass to Print(),
TextOut() and CreateTextObject() when you want to print a
single square bracket. For instance, the following code
| Print("[Hello World]") ; this is Hollywood 2.0 code!
|
would generate a syntax error in Hollywood 2.5 because the
new text engine expects a formatting command after a square
brackets. Thus, you would have to write it as follows:
| Print("[[Hello World]]") ; OKAY in Hollywood 2.5!
|
Then it will work as you expect it.
- – If the fill style is set to
#FILLTEXTURE
or #FILLGRADIENT
and you draw using a ARGB value, these fill styles will
now also respect the alpha value. This was not the case
in Hollywood 2.0.
- – If layers are enabled and you call a command from the draw
library (e.g. Ellipse()) and specify an ARGB color (i.e.
you want to draw with transparency), Hollywood 2.0 would
create a transparent layer for you as if you called the
SetLayerTransparency() function with the A byte of the ARGB
value as the transparency setting. This is no longer done
in that way. If you draw with an ARGB color, Hollywood 2.5
will not give the layer a transparency setting, although
the layer has of course a transparency now, but with 2.5
the transparency is already rendered to graphics data (i.e.
the alpha channel) and is not kept dynamic as in the case
of SetLayerTransparency().
- – Up to Hollywood 2.0, RotateBrush() always returned a brush
of the maximum size that a rotation with the source brush
could occupy, i.e. maxs = sqrt(width * width + height * height).
The new brush allocated by Hollywood would then be of width
and height 'maxs'. This is no longer done now. The brush is
exactly as big as it needs to be to contain all graphics.
- – In Hollywood 2.0, WriteMem() and ReadMem() always used
unbuffered IO while all the other DOS functions used buffered
IO. Now all functions have been unified and they use all
buffered IO by default. Furthermore, in Hollywood 2.0 WriteMem()
always automatically flushed buffers before starting the write
operation. This is no longer done in 2.5. So, if you used
WriteMem()/ReadMem() in your scripts and you need it to have
unbuffered IO like in 2.0, you first have to call SetIOMode()
to change the IO mode to unbuffered. Then it will work as
you are used to it but remember that it does not flush the
buffers as in Hollywood 2.0. And remember that once you call
SetIOMode() all other DOS functions will also use the IO mode
set here! If you only want unbuffered IO for WriteMem() or
ReadMem() you have to use SetIOMode() again after your call.
You also have to call FlushFile() manually if you switch from
buffered to unbuffered IO on the same file. This all might
sound a bit complicated, but it is really easy. In fact, it
gives you full control over the DOS functions which can come
in pretty handy at many times. Please see the documentation
of SetIOMode() for more information.
- – Up to Hollywood 2.0, TextOut() would automatically align the
text if a special coordinate constant like
#CENTER
or #RIGHT
was specified as x
. This is no longer done in this way. There
is a new argument which you can use to specify the desired
alignment.
Hollywood 2.0 API changes
Although Hollywood 2.0 is a gigantic update, only little API
changes were necessary. Here is a list of things you have to
change in your script:
- – If you call functions that do not accept any arguments but
return a value, you have to use brackets. For example, the
following code worked in 1.9 but does no longer work in 2.0:
| ; wrong!
x = MouseX
y = MouseY
|
You have to write this as:
| ; correct!
x = MouseX()
y = MouseY()
|
The wrong version will not trigger a compiler error by the
way. It is correct Hollywood code but does something completely
different: It assigns the function MouseX() to the variable x
which is not what you want.
- – GetTimer() always returns the value in milliseconds now. In
Hollywood 1.x the default unit was seconds. This is a vanity
API break. Of course, I could have kept the old implementation
but honestly, there's noone who wants a return value in seconds
because it is just too unprecise. Thus, I decided to do programmers
a favour and make milliseconds the default, so you do not have
to type the lengthy GetTimer(1,
#MILLISECONDS
) every time but
just GetTimer(1).
- – The MoveBrush(), MoveTextObject(), MoveAnim()... functions can
no longer "grab" old objects. For example, the following code
does not work correctly in 2.0:
| MoveBrush(1, #LEFTOUT, #CENTER, #CENTER, #CENTER)
Wait(100)
MoveBrush(1, #CENTER, #CENTER, #RIGHTOUT, #CENTER)
|
In Hollywood 1.x, this code moved the brush 1 from the outer
left to the center, waited 100 ticks, and moved the brush to
the outer right. In Hollywood 2.0 it will do the same, but the
a copy of the brush will remain in the center of the display.
This is due to major changes in the refresh system. If you want
to imitate the 1.x behaviour, use MoveSprite() instead of
MoveBrush().
- – DisplayTransitionFX() can no longer be used to display
transparent background pictures; switching to transparent
BGPics can only be done without an effect now. This is
because Hollywood 2.0 uses real transparent windows on
MorphOS, OS4 and AROS now. Those windows have a layer where
no graphics can be drawn.
- – In Hollywood 1.x, MixBrush() scaled the two brushes to the
same size if they were of different dimensions. This is no
longer done. MixBrush() just mixes the parts that match and
drops the rest.
- – RotateBrush() will now create a mask for the brush if it does
not have one. You no longer have to do this on your own.
- – If layers are enabled and you use InKeyStr() only one layer
of type
#PRINT
will be installed by InKeyStr(). In Hollywood 1.x,
InKeyStr() left a #PRINT
layer for each character.
Hollywood 1.9 API changes
There were some minor API changes in Hollywood 1.9, which are
listed here:
- – the commands EnableEventHandler() and DisableEventHandler()
were removed. They could cause much trouble because if you
use them, you do not know when your event procedures are
called. Please use the new CheckEvent() function now!
- – EnablePrecalculation() and DisablePrecalculation() were
removed because effect precalculation is no longer supported by
Hollywood. The PRECALCULATION argument/tooltype is also
gone now.
- – WhileMouseOn() had some changes that you will most likely
not notice but under certain circumstances you might get
a problem with it now: In earlier versions, Hollywood would
immediately jump back to your WaitEvent() loop after an
ONBUTTONCLICK event occurred. This was a wrong behaviour!
Now it will jump back to your WhileMouseOn() command because
the mouse is still over your button after ONBUTTONCLICK
occurred. If you want Hollywood 1.9 to behave like Hollywood
1.0 and 1.5 did, you need to use the new BreakWhileMouseOn()
command
Hollywood 1.5 API changes
Unfortunately I had to make some API changes to the Hollywood
language in the 1.5 update. If your script does not work
correctly under Hollywood 1.5 but worked under 1.0, please
read the following information and adapt your script.
- – the constant syntax has changed. In Hollywood 1.0 you just
specified constants by their name but now you will have to
specify also a '#'-prefix. So you have to specify e.g.
#CENTER
instead of CENTER and #BOLD
instead of BOLD. I'm
sorry but this change was absolutely necessarily.
- – Undo() will not work until you have called EnableLayers().
If you are using Undo() in your script, make sure you
call EnableLayers() at the beginning.
- – syntax of PlaySample() has changed. You can no longer
specify a channel for playback. Hollywood will do everything
for you. Just specify the sample number and if it shall
be looped or not.
- – syntax of PlayAnim() has changed. It runs now synchronously.
This change was necessary because the old PlayAnim()
implementation did no longer fit in the concept. If you
need to play anims asynchronously, use brush links of
frames and display them with DisplayBrush(). Because
PlayAnim() is synchronous now, the commands IsAnimPlaying()
and WaitAnimEnd() are no longer required and were removed.
- – ClearScreen() was removed because it did no longer fit in
the concept.
- – LoadModule() does not load THX, P61 or MED modules any
longer. Module support now concentrates on the Protracker
format. Other module formats cannot be played back cleanly
through AHI.
- – Print() does no longer support anti alias for true type
fonts. This change was currently necessary to stay
compatible with layers. Anti aliasing will be re-introduced
for all objects in Hollywood 2.0.
Show TOC