Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Mequa]

I see the AMOS Animation Language hasn't gotten much love, even here.  

I have created an almost-complete implementation of AMAL in Clickteam's (now defunct) Jamagic language. It used an interpreter (running on an interpreter) and was somewhat slow, especially when parsing the AMAL strings.

I am currently in the process of developing a reimplementation of the AMOS Animation Language in Java.
My goal is to enable AMAL scripts to be created using standard Java Swing text editing, and ran from a Java applet via an interpreter, on both PCs and mobile devices.
It should also be possible to compile AMAL scripts directly to Java classes in Java code, which would be compilable into Java bytecode and runnable cross-platform via JIT compilation.

For the graphical engine I will use an open-source Java game engine such as JGame. This will also enable graphical effects far exceeding the Amiga, such as transparency effects via OpenGL enabling multiple parallax across various "screens", directly controllable via AMAL scripts. "Bobs" and "Sprites" would be implemented appropriately alongside "screens".

If I complete this project, I hope to release it under a BSD-style licence.

Due to various commitments, I am unlikely to have this project completed before Summer 2011.
However, if I ever get it working, I would look to do a C++ rewrite. Perhaps even an ANSI C rewrite if this would be useful for the Mattathias BASIC project.

[SamuraiCrow]

I voted "UGH! Forget it already!" because it was essentially just a kludge to get animations to compile to faster machine language than the AmosPro compiler.  Also, Mattathias is on indefinite hold because it was taking too long to implement and Sidewinder and I ran into financial hardship as a result.  If Mattathias was still being actively developed, I would have said to go for it, but I'm just involved in portions of the project that I think will yield results quickly enough and broadly enough to be applied to other projects if at all possible.  AMAL would have been the last part of the project to be implemented anyway.   

[Lonewolf10]

I voted "It may have some historical interest."

It was a great idea, and some people did manage to make some great use of it. But for me the 2 letter instructions were just too hard to remember and I prefer using normal commands (or assembler) for my software.


Regards,
Lonewolf10

PS. Sorry to hear about Mattathias. I hope the project gets completed someday, perhaps when the economy picks up (solar flares allowing).

[SamuraiCrow]

PS. Sorry to hear about Mattathias. I hope the project gets completed someday, perhaps when the economy picks up (solar flares allowing).

Considering the next Blood Moon (lunar eclipse) is on the Winter Solstice, 2010, it looks like the Dreadful Day of the Lord is at hand.    Reference:  Joel 2:31-32.

In the meantime, I'm going to see about working on a shared-library collection of container classes with Chris Handley, the author of PortablE.  This could potentially be used with another object-oriented language.  Toward the end, we looked at making Mattathias into two projects: one AmosPro clone and one OOP language.  Perhaps PortablE will be that OOP language.

Maybe, if we are still around after the Second Coming and the Mattathias project makes sense in a few years, Sidewinder and I'll restart the Amos-clone aspect of Mattathias.  It's possible that Freddix will continue his DarkBasic clone though so we can look into helping with that instead.

[Mequa]

I voted "UGH! Forget it already!" because it was essentially just a kludge to get animations to compile to faster machine language than the AmosPro compiler

AMAL's compiler pre-dates the AMOSPro compiler.

AMAL added to AMOS the means to develop sprite scripts which run concurrently, effectively a primitive form of multi-threading. Without AMAL, managing multiple animated sprites in a procedural BASIC such as AMOS is cumbersome at best. AMAL effectively allowed each sprite to have its own unique program flow. This was an impressive trick which allowed a more concurrent programming style than otherwise permitted by AMOS (as well as being faster).
In allowing AMAL "channels" to be re-used for different sprites, AMAL also introduced a primitive form of object orientation.

AMAL was straightforward enough for me to become more-or-less fluent at the age of 10.
(This cannot be said for the AMOSPro Interface language, however, which I never bothered with.)

