From: Alexander S. <ast...@it...> - 2005-02-19 19:03:30
|
On Feb 19, 2005, at 1:12 PM, Christopher Lund wrote: > I'm still having trouble with the SDL headers / frameworks. SDL and > SDL_net refer to each other but can't find each other's headers - and > moving the framework from my home lib to the root lib didn't work. Do > you have any idea how to fix this problem? Or at the very least, do > you know of somebody else I can ask? > > Thanks for your time anyhow. > > C Lund I checked the latest build, and it looks like the frameworks inside it don't have the headers anymore. You might want to try the previous build (http://prdownloads.sourceforge.net/marathon/ AlephOneCarbon20040417.dmg?download). |
From: Gregory S. <wo...@tr...> - 2005-02-21 13:18:38
|
Is this a problem? You don't need the headers installed for the binary to use the frameworks, right? You would need the headers to build Aleph One but you can get them from the SDL website. Gregory Alexander Strange wrote: > > On Feb 19, 2005, at 1:12 PM, Christopher Lund wrote: > >> I'm still having trouble with the SDL headers / frameworks. SDL and >> SDL_net refer to each other but can't find each other's headers - and >> moving the framework from my home lib to the root lib didn't work. Do >> you have any idea how to fix this problem? Or at the very least, do >> you know of somebody else I can ask? >> >> Thanks for your time anyhow. >> >> C Lund > > > I checked the latest build, and it looks like the frameworks inside it > don't have the headers anymore. You might want to try the previous > build (http://prdownloads.sourceforge.net/marathon/ > AlephOneCarbon20040417.dmg?download). > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Marathon-devel mailing list > Mar...@li... > https://lists.sourceforge.net/lists/listinfo/marathon-devel |
From: Eric P. <Fre...@ch...> - 2005-02-21 14:42:55
|
Not the ones for SDL_image. =/ On Feb 21, 2005, at 7:14 AM, Gregory Smith wrote: > Is this a problem? You don't need the headers installed for the > binary to use the frameworks, right? You would need the headers to > build Aleph One but you can get them from the SDL website. > > Gregory > > Alexander Strange wrote: >> On Feb 19, 2005, at 1:12 PM, Christopher Lund wrote: >>> I'm still having trouble with the SDL headers / frameworks. SDL and >>> SDL_net refer to each other but can't find each other's headers - >>> and moving the framework from my home lib to the root lib didn't >>> work. Do you have any idea how to fix this problem? Or at the very >>> least, do you know of somebody else I can ask? >>> >>> Thanks for your time anyhow. >>> >>> C Lund >> I checked the latest build, and it looks like the frameworks inside >> it don't have the headers anymore. You might want to try the >> previous build (http://prdownloads.sourceforge.net/marathon/ >> AlephOneCarbon20040417.dmg?download). >> ------------------------------------------------------- >> SF email is sponsored by - The IT Product Guide >> Read honest & candid reviews on hundreds of IT Products from real >> users. >> Discover which products truly live up to the hype. Start reading now. >> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >> _______________________________________________ >> Marathon-devel mailing list >> Mar...@li... >> https://lists.sourceforge.net/lists/listinfo/marathon-devel > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Marathon-devel mailing list > Mar...@li... > https://lists.sourceforge.net/lists/listinfo/marathon-devel > |
From: <wo...@tr...> - 2005-02-21 15:03:52
|
Source files (including headers) for SDL_image are available here: http://www.libsdl.org/projects/SDL_image/ There's a link on the right hand side of the main SDL page "Libraries" which brings up a search page into which you can type whatever SDL library you are looking for. Gregory On Mon, 21 Feb 2005, Eric Peterson wrote: > Not the ones for SDL_image. =/ > > On Feb 21, 2005, at 7:14 AM, Gregory Smith wrote: > >> Is this a problem? You don't need the headers installed for the >> binary to use the frameworks, right? You would need the headers to build >> Aleph One but you can get them from the SDL website. >> >> Gregory >> >> Alexander Strange wrote: >>> On Feb 19, 2005, at 1:12 PM, Christopher Lund wrote: >>>> I'm still having trouble with the SDL headers / frameworks. SDL and >>>> SDL_net refer to each other but can't find each other's headers - and >>>> moving the framework from my home lib to the root lib didn't work. Do >>>> you have any idea how to fix this problem? Or at the very least, do >>>> you know of somebody else I can ask? >>>> >>>> Thanks for your time anyhow. >>>> >>>> C Lund >>> I checked the latest build, and it looks like the frameworks inside it >>> don't have the headers anymore. You might want to try the previous >>> build (http://prdownloads.sourceforge.net/marathon/ >>> AlephOneCarbon20040417.dmg?download). >>> ------------------------------------------------------- >>> SF email is sponsored by - The IT Product Guide >>> Read honest & candid reviews on hundreds of IT Products from real >>> users. >>> Discover which products truly live up to the hype. Start reading now. >>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >>> _______________________________________________ >>> Marathon-devel mailing list >>> Mar...@li... >>> https://lists.sourceforge.net/lists/listinfo/marathon-devel >> >> >> >> ------------------------------------------------------- >> SF email is sponsored by - The IT Product Guide >> Read honest & candid reviews on hundreds of IT Products from real users. >> Discover which products truly live up to the hype. Start reading now. >> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >> _______________________________________________ >> Marathon-devel mailing list >> Mar...@li... >> https://lists.sourceforge.net/lists/listinfo/marathon-devel >> > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Marathon-devel mailing list > Mar...@li... > https://lists.sourceforge.net/lists/listinfo/marathon-devel > |
From: Eric P. <Fre...@ch...> - 2005-02-22 04:00:20
|
Well...yeah. But don't you need the Frameworks to make it go? On Feb 21, 2005, at 8:59 AM, wo...@tr... wrote: > Source files (including headers) for SDL_image are available here: > > http://www.libsdl.org/projects/SDL_image/ > > There's a link on the right hand side of the main SDL page > "Libraries" which brings up a search page into which you can type > whatever SDL library you are looking for. > > Gregory > > On Mon, 21 Feb 2005, Eric Peterson wrote: > >> Not the ones for SDL_image. =/ >> >> On Feb 21, 2005, at 7:14 AM, Gregory Smith wrote: >> >>> Is this a problem? You don't need the headers installed for the >>> binary to use the frameworks, right? You would need the headers to >>> build Aleph One but you can get them from the SDL website. >>> Gregory >>> Alexander Strange wrote: >>>> On Feb 19, 2005, at 1:12 PM, Christopher Lund wrote: >>>>> I'm still having trouble with the SDL headers / frameworks. SDL >>>>> and SDL_net refer to each other but can't find each other's >>>>> headers - and moving the framework from my home lib to the root >>>>> lib didn't work. Do you have any idea how to fix this problem? Or >>>>> at the very least, do you know of somebody else I can ask? >>>>> Thanks for your time anyhow. >>>>> C Lund >>>> I checked the latest build, and it looks like the frameworks inside >>>> it don't have the headers anymore. You might want to try the >>>> previous build (http://prdownloads.sourceforge.net/marathon/ >>>> AlephOneCarbon20040417.dmg?download). >>>> ------------------------------------------------------- >>>> SF email is sponsored by - The IT Product Guide >>>> Read honest & candid reviews on hundreds of IT Products from real >>>> users. >>>> Discover which products truly live up to the hype. Start reading >>>> now. >>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >>>> _______________________________________________ >>>> Marathon-devel mailing list >>>> Mar...@li... >>>> https://lists.sourceforge.net/lists/listinfo/marathon-devel >>> ------------------------------------------------------- >>> SF email is sponsored by - The IT Product Guide >>> Read honest & candid reviews on hundreds of IT Products from real >>> users. >>> Discover which products truly live up to the hype. Start reading now. >>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >>> _______________________________________________ >>> Marathon-devel mailing list >>> Mar...@li... >>> https://lists.sourceforge.net/lists/listinfo/marathon-devel >> >> >> >> ------------------------------------------------------- >> SF email is sponsored by - The IT Product Guide >> Read honest & candid reviews on hundreds of IT Products from real >> users. >> Discover which products truly live up to the hype. Start reading now. >> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >> _______________________________________________ >> Marathon-devel mailing list >> Mar...@li... >> https://lists.sourceforge.net/lists/listinfo/marathon-devel >> > |
From: Christopher L. <chr...@ch...> - 2005-02-24 22:33:39
|
I finally managed to compile AO on PB. I've written down the steps I had to go through in order to make it work. It might be helpful to others: ------------------------ 1. Download MacCVS Pro and Aleph One as pr the instructions on http://source.bungie.org/_enginedevelopment/cvs/aboutcvs.html 2. Download a compiled copy of AO. Copy the SDL and SDL_net frameworks in the .app folder to your library folder. (thanks, Alexander Strange) 3. Follow the instructions in the INSTALL.MacOSX.Carbon in your source folder. But when installing Speex, the last two lines of the recipe, Make directory /Library/Application Support/Speex Move speex-1.0 directory into /Library/Application Support/Speex are not done in Terminal - they are done in the GUI. Make a folder called Speex in the Support directory, and move the thing into the app support folder. (thanks, Alexander Strange) 4. Add the "Metaserver" folder to the project. It's located in Source_Files/Network/. 5. Add "speex.h" to the project. It's located in (hard drive)/Library/Application Support/Speex/speex-1.0/libspeex. 6. Locate all instances of #include "SDL.h" and #include "SDL_net.h" Change them to #include "SDL/SDL.h" and #include "SDL_net/SDL_net.h" (thanks, Michael Ash, of comp.sys.mac.programmer.help) 7. Locate #include "metaserver_dialogs.h" and change it to #include "Metaserver/metaserver_dialogs.h" 8. Locate all instances of #include "SDL_timer.h" and change them to #include "SDL/SDL_timer.h" 9. Locate all instances of #include "SDL_thread.h" and change them to #include "SDL/SDL_thread.h" 10. Locate #include "SDL_error.h" and change it to #include "SDL/SDL_error.h" ------------------------ I'm still getting a warning message though. But it doesn't seem to have any effect so I'm going to ignore it unless it does become a problem: ld: warning -L: directory name (/usr/local/lib) does not exist Any idea what that means? Doesn't seem to be a problem though. C Lund |
From: Gregory S. <wo...@tr...> - 2005-02-24 23:31:16
|
I would recommend against changing #include files, you're just setting yourself up for a lot of maintenance any time you want to update from CVS. Much better to change the project includes path to include SDL, SDL_net, and Metaserver. The command line version of CVS included with OS X works just fine, there's no need to download MacCVS. Those instructions are ridiculously out of date. You want to install the SDL and SDL_net frameworks (both binaries and devel) from the SDL website, not from an old version of Aleph One! In the interest of helping others :) Gregory On Feb 24, 2005, at 5:33 PM, Christopher Lund wrote: > I finally managed to compile AO on PB. I've written down the steps I > had to go through in order to make it work. It might be helpful to > others: > > ------------------------ > > 1. Download MacCVS Pro and Aleph One as pr the instructions on > > http://source.bungie.org/_enginedevelopment/cvs/aboutcvs.html > > 2. Download a compiled copy of AO. Copy the SDL and SDL_net frameworks > in the .app folder to your library folder. (thanks, Alexander Strange) > > 3. Follow the instructions in the INSTALL.MacOSX.Carbon in your source > folder. But when installing Speex, the last two lines of the recipe, > > Make directory /Library/Application Support/Speex > Move speex-1.0 directory into /Library/Application Support/Speex > > are not done in Terminal - they are done in the GUI. Make a folder > called Speex in the Support directory, and move the thing into the app > support folder. (thanks, Alexander Strange) > > 4. Add the "Metaserver" folder to the project. It's located in > Source_Files/Network/. > > 5. Add "speex.h" to the project. It's located in (hard > drive)/Library/Application Support/Speex/speex-1.0/libspeex. > > 6. Locate all instances of > > #include "SDL.h" > and > #include "SDL_net.h" > > Change them to > > #include "SDL/SDL.h" > and > #include "SDL_net/SDL_net.h" > > (thanks, Michael Ash, of comp.sys.mac.programmer.help) > > 7. Locate > > #include "metaserver_dialogs.h" > > and change it to > > #include "Metaserver/metaserver_dialogs.h" > > 8. Locate all instances of > > #include "SDL_timer.h" > > and change them to > > #include "SDL/SDL_timer.h" > > 9. Locate all instances of > > #include "SDL_thread.h" > > and change them to > > #include "SDL/SDL_thread.h" > > 10. Locate > > #include "SDL_error.h" > > and change it to > > #include "SDL/SDL_error.h" > > ------------------------ > > I'm still getting a warning message though. But it doesn't seem to > have any effect so I'm going to ignore it unless it does become a > problem: > > ld: warning -L: directory name (/usr/local/lib) does not exist > > Any idea what that means? Doesn't seem to be a problem though. > > C Lund |
From: Christopher L. <chr...@ch...> - 2005-02-25 07:53:15
|
On 25. feb 2005, at 00:31, Gregory Smith wrote: > I would recommend against changing #include files, you're just setting > yourself up for a lot of maintenance any time you want to update from > CVS. Much better to change the project includes path to include SDL, > SDL_net, and Metaserver. The project wouldn't compile when the include lines were #include "SDL_net.h" etc. I didn't really have any options there. Not that replacing the lines were all that work. All I did was follow the error messages.. ;) > The command line version of CVS included with OS X works just fine, > there's no need to download MacCVS. Those instructions are > ridiculously out of date. Hmm.. In that case, you guys might want to update those instructions... > You want to install the SDL and SDL_net frameworks (both binaries and > devel) from the SDL website, not from an old version of Aleph One! I tried that, but couldn't get them to compile. Of course, that was before I fixed the "include" lines. Maybe I'll try downloading them again. One question about the SDL_net framework from the SDL website: Why does it install both in the root lib *and* the home/lib? Even stranger - only the framework in the urs/lib gets the headers. > In the interest of helping others :) > > Gregory C Lund |
From: Alexei S. <isv...@sy...> - 2005-02-25 18:13:57
|
>> The command line version of CVS included with OS X works just fine, >> there's no need to download MacCVS. Those instructions are >> ridiculously out of date. > > Hmm.. In that case, you guys might want to update those instructions... > To note: CVS is included with OS X only if you have installed the developer tools. Aside from that, someone _does_ need to update the instructions on how to get Aleph One to compile, including installing all the libraries, all on one page so it would be easier for users to get it running from a fresh cvs checkout. -Myrd |
From: Timothy C. <da...@ma...> - 2005-02-25 18:24:34
|
On Feb 25, 2005, at 1:13 PM, Alexei Svitkine wrote: >>> The command line version of CVS included with OS X works just fine, >>> there's no need to download MacCVS. Those instructions are >>> ridiculously out of date. >> >> Hmm.. In that case, you guys might want to update those >> instructions... >> > > To note: CVS is included with OS X only if you have installed the > developer tools. Aside from that, someone _does_ need to update the > instructions on how to get Aleph One to compile, including installing > all the libraries, all on one page so it would be easier for users to > get it running from a fresh cvs checkout. You're going to need the devtools if you plan to build A1 from source, no matter how you actually come by the source. Timothy Collett |
From: Christopher L. <chr...@ch...> - 2005-02-26 16:47:01
|
Where do I send specific questions wrt coding? The marathon-devel list? One of the other addresses above? Somewhere else? First question: I want to alter the prefs so certain selections can't be made - such as not allowing fog to be turned off*, not being allowed to "fix" the smears caused by untextured surfaces, and other things that would be detrimental to Rubicon. Where do I make those changes? I deleted the "enable fog" checkbox in the nib file just to see what would happen. But when I ran the engine and checked the prefs, the checkbox was still there. It is added programmatically rather than loaded from the nib? Also, why is the Images file the only file that has to have it's original name? All the other data files can be renamed without any negative effect. * The rumours I heard long ago of fog being broken in AO were just rumours, right? C Lund |
From: Gregory S. <wo...@tr...> - 2005-02-26 17:14:03
|
The marathon-devel list is the right place. Are you intending on making your own version of Aleph One for Rubicon? You'll miss out on updates, bug fixes, break network compatibility, etc. Seems like that's a high price to pay for removing someone's ability to taylor the game to his machine and tastes. Gregory On Feb 26, 2005, at 11:46 AM, Christopher Lund wrote: > Where do I send specific questions wrt coding? The marathon-devel > list? One of the other addresses above? Somewhere else? > > First question: I want to alter the prefs so certain selections can't > be made - such as not allowing fog to be turned off*, not being > allowed to "fix" the smears caused by untextured surfaces, and other > things that would be detrimental to Rubicon. Where do I make those > changes? I deleted the "enable fog" checkbox in the nib file just to > see what would happen. But when I ran the engine and checked the > prefs, the checkbox was still there. It is added programmatically > rather than loaded from the nib? > > Also, why is the Images file the only file that has to have it's > original name? All the other data files can be renamed without any > negative effect. > > * The rumours I heard long ago of fog being broken in AO were just > rumours, right? > > C Lund |
From: Christopher L. <chr...@ch...> - 2005-02-26 17:36:36
|
On 26. feb 2005, at 18:13, Gregory Smith wrote: > The marathon-devel list is the right place. Ok. That's where I'll be asking from now on. B) > Are you intending on making your own version of Aleph One for > Rubicon? You'll miss out on updates, bug fixes, break network > compatibility, etc. Seems like that's a high price to pay for removing > someone's ability to taylor the game to his machine and tastes. The alternative is being bogged down with complaints about missing sound - that is an almost guaranteed result of using the generic AO engine. 90% of the players will complain about no sound. And then there's the fact that the prefs can seriously mess up the visuals of rubicon (such as the smear bug, which I've used on several levels). It won't have any effect on network compatibility, since players would only be able to play rubicon network levels against other players with rubicon anyway (or are the textures also sent to the clients?). And if some seriously valuable updates or bug fixes are applied, then I'll consider releasing a updated Rubicon engine later on. The changes I plan on making aren't drastic, just vital to what I want Rubicon X to be. > Gregory C Lund |
From: Gregory S. <wo...@tr...> - 2005-02-26 18:02:11
|
Have you considered fixing the 16-bit/8-bit sound issue, rather than working around it by making your own version of the engine? And perhaps it's possible to add a new texture mode "smear", so that purposefully smeared textures would render correctly even if the preference for un-textured polys was enabled. Name a game besides Aleph One where you can't disable fog. What about people who can't use fog because their hardware isn't powerful enough? Or people who don't have 3D hardware at all, they won't see it in the first place. I think many of us have been tempted to make our own version of the engine, but in the end we all benefit more from working on one code base. Think of how many scenarios you could help by making aleph one revert to the 8-bit sound if it couldn't find a 16-bit sound in the slot, rather than spending probably the same amount of time branching your own version, hacking a few checkboxes out, and then figuring out how to build and test it on all the platforms Aleph One supports. Not to mention merging in new features and bug fixes that come along in the main Aleph One code base. But I'll be happy to lend support either way you do it. The reason editing NIBs files won't remove the checkboxes from the standard build is because NIBs aren't used unless you enable them. The default carbon build still uses the marathon 2 resources. Gregory On Feb 26, 2005, at 12:36 PM, Christopher Lund wrote: > On 26. feb 2005, at 18:13, Gregory Smith wrote: > >> The marathon-devel list is the right place. > > Ok. That's where I'll be asking from now on. B) > >> Are you intending on making your own version of Aleph One for >> Rubicon? You'll miss out on updates, bug fixes, break network >> compatibility, etc. Seems like that's a high price to pay for >> removing someone's ability to taylor the game to his machine and >> tastes. > > The alternative is being bogged down with complaints about missing > sound - that is an almost guaranteed result of using the generic AO > engine. 90% of the players will complain about no sound. And then > there's the fact that the prefs can seriously mess up the visuals of > rubicon (such as the smear bug, which I've used on several levels). It > won't have any effect on network compatibility, since players would > only be able to play rubicon network levels against other players with > rubicon anyway (or are the textures also sent to the clients?). > > And if some seriously valuable updates or bug fixes are applied, then > I'll consider releasing a updated Rubicon engine later on. The changes > I plan on making aren't drastic, just vital to what I want Rubicon X > to be. > >> Gregory > > > > C Lund |
From: Alexander S. <ast...@it...> - 2005-02-26 18:12:20
|
On Feb 26, 2005, at 1:01 PM, Gregory Smith wrote: > Have you considered fixing the 16-bit/8-bit sound issue, rather than > working around it by making your own version of the engine? And > perhaps it's possible to add a new texture mode "smear", so that > purposefully smeared textures would render correctly even if the > preference for un-textured polys was enabled. A new texture mode would be a bit hard, since Forge and Anvil wouldn't understand it. I'm not sure what a better solution would be, except for adding another MML toggle that forced smearing on. > ... > But I'll be happy to lend support either way you do it. The reason > editing NIBs files won't remove the checkboxes from the standard build > is because NIBs aren't used unless you enable them. The default carbon > build still uses the marathon 2 resources. Have all the issues with NIB support been fixed? If they have, I don't want it using the old, almost completely uneditable GUI code. If they haven't, what's still to fix? |
From: James W. <jk...@ya...> - 2005-02-27 03:41:27
|
--- Alexander Strange <ast...@it...> wrote: > Have all the issues with NIB support been fixed? If they have, I don't > want it using the old, almost completely uneditable GUI code. If they > haven't, what's still to fix? > There are some features nonimplemented in NIBs. (autogather, network lua script selector) Code needs to be factored out so NIBs and rsrc/SDL can share. I think NIB support is OK otherwise. __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail |
From: Christopher L. <chr...@ch...> - 2005-02-26 18:32:53
|
On 26. feb 2005, at 19:01, Gregory Smith wrote: > Have you considered fixing the 16-bit/8-bit sound issue, Working on the sounds file is a huge pain - one I'd rather not go through again. Besides, I'm not sure we still have 16-bit sounds sources for all the files anyway. > rather than working around it by making your own version of the > engine? And perhaps it's possible to add a new texture mode "smear", > so that purposefully smeared textures would render correctly even if > the preference for un-textured polys was enabled. Would you guys be willing to add something like that to the engine? > Name a game besides Aleph One where you can't disable fog. What about > people who can't use fog because their hardware isn't powerful enough? > Or people who don't have 3D hardware at all, they won't see it in the > first place. Hmm.. you have a point there. Although I think players with machines that old would have trouble with some of the new levels, fog or no fog... Aleph One supports above and below-water fog, right? I think I found something like that in the code. > I think many of us have been tempted to make our own version of the > engine, but in the end we all benefit more from working on one code > base. Think of how many scenarios you could help by making aleph one > revert to the 8-bit sound if it couldn't find a 16-bit sound in the > slot, rather than spending probably the same amount of time branching > your own version, hacking a few checkboxes out, and then figuring out > how to build and test it on all the platforms Aleph One supports. Not > to mention merging in new features and bug fixes that come along in > the main Aleph One code base. The thing is.. AO is Carbon. While I can code C, I am unfamiliar with the Carbon API. Simply hacking the prefs and editing some variables here and there is a lot less work for me than implementing real changes to the code. If AO for OS X had been in Cocoa, I might have been able to make some serious contributions to the project, but that is not the case. At least, that is how it seems to me. What I was intending was to hack it so it did what I wanted on OS X and then release the code (plus some descriptions of what changse I've made) so anybody who wanted to could port it to some other platform. If I made a list of features that I miss in Aleph One, would you (or the dev-team) be willing to implement them? This would be stuff like MML tags that disable or override certain prefs, terminals and chapter screens that fill the screen rather than appear in a tiny box in the middle of an otherwise black screen, and so on. And of course the smears and 16/8 bit sound thing. None of the "have to be done" things were major. The only thing I would have liked to do that would have been a serious effort would be to move the "zoom view" function from the function keys to a weapons trigger - and I'm probably not able to do that anyway. > But I'll be happy to lend support either way you do it. The reason > editing NIBs files won't remove the checkboxes from the standard build > is because NIBs aren't used unless you enable them. The default carbon > build still uses the marathon 2 resources. The res-edit resources. Ok. > Gregory C Lund |
From: Alexander S. <ast...@it...> - 2005-02-26 19:13:29
|
On Feb 26, 2005, at 1:31 PM, Christopher Lund wrote: > > On 26. feb 2005, at 19:01, Gregory Smith wrote: > >> Have you considered fixing the 16-bit/8-bit sound issue, > > Working on the sounds file is a huge pain - one I'd rather not go > through again. Besides, I'm not sure we still have 16-bit sounds > sources for all the files anyway. This means fixing Aleph itself so it will automatically play the 8-bit sounds when there are no 16-bit sounds, not changing the Sounds file. I'm not sure if any of our sound APIs allow mixed 8bit/16bit, but it should be easy to automatically convert the 8bit to 16bit if there's no real 16bit sample. (using sixteen = eight | eight<<8) |
From: Bill C. <ra...@ex...> - 2005-02-26 19:24:32
|
At 1:01 PM -0500 on 2/26/05, Gregory Smith wrote: > I think many of us have been tempted to make our own version >of the engine, but in the end we all benefit more from working on >one code base. The only thing that's stopped me is my lack of understanding of how the code works (I have yet to get it to compile). Albeit, I've been spending most of my effort at updating maps, physics, and textures, so perhaps at some point I will have the time to venture down that path. >Think of how many scenarios you could help by making aleph one >revert to the 8-bit sound if it couldn't find a 16-bit sound in the >slot, rather than spending probably the same amount of time >branching your own version, hacking a few checkboxes out, and then >figuring out how to build and test it on all the platforms Aleph One >supports. Interestingly, we've already found away around the sound problem. Glen (the other Glen) created a version of our Sounds file that maps the 8-bit sounds to the 16-bit sounds using *I forgot the name* utility, and it works great. >Not to mention merging in new features and bug fixes that come along >in the main Aleph One code base. The key (and if I were to make any changes to customize an engine for EMR I would do this) is to minimize the changes only for necessary customizations that you *know* the AlephOne group will not support (e.g., things that break recorded movie playback), but give your scenario that extra kick that you've been dreaming about and desperately hoping some day to implement. Bill -- Bill Catambay The Marathon Map Makers Guild mailto:ra...@ex... http://excaliburworld.com/emr/ |
From: Christopher L. <chr...@ch...> - 2005-03-02 10:34:59
|
On 26. feb 2005, at 19:01, Gregory Smith wrote: > I think many of us have been tempted to make our own version of the > engine, but in the end we all benefit more from working on one code > base. Think of how many scenarios you could help by making aleph one > revert to the 8-bit sound if it couldn't find a 16-bit sound in the > slot, rather than spending probably the same amount of time branching > your own version, hacking a few checkboxes out, and then figuring out > how to build and test it on all the platforms Aleph One supports. Not > to mention merging in new features and bug fixes that come along in > the main Aleph One code base. As I suggested in my previous email (but perhaps it was poorly worded) is that there is a way to use a generic AO engine with Rubicon - provided certain features are added - mostly MML tags disable or override certain preferences. There should also be a tag that lets the script dictate what a preference file is supposed to be called (fex "Rubicon Preferences" instead of "AO Preferences"). This is because players will probably want to have seperate preferences for the various scenarios - especially when some scenarios, like mine, override the prefs. Furthermore, AO should look for scripts not in a folder called "Scripts", but in a folder with a name that *ends* with "Scripts" - so I can have a folder called "Rubicon Scripts". (and why does AO insist that the Images folder be called Images, when it is not so strict with the other data files?) It would also be nice if the scripts could be used to tell AO which set of icons to use. Would these things be much work to implement? Does AO support level-specific scripts embedded in resource fork of the map? Another thing: I've been making some vanilla Infinity network maps lately (as a result of discovering online play with AO), but I can't get the fog to work on those levels. How do I do that? I know fog worked in earlier versions of AO, but I don't seem to be able to get it to work in this version. Yet I know the code is in the engine. C Lund |
From: Gregory S. <wo...@tr...> - 2005-03-02 13:00:45
|
The MML documentation that comes with the game contains the answers to many of your questions about filenames and fog. Give it a read. It's useful to have Aleph One look in "Scripts" because otherwise it would require an MML script to tell it where to look, and those are usually stored in "Scripts" :-) Icons are built into the game when it is compiled, there's no way to change those with MML. It would be possible, I suppose, to add an MML tag to (for example) always use fog even when the user tries to disable it. For reasons I've already listed I don't think this is a good idea. The other alternative is to make the MML tag enable it by default only when creating a new preferences file (which would happen whenever users first use your scenario), which is probably OK, although that would still annoy those of us who don't use fog, and is also a bit inconsistent for users. I haven't played many other games that default to having extra graphics options turned on. Gregory Christopher Lund wrote: > On 26. feb 2005, at 19:01, Gregory Smith wrote: > > I think many of us have been tempted to make our own version of the > engine, but in the end we all benefit more from working on one code > base. Think of how many scenarios you could help by making aleph one > revert to the 8-bit sound if it couldn't find a 16-bit sound in the > slot, rather than spending probably the same amount of time > branching your own version, hacking a few checkboxes out, and then > figuring out how to build and test it on all the platforms Aleph One > supports. Not to mention merging in new features and bug fixes that > come along in the main Aleph One code base. > > > As I suggested in my previous email (but perhaps it was poorly worded) > is that there is a way to use a generic AO engine with Rubicon - > provided certain features are added - mostly MML tags disable or > override certain preferences. There should also be a tag that lets the > script dictate what a preference file is supposed to be called (fex > "Rubicon Preferences" instead of "AO Preferences"). This is because > players will probably want to have seperate preferences for the various > scenarios - especially when some scenarios, like mine, override the prefs. > Furthermore, AO should look for scripts not in a folder called > "Scripts", but in a folder with a name that *ends* with "Scripts" - so I > can have a folder called "Rubicon Scripts". (and why does AO insist that > the Images folder be called Images, when it is not so strict with the > other data files?) > It would also be nice if the scripts could be used to tell AO which set > of icons to use. > Would these things be much work to implement? > > Does AO support level-specific scripts embedded in resource fork of the > map? > > Another thing: I've been making some vanilla Infinity network maps > lately (as a result of discovering online play with AO), but I can't get > the fog to work on those levels. How do I do that? I know fog worked in > earlier versions of AO, but I don't seem to be able to get it to work in > this version. Yet I know the code is in the engine. > > > */C Lund/* > |
From: Timothy C. <da...@ma...> - 2005-03-02 14:13:46
|
On Mar 2, 2005, at 7:55 AM, Gregory Smith wrote: > It's useful to have Aleph One look in "Scripts" because otherwise it > would require an MML script to tell it where to look, and those are > usually stored in "Scripts" :-) But is there no way to change the behaviour from looking in ./Scripts to looking in ./*Scripts? > Icons are built into the game when it is compiled, there's no way to > change those with MML. I don't know how it works on Linux and Windows, but on OS X, with a bundled app , the icons are stored inside the app bundle, and specified by the Info.plist file. If you create your own Info.plist and replace the one in Aleph One.app/Contents/ with it, then put your icons in Aleph One.app/Contents/Resources/, it will use your icons. This should be easy to do with a shell script when people install Rubicon. You could even have it save the existing Info.plist with a different name (Info.old or something), and also provide a script that could toggle between vanilla A1 and Rubicon icons. I don't know if there would be an MML way of doing this... It seems to me that a very good solution to all of this would be to add to A1 the concept of a "scenario", which would allow us to compartmentalize things much better. A1 ought to be able to read and write its own Info.plist file (though, again, I have no idea how icons are handled in Windows and Linux) so as to use the icons provided by the scenario (note that this is simply a statement of technical capability, not an endorsement...I'm brainstorming here ;-) ). It also ought to be able to accept a specified set of Map/Images/Shapes/Sounds/PM files to make up the scenario, and select them all at once in the Environment prefs. I don't see this as modifying the fundamental behaviour of Marathon, since it can still just read whatever you put there: a scenario would be an option, specified by an XML file or something. Is there any philosophical, or significant technical, objection to implementing this? Besides the obvious "we're working on other things"? Timothy Collett (New computer--.sigs not transferred yet) |
From: <wo...@tr...> - 2005-03-02 15:54:25
|
On Wed, 2 Mar 2005, Timothy Collett wrote: > But is there no way to change the behaviour from looking in ./Scripts to > looking in ./*Scripts? So if I create a directory in my aleph one data directory called "Disabled Scripts" Aleph One should use them? I don't think it's a bad thing to standardize this one thing. Is it really necessary that *every* file and directory begin with the name of your scenario? > I don't know how it works on Linux and Windows, but on OS X, with a bundled > app , the icons are stored inside the app bundle, and specified by the > Info.plist file. If you create your own Info.plist and replace the one in > Aleph One.app/Contents/ with it, then put your icons in Aleph > One.app/Contents/Resources/, it will use your icons. This should be easy to > do with a shell script when people install Rubicon. You could even have it > save the existing Info.plist with a different name (Info.old or something), > and also provide a script that could toggle between vanilla A1 and Rubicon > icons. On windows the icon has to be added to the executable resources, which I haven't done for the last two builds. Hopefully next time. On linux there is no concept of an icon associated with an executable. But if you include a PNG or XPM icon, most users or packagers should be able to put it in the right place. > It seems to me that a very good solution to all of this would be to add to A1 > the concept of a "scenario", which would allow us to compartmentalize things > much better. A1 ought to be able to read and write its own Info.plist file > (though, again, I have no idea how icons are handled in Windows and Linux) so > as to use the icons provided by the scenario (note that this is simply a > statement of technical capability, not an endorsement...I'm brainstorming > here ;-) ). It also ought to be able to accept a specified set of > Map/Images/Shapes/Sounds/PM files to make up the scenario, and select them > all at once in the Environment prefs. > I don't see this as modifying the fundamental behaviour of Marathon, since it > can still just read whatever you put there: a scenario would be an option, > specified by an XML file or something. We've got all of this right now, via MML, except the writing of the Info.plist, which can't possibly be a good idea while the application is running. It's probably better to do the install script idea, or just include a folder that has the icon so the user can copy and paste it :) I think in the long run we do need to add a few things to MML to make scenario support a bit better, such as being able to specify a scenario ID for net games (so inf users won't be able to join rubicon games). I also think we need an enhanced map format, which can deal with per-level scripts and terminals without using resource forks. > Is there any philosophical, or significant technical, objection to > implementing this? Besides the obvious "we're working on other things"? Aside from my earlier explanation of why I don't think it's necessary, I'll (and I'm sure the other, more prominent developers will) always accept patches that don't break the classic Marathon gameplay, and don't have other major flaws, like confounding users or compromising their security. You may want to elaborate on your ideas here to get feedback as to things others might want, and feedback from the developers on how they could be made to fit in the engine better, before you start working on anything serious. There's probably a latent flamewar about map/scenario formats, but usually whoever actually implements something wins those. > > Timothy Collett > > (New computer--.sigs not transferred yet) Gregory |
From: Timothy C. <da...@ma...> - 2005-03-02 16:31:45
|
On Mar 2, 2005, at 10:49 AM, wo...@tr... wrote: > So if I create a directory in my aleph one data directory called > "Disabled Scripts" Aleph One should use them? I don't think it's a bad > thing to standardize this one thing. Is it really necessary that > *every* file and directory begin with the name of your scenario? Well, I don't know the issues involved here. Does it already select the appropriate script within the Scripts folder for the scenario? > On windows the icon has to be added to the executable resources, > which I haven't done for the last two builds. Hopefully next time. On > linux there is no concept of an icon associated with an executable. > But if you include a PNG or XPM icon, most users or packagers should > be able to put it in the right place. So does that mean that the *only* way to change the icon-set on Windows is at compile time? (please forgive my utter ignorance in the matter...) > We've got all of this right now, via MML, except the writing of the > Info.plist, which can't possibly be a good idea while the application > is running. It's probably better to do the install script idea, or > just include a folder that has the icon so the user can copy and paste > it :) That's probably true ;-) But is there, in fact, a way within the game to select, from a menu of some sort, the scenario you want to play (eg, "Marathon 2", "M1A1", "Rubicon") and have it select all the appropriate files for that? Basically, that's what I'm imagining: an extra popup menu in the Environment prefs that has all available scenarios. When you select one, it sets each of the popups below to the appropriate filename. Timothy Collett |
From: <wo...@tr...> - 2005-03-02 18:40:08
|
On Wed, 2 Mar 2005, Timothy Collett wrote: > On Mar 2, 2005, at 10:49 AM, wo...@tr... wrote: >> So if I create a directory in my aleph one data directory called >> "Disabled Scripts" Aleph One should use them? I don't think it's a bad >> thing to standardize this one thing. Is it really necessary that *every* >> file and directory begin with the name of your scenario? > > Well, I don't know the issues involved here. Does it already select the > appropriate script within the Scripts folder for the scenario? It applies all scripts within that folder. > >> On windows the icon has to be added to the executable resources, >> which I haven't done for the last two builds. Hopefully next time. On >> linux there is no concept of an icon associated with an executable. But >> if you include a PNG or XPM icon, most users or packagers should be able >> to put it in the right place. > > So does that mean that the *only* way to change the icon-set on Windows is at > compile time? (please forgive my utter ignorance in the matter...) No, like I said it's part of the executable resources. But altering itself at run time is not something Aleph One is capable of doing. >> We've got all of this right now, via MML, except the writing of the >> Info.plist, which can't possibly be a good idea while the application is >> running. It's probably better to do the install script idea, or just >> include a folder that has the icon so the user can copy and paste it :) > > That's probably true ;-) > But is there, in fact, a way within the game to select, from a menu of some > sort, the scenario you want to play (eg, "Marathon 2", "M1A1", "Rubicon") and > have it select all the appropriate files for that? Hmm, typically the MO for total conversions is to have their own directory, and drop in an Aleph One app. M1A1 for example. So to switch to that scenario, you just run the Aleph One in that directory (or set your data directory, depending on the platform). I prefer this approach myself. It's a little more complicated on Windows, sadly, because in addition to the app you need to copy about 8 dlls as well. It's ideal in Linux because you can tell Aleph One what directory to use, so you don't need to waste what is now a trivial amount of disk space storing multiple copies of the executable. > Basically, that's what I'm imagining: an extra popup menu in the Environment > prefs that has all available scenarios. When you select one, it sets each of > the popups below to the appropriate filename. That's an alternative to having separate directories for each scenario, I suppose. I don't know if it buys you any major advantages. Like I said, there is a considerable amount of discussion necessary to hash all this out. > Timothy Collett Gregory |