Open GoogleCodeExporter opened 8 years ago
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
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
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
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
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
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
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
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
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
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
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
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
Original issue reported on code.google.com by
xander4j...@yahoo.com
on 17 Nov 2010 at 4:52