Is there any way of modularize AMOS code?

[darkhog]

Something like Pascal units or #include in C. Or do I have to put everything in a huge file? New to AMOS, no examples seem to have code spread along several files, but the fact it isn't used doesn't mean it doesn't exist.

[Samurai_Crow]

Highlight the code you want to reuse and export it to ASCII text using the appropriate menu options. You can merge it from another menu option into your destination program.

Sadly it must be a big file before you are done since reusable code is usually written in Assembly and saved as an extension.

[darkhog]

_panda:

I wish this could be added for 3.0 though (since AMOS is apparently opensource now). Something like INCLFILE "Filename.amos" and then it would work just like C's #include

[Lonewolf10]

Originally Posted by darkhog

Something like Pascal units or #include in C. Or do I have to put everything in a huge file? New to AMOS, no examples seem to have code spread along several files, but the fact it isn't used doesn't mean it doesn't exist.

You can have sound and images stored in separate files, then load them in as needed. I usually store everything in one large file in the final version though.

You can, however, split programs up. I have a (crappy) AMOS game called BLAIM! which I wrote around 10 years ago. It is split into 2 files, one is the intro and then it loads the main game, which is stored in a 2nd file. I think I used the instruction RUN "FILENAME" to load and run the 2nd file from within the intro program.

[darkhog]

I see. Though I figure it would play badly with the compiler.

I was thinking about separating code into logical segments though, e.g. map handling routines in one file, custom menu handler in other file, gameplay rutines in another and main file to bind them all together. Like Pascal units or C includes. But apparently you can't do it in AMOS.

[idrougge]

I think you can do so, at least using the compiler. There are some caveats, but the way to do so is described somewhere in the manual.

[Lonewolf10]

Originally Posted by darkhog

I see. Though I figure it would play badly with the compiler.

No. Just compile each file individually. Data can be saved to the RAM: disk for transferring between each program - there may be a better way, but I couldn't figure out how back then.

Originally Posted by darkhog

I was thinking about separating code into logical segments though, e.g. map handling routines in one file, custom menu handler in other file, gameplay rutines in another and main file to bind them all together. Like Pascal units or C includes. But apparently you can't do it in AMOS.

Personally, I like to clump all my code together but split into different subroutines and subsections as appropriate.

I'm not familiar with C or Pascal programming languages - I have heard of them, just not used them before.

[Samurai_Crow]

The fact that an AmosPro tokenized source can hold .abk files inside means that merge ASCII is the only way.

As far as the compiler is concerned, I think that being able to write extensions in Amos and lift the 26 extension limit would solve the problems nicely for Amos 3. The bug fix release 2.1 should be first.

[idrougge]

From the manual, page 10.2.16:

INCLUDE
instruction: specify a file for inclusion when testing a program
Include "File_To_Include.AMOS"
The INCLUDE command must occupy a line on its own, otherwise the specified file will not be detected , and so it
will not be included. The effect of INCLUDE on a file is as follows:
Immediately before a program is tested, AMOS Professional scans the beginning of each program line for an INCLUDE instruction.
If an INCLUDE is encountered, AMOS Professional opens the specified file, reads its length and checks its validity.
This process takes place for each INCLUDE that is found, in order.
A memory buffer is reserved for the total length of the re-created program.
AMOS Professional now copies sections of the source program, without the Includes, and loads the files from disc.
All files are now closed, and with the memory buffer holding the re-created program, the testing process begins as normal.
You will need enough memory to hold the original buffer space and the included files at the same time for this process to operate, but if your program is large enough to slow down the Editor it is obvious that you have access to a reasonable amount of memory.
Please note that included files are only supported in the original source, and an INCLUDE in an included file will generate an error when the program is run. The re-created buffer is erased as soon as the program is left, so the specified files must be loaded every time the program is tested. If programs are included which have memory banks, these banks will be left out.

[volvo_0ne]

Yup! that works.... tried it lastnight and it's a gem

I hadn't even heard of that option before.

Thank idrougge that'll come in useful sometime