User Tag List

Page 2 of 6 FirstFirst 1 2 3 4 ... LastLast
Results 11 to 20 of 59

Thread: Building on Mac and Linux

  1. #11
    Administrator DarkDragon's Avatar
    Join Date
    Oct 2001
    Posts
    6,228
    Mentioned
    70 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    11,025
    Level
    31
    vBActivity - Bars
    Lv. Percent
    8.16%
    What conversion is needed? 4.4 API is not backwards compatible with 4.2?

  2. #12
    Administrator DarkDragon's Avatar
    Join Date
    Oct 2001
    Posts
    6,228
    Mentioned
    70 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    11,025
    Level
    31
    vBActivity - Bars
    Lv. Percent
    8.16%
    In any case, one incremental step at a time. My main concern in this thread is getting a sane build system set up that works with the platforms we currently support. Once that is done, we can clean up the repository structure, and *then* discuss swapping out libraries.

  3. #13
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.7%
    Quote Originally Posted by DarkDragon View Post
    What conversion is needed? 4.4 API is not backwards compatible with 4.2?
    The main thing, was adding functions to handle the packfile password junk. That's done. At present, IDK why the audio libs are crashing on the Win platform, and Grayswandir is having different issues with audio on Linux. I think that Allegro itself is fine now, but finishing up the other libs mayn't be.

    It feel as if GME is causing the problems, but I'm unsure. We need to update that, too. We're a dozen releases back, and the newer version is more stable, with better output, and more supports more formats, including NSFE.

    Did you try running those binaries? Maybe you can debug why playing any NSF causes them to crash. If you want all the allegro stuff and the makefile that I'm using to process ZC, I can pack it all up for you. In fact, it is probably here:

    http://timelord.insomnia247.nl/zc/zc...egro_4.4.3.zip

    This relates to these log entries for ag4.4:

    Code:
    Eliminated the need for old DirectX headers for the Windows port (David Capello). 
    
    Fix problems in Windows when you use Alt-Tab. Sometimes the Alt modifier is kept pressed when you focus the Allegro window. (David Capello)
    The latter of these two issues was a very annoying bug in ZC/ZQuest, and the former helps fix some graphic badness.

    The makefile should be in there, I build Allegro following the instructions here, here, and here using the latest Allegro 4.4 tree from one year ago.

    As long as we have the libs working on our end, then there's no real reason not to include them in the main branch. Cleaning up the repo clearly isn't happening, and that's outside of my realm of control. If we make a package that has ag4.4, with clean build files, clean and updated libs, and such; then it may as well be the new main, and it can go up into the repo whenever Gleeok or Saffith want to fix it, which if things progress as they have gone in the past, will be in a few months.

    Realistically, we could fix that in a day or two, but they are the ones with repo access, and unless they want to add anyone else, they are stuck handling it. In the interim, I'd like to get us off all these ancient library versions so that maybe we can fix some of the hindrances that we're trying to fix in the worst ways possible. Hell, if we were to 'fix' one of these bugs without updating, then updating could instead introduce some quirk that we didn't expect, because we did something silly to work around a bug in software that is a decade out of date with the current tree.

    4.4 also has quite a number of Mac-specific fixes, too. You should read the changelogs. Too bad that log doesn't cover 4.4.2 to 4.4.3. Could also fix the joystick issues on some Linux systems.

    4.2 also refused to comply with being built on Linux, for @Grayswandir : He couldn't compile ZC at all, using Allegro 4.2.x., for a long while. TBH, I don't recall if he ever solved that, or if he just went with 4.4.3.

  4. #14
    Administrator DarkDragon's Avatar
    Join Date
    Oct 2001
    Posts
    6,228
    Mentioned
    70 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    11,025
    Level
    31
    vBActivity - Bars
    Lv. Percent
    8.16%
    Cleaning up the repo clearly isn't happening
    I don't know why you say this -- it is going to happen, as soon as Gleeok and Saffith help me get the build tuned so that it works for them.

    I am not opposed to switching to Allegro 4.4, but this is the wrong thread for that discussion. Moreover, if the switch happen, it will be over a series of small, thoroughly-tested and reviewed patches.

  5. #15
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.7%
    Quote Originally Posted by DarkDragon View Post
    I don't know why you say this -- it is going to happen, as soon as Gleeok and Saffith help me get the build tuned so that it works for them.

    I am not opposed to switching to Allegro 4.4, but this is the wrong thread for that discussion. Moreover, if the switch happen, it will be over a series of small, thoroughly-tested and reviewed patches.
    Mostly, because all threads with posts on the subject are silent, and there has been no reply on either the plan, or the status.

    I'm not sure how many incremental patches you'd want to do, other than one per library base, but we can discuss it later. I'm only asking you to test that build, because you are the only one with win10 that experiences these symptoms. I have win10, and I have never experienced anything other than the blue flicker bug, which this did fix. Primarily, my system is barely powerful enough to run win10 at all. |it doesn't have any fancy gfx hardware, and running the kinds of tests that prove anything just aren't feasible.

    Knowing if you have the same problem with ag4.4 would indicate to us if this is meaningful, and if it requires further investigation, possibly including hardware purchases in the future.

    Feel free to respond in the win20 thread though, as it'd be better than trailing off with this.

    It would however, be good for @Grayswandir to post about his experiences in working with compiling the 2.50.3 sources in Linux here, when he has time.

  6. #16
    Keese
    ZC Developer

    Join Date
    Jan 2007
    Age
    34
    Posts
    52
    Mentioned
    27 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    778
    Level
    9
    vBActivity - Bars
    Lv. Percent
    78.95%
    Quote Originally Posted by DarkDragon View Post
    I don't know why you say this -- it is going to happen, as soon as Gleeok and Saffith help me get the build tuned so that it works for them.
    Well, from my point of view, the very first thing you'd want to do to get the repo ready is to rename master into some other branch and get the current 2.50.x branch as master. Since that should take all of 5 minutes ... I'm not really sure what exactly you guys are doing.


    Anyway, as for building on linux - the only problem I had was the sound only working with oss, which I'm pretty sure I've narrowed down to how allegro was built. Since we're not interested in allegro 4.4 right now, and I won't be able to get ZC's frakenstein version of 4.2 to compile without tens of hours of work, I don't really have much more to contribute to the discussion. Take a look at my makefile if you want. It's considerably shorter, and halfway decently commented.

    (The actual changes to ZC making it compatible with 4.4 amounted to around 15 lines of code. And that was all undoing the changes that somebody decided to hack into ZC's allegro because having threadsafe file loading is vitally important. )

  7. #17
    Administrator DarkDragon's Avatar
    Join Date
    Oct 2001
    Posts
    6,228
    Mentioned
    70 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    11,025
    Level
    31
    vBActivity - Bars
    Lv. Percent
    8.16%
    Well, from my point of view, the very first thing you'd want to do to get the repo ready is to rename master into some other branch and get the current 2.50.x branch as master. Since that should take all of 5 minutes ... I'm not really sure what exactly you guys are doing.
    It's not branch 2.50.x that will be made master, it's branch cmake, and I'm not going to do this until I hear something from the other developers (and likely help them sort out how to make CMake correct configure the build on their system). What's the point in making 2.50.x the temporary master for a couple of days?

  8. #18
    Keese
    ZC Developer

    Join Date
    Jan 2007
    Age
    34
    Posts
    52
    Mentioned
    27 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    778
    Level
    9
    vBActivity - Bars
    Lv. Percent
    78.95%
    I wasn't saying you should. I was just pointing out that, as far as information I have, that's where we're at. Since fixing it would take 5 minutes, my best guesses are that either everybody is being incredibly lazy, or y'all decided to do something different and didn't bother telling us about it.

  9. #19
    The Time-Loop Continues ZC Developer
    Gleeok's Avatar
    Join Date
    Apr 2007
    Posts
    4,815
    Mentioned
    259 Post(s)
    Tagged
    10 Thread(s)
    vBActivity - Stats
    Points
    12,933
    Level
    33
    vBActivity - Bars
    Lv. Percent
    23.44%
    This is somewhat a conglomeration of different topics.

    Sorry guys; I'm a little unsure about the repo status as well. Keep in mind that 'master' is a few years of random commits - this represents the shardstorm repo as well. Most of these are from Saffith and I don't know what he wants to keep and throw away. I know that I want to keep all my changes, though the most I've done with ZC this last year is to basically get it all open sourced, and I'm not too sure about what's going on with it on the source code level: The files between the trunk and 2.50 can vary wildly, and I'm skeptical that this won't introduce really stupid (and potentially nasty) bugs. Testing will be required, and after 2.50.4 I think we should bump the major version.

    I think I might feel better about merging files into 'cmake 2.50.x' one at a time. I've never done such a large "code squish" before, and certainly not one with multiple devs that represent both such a large time frame and also with an interestingly complex codebase that users count on to be stable at the same time. My subversion skills are also very basic as well, which I think is normally a good thing not having to lean on tools too much, but not so much here. To put it another way, my git skills are simply terrible.

    Instead of CMake I'd prefer to migrate over my custom build from the trunk since it eliminates minutes (over 400% faster) off of the compile times and binary sizes, but I can download CMake and test it anyway.


    Quote Originally Posted by Grayswandir View Post
    I wasn't saying you should. I was just pointing out that, as far as information I have, that's where we're at. Since fixing it would take 5 minutes, my best guesses are that either everybody is being incredibly lazy, or y'all decided to do something different and didn't bother telling us about it.
    We definitely will not be accepting any pull requests until everyone gets settled anyway so what's the difference?



    [edit]
    Downloading now...

    1)Okay, so branch 'cmake' is definitely the WIP 2.50.x->master? So that's the one I should start dumping things into, right?

    2)Can we just swap that one with master once the minor issues get sorted out, then worry about the rest of it afterward, or does anything else need to be done first?

    3)2.50.x should be kept for 2.50.3 and short-term only minor bugfixes then, and we will accept only bugfixes for this branch then; is this also correct?


    [edit2]
    If we have people maintaining project files for different builds can we just have cmake as a 'backup' for everyone else?


    ..The holidays are getting to me. I'll have to start this project tomorrow. My brain is turning into mush.
    Last edited by Gleeok; 12-26-2016 at 07:58 AM.
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

  10. #20
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.7%
    Quote Originally Posted by Grayswandir View Post
    Well, from my point of view, the very first thing you'd want to do to get the repo ready is to rename master into some other branch and get the current 2.50.x branch as master. Since that should take all of 5 minutes ... I'm not really sure what exactly you guys are doing.


    Anyway, as for building on linux - the only problem I had was the sound only working with oss, which I'm pretty sure I've narrowed down to how allegro was built. Since we're not interested in allegro 4.4 right now, and I won't be able to get ZC's frakenstein version of 4.2 to compile without tens of hours of work, I don't really have much more to contribute to the discussion. Take a look at my makefile if you want. It's considerably shorter, and halfway decently commented.

    (The actual changes to ZC making it compatible with 4.4 amounted to around 15 lines of code. And that was all undoing the changes that somebody decided to hack into ZC's allegro because having threadsafe file loading is vitally important. )
    Oh, the threadsafe file loading was likely an attempt to prevent buggering the save file. I think that is separately resolved by preventing multiple instances as a runtime option, as that fix didn't work (?).

    Mates, IDK what is happening. When Saffith said he wanted to make 2.50.x 'master', because he wanted to toss out the refactoring, and Gleeok said that'd be fine, we've all been acting under the presumption that this was finalized. That's why you can't let weeks pass when deciding these things, and then jump in and change things without public discussion and announcements of the plan.

    We've all spent considerable time working on this mess, and remerging the changes is a genuine pain.

    Make something main that isn't going to change. I suggest 2.50.x, stable. Make something the next dev branch. Set them in the repo, and we'll work from there, but please stop changing the plan, and doing things without discussing them in threads; so that we're all on the same page.

    I'm going to again ask that the stable version slated as the next release is kept as master. That way, it's sane, and anyone who wants to build from it knows what is what. Making the development branch 'main' is just downright confusing to everyone, and it's very rarely done that way.

    We can probably fix our changes in one or two days, but it's still a waste of time.

    Also, is the CMake branch going to retain the MinGW/MSYS essentials? I don't particularly want to shift to CMake, especially as the way I've things configured now, it takes me all of two seconds to shift lib stuff out, and I can do simultaneous builds using the old, and the new libs without changing any paths or includes. I could use separate makefiles, I suppose, but this way I only need to decide if I use MSYS or cmd.exe to do the build. (MSYS builds on the old libs, cmd.exe with MinGW32-make does ag4.4.)

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
About us
Armageddon Games is a game development group founded in 1997. We are extremely passionate about our work and our inspirations are mostly drawn from games of the 8-bit and 16-bit era.
Social