My Java reimplementation of AMAL is for my own interest, although I am happy to put the source out there (once it's completed) for anyone to re-use.
François Lionet has also expressed an interest in this project.

[Mequa]

Just a quick mock-up (not final) of my proposed name and logo for this project: "jAMAL"



I have also obtained permission from François to use the names AMOS and AMAL.

[Lonewolf10]

AMAL was straightforward enough for me to become more-or-less fluent at the age of 10.
(This cannot be said for the AMOSPro Interface language, however, which I never bothered with.)

You got lucky, because the Interface examples in the manual don't seem to work. I did try it a few years back, but didn't get anyway. I did find code within the AMOS Pro executable which suggests that Francois used it for the bit that pops up after loading.


Regards,
Lonewolf10

[Mequa]

Just to announce that my Java-based AMAL Lexer is well underway.
This will form the basis of an AMAL interpreter runnable from a Java applet.

At the moment, the Java-based lexer can understand and parse all AMAL instructions (including differentiating between PLR0=X and P LR0=X, for instance).
I have attached an output module which currently generates Java-style pseudo-code. My aim for this module is to output ready-to-compile Java code.

I have attached two AMAL scripts loadable via one standard ASCII text file, a stripped version of both scripts auto-generated by the lexer (which also works), and the output code. The output is not yet buildable, but gives a rough look at how both my AMAL compiler and interpreter will handle the code.

This output module will form the basis for an AMAL compiler, allowing generated Java code to be compiled with a Java compiler to Java bytecode (runnable via JIT compilation). However, it is likely that interpreted mode will be fast enough anyway (and most likely the only option in an applet).


Still to do for jAMAL Lexer:
- Allow numeric values (including hex $ABC) to be entered
- Allow complex expressions such as X*Y+A (evaluated strictly left-to-right)
- Allow functions such as XS(XM) and Z(256)
- Optimise data structures, split code to more classes, more testing

Once this is working, I'll be on to writing an interpreter and integrating it with something like JGame to simulate AMOS screens, bobs, sprites and rainbows.

[Mequa]

Approximate release date: July 2011

[Mequa]

Update: The jAMAL lexer now understands a considerable subset of AMAL, some major fixes have already been implemented.

I include the same kind of output as before, this time with input of 3 AMAL scripts.

I lifted some AMAL code directly from an AMOS game to illustrate - only Move and Anim are missing from this example (commas are still a WIP).

- Mequa

P.S. Correction to earlier - the correct AMAL code is XS(0,XM) for screen 0. This is also still being worked on.

[Mequa]

We have action!
The jAMAL interpreter (and lexer) is now working - in both Java application and applet mode - in conjunction with a basic jGame sprite.
The sprite's position is now directly controllable via an AMAL script. In Java.

AMAL scripts are loadable from an ASCII file either from disk or as an applet-friendly resource file.
(Most of AMAL is implemented already, there are just a few complex expressions/functions to debug.)

I'll likely beef up the AMOS simulation module over Christmas, and debug the lexer and interpreter some more.
A demo will follow shortly. (Source to be released next summer)

[Mequa]

Update: Make that 32 sprites controlled by 32 separate AMAL scripts (duplicated) on 32 channels. I believe I've surpassed AMOS?
Running smooth (well as smooth as possible without JOGL). Much faster than my Jamagic prototype.

The script I tested was the third one from earlier (with the Autotest), it works fine.
It can also dynamically load AMAL scripts from Java strings, just like in AMOS.

[Mequa]

I present my first public release: jAMAL alpha demo 0.1.

jAMAL.jar and readme.txt files enclosed in a zip file (members only).
This is still somewhat buggy, but as a proof of concept this alpha works well.

I'll be sending a copy to François. (edit: done)

[Aghnar]

Hello,

Very interesting.

You probably think already about this but don't forget integration with IDE like eclipse or netbeans.

Good luck.

Bye

[Mequa]

Hi,

This is already integrated in Eclipse I haven't used NetBeans though.

AMAL banks can be loaded from ASCII plain text files, either from disk (not in the demo) or a resource file.
Currently all examples I added in the demo (each containing one or multiple AMAL scripts) are stored as ASCII plain text files with the extension ".amal" as an Eclipse resource file.

The AMAL scripts (as resource files) are directly editable in Eclipse as plain text. Edit the AMAL and press "run" in Eclipse - it will update it just as naturally as editing Java source. (You'll have to wait for the jAMAL sources to be released first though - coming soon )

In case you wondered, this demo WILL allow you to modify and run your own AMAL scripts. Delete the content of a channel's program to write your own. It's currently a bit buggy though (I need to iron out some concurrency issues in the editor I cobbled together). Select Start -> Run from its menu to run. If it fails, try it again. It usually works perfectly eventually. (Unless your code has syntax errors, or currently unsupported syntax [see readme.txt], which may cause the alpha version to hang.)