Allegro5 for AmigaOS4.1

https://code.google.com/p/allegro5foramigaos/

Hi just started a new project on code.google.com, to re-implement Allegro5 for AmigaOS4.1.

way reimplement Allegro5 when we have allegro on OS4Depot.net, because it different API its Allegro4.

and because I have been working on making a game for a PC, and I just wanted it to run it on AmigaOS4, so I decided to do it this way, it might not be the best way, but that's what I did.

Its incomplete, it's unorganized and need a lot of work, so if you won't to help out, or won't try using it for whatever, send me PM with your e-mail and I add you to the project.

@LiveForIt
Is it the successor of AmidarkEngine ?

@zzd10h

Quote:

Yes, how did you find that out?

I'm only sharing it because it does me no good and no one else any good, if its hidden on my hard drive. I'm sure some people wont a finished product, that it's not, I admit, its not for people who just wont to compile stuff, you will need to write your own makefiles, you need to possibly add stuff that is missing, or maybe correct stuff that is not correct.

Basically its work in progress, not high on my priority list.

If people are interested in contribute, in this product will become complete over time, if not it is what it is, and it wont improve unless I care.

When I mean contribute, I'm not asking for cash, contribute means adding or improving stuff on the actual code.

@LiveForIt
I just made the comparaison because according to the Allegro wiki it looked like AmidarkEngine. It implement 2D, input, sound and better than AmidarkEngine, 3D.

And it seems to be the same "busines model"

"If people are interested in contribute, in this product will become complete over time, if not it is what it is, and it wont improve unless I care."

@zzd10h

Quote:

Basically it easy to use cross platform game library like SDL, should have all you need to make Game, IO support for joysticks and Game pads, Keyboard, it has its own commands for graphics, disk io, founts, sound, and so on.

"3D" is Completely missing in my implementation.
In the official Allegro you use OpenGL for 3D stuff.

joysticks and Game pads support is missing.
(the game i ported need just keyboard)

I believe its easier to use then SDL, I have no idea how it compares to AmidarkEngine.

You can use Allegro on Windows/Linux/MacOSX etc, and there is a Java version for Android I believe.

http://lifeofliveforit.blogspot.no/se ... %20platform%20application.

Manual

https://www.allegro.cc/manual/

@zzd10h

Just to be clear about this Allegro is big, it contains a lot things, I don't necessary need, I only implement things that is need at the time, here is complete list of Allegro5 should have.

"Some" - A few commands supported.
"Not done" - Not worked on at all, not supported

API

Not done - Configuration files
some - Display routines
some - Events
some - File I/O
Not done - Filesystem
Not done - floating point math
some - Graphics routines
Not done - Joystick routines
some - Keyboard routines
some - Memory management
Not done - Mouse routines
Not done - Path structures
Not done - State
Not done - System routines
Not done - Threads
Not done - Time
some - Timer
Not done - Transformations
Not done - UTF-8 string routines
Not done - Miscellaneous
Not done - Platform-specific
Not done - Direct3D integration
Not done - OpenGL integration

Addons

some - Audio addon
some - Audio codecs
Not done - Color addon
some - Font addons
Not done - Image I/O addon
Not done - Memfile addon
Not done - Native dialogs addon
Not done - PhysicsFS addon
some - Primitives addon

It is possible that parts can be simply copied from official Allegro5, but it more than likely issues with that.

"I only implement things that is need at the time"
You are right to do only what you need.

And thank you for the detailed reply.

Since Allegro is multi platform I suppose that you just modify those parts to suit your need and be able to sync the common files if Allegro is updated right ?
Nice initiative Allegro is simpler to work with than SDL IMHO.

Update : Just checked sourceforge this is a lot more work than I thought wouldn't be easier in a first time to just do a straight port and see how to work then so a .library?
The problem with what you do is that you'll not benefit from bugs and new features of the original branch and the not being able to port Allegro games depending on them.
Kamelito

@Kamelito

Quote:

The issue is always having to deal with configure and build system, and then the dependencies, and then having to write custom code so that what happens in Allegro is translated to AmigaOS API's, but things that don't depend on the OS, should be just question of drop in.

Quote:

Its not that complicated to make a .library, the issue is more about keeping it up to date, because some .h / .c files has to be generated form a XML file.

And there is bug in command to generate the stuff, sorry don't remember what had to change last time, but I think it was some thing like sizeof(some_thing_wrong).

Anyway its good idea to get correct the first time you generate this files.

Quote:

You will always need to do a new port every time Allegro is updated, unless you commit to theres SVN/GIT server, what ever they use, what I'm doing is creating my own bugs, so there bugs might be unrelevant.

Quote:

Well you can always port what ever you wont, but you can't do it with out contributing, adding missing features, thats how this project started in first place, just to get some thing running nothing more.

I even compiled the game before I had commands just doing.

#defines SomeCommand(arg1,arg2)

basically don't do what command says, or.

#defines SomeCommand(arg1,arg2) NULL

always return NULL, until its implemented.

#defines SomeCommand(arg1,arg2) 0

