Lots of quotes here, so please bear with me...
The tl;dr is that we need to fix the KB issue, and the colour conversion slowdown on Windows, plus the audio issues on Linux.
At that point, I would consider replacing MIDI with MOD.
This is not an option for us. Our userbase is very heavily MIDI-dependent. I have been looking at all of the various allegro config options for MIDI drivers, so if any of you could try setting various config options to see what works, and find one, please report it to us, so that we know what's going on with this thing.
I'm thinking that this may be an ALSA issue, too. I wish that I knew what changed in the Linux kernel that is causing this, but I have not been keeping pace with Linux stuff in the last five years.
(I run Ubuntu 10.04.)
I'm thinking that some of the tid-bits here may apply to this: https://wiki.allegro.cc/index.php?title=Using_TiMidity%2B%2B_with_ALSA_raw_MIDI
Setting the specific MIDI driver used by the kernel, may fix the issue. Allegro simply needs to know where to find it.
SiegeLord applied the patch to GIT, and the binaries I built are on the dev board.
I grabbed the bins. We still need some kind of fix for the threading issue (keyboard input), and I should mention that on WIndows (and on OSX), fullscreen display has serious issues if you use -bit video bitmaps. Our fix, was to blit our -bit memory bitmap to a 24/32b memory bitmap.
I'm not sure if any combination of compiler, OS version, or libs, would help with that issue, as it seems to be related to changes in DirectDraw/DirectX. OSX in general, no longer supports dropping to an 8-bit plane without heavy-handed forcing the mode, which is just silly.
Found a bug!
Start a game, head right from the start screen and die there.
Play again, head right again.
Game crashes with an assert, here [github.com]
This is on Linux using the code from github. I haven't tried it with the released version, or other platforms.
Which branch, master or 2.50.x?
Note: Fixing both the threading issue (keyboard input) and the Linux audio issues are my main concern at this point. Any help here, even casual, is very useful, and I would appreciate it.
Personally, to assist this project, I'd be interesting either in working on my a4a5 compatibility bridge idea, or, perhaps moreso, in making A5 plugins for Midi, packfiles, and other A4 features missing from A5.
As I have said, the a4a5 thing seems ideal, to me. Adding ag5 plugins for all of the missing a4 elements seems like as much work, and it may have other shortcomings. Using ag4 and ag5 at the same time, to permit a slow transition, would solve most of our major concerns. In fact, if we could use a5 input, that would be very beneficial.
Ag5 supports TTFs now, right? I was going to try to get alfont.h working, so that we can add TTF support, but if this transition layer works, and we can use the ag5 string drawing to an ag4 bitmap, holy hell, that would be brilliant.
Reharding CMake This is also a learning curve thing for me. Until ZC moved to CMake, I rarely, if ever, used it. I am in no state to fix the CMake lists, as I would need to learn the same stuff as everyone else here seems to need to learn, and I do not have all of the systems and compilers at my disposal, to test this stuff.
I'm in the process of trying to acquire a dirt cheap OSX laptop--all of my Mac stuff is PPC, not Intel--and trying the Code::Blocks config. I expect that to be broken too, and I will eventually need to learn CMake, but well, finite time, and lots of work-related worries at present.
Some ZC Notes
The ZC Repo is set up with two main branches:
Master This represents the 'next gen' main release, dubbed 2.60. All of the most radical changes are going into this.
2.50.x This represents the latest planned 'stable; release, dubbed 2.53.0. THis build is my present priority, to get out a final build for the 2.50.x line.
Undeterminedi also plan to do interim-releases of 2.54, and 2.55, incorporating new features, and fixes, as a user-transition phase until 2.60 is ready. I was originally hoping that master would be 2.55, but the scope of the planned changes, improvements, and other new stuff keeps pushing it forward. Feature creep is taking over, and it seems that it will take a while to solidify the plans.
Once I have 2.53.0 done and ready, I can focus on both master, and some kind of interim release. My goal, is to see one major release every 6 to 12 months, from this point onward.
One major user concern in the present 2.53.0 betas is that the framerate was halved, seemingly caused by the lack of ASM routines for colour conversion. I do not know if this is an allegro bug, or an artefact of how the libs were compiled. If you run 2.50.2, and 2.53.0-beta2 sie-by-side, the maximum FLS is halved for the latter.
For vanilla stuff, this is not a huge issue, but once you factor in scripting events, this can be a major issue, particularly on older HW, which many of the people in the ZC community still use.
I'll try compiling the latest 4.4.3 repo next week,a nd see if my compilation produces any different results. For those interested, I am using:
gfx_card = DXAC
This is on Windows. I'm not sure how any of this affects Linux, save that on my old Inspiron 910, running ZQ using Ubuntu 10.04LTE with Gnome, was unplayably slow, in a stock, non-scripted quest, whereas on the exact same system running Win XP it was super-fast.
Once I acquire more parts, i will rebuild my second Dell E6430, running 10.04, and 12.10, and see what happens. I can run that side-by-side with my E6430 running Win 7, to compare.
if any of you know in what Linux kernel the changes were introduced that affect MIDI drivers, please let me know,