Port to Allegro 5

[GoogleCodeExporter]

Allegro 4 is outdated and isn't designed with modern operating systems in mind. 
Porting EOF to Allegro 5 will allow more efficient usage of the CPU (it will 
only use what it needs) and better compatibility with Mac OS X and Linux.

Original issue reported on code.google.com by xander4j...@yahoo.com on 17 Nov 2010 at 4:52

[GoogleCodeExporter]

I'm sure a large amount will port cleanly because there will be the usual 
rendering routines.  I'm more worried about some of the modules, since I don't 
know if some of them will be replaced by Allegro or will be incompatible out of 
the box..

Original comment by raynebc on 17 Nov 2010 at 5:11

[GoogleCodeExporter]

I've made some progress on a GUI that works with Allegro 5. The GUI system is 
based on the Allegro 4 GUI so minimal changes will need to be made to get EOF's 
GUI ported over. This is the only major hurdle I can think of so once I have 
this working 100% I will be ready to do the port.

One problem I've been thinking about is how to handle the waveform graph 
rendering. Allegro 5 uses the graphics hardware for drawing so a huge texture 
will not work. We can use a memory bitmap but a system will need to be devised 
to get this memory bitmap sent to the GPU and ready to render because drawing 
from a memory bitmap is too slow to be used in real-time. We would probably 
need a few textures to use as cache and have a separate thread to get the data 
from the memory bitmap onto the textures. A separate thread would enable us to 
keep the program running smoothly while the data is sent to the GPU. We would 
basically be keeping two large textures (2048x64 or whatever we need for 
height) and after one goes off the left side of the screen upload the next 
portion so it will be ready when that portion comes into view.

Original comment by xander4j...@yahoo.com on 19 Jan 2011 at 12:48

[GoogleCodeExporter]

Line rendering should be cheaper than circles and circle fills, so whatever you 
think would work best sounds good.

Original comment by raynebc on 19 Jan 2011 at 1:07

[GoogleCodeExporter]

Allegro 5 is out now. I still plan on waiting until we get to EOF v2.0 to do 
the port.

Original comment by xander4j...@yahoo.com on 6 Feb 2011 at 6:31

[GoogleCodeExporter]

Allegro 5.1 now has native menu support. This will make porting the GUI much 
easier. I'm planning on staging some code for the transition after 1.8 is 
released.

Original comment by xander4j...@yahoo.com on 8 Jan 2013 at 5:54

[GoogleCodeExporter]

There is now a GUI that is based on the A4 GUI called EGGDialog. With this we 
should be able to port the UI fairly easily.

Original comment by xander4j...@yahoo.com on 10 Sep 2013 at 3:20

[GoogleCodeExporter]

I read about that on the Allegro forum the other day, but it seemed like they 
thought the AGUP stuff would still have to be ported.  I'm not familiar enough 
with A5 to know if that would be labor-intensive.

Original comment by raynebc on 10 Sep 2013 at 3:24

[GoogleCodeExporter]

I plan on updating the look so I will be moving away from AGUP. EGGDialog 
supports theming. I'm going to try and come up with a unique look for the GUI.

Original comment by xander4j...@yahoo.com on 10 Sep 2013 at 11:57

[GoogleCodeExporter]

Are you attached to allegro specifically? I've been very impressed by the 
expressiveness of Qt's QML scripting, which is the first time I've encountered 
a way of creating UI's that feels enabling rather than it being in the way of 
creating what I want to do with it.

For example, I toyed around and re-created part of EOF's lyrics editor like 
this: https://gist.github.com/quarnster/9150668.

QML's got a very strong Model-View-Controller separation, allowing very elegant 
solutions. For example performing fancy animations when an arbitrary property 
changes is just a matter of binding an animation to that property, like this 
for animating changes to "x", "y", "width", "height" or "z": 
                            NumberAnimation { properties: "x,y,width,height,z"; easing.type: 
Easing.InOutQuad }

Original comment by quarns...@gmail.com on 22 Feb 2014 at 9:29

[GoogleCodeExporter]

I am, yes. Since I mostly work on games, I don't have a good reason to learn 
Qt. Learning it just to make a port of this application doesn't seem like a 
good use of time for me.

I've spent the last few years building up a solid code base on top of Allegro 5 
for doing the things I need to do. Sticking with Allegro is going to allow the 
porting process to move along more quickly.

With all that said, if someone else wanted to step in and do this port, they 
can use whatever they want. The whole point is to get away from the old APIs 
and move to a more modern event-based model that plays nice with modern 
hardware and operating systems. Allegro 5 does this, but there are plenty of 
other ways to achieve this end.

Original comment by xander4j...@yahoo.com on 27 Feb 2014 at 7:15

[GoogleCodeExporter]

Has there been any movement on this?  You currently can't compile the project 
on any OSX version higher than Mountain Lion because Apple removed APIs that 
the Allegro 4 project depends on.  Since there is no binary release of Allegro 
4, that's a show stopper.

https://www.allegro.cc/forums/thread/613118

Is any of the work to port to Allegro 5 checked into the project?  Maybe it'd 
be a good idea to start an Allegro 5 branch.

Original comment by kaluza.s...@gmail.com on 27 Feb 2015 at 1:42

[GoogleCodeExporter]

No code has been written for the A5 port yet. The OS X native menus were 
finally patched recently, so the menus can be ported now. That was the last 
thing needed before work could really begin. I am tied up with other projects 
at the moment so I lack time to commit to this.

I have an external hard drive with Snow Leopard on it that I can use to compile 
EOF. Not sure if it will run on Yosemite. I heard they finally removed the 
deprecated APIs the A4 uses in that version of OS X.

Original comment by xander4j...@yahoo.com on 27 Feb 2015 at 4:10