PDA

View Full Version : Allegro pull requests



DarkDragon
07-24-2017, 11:38 AM
FYI, ZoriaRPG got in touch with the Allegro folks and it sounds like they're willing to process pull requests for bugfixes to the 4.4 branch that we send them. I've already filed one containing our modifications (https://github.com/liballeg/allegro5/pull/789) but if you fix the keyboard bug, etc, consider also sending it upstream; it'd be nice not to have to maintain our own patched version of Allegro. Feel free to use the allegro5 fork in the AGN github account as a staging area.

ZoriaRPG
07-24-2017, 03:48 PM
Aye. Edgar Reynaldo over on allegro.cc is being just brilliant on this subject.

I went in expecting to get the old story of 'Just upgrade to Allegro 5', but instead I find that there is better support for ag4 now, than there was in 2011; so it would be prudent for each of us to participate on the forums there, and try to fix as much as possible in ag 4.4.3, and aim for a proper release of that.

Here is a changelog for allegro 4.4.3 (https://pastebin.com/JinsWu26)over 4.4.2.

Insofar as they KB issue, I am having problems making the bug occur in any ZC build at present, including in 2.50.2. If it is a race condition as Saffith suspects, then I am unsure how to trigger it. If it is a library issue as Gleeok and I believe, then it may have been fixed--hard to tell just yet.

It would be great if all of our special needs, and out fixes, are simply in the core library though.

I have a few live topics over on allegro.cc if anyone wishes to participate in them.

ZoriaRPG
07-24-2017, 03:49 PM
Aye. Edgar Reynaldo over on allegro.cc is being just brilliant on this subject.

I went in expecting to get the old story of 'Just upgrade to Allegro 5', but instead I find that there is better support for ag4 now, than there was in 2011; so it would be prudent for each of us to participate on the forums there, and try to fix as much as possible in ag 4.4.3, and aim for a proper release of that.

Here is a [url=https://pastebin.com/JinsWu26]changelog for allegro 4.4.3 ]/url]over 4.4.2.

Insofar as they KB issue, I am having problems making the bug occur in any ZC build at present, including in 2.50.2. If it is a race condition as Saffith suspects, then I am unsure how to trigger it. If it is a library issue as Gleeok and I believe, then it may have been fixed--hard to tell just yet.

It would be great if all of our special needs, and out fixes, are simply in the core library though.

I have a few live topics over on allegro.cc if anyone wishes to participate in them.

ZoriaRPG
07-24-2017, 03:50 PM
[DP; remove]

DarkDragon
07-24-2017, 03:58 PM
Aye. Edgar Reynaldo over on allegro.cc is being just brilliant on this subject.

I went in expecting to get the old story of 'Just upgrade to Allegro 5', but instead I find that there is better support for ag4 now, than there was in 2011; so it would be prudent for each of us to participate on the forums there, and try to fix as much as possible in ag 4.4.3, and aim for a proper release of that.

Here is a changelog for allegro 4.4.3 ]/url]over 4.4.2.

Insofar as they KB issue, I am having problems making the bug occur in any ZC build at present, including in 2.50.2. If it is a race condition as @[URL="http://www.armageddongames.net/member.php?u=38582"]Saffith (https://pastebin.com/JinsWu26) suspects, then I am unsure how to trigger it. If it is a library issue as @Gleeok (http://www.armageddongames.net/member.php?u=42714) and I believe, then it may have been fixed--hard to tell just yet.

It would be great if all of our special needs, and out fixes, are simply in the core library though.

I have a few live topics over on allegro.cc if anyone wishes to participate in them.

The code snippet that Saffith posted on Pure is definitely buggy:


buffer->lock++;

if (buffer->lock != 1) {
buffer->lock--;
return;
}

// Do stuff

buffer->lock--;

C++ is not required to compile lock++ into an atomic operation, in which case the following sequence is possible:

Thread 1 reads the value of lock (0)
Thread 2 reads the value of locK (0)
Thread 1 post-increments lock (now 1) and enters the critical section
Thread 2 post-increments lock (writing 1 again) and enters the critical section
Both threads decrement lock (now -1).

As with all concurrency bugs, however, even though the code is objectively incorrect, it might happen to work on some compilers on some machines, where the increment happens to be atomic; or the bug might be present but never exercised due to precise timings of context switches on some particular machine.

ZoriaRPG
07-24-2017, 04:33 PM
The code snippet that Saffith posted on Pure is definitely buggy:


buffer->lock++;

if (buffer->lock != 1) {
buffer->lock--;
return;
}

// Do stuff

buffer->lock--;

C++ is not required to compile lock++ into an atomic operation, in which case the following sequence is possible:

Thread 1 reads the value of lock (0)
Thread 2 reads the value of locK (0)
Thread 1 post-increments lock (now 1) and enters the if block
Thread 2 post-increments lock (writing 1 again) and enters the if block
Both threads decrement lock (now -1).

As with all concurrency bugs, however, even though the code is objectively incorrect, it might happen to work on some compilers on some machines, where the increment happens to be atomic; or the bug might be present but never exercised due to precise timings of context switches on some particular machine.

Wouldn't a basic statement of :


if ( buffer->lock > 0 ) buffer->lock--;

help there?

That way, the second thread would not touch it.

DarkDragon
07-24-2017, 04:34 PM
Nope. This has the exact same problem as the original code.

ZoriaRPG
07-24-2017, 06:04 PM
Nope. This has the exact same problem as the original code.

I'm not really sure how to make this an atomic operation that is respected in each of our various compilers, and on every architecture that we use. I think it would be different between gcc/MinGW, and MSVC, and possibly between different MSVC versions; plus it may be different from Windows to Liux and OSX (FreeBSD).

If any if you are clever-enough to know a solution, I'm all eyes. Is using std::atomic for the variable sufficient for our needs, or will that fail based on the compiler? I'm not sure at what point this was introduced as art of the cpp spec, to keep this cpp08 happy.

Which allegro file is this, BTW, so that I can post the problem on allegro.cc? ?

DarkDragon
07-24-2017, 06:21 PM
Right. It's one of the many things that is a lot easier to do in C++11 than C++03. I'm pretty sure Allegro already has a mutex implementation somewhere, though.

ZoriaRPG
07-24-2017, 09:25 PM
Right. It's one of the many things that is a lot easier to do in C++11 than C++03. I'm pretty sure Allegro already has a mutex implementation somewhere, though.

I could still use a file ref where this code lives. For some reason, my search function started to refuse to give any results on any source code, which if quite, quite, fun.

P.S. I would search the GH branch, but IIRC, GH does not permit searching branches.

Searching the build for ALL_ZC in MSVC returns nothing.

Never mind. The file is keyboard.c as a deep search with DOpus discovered.

ZoriaRPG
07-24-2017, 10:16 PM
Well, the edit post button seems to be failing. I'll post a P.S. about that below.

Here is a link to the discussion on this topic over at allegro.cc (https://www.allegro.cc/forums/thread/616984/1031737#target). Mates, you might want to chime in over there.
War Lord & DarkDragon

I have encountered some issues on AGN today, and yesterday. The edit post button seems to fail to load the edit dialogue, and on two occasions I received an error:



You do not have permission to accesss /newreply.php on this server.


I'm posting this here, in the event that I run into it again. I'm hoping that this post goes through.

Gleeok
07-24-2017, 10:28 PM
I was just going to copy over some atomic code from my own library I use and use that to fix it, but if you guys want to do it then be my guest. ;)



I'm not really sure how to make this an atomic operation that is respected in each of our various compilers, and on every architecture that we use. I think it would be different between gcc/MinGW, and MSVC, and possibly between different MSVC versions; plus it may be different from Windows to Liux and OSX (FreeBSD).

If any if you are clever-enough to know a solution, I'm all eyes. Is using std::atomic for the variable sufficient for our needs, or will that fail based on the compiler? I'm not sure at what point this was introduced as art of the cpp spec, to keep this cpp08 happy.

Which allegro file is this, BTW, so that I can post the problem on allegro.cc? ?

You can use intrinsics. std::atomic, like all of c++, is just bloated wrappers around c. Plus, allegro compiles as c code so simple is fine. For example, std::atomic::operator++ is the equivalent of:
_InterlockedIncrement(); on windows, or
__sync_add_and_fetch(). on gcc, etc.


Right. It's one of the many things that is a lot easier to do in C++11 than C++03. I'm pretty sure Allegro already has a mutex implementation somewhere, though.

Lies! Nothing in c++11 makes anything easier. Only sadness will you find. :P

DarkDragon
07-24-2017, 10:33 PM
Okay, challenge accepted. Please post C or C++03 code that performs an atomic increment correctly on every single standard-compliant C++03 compiler on every computer architecture in the world. I will do the same for C++11 ;)

DarkDragon
07-24-2017, 10:35 PM
Well, the edit post button seems to be failing. I'll post a P.S. about that below.

Here is a link to the discussion on this topic over at allegro.cc (https://www.allegro.cc/forums/thread/616984/1031737#target). Mates, you might want to chime in over there.
@War Lord (http://www.armageddongames.net/member.php?u=38500) & @DarkDragon (http://www.armageddongames.net/member.php?u=1)

I have encountered some issues on AGN today, and yesterday. The edit post button seems to fail to load the edit dialogue, and on two occasions I received an error:



You do not have permission to accesss /newreply.php on this server.


I'm posting this here, in the event that I run into it again. I'm hoping that this post goes through.

I pinged War Lord about this earlier in the afternoon and he is aware of the problem. I think the host has fixed the issue... for now.

ZoriaRPG
07-24-2017, 11:43 PM
I was just going to copy over some atomic code from my own library I use and use that to fix it, but if you guys want to do it then be my guest. ;)




You can use intrinsics. std::atomic, like all of c++, is just bloated wrappers around c. Plus, allegro compiles as c code so simple is fine. For example, std::atomic::operator++ is the equivalent of:
_InterlockedIncrement(); on windows, or
__sync_add_and_fetch(). on gcc, etc.



Lies! Nothing in c++11 makes anything easier. Only sadness will you find. :P

Ill take your fix for now, thanks. I don't want to delve into the murky waters of this more than needed. If it turns out to need more, than it needs more, but let's try the simple fix, first.

I will also further try to convince the allegro blokes to incorporate it, or take it and expand if if they so desire. One genius telling me that we should not care about threads and that allegro was not designed to be thread-safe on 1980s architecture, is just an example of pure madness.

If for some reason it does not work on one compiler or another, we can add in compiler definitions. Yay.
jman2050 Still has an allegro.cc account, and he is the one who posted the original ZC project listing there. I posted an updated listing, and I will add to it as time permits. There is some weird issue with their FTP upload, which claims to support 100MB files, but it is failing me. (I', trying to add the stable Linux build, which is 43MB in size.)

Here is the entry: https://www.allegro.cc/depot/ZeldaClassic1

If jman2050 wants to go in and update his entry (here (https://www.allegro.cc/depot/ZeldaClassic)), then that would also work. Please let me know what you think of my project description and either approve, or grumble.

DarkDragon
07-25-2017, 12:04 AM
Allegro already has code for mutexes. I can guarantee you they will refuse to incorporate a fix that half-works on only some platforms, instead of using their own mutex implementation for some reason.

ZoriaRPG
07-25-2017, 12:05 AM
Allegro already has code for mutexes. I can guarantee you they will refuse to incorporate a fix that half-works on only some platforms, instead of using their own mutex implementation for some reason.

Well, again, if you want to do this, go for it. I don't understand why you and Gleeok butt heads every ten seconds these days. I don't want every stage of this to be a bicker-fest.

DarkDragon
07-25-2017, 12:11 AM
Butting heads where? We're bantering about C++11 but switching the whole Allegro project from C to C++11 was obviously not a serious suggestion (and there's a 0% chance the Allegro folks would accept a pull request that tries to do so).

I'm trying to give you practical advice about how to proceed in the way least likely to waste your time, based on my observations about how the Allegro folks run their ship. Obviously feel free to check with Edgar directly if you believe I am wrong.

Saffith
07-25-2017, 01:17 AM
You don't need C++, anyway. C11 added stdatomic.h and an _Atomic qualifier.

Gleeok
07-25-2017, 01:19 AM
Fun fact: Mutexes is not multi-threading. Mutex locks are the opposite of multi-threading! :P Bicker!!!


Okay, challenge accepted. Please post C or C++03 code that performs an atomic increment correctly on every single standard-compliant C++03 compiler on every computer architecture in the world. I will do the same for C++11 ;)

Bicker bicker bicker!!! Are you saying that c++11 is more widely supported than c? Bicker? Stuff, bicker. Nonsense! Bicker!!


P.S. Anyway, I guess newer gcc can use "__atomic*" prefix...? But clang uses "__sync*" ? ..Whatever. AFAICT they cover windows and unix toolchains so there's probably no issues there.

[edit] Keep in mind that the allegro.cc folks like to argue about anything and everything. At least that's what happened every time I used to stop by there. :P

Chris Miller
07-25-2017, 01:41 AM
https://media.giphy.com/media/TrDxCdtmdluP6/giphy.gif

DarkDragon
07-25-2017, 01:44 AM
Fun fact: Mutexes is not multi-threading. Mutex locks are the opposite of multi-threading! :P Bicker!!!



Bicker bicker bicker!!! Are you saying that c++11 is more widely supported than c? Bicker? Stuff, bicker. Nonsense! Bicker!!


P.S. Anyway, I guess newer gcc can use "__atomic*" prefix...? But clang uses "__sync*" ? ..Whatever. AFAICT they cover windows and unix toolchains so there's probably no issues there.

[edit] Keep in mind that the allegro.cc folks like to argue about anything and everything. At least that's what happened every time I used to stop by there. :P

That's definitely true of the guy that's currently posting in the linked thread (he also doesn't seem to have a solid grasp of the problem we're reporting). But the guy Zoria has been talking to (Edgar; I think the main 4.4 maintainer?) sounds reasonable (fingers crossed...)

ZoriaRPG
07-25-2017, 04:39 AM
Oh, hell, I was saying c++03 or c++08 and it should be C99 or C03 something therearound. My error.

Gleeok
07-25-2017, 08:24 AM
Insofar as they KB issue, I am having problems making the bug occur in any ZC build at present, including in 2.50.2. If it is a race condition as Saffith suspects, then I am unsure how to trigger it.

I have a few live topics over on allegro.cc if anyone wishes to participate in them.

I know your super-enthused and everything, but trying to repro extremely rare cases is not a good use of time. Trust me. Especially so when Saffith was already able to repro it and trace it to a location, and there is already a proposed fix on top, with cherries even. I find a better use of time is to smoke crack and try to cut flying stink bugs in half with scissors. Those are my pomegranates you sons of bitches!!! Let's see you all try and procreate when you don't have any heads! D:


I would head over to allegro.cc, but I forgot both my password and my username...also can't remember what email I used. lol >_<
If need be I'll make a new account though.

ZoriaRPG
07-26-2017, 05:03 PM
I know your super-enthused and everything, but trying to repro extremely rare cases is not a good use of time. Trust me. Especially so when Saffith was already able to repro it and trace it to a location, and there is already a proposed fix on top, with cherries even. I find a better use of time is to smoke crack and try to cut flying stink bugs in half with scissors. Those are my pomegranates you sons of bitches!!! Let's see you all try and procreate when you don't have any heads! D:


(Emphasis, mine.)

You don't honestly think this; right?

The only reason that I am doing this, is to try to deduce what specific events trigger the clash, and it is only using CPU cycles, not much of my actual time. If I had to invest a huge amount of time into it, then I would likely not want to do it at all.



I would head over to allegro.cc, but I forgot both my password and my username...also can't remember what email I used. lol >_<
If need be I'll make a new account though.

A new account would be wise, as they seem to invalidate accounts after a while. jman2050 has an account there, but when i tried to add him to the project that I listed, it said that his account was invalid.

Gleeok
07-27-2017, 03:39 AM
(Emphasis, mine.)

You don't honestly think this; right?

The only reason that I am doing this, is to try to deduce what specific events trigger the clash, and it is only using CPU cycles, not much of my actual time. If I had to invest a huge amount of time into it, then I would likely not want to do it at all.


Of course I do. I mean what I say and I say what I mean. You know what I mean? I mean, sure, I could just spray them, but then I wouldn't have acquired these deadly precision striking skills with ordinary household items. You knows what I sayin' yo?

ZoriaRPG
08-01-2017, 05:07 AM
I opened a ZC topic over on Allegro.cc here:
https://www.allegro.cc/forums/thread/616990/1031895#target

There is also this discussion on an a4a5 transition layer, that seems to be going somewhere:
https://www.allegro.cc/forums/thread/616977/1

jman2050
08-04-2017, 10:57 PM
I'm not really sure if I can access my allegro.cc account at all. None of the passwords I might have used work and there seems to be no way of resetting passwords on the site.

ZoriaRPG
08-05-2017, 11:48 AM
I'm not really sure if I can access my allegro.cc account at all. None of the passwords I might have used work and there seems to be no way of resetting passwords on the site.

I think that your account was closed for some reason, as when I tried to add you to the second project listing, I was shown 'No such user' as an error. They probably expire accounts after N-years of non-use. You might try opening a new account with the same username, and see if you can do that. If so, then someone can fix the bindings for your account and the listing for ZC in the projects list.

ZoriaRPG
08-06-2017, 03:43 PM
Gleeok: Are you working on this? I've been waiting for an update from you.

DarkDragon
08-11-2017, 01:17 AM
What is "this"?

I've working on fixing the issues the Allegro folks pointed out (I didn't correctly apply the 4.2 patch to 4.4) and should be done later this evening.

Gleeok
08-11-2017, 06:10 AM
Gleeok: Are you working on this? I've been waiting for an update from you.

Sorry, must of missed this (pun intended). :P

What DD said. Not sure. If you mean the AS scripting I am messing around different ideas of getting scripts to "inherit" from c++ code and whatnot - kind of off and on. If you mean the atomic fix then no.

ZoriaRPG
08-12-2017, 07:33 AM
Sorry, must of missed this (pun intended). :P

What DD said. Not sure. If you mean the AS scripting I am messing around different ideas of getting scripts to "inherit" from c++ code and whatnot - kind of off and on. If you mean the atomic fix then no.

Gleeok and DarkDragon

I meant the atomic fix. Should I just go with std::atomic and roll with it? I want to try fixing the libs before I compile them again. One nice thing about 4.4.3, is that the main deps are included, so it seems that it is no longer mandatory to do all the extra build steps at this point. I just wish that I knew with certainty what was needed to fix this, as it seems that the two of you have very different ideas on what is needed, and how to proceed.

You both seemed ready to tackle it, so I was waiting to see the results. I am not going to hack ASM back in to the library for a variety of reasons. THe most important, being that it is likely going to cripple it in the future, and it would never be pulled into the main 4.4.3 repo.

My plate has been pretty full of late, with many work-related requirements placed on me shoulders. I want to fix the libs, and make the needed fixes to 2.53, and simply be done with it, so that I can get back to working on master, and interim stuff.

DarkDragon
08-13-2017, 01:23 AM
You both seemed ready to tackle it, so I was waiting to see the results.

Sure, I'll do it.

Gleeok
08-13-2017, 01:51 AM
Gleeok and DarkDragon

I meant the atomic fix. Should I just go with std::atomic and roll with it? I want to try fixing the libs before I compile them again. One nice thing about 4.4.3, is that the main deps are included, so it seems that it is no longer mandatory to do all the extra build steps at this point. I just wish that I knew with certainty what was needed to fix this, as it seems that the two of you have very different ideas on what is needed, and how to proceed.

You both seemed ready to tackle it, so I was waiting to see the results. I am not going to hack ASM back in to the library for a variety of reasons. THe most important, being that it is likely going to cripple it in the future, and it would never be pulled into the main 4.4.3 repo.

My plate has been pretty full of late, with many work-related requirements placed on me shoulders. I want to fix the libs, and make the needed fixes to 2.53, and simply be done with it, so that I can get back to working on master, and interim stuff.

Only problem is std::atomic is c++.

Sure. Point me to the 4.4.3 files (I'm assuming you guys are wanting to upgrade to the elusive dot three now) in the ZC master repo that need fixing (unless it's just wwin.c) and I'll give it a shot.


[edit] I should of hit reply hours ago before I got distracted and made dinner, not after. ..hardly counts as being ninja'd... Oh well, whatever. :P

DarkDragon
08-13-2017, 02:51 AM
I just pushed a fix here: https://github.com/ArmageddonGames/allegro5/commit/f805b1ed4ac1aeab631763b699060943e157cfa3

Gleeok
08-13-2017, 04:06 AM
I just pushed a fix here: https://github.com/ArmageddonGames/allegro5/commit/f805b1ed4ac1aeab631763b699060943e157cfa3

Great. Maybe now we'll get a rainbow without the death crash. :P


Completely hypothetical question for you: Do you think this is more likely to manifest on newer computers because of increased core counts and more complex (read: stupid ms windows) kernel scheduling? ...Like, for example, might something similar to this affect crash occurrence in theory if it didn't interrupt or block as much:



SetProcessAffinityMask(GetCurrentProcess(), 1);
SetThreadAffinityMask(GetCurrentThread(), 1);


?

Just a random thought.

ZoriaRPG
08-13-2017, 08:55 AM
Well, this is certainly fun. MSVC 2008 chokes and dies compiling this CMake build of ag 4.4.3. I might need some of your includes, whatever you used, as the headers for stdint.h and inttypes.h fail to compile on MSVC9, and there are some major issues with a few of the allegro source files, too.

Have a look:

https://pastebin.com/wesKpgFu

Are the errors in color.c resulting from our changes, and thus, our fault?

Likewise, for config.c/h? I know that I've compiled this bastard before in MSYS, and I may need to go that route again.

I suspect that no-one even bothered to try compiling the build for Windows using MSVC9, as all of the allegro users are Linux blokes. THose who build it on Windows use MSYS/MinGW, which is the opposite of our conundrum for ZC.

DarkDragon
08-13-2017, 11:23 AM
Are the errors in color.c resulting from our changes, and thus, our fault?
Nope.

Are you *sure* you're trying to compile the right thing? Branch "4.4-ZCfixes" of https://github.com/ArmageddonGames/allegro5? The line numbers in your pasted output do not make a lot of sense.

DarkDragon
08-13-2017, 11:30 AM
Great. Maybe now we'll get a rainbow without the death crash. :P


Completely hypothetical question for you: Do you think this is more likely to manifest on newer computers because of increased core counts and more complex (read: stupid ms windows) kernel scheduling? ...Like, for example, might something similar to this affect crash occurrence in theory if it didn't interrupt or block as much:



SetProcessAffinityMask(GetCurrentProcess(), 1);
SetThreadAffinityMask(GetCurrentThread(), 1);


?

Just a random thought.

Could be. But if the keyboard thread doesn't run as often, that can also cause problems (slow response to keyboard input, missed keys, etc).

ZoriaRPG
08-13-2017, 12:32 PM
Oh boy. GitHib , in the last few days, deprecated some older Firefox clients. Guess what no longer works? Branch selection.

Why the flidd would they disable that, for older browsers?

DarkDragon
08-13-2017, 02:20 PM
Here's a crazy thought: upgrade your browser? Probably your computer is riddled via trojans if you haven't been keeping up with security updates...

Also, you don't need to do any branch selection on the GitHub site to download the code. Just git clone https://github.com/ArmageddonGames/allegro5.git and then on your computer (*not* your browser) switch to the 4.4-ZCfixes branch.

Gleeok
08-14-2017, 03:28 AM
Could be. But if the keyboard thread doesn't run as often, that can also cause problems (slow response to keyboard input, missed keys, etc).

Oh no no no. I wasn't suggesting that as a fix (that would be stupid!), just contemplating why it works on old hardware and as the computers get newer the problems would get worse. ...yeah, I'm not so great with hardware. CPUs are just crazy complicated nowadays.



P.S. ZoriaRPG: How's CMAKE working out for you so far? :gavel:

ZoriaRPG
08-14-2017, 06:08 AM
Oh no no no. I wasn't suggesting that as a fix (that would be stupid!), just contemplating why it works on old hardware and as the computers get newer the problems would get worse. ...yeah, I'm not so great with hardware. CPUs are just crazy complicated nowadays.



P.S. ZoriaRPG: How's CMAKE working out for you so far? :gavel:


Edit: I may have this sorted.

I managed to build 4.4.3, but it is spitting out loadpng.dll and jpgalleg.dll as separate files from alleg44.dll. I'm not sure how to fix that. Any clues would be helpful.

Are there linker options in MSVC to build this in a monolithic mode, or CMake flags to use? Egdar wasn't very optimistic, despite 4.4.2 building as a monolith before, and I believe 4.4.3 did, too.

The actual alleg44.dll is working, and seems somewhat faster ( 20 to 40% ) , but of course, PNG and JPEG loading are broken. I do not know how to force link these three.


Here's a crazy thought: upgrade your browser? Probably your computer is riddled via trojans if you haven't been keeping up with security updates...

Also, you don't need to do any branch selection on the GitHub site to download the code. Just git clone https://github.com/ArmageddonGames/allegro5.git and then on your computer (*not* your browser) switch to the 4.4-ZCfixes branch.

(1) Newer firefox builds run far slower, and less reliably. They are plain awful,a nd TBH, if I did not need some features that were not in 28.0, I would still be using that. I can count the number of websites that I visit on this machine on my fingers. The majority of the time, it is simple:

(2) On this system, those are AGN, Pure, DoctorWhoTV, Youtube, StackExchange, Pastebin, GutHub, SourceFoce, Twitch (streams only), and HitBox (broadcasting only); and now, allegro.cc. I rarely venture outside of this range, and I run NoAcript, with all scripts disabled by default. I only enable content that I can validate. I'm quite far from the typical Internet user. I also run ABP to prevent any unauthorised content that NS misses, and ABE to catch redirect exploits. These tools are vastly superior to anything that Firefox 4+ offers, and given that Firfox + tend to make this system unusably slow, there is no real reason to update, until some content that I need forces it

(3) I do not download binary files on this system, barring open source content that I can verify, or build; or libs from very trusted sources.

(4) In-browser security, is primarily in the form of exploit prevention. For the most part, the bloat added to newer browsers to make them prettier, or to tack on useless features, is pointless, and their exploits are generally avoided by careful control over the sites and the services that you use, and the content that you permit to run. As I permit nothing to run by default, it's unimportant.

(5) I use no 'social media' sites, I do not log into anything untrusted, and I generally keep my circle very small.
For other content, I VNC into a remote system, and use that.

I have most of the major cookie engines, data mining engines (such as Google's advert mining) and such set to loop back to 127.0.0.1; too.

When I must use a newer browser, I have a current install of Chrome, which runs terribly, uses 4x as much RAM, and has a terrible UI.

DarkDragon
08-14-2017, 06:28 AM
So the issue is that Allegro is compiling loadpng as a dynamic rather than static library? You can try recompiling loadpng with SHARED off. If that doesn't work the easiest solution may be to change how *we* compile ZC so that we use loadpng (and possibly the other sound/graphics libraries) as dynamic libraries. But first see you can get Allegro to compile them as static libraries, because the fewer .dlls we have to ship with ZC, the better.

Gleeok
08-14-2017, 07:24 AM
You may be able to open the generated msvc projects' properties and change them to "static library" instead of mussing with CMAKE I guess? Don't know if you'd then need to tell aleg44 to link library dependencies or not also.


I used to use Firefox 3.5 or something until a few years ago. I switched from that to Firefox 25.1 and immediately wanted to strangle the Mozilla team with razor wire. Build 45 is the last version I've used and you can imagine how I feel about that. Don't even get me started on google "technology" either...

Notice how youtube changed all their shit the last few weeks? Well yesterday youtube hung and crashed my graphics card. [True Story] Of course then windows couldn't figure out how to reload the offending ati lib and then Blue-Screened, so I had to restart. Makes me miss the good old days where youtube just randomly stops working until you Ctrl-F5 the page.... Oh no, wait. They still do that.

ZoriaRPG
08-14-2017, 07:39 AM
You may be able to open the generated msvc projects' properties and change them to "static library" instead of mussing with CMAKE I guess? Don't know if you'd then need to tell aleg44 to link library dependencies or not also.


I used to use Firefox 3.5 or something until a few years ago. I switched from that to Firefox 25.1 and immediately wanted to strangle the Mozilla team with razor wire. Build 45 is the last version I've used and you can imagine how I feel about that. Don't even get me started on google "technology" either...

Notice how youtube changed all their shit the last few weeks? Well yesterday youtube hung and crashed my graphics card. [True Story] Of course then windows couldn't figure out how to reload the offending ati lib and then Blue-Screened, so I had to restart. Makes me miss the good old days where youtube just randomly stops working until you Ctrl-F5 the page.... Oh no, wait. They still do that.



I feel your pain. Now firefox is dropping extension support, entirely. All of the extensions and plug-ins that we use, will cease working with FF 53.

The Mozilla team simply does not care. I'm on the verge of exploring alternatives based on the older Mozilla code, or just compiling my own browsers.

I mucked about with the linker options, and I think that I have the libs linked. they seem to be working,

http://timelord.insomnia247.nl/zc/zc_dev/2.53_Win_Beta_3.zip
New libs, only.

ugh. PNG and JPEG loading do work, but only on the second and later attempts. Something is not linked right, or the libs are not loading when the first instance of loading a file is called.

Chris Miller
08-14-2017, 08:41 AM
ZoriaRPG
Pale Moon is where it's at. There's also a 64-bit version. And none of the horseshit going on in the boardroom.

DarkDragon
08-14-2017, 11:32 AM
I feel your pain. Now firefox is dropping extension support, entirely. All of the extensions and plug-ins that we use, will cease working with FF 53.

The Mozilla team simply does not care. I'm on the verge of exploring alternatives based on the older Mozilla code, or just compiling my own browsers.

I mucked about with the linker options, and I think that I have the libs linked. they seem to be working,

http://timelord.insomnia247.nl/zc/zc_dev/2.53_Win_Beta_3.zip
New libs, only.

ugh. PNG and JPEG loading do work, but only on the second and later attempts. Something is not linked right, or the libs are not loading when the first instance of loading a file is called.

Why is there a jpgalleg.dll in the zip? As I already tried to explain, you need to build jpgalleg as a static library. Static and dynamic libraries both have the same file extension (.lib) but they are very different things.

The steps for doing this (works for me on MSVC 2015) are:

1. Run Allegro's CMake with SHARED set to true (checked).
2. Compile Allegro (only). This will generate alleg44.lib and alleg44.dll.
3. Run Allegro's CMake with SHARED set to false (unchecked).
4. Compile loadpng and jpgalleg (only). This will generate jpgalleg.lib and loadpng.lib (no .dlls).
5. Copy all .libs into libs/win32 in your ZC folder
6. Rename jpgalleg.lib to libjpgal.lib (or alternatively, change the name in CMakeLists.txt).
7. Build ZC
8. Copy alleg44.dll into whichever folder you are running the ZC .exes from.

Alternatively, you can skip steps 3-8 and instead build jpgalleg and loadpng from the standalone source, like we used to do (sources are in other/ldpng15.zip and other/jpgalleg-2.5.tar). These don't have Visual Studio projects so you'll have to configure and build them yourself (way easier than CMake, amirite?)

ZoriaRPG
08-14-2017, 02:39 PM
Why is there a jpgalleg.dll in the zip? As I already tried to explain, you need to build jpgalleg as a static library. Static and dynamic libraries both have the same file extension (.lib) but they are very different things.

I forgot to delete them. The .lib files are there, too.




The steps for doing this (works for me on MSVC 2015) are:

1. Run Allegro's CMake with SHARED set to true (checked).
2. Compile Allegro (only). This will generate alleg44.lib and alleg44.dll.
3. Run Allegro's CMake with SHARED set to false (unchecked).
4. Compile loadpng and jpgalleg (only). This will generate jpgalleg.lib and loadpng.lib (no .dlls).
5. Copy all .libs into libs/win32 in your ZC folder
6. Rename jpgalleg.lib to libjpgal.lib (or alternatively, change the name in CMakeLists.txt).
7. Build ZC
8. Copy alleg44.dll into whichever folder you are running the ZC .exes from.

Alternatively, you can skip steps 3-8 and instead build jpgalleg and loadpng from the standalone source, like we used to do (sources are in other/ldpng15.zip and other/jpgalleg-2.5.tar). These don't have Visual Studio projects so you'll have to configure and build them yourself (way easier than CMake, amirite?)

I see the issue. Hmph. I should have thought about this a bit more, but, ah, the stresses of life.

I will give this a try. One thing to note, is that when I left ZC running for a few hours, it was stealing enter key presses from other programmes.. By that, I mean that until I exited ZC, my enter key did nothing elsewhere but I did not rebuild ZC in the process--my fault. I will check again after I rebuild it all.

Now I know what I'll be doing tomorrow.

P.S. Did you backport the fixes that you made (in response to Lut's post) from master to 2.50.x, so will I be doing that?

DarkDragon
08-14-2017, 02:41 PM
That's something to ask the Allegro folks---none of our changes should have caused any difference in behavior of the keyboard driver itself.

ZoriaRPG
08-17-2017, 08:16 AM
DarkDragon

FYI, the aleg44.dll that you put in the AGN repo is bad. It fails to load, because it requires VCRUNTIME140.dll. You should probably be setting the CMake flag CMAKE_BUILD_TYPE as Release for this.

I tried the process that you detailed, and I am encountering linker errors. I did each step precisely as you described. I will need to go in and try building the dependency libs manually, but I believe that our loadpng stuff is outdated. I'll look into it again after a sanity refill. Building ZC using the alleg44 file made with SHARED = true, and using the deps with SHARED = false, results in a long chain of critical linker errors.

Did you specify any special linker flags in the CMake config when you built ag44 or its deps?

DarkDragon
08-17-2017, 10:47 AM
What are these errors?

alleg44 is not "bad," but it was built using MSVC2015, it makes sense you can't use it if you're running an old version of the compiler.

ZoriaRPG
08-19-2017, 04:43 AM
What are these errors?

alleg44 is not "bad," but it was built using MSVC2015, it makes sense you can't use it if you're running an old version of the compiler.

No, no. the alleg44.dll file in /bin/win32 , when used by ZC/ZQuest (and ROMView) binaries, requires the MSVC2015 dll. If that file was meant specificallyu for MSVC debugging, that's fine, but flagging it -debug-msvc15.dll would be prudent. As that file output is meant for general ZC/ZQ testing, and MSVC2015 is not a mandatory component to doing that, there needs to be a release dll in that path.

i.e. The dll provided for us eby the binaries cannot be used by everyone.

I'm not sure if I am using the correct headers for the PNG library. The allegro CMake file wants to point to png.h, but tht is part of lpng1212, not loadpng15. When i compile lpng1212, the first attempt to load a PNG file does nothing, and all future attempts work. When I tried to point Allegro's CMake to loadpng15's header, it spewed a list of syntactical issues.

The Linker errors when using loadpng.lib and libjpegal.lib were along these lines:



5>alleg_compat.cpp
5>init.cpp
5>Generating Code...
5>Compiling...
5>zc_custom.cpp
5>subscr.cpp
5>sprite.cpp
5>save_gif.cpp
5>qst.cpp
5>particles.cpp
5>md5.cpp
5>midi.cpp
5>gamedata.cpp
5>EditboxView.cpp
5>EditboxModel.cpp
5>editbox.cpp
5>defdata.cpp
5>colors.cpp
5>Generating Code...
5>Compiling resources...
5>MSVCRT.lib(MSVCR90.dll) : error LNK2005: _free already defined in LIBCMT.lib(free.obj)
5>MSVCRT.lib(MSVCR90.dll) : error LNK2005: _malloc already defined in LIBCMT.lib(malloc.obj)
5>MSVCRT.lib(MSVCR90.dll) : error LNK2005: _atof already defined in LIBCMT.lib(atof.obj)
5>MSVCRT.lib(MSVCR90.dll) : error LNK2005: _getenv already defined in LIBCMT.lib(getenv.obj)
5>MSVCRT.lib(MSVCR90.dll) : error LNK2005: _calloc already defined in LIBCMT.lib(calloc.obj)
5>MSVCRT.lib(ti_inst.obj) : error LNK2005: "private: __thiscall type_info::type_info(class type_info const &)" (??0type_info@@AAE@ABV0@@Z) already defined in LIBCMT.lib(typinfo.obj)
5>MSVCRT.lib(ti_inst.obj) : error LNK2005: "private: class type_info & __thiscall type_info::operator=(class type_info const &)" (??4type_info@@AAEAAV0@ABV0@@Z) already defined in LIBCMT.lib(typinfo.obj)
5>libpng.lib(pngerror.obj) : MSIL .netmodule or module compiled with /GL found; restarting link with /LTCG; add /LTCG to the link command line to improve linker performance
5>MSVCRT.lib(MSVCR90.dll) : error LNK2005: _free already defined in LIBCMT.lib(free.obj)
5>MSVCRT.lib(MSVCR90.dll) : error LNK2005: _malloc already defined in LIBCMT.lib(malloc.obj)
5>MSVCRT.lib(MSVCR90.dll) : error LNK2005: _atof already defined in LIBCMT.lib(atof.obj)
5>MSVCRT.lib(MSVCR90.dll) : error LNK2005: _getenv already defined in LIBCMT.lib(getenv.obj)
5>MSVCRT.lib(MSVCR90.dll) : error LNK2005: _calloc already defined in LIBCMT.lib(calloc.obj)
5>MSVCRT.lib(ti_inst.obj) : error LNK2005: "private: __thiscall type_info::type_info(class type_info const &)" (??0type_info@@AAE@ABV0@@Z) already defined in LIBCMT.lib(typinfo.obj)
5>MSVCRT.lib(ti_inst.obj) : error LNK2005: "private: class type_info & __thiscall type_info::operator=(class type_info const &)" (??4type_info@@AAEAAV0@ABV0@@Z) already defined in LIBCMT.lib(typinfo.obj)
5>LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library
5>C:\Users\DELL\Desktop\ZC_2.54\_ZC253\ZeldaClassic\ Release\zquest.exe : fatal error LNK1169: one or more multiply defined symbols found
5>Build log was saved at "file://c:\Users\DELL\Desktop\ZC_2.54\_ZC253\ZeldaClassic\ zquest.dir\Release\BuildLog.htm"
5>zquest - 15 error(s), 20 warning(s)


This occurred when compiling ZC with the newly compiled static libs.

Obviously, something is awry, but i do not know what is causing this; nor what default lib the Allegro config wants--which seems to be one of the major problems here. This is the issue when the CMake config is both clearly tailored for MiGW, and primarily tested on Linux. it has no appropriate defaults set up for any of these deps.

I may just go with MiNGW, as at least that is a tried and proven method of compiling ag 44, and there is effectively no support for anything else on allegro.cc, nor any interest in supporting other compilers. At that rate, thay may as well just have included a makefile and require a specific compiler. :/

DarkDragon
08-19-2017, 10:51 AM
You get these errors when you compile Allegro yourself? Or using the Allegro .lib in the repository?

DarkDragon
08-19-2017, 11:03 AM
1) Linker errors related to LIBCMT: these are due to compiling Allegro with /MD (the way they have configured their build) rather than /MT. I've pushed new versions of the libraries with the correct flags set.
2) Linker errors related to MSVC2015's standard library: may or may not be fixed. I compiled the library using MSVC2015 so there's no reason to expect it will be possible to link to it with older versions of the compiler, but you can always try...
3) Errors related to loadpng: yes, you need to either rename the .lib or change the name in CMakeLists, if you want to use the new implementation included in Allegro 4.4. The issue you're reporting where loading an image only works the second time sounds very strange and I wouldn't expect it to be related to .libs at all, but you'll have to provide more details.

EDIT: I've also pushed changes to Allegro's configuration that sets the proper flags for ZC.

Gleeok
08-29-2017, 07:13 AM
When you compile a lib the two options you want are input (or dependencies), and output; e.g. output you can specify a dll (allegro defaults to this) and link dependencies to that. MSVCRT and LIBCMT are just a few; libpng and zlib are essentially the same as well. If you want a static lib that links to dlls you can do that, and in the same way you can make a shared lib that links to static libraries.

If you get errors that you are missing a dll like libpng, for example, it means you compiled and linked libpng as a dll. ...But don't get me started up on build systems again. :p

ZoriaRPG
08-31-2017, 01:00 AM
When you compile a lib the two options you want are input (or dependencies), and output; e.g. output you can specify a dll (allegro defaults to this) and link dependencies to that. MSVCRT and LIBCMT are just a few; libpng and zlib are essentially the same as well. If you want a static lib that links to dlls you can do that, and in the same way you can make a shared lib that links to static libraries.

If you get errors that you are missing a dll like libpng, for example, it means you compiled and linked libpng as a dll. ...But don't get me started up on build systems again. :p

I figured out the issue. I thought that I was not linking properly, but this turned out to be yet another case of the packfile_password needing to be set null.