@freddix

C++ uses the same macro syntax as C. Your example would be done with parentheses around the passed parameters and commas separating them.

If you need to make Assembly macros you'll have to do it with Gas (the GNU Assembler used by GCC on the PPC Amiga). I'm not sure if it even has macro processing functions since it is intended primarily for use as a compiler backend.

@spotUP

The Amos compatibility should be quite good. All of the hardware banging was done by Amos and its extensions themselves so that the end programmer wouldn't need to know how to do so manually. This means that the hardware banging is encapsulated by the language and can be replaced by SDL code to a large extent.

Sorry it took so long to respond, I'm on vacation at the moment.

@spotUP

Hi Spotty and everyone,

I've been working on Mattathias BASIC's Amos compatibility front-end. We'll be ready to add the code-generation stage to it as soon as we figure out how the C bindings of LLVM work.

For more information about Mattathias, see our Yahoo Groups page and, to look at the source code, look in the Modules directory of the CVS repository on SourceForge. Of particular note is the parser frontend for the Amos parser.

@emeck

Helix Player might work. It lists the licenses of the player on the Wikipedia article. If it's legal, then maybe it would do the job. Thanks emeck.

@freddix

Shadow's example converts an int into a C string. I second Hans' advice and use stringstreams instead if you're in C++. There is a brief description of stringstreams on CppReference.com.

Also, if you do use C, snprintf instead of sprintf because sprintf allows buffer overruns (writing past the end of allocated memory) while snprintf keeps track of the length of the buffer it is writing to.

@emeck

Totem uses GStreamer and Xine-lib plugins. I'm not sure that all of the plugins for those formats are open-source. If they are, they may be illegal in some countries. Even if they are legal, that doesn't mean they will all work on big-endian PowerPC chips.

Generally RealAudio is available in a closed-source player format with lots of patents and DRM which makes writing a legal player requires an expensive license from Real Networks (I think that's the company name) and doesn't work very well under Linux from what I've heard.

@spotUP

All of the RealAudio players that I have ever seen for Linux are closed source.

Umm... How about the old Mozilla 1.7.5 sources. They are used internally by OpenOffice.org and would be a useful tool on their own right.

Quote:

@Atheist

Internally, Hollywood uses a custom parser of the LUA scripting engine. That'll bloat the code somewhat but it should save on the compile times.

Also, since SCUI doesn't require much underlying GUI code, that tends to take some memory also. (As opposed to an OS4 specific version that would use Reaction.) Furthermore, doing things this way is necessary to maintain portability.

@Elwood

According to the compiling instructions it needs wxWidgits for the GUI.

@Elwood

I don't see a source download link. I think it's closed source.

-edit-
There is a link to the SourceForge.net project page on the homepage. It is at http://sourceforge.net/projects/scorched3d .

@BrandonLee

Sidewinder doesn't have AmigaOS 4.x yet. Those tutorials are for AmigaOS 3.x .

@Atheist

The only reason Amos looks so plain to you is that it does a lot of work that is totally hidden to you. It opens a screen by default so you don't have to, for example. Even sdlBasic doesn't do that for you. It allows input on that screen without opening a window on that screen. Even AmigaOS doesn't allow that.

Atheist, you have no idea how much more work it is to write a hardware-banging monstrosity like Amos than to write a system-friendly programming language like PortablE.

Incidently sdlBasic is forever doomed to be an interpreted language because of the way that it handles the typing of its variables. You can use a variable as a string in one context and an integer in another context just by reassigning the variable a different value. That's fine for Python and sdlBasic but if you want to compile them for greater efficiency, you're better off with another language.

I have used C for a long time and I don't think it is all that simple. It tries to use single characters where keywords should have been used. C++ is easier to write classes but can still be done cryptically in C.

If you want to count AmosPro as being a useful language you'd better not rule out Assembly because that is the language that all of the extensions are written in. You can't write extensions for AmosPro in AmosPro, you can only include reuseable procedures with the Include command.

You've been waiting for Sidewinder and i to finish Mattathias for a long time. You know what? It's going to still be a long time because of the amount of work it is to write it.

With PortablE, you can write extensions to the language in PortablE. That is the value of an object-oriented language. The downside is that you're expected to write extensions to get the job done.

If you want to converse on the subject off-list, send me a PM.

@thread

I, for one, would like to see the LLVM JIT used in an Amiga emulator. It's open source, it's written in C++, it's portable to all of the major OS vendors' operating systems already, and it is promising to be a nice replacement for the GNU tools for compiler construction.

@freddix

From disassembled code, it would be difficult to find the offsets because the interface, while it wouldn't be in a different register each time, would not use the same register for each library to offset from. You'd have to know which register each interface structure was referencing.

Here's kind of how it works in C:


It's been a while since I've coded for OS4 and this pseudo code won't compile but i hope you get the idea. The iexec pointer variable is the interface to exec.library and iintuition is the interface to intuition.library. The libptr variable points to the library base of intuition.library but is only used to obtain the interface and the interface is used after that.

Normally when importing source code written for AmigaOS 3.x there is a pragma that is either defined at the beginning of the code or from the command line that will hide all of the interface usage behind a bunch of macros so you can call the functions without being aware of the interface stuff going on in the meantime.

Hopefully somebody can point you to a better example than this because I've loaned out my MicroA1-c to DiscreetFX to use in porting Aladdin4d to OS4.

@freddix

The .library structure has changed in OS 4 from the days of OS 3. If you use the offsets from FD2PRAGMA, you'll need to be programming in 68k compatibility mode. The offsets for the PPC codes are in another data structure called an "interface" that is obtained by the call to "ObtainInterface" in the library you're using.

@freddix

I didn't think the .sfd files generated by the XML parser on OS 4.x would work with those programs. I think they only generate PPC code for MorphOS.

-edit-
I'm assuming you're talking about FD2PRAGMA, am I correct?

@Snuffy

sdlBasic homepage is at the link I just gave. Maybe it will be helpful to others. That tutorial about programming SDL in C might be helpful to others also though.

@freddix

DarkBasic Pro was written in C++ rather than Assembly. That's why he was able to come out with such quick results.

How good are you with MiniGL and C? If you don't mind coding some MiniGL equivalences for the Mattathias runtime libraries, I'd appreciate the help!

Sidewinder is working on getting a software development suite working at his place of employment so he can work on Mattathias' parser generator any spare minute he gets!

If you want to help, be sure to let me know by contacting the Mattathias mailing list. BTW, the license to what we are writing is LGPL 3.0 so don't use anything patentable and don't plan on keeping your code a secret if you work with us.

@Mikey_C

The PowerPC version of Payback bangs on the Paula to avoid a context switch. The 68k version supports AHI for compatibility with Amithlon.