always return 0, until its implemented.

That gives you a none working port, that allows you to implement the missing commands one by one, with out having to deal with a bunch of errors and warnings.

if you just want the Allero 5 interfaces maybe you could use the SDL implementation as it's already ported to Amiga. The Morphos version is also .library.
http://aminet.net/package/util/libs/powersdl_src

Kamelito

@Kamelito

SDL is not Allegro5, Allegro5 is different cross platform library, and its not the same as Allegro4.

SDL != Allegro4 != Allegro5.

Even if it was then the MorphOS source code is not compatible with AmigaOS4, you need to generate the interfaces for AmigaOS4, as MorphOS is using old school JMP table so again you need to generate that.

Yes I agree a port of PowerSDL is good idea, I believe they done what I have done, make a native version, optimized not just ported, but its a different project.

I only use only Composition to do all blit operations on the hardware, anyway I think the two operating systems have different names for this, so that has to be rewritten.

@LiveForIt

Maybe you can use certain part of code from the old release ?

http://os4depot.net/index.php?functio ... t/game/allegro_source.zip

@samo79

that might be possible, how ever you need to change some names on few commands and so on.

Command will need to be updated to latest standard and some code rewritten, I think be easier to take some part from the official Allegro5 sources and merge them.

A while ago I took Hitman's Allegro 1.1 (based on 4.3.11) and updated the Allegro base to 4.4.2, and added some very basic DIGMID support (no volume ramping, vibrato or tremolo, so many midi files will sound like crap). I didn't upload it to OS4Depot but I guess I should. Someone else would have to finish the DIGMID support properly because I'm severely lacking the skills needed for that. I sorta hacked it together and it's enough for the 1 game that needed it. DIGMID is rarely used for anything anyway and not part of Allegro 5.

The library on OS4Depot has a bunch of 3rd party addons in it too that I'll have to look at before I upload anything. But anyone can just message me if they want it beforehand, or the shared object is included in the "TOD" archive.

@MickJT

Start a new project for Allegro 4 at code.google.com and commit it there, so people can take a look and fix the bugs.

OK sounds like a plan. I'll just upload the source I have and let others contribute. I haven't used code.google.com before so I'll have to see how it works reg. giving people permission to commit changes etc. As I said, what I've done with DIGMID is a crude hack-job. It'd be good for people who know what they're doing to take a look at it (it's asound.c that needs work, the DIGMID driver itself isn't the issue, but unimplemented functions in the amiga sound driver and/or AHI). Graphics & sound routines could probably be improved too.

/thread-hijack

Edit: https://code.google.com/p/allegro4foramigaos/

Will this allegro5 library be easy to use, for example an .a wrapper that points to the .library so programs can be ported without (or minimal) changes? If not, I'd probably need help on what changes are needed for Allegro5 programs to use the library.

@MickJT

Basically, it's not lot difference.

* You include .h files in your program as you always do.
(If you are porting a program you already have this in there, you need just to set search path for GCC.
some thing like -I./allegro5 (this where you put the files)
)
* You don't add the –lallegro5 or whatever (-lallegro-5.0.3-md) in the Makefile
(you remove that if you find it)
* You add a line to open allegro library at the start of the program.
* you add a line to close allegro library at end of program.

This how you do it when you have .library, but there is no .library yet.

For audio you need -lalut and -ogg and -vorbis, in the makefile.
(mp3 not supported only ogg)

So you need to build etch .cpp file into .o file and link it into the ELF file, this how it works for now.

Then instead of opening allegro library, you type this at top of the program.

// open libs.
If (amiga_init()==FALSE)
{
Amiga_uninit(); // close libs if some thing failed.
return 0;
}

At the end of the program.

Amiga_uninit();

To close and open dependent libraries.
That’s 1,2,3 guild how to use it.

Uh. You make it sound simple, but I think I'd need to see an example source. amiga_init has to come from somewhere. I'm guessing that'll be in the allegro source I haven't seen yet. Nevertheless, once I see a single program's source that uses it, I'm sure I'll immediately understand, since you're saying it's just a few lines.

If I have this right, it's like this.

1. There's a .c, or something, that contains amiga_init and amiga_uninit. These functions open and close the .library (Edit: Or this extra .c is temporary for now due no actual .library yet)

2. Seeing as these functions exist, all that has to be done is add amiga_init() to the start of main(), and amiga_uninit() at the end of main() or in an atexit(). I'm assuming an atexit() would be better.

In the case that you run two programs that use the library, then does the library need to be opened twice, or does amiga_init detect if the library is already opened? Amiga .library's are actually shared as opposed to .so, so I'm not sure how it works if the library is closed while another program using it is still running. I'm guessing amiga_uninit handles that too?

@MickJT


Quote:

Quote:

https://code.google.com/p/allegro5fora ... allegro.cpp?spec=svn2&r=2

Quote:

Yes, that is how the library knows how many program use it, if no program use it, its unloaded from memory.

Quote:

amiga_init() and amiga_uninit() is just temporary fix for now.