alephmodular-devel Mailing List for AlephModular (Page 21)
Status: Pre-Alpha
Brought to you by:
brefin
Menu
▾
▴
alephmodular-devel — AlephModular Developers Mailing List
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(61) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(193) |
Feb
(61) |
Mar
(55) |
Apr
(5) |
May
(3) |
Jun
(1) |
Jul
(3) |
Aug
(14) |
Sep
(19) |
Oct
(48) |
Nov
(6) |
Dec
(25) |
| 2004 |
Jan
(1) |
Feb
|
Mar
(2) |
Apr
(6) |
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(17) |
Jun
(20) |
Jul
(13) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Br'fin <br...@ma...> - 2002-12-31 00:56:11
|
On Monday, December 30, 2002, at 06:01 PM, Michael Adams wrote: >> On another topic, thought I'd mention the GUI issue >> (only just joined >> the list so I missed the discussion). I think that >> at some point in the >> future, it would be nice to have a separate graphics >> module with a layer >> of abstraction, so that we can write a custom GUI >> not limited to any one >> OS/graphics API (as is the case in A1 now), and no >> matter what system >> someone runs AM on, they'll have the same interface. >> >> I've experimented with my own custom GUI (admittedly >> it used only >> OpenGL, but it ran on windows & mac), and it's not >> the easiest of tasks, >> especially as I allowed widgets to contain widgets >> which contain widgets >> etc... A custom GUI is much more suitable for a >> game, but it'll only be >> worth it if it's powerful enough, as people seem to >> prefer A1's mac >> dialogs to the SDL dialogs... >> >> Nick. > > I have to agree with you on this. A foundation of > "safe" crossplatform function calls needs to be > established (e.g. anything in ANSI is safe, but not > POSIX), then *everything* is written to those function > calls. Otherwise, the #ifdef's will never be in sync. > We all know how much that happened with A1. We could > write this foundation our selves, but like you said > that can be a very major headache. Our best bet is to > find a foundation that already exists, with maybe a > few additions of our own for those things that people > just insist on being native (e.g. file dialogs). I'm not quite sure what you mean by #ifdef poisoning. A1 makes a harsh example just because so little time seems to have been spent on cross platform issues. (It's Mac code and someone hacked in SDL support to the side) And when someone had a good idea, like the File Objects... they still implemented it's interface differently for each platform! D'oh. Thus forcing much code that dealt with file objects to still do checks for which platform... > Personally, I don't care what foundation is used, just > so long as some foundation is established and used all > the time (no cheating). You could use MacApp for all > I care! At least it would eliminate #ifdef poisoning. > Just to get you started here are some foundations > that I know of: wxWindows <www.wxwindows.org>, FLTK > <www.fltk.org>, PLIB <plib.sourceforge.net> (PUI is > the GUI part), and of course SDL <www.libsdl.org>. wxWindows seems good on paper. Looking to have support for the platforms we care about and leaning towards a native look and feel. SDL I'm not sure of. (It was functional in A1/SDL OSX, but I can't say I was happy with it) though there are apparently projects within the SDL realm to put an even better gui forward within SDL. My current leaning is to aim for allowing any number of different GUIs/platforms with a set way of communicating with the underlying systems. OSX would simply be one implementation of a GUI. At that point, if someone can implement an alternate GUI that works well and looks good across platforms, then we can consider standardizing on that one for all platforms. I agree with your points. But I'm being conservative and I'm not currently ready to commit to the One GUI to rule them all and throw all the GUIs we have entirely. Certainly not until the One GUI goes from being a good idea to something that can prove itself. -Jeremy Parsons |
|
From: Nick R. <nr...@nt...> - 2002-12-31 00:39:14
|
> > >I have been running A1/SDL under Windows for quite >some time and SDL doesn't seem to be a problem. >Either that or the A1 team wrote the code so well that >I never noticed. Do you have a specific reason to >think that SDL is flaky on Windows or was that just a >"suspicion"? > Not much more than a suspicion :) I'll take your word for it then, I've never used SDL myself, I was just thinking of the problems that A1Win has had with running in fullscreen (of which I'm sure you're aware), and assuming that it was SDL at fault. If it is robust, then I have no problem with it, as long as only having Mac & SDL support doesn't lead to the current A1 situation. |
|
From: Michael A. <mdm...@ya...> - 2002-12-30 23:01:10
|
--- Nick Rolfe <nr...@nt...> wrote: > Br'fin wrote: > > >> > >> What about making the Carbon build OS 9 > compatible? I know of dozens > >> of apps that have "fat carbon" versions that run > equally well on OS > >> X and OS 9. > > > > > > Unfortunately it comes down to the same problem. > I, personally, only > > have the ability to compile Mach-O binaries for > MacOS X. Project > > Builder doesn't appear to be able to create > applications that can run > > as "fat carbon" applications. > > > > If we could find someone to maintain builds for > MacOS 9 then we could > > debate with them whether it uses all the classic > APIs or uses Carbon > > APIs in all the applicable spots. > > > > Right now it's simply out of my hands. :/ > > > > -Jeremy Parsons > > > How about just having OS X support for now, but when > it's modular enough > to have support for any OS, add OS 9 support (in the > same way you might > add Win32 support). Am I right in thinking that > you're aiming for a > setup where you have support for any number of > systems, not just Mac & > SDL? I have suspicions that SDL is somewhat flaky in > Windows, and using > the Windows API instead of SDL is a better option > (if there's someone to > maintain it), although I could easily be wrong. I have been running A1/SDL under Windows for quite some time and SDL doesn't seem to be a problem. Either that or the A1 team wrote the code so well that I never noticed. Do you have a specific reason to think that SDL is flaky on Windows or was that just a "suspicion"? > On another topic, thought I'd mention the GUI issue > (only just joined > the list so I missed the discussion). I think that > at some point in the > future, it would be nice to have a separate graphics > module with a layer > of abstraction, so that we can write a custom GUI > not limited to any one > OS/graphics API (as is the case in A1 now), and no > matter what system > someone runs AM on, they'll have the same interface. > > I've experimented with my own custom GUI (admittedly > it used only > OpenGL, but it ran on windows & mac), and it's not > the easiest of tasks, > especially as I allowed widgets to contain widgets > which contain widgets > etc... A custom GUI is much more suitable for a > game, but it'll only be > worth it if it's powerful enough, as people seem to > prefer A1's mac > dialogs to the SDL dialogs... > > Nick. I have to agree with you on this. A foundation of "safe" crossplatform function calls needs to be established (e.g. anything in ANSI is safe, but not POSIX), then *everything* is written to those function calls. Otherwise, the #ifdef's will never be in sync. We all know how much that happened with A1. We could write this foundation our selves, but like you said that can be a very major headache. Our best bet is to find a foundation that already exists, with maybe a few additions of our own for those things that people just insist on being native (e.g. file dialogs). Personally, I don't care what foundation is used, just so long as some foundation is established and used all the time (no cheating). You could use MacApp for all I care! At least it would eliminate #ifdef poisoning. Just to get you started here are some foundations that I know of: wxWindows <www.wxwindows.org>, FLTK <www.fltk.org>, PLIB <plib.sourceforge.net> (PUI is the GUI part), and of course SDL <www.libsdl.org>. I have to laugh at the irony of my situation. Usually, the non-Windows person is the one promoting crossplatform, but here I am a Win guy promoting crossplatform to Mac people. I want to help, but since I only have a WinXP machine (maybe a GNU/Hurd soon) I can't help until it's ported. Porting would be a big task probobly as much as a full 0.X release (e.g. 0.4 -> 0.5). If it is done adhoc then I will require continual maininance, but if it is ported to a single foundation that we all agree to use exclusivly, then the port only needs to be done once and only one codebase needs to be maintained. Michael D. Adams mdm...@ya... __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Nick R. <nr...@nt...> - 2002-12-30 19:16:48
|
Br'fin wrote: >> >> What about making the Carbon build OS 9 compatible? I know of dozens >> of apps that have "fat carbon" versions that run equally well on OS >> X and OS 9. > > > Unfortunately it comes down to the same problem. I, personally, only > have the ability to compile Mach-O binaries for MacOS X. Project > Builder doesn't appear to be able to create applications that can run > as "fat carbon" applications. > > If we could find someone to maintain builds for MacOS 9 then we could > debate with them whether it uses all the classic APIs or uses Carbon > APIs in all the applicable spots. > > Right now it's simply out of my hands. :/ > > -Jeremy Parsons How about just having OS X support for now, but when it's modular enough to have support for any OS, add OS 9 support (in the same way you might add Win32 support). Am I right in thinking that you're aiming for a setup where you have support for any number of systems, not just Mac & SDL? I have suspicions that SDL is somewhat flaky in Windows, and using the Windows API instead of SDL is a better option (if there's someone to maintain it), although I could easily be wrong. On another topic, thought I'd mention the GUI issue (only just joined the list so I missed the discussion). I think that at some point in the future, it would be nice to have a separate graphics module with a layer of abstraction, so that we can write a custom GUI not limited to any one OS/graphics API (as is the case in A1 now), and no matter what system someone runs AM on, they'll have the same interface. I've experimented with my own custom GUI (admittedly it used only OpenGL, but it ran on windows & mac), and it's not the easiest of tasks, especially as I allowed widgets to contain widgets which contain widgets etc... A custom GUI is much more suitable for a game, but it'll only be worth it if it's powerful enough, as people seem to prefer A1's mac dialogs to the SDL dialogs... Nick. |
|
From: Br'fin <br...@ma...> - 2002-12-30 18:09:14
|
On Sunday, December 29, 2002, at 09:40 PM, Chris Pickel wrote: > On Sunday, December 29, 2002, at 07:39 PM, Br'fin wrote: >> What sort of independent pieces would people like to see? > > The first target, in my opinion, should be the definitions. I've got a=20= > list of them somewhere... got it. Bottom of the message, it's fairly=20= > long. The most important ones to modularize are the ones in: > - device.cpp > - fades.cpp > - game_window.cpp > - item_definitions.cpp > - media_definitions.cpp > - scenery_definitions.cpp > - sound_definitions.cpp > > Interestingly enough, the number comes out to 7. But more importantly,=20= > modularizing these would mimic the functionality of MML in A1. These=20= > are smaller things, and should be fairly easy to split off, while=20 > other, hairier things (rendering, networking) might take some more=20 > time and effort for less of an immediate return. A very good list. I'm trying to think of what we should call this group=20= of ... extended physics. Scenario? Personality? (Do you play a Map=20 Scenario ala E:MR within AM with the Personality of M2?) I agree that=20 they should have their own module. Something that might interface a bit=20= more strongly with the other modules than any other module is allowed=20 to. An extended example would include not just monster definitions, but=20 also provide the monster control functions. (Hah! *MY* Scenario=20 implements a segmented worm as a monster!) I'd really like a decent name for this! > Another thing that should be modularized quickly, and hopefully almost=20= > as easily, would be the network game types. I'm not entirely sure how=20= > to go about it myself =96 we'd need to split apart the switch-cases = that=20 > are in most of the network_games.cpp functions in such a way that it=20= > handled a variable number of game types. I'm not sure about modularized quickly. Mainly because we don't have=20 working netplay yet. I don't want to break the netcode before someone=20 is actually in a position to neatly fix it back up :) It's for this reason that I've not done any of the cleanup steps on any=20= of the network* files. -Jeremy Parsons |
|
From: Br'fin <br...@ma...> - 2002-12-30 16:19:15
|
On Monday, December 30, 2002, at 10:12 AM, Etienne Samson wrote: >> >> Welcome aboard! :) >> >> The SourceForge project site has information on using command line >> anonymous CVS >> http://sourceforge.net/cvs/?group_id=69003 >> >> The module name that should be filled in is alephModular (note the >> uppercase M) >> >> Currently the only build environment set up within CVS is Project >> Builder for MacOS X. >> >> -Jeremy Parsons >> > > Hmm, how should I use PB to get the source ? > ( I know my question is dumb, but I just gto the opportunity to switch > really on OSX, and I'm dissapointed on how should I continue > developpement. > > tiennou ;-) I'm not about to call it a dumb question. I haven't put up anything close to a decent document on the matter. I can't tell you to RTFM if it hasn't been written. :) Project Builder is only used to compile the source. Under MacOS X I use the command line CVS tools. You may be able to use other CVS tools, but I don't know how to set them up. To setup the AlephModular source code: * Create a directory in the finder to hold the code. * Open Terminal * Navigate within Terminal to the directory you just created I find this easiest to do by typing 'cd ' and then dropping the folder on the Terminal window. * Login to the anonymous CVS server Type the following in the terminal and press enter cvs -d:pserver:ano...@cv...:/cvsroot/ alephmodular login * Checkout the source from CVS Type the following in the terminal and press enter cvs -z3 -d:pserver:ano...@cv...:/cvsroot/ alephmodular co alephModular At this point AM will get checked out from CVS. If you use the finder to navigate within the checked out files to alephModular/build/macosx/AlephModular.pbproj, you can open the project within Project Builder and compile it. You will need to copy the Marathon2 data files to the directory alephModular/build/macosx/build/ in order to run AM within PB's debugger. Once you have checked out the AM files from cvs then you would update those files from the Terminal. cd to the alephModular directory, and type cvs update -AdP http://www.cvshome.org/ is the homepage for CVS and the cvs command line tools are not only installed by default, but ProjectBuilder can integrate with them. Thus allowing you to compare or update files from within ProjectBuilder to a certain degree. I don't know what other resources might be good, but I suspect they're out there. Hmm -Jeremy Parsons |
|
From: Etienne S. <po...@li...> - 2002-12-30 15:12:39
|
=09 Le lundi, 30 d=E9c 2002, =E0 13:45 Europe/Paris, Br'fin a =E9crit : > > On Monday, December 30, 2002, at 07:04 AM, tiennou wrote: > >> Hi everybody ! >> >> I join your list because I found the Aleph Modular project is a good=20= >> thing. I won't tell much things for now, I'll just lurk around, and=20= >> see you do. I just need to know how could I get access to the source. >> >> Thanks, and good luck ! >> >> tiennou ;-) > > Welcome aboard! :) > > The SourceForge project site has information on using command line=20 > anonymous CVS > http://sourceforge.net/cvs/?group_id=3D69003 > > The module name that should be filled in is alephModular (note the=20 > uppercase M) > > Currently the only build environment set up within CVS is Project=20 > Builder for MacOS X. > > -Jeremy Parsons > Hmm, how should I use PB to get the source ? ( I know my question is dumb, but I just gto the opportunity to switch=20= really on OSX, and I'm dissapointed on how should I continue=20 developpement. tiennou ;-)= |
|
From: Br'fin <br...@ma...> - 2002-12-30 12:45:08
|
On Monday, December 30, 2002, at 07:04 AM, tiennou wrote: > Hi everybody ! > > I join your list because I found the Aleph Modular project is a good > thing. I won't tell much things for now, I'll just lurk around, and > see you do. I just need to know how could I get access to the source. > > Thanks, and good luck ! > > tiennou ;-) Welcome aboard! :) The SourceForge project site has information on using command line anonymous CVS http://sourceforge.net/cvs/?group_id=69003 The module name that should be filled in is alephModular (note the uppercase M) Currently the only build environment set up within CVS is Project Builder for MacOS X. -Jeremy Parsons --------------------- +------------------------------------------------------ Br'fin | TIMSter, MU*er, Web Programmer, ... Insane? The Denim Warrior | You be the judge... br...@ma... | --------------------- +------------------------------------------------------ |
|
From: tiennou <po...@li...> - 2002-12-30 12:03:31
|
Hi everybody ! I join your list because I found the Aleph Modular project is a good thing. I won't tell much things for now, I'll just lurk around, and see you do. I just need to know how could I get access to the source. Thanks, and good luck ! tiennou ;-) |
|
From: Chris B. <zzk...@uq...> - 2002-12-30 05:30:45
|
I'm not sure that i'd totally agree with that.. there are a number of programming techniques which are simply not available on Mac OS 9. The most obvious example is preemptive threading. If OS 9 support is deliberately dropped, there is no reason to avoid such techniques. If code is written (eg. networking code) which requires preemptive threading, it may take a complete rewrite to make it work with OS 9. Of course, it's possible that AM move forward with the "don't do anything that we know is going to break OS 9 support" mentality - in which case we wouldn't be supporting OS 9, but it shouldn't take too much work to fix the old OS 9 code. My personal view is that OS 9 isn't worth supporting; if we can't find anyone to maintain an OS 9 version then i'd prefer to see it dropped permanently. The opinions of those who still use OS 9 may differ ;-) chris On Monday, Dec 30, 2002, at 16:15 Australia/Brisbane, Mark Levin wrote: >> Unfortunately it comes down to the same problem. I, personally, only >> have the ability to compile Mach-O binaries for MacOS X. Project >> Builder doesn't appear to be able to create applications that can run >> as "fat carbon" applications. > > And besides, if the promise of modularity is fulfilled, it should be > as easy or easier to add OS 9 support back into AM in the future than > try to preserve it through all possible transformations at all times. > > --Mark > > "There is nothing so absurd that some philospher has not said it." > |
|
From: Mark L. <hav...@ma...> - 2002-12-30 05:18:50
|
> Unfortunately it comes down to the same problem. I, personally, only > have the ability to compile Mach-O binaries for MacOS X. Project > Builder doesn't appear to be able to create applications that can run > as "fat carbon" applications. And besides, if the promise of modularity is fulfilled, it should be as easy or easier to add OS 9 support back into AM in the future than try to preserve it through all possible transformations at all times. --Mark "There is nothing so absurd that some philospher has not said it." |
|
From: Br'fin <br...@ma...> - 2002-12-30 05:06:17
|
On Sunday, December 29, 2002, at 09:40 PM, Chris Pickel wrote: > [On your second message] >> ENUMS > Well, in a lot of instances, we would want to allow modules to define > values past those that were originally in the enum. A typedef would > prevent anyone from adding _media_milk on to the media types enum, so > it we should probably keep things as they are. > > On your other points, I agree. Typecasts are bad, new is good, > obsolete is bad. Well, those same ENUMS also define MAXIMUM_<enum-type> for that ENUM, so it would make additions to the enums hard to begin with. I certainly agree with your interest in adding to the enums. Poking through things, there is a definite need for a secondary Physics type file. There's quite a number of Marathon 2 definitions in the source (Media and effect definitions and sound effects) which need to be on some kind of a switch (We're loading an M2 map, swap out the Minf definitions and use the M2 ones) -Jeremy Parsons |
|
From: Br'fin <br...@ma...> - 2002-12-30 04:46:41
|
On Sunday, December 29, 2002, at 10:04 PM, Aaron Davies wrote: > On Sunday, December 29, 2002, at 07:17 PM, Br'fin wrote: > >> OBSOLETE CODE REMOVAL >> >> In the code we have, we currently have parts of coded surrounded by >> #if 0, #ifdef NEW_AND_BROKEN, #ifdef OBSOLETE, #ifdef CYBERMAXX as >> well as code for Classic Mac APIS (Non-carbon) and Valkyrie video >> accelerators. >> >> Chris suggested dumping all pre-carbon support. I myself am >> ambivalent, but I can't support it. I don't have the compilers for >> making a PPC MacOS 9 build, nevermind even attempting any kind of 68k >> build. >> >> If you want or need MacOS 9 support, don't just ask for it, try to >> find someone to get this project building under MacOS 9 and then >> ask this project to continue to support it. Now is the best time as I >> haven't tried to remove anything yet. So everything should still be >> available. > > What about making the Carbon build OS 9 compatible? I know of dozens > of apps that have "fat carbon" versions that run equally well on OS X > and OS 9. Unfortunately it comes down to the same problem. I, personally, only have the ability to compile Mach-O binaries for MacOS X. Project Builder doesn't appear to be able to create applications that can run as "fat carbon" applications. If we could find someone to maintain builds for MacOS 9 then we could debate with them whether it uses all the classic APIs or uses Carbon APIs in all the applicable spots. Right now it's simply out of my hands. :/ -Jeremy Parsons --------------------- +------------------------------------------------------ Br'fin | TIMSter, MU*er, Web Programmer, ... Insane? The Denim Warrior | You be the judge... br...@ma... | --------------------- +------------------------------------------------------ |
|
From: Chris P. <sf...@ma...> - 2002-12-30 02:36:25
|
On Sunday, December 29, 2002, at 07:39 PM, Br'fin wrote: > What sort of independent pieces would people like to see? The first target, in my opinion, should be the definitions. I've got a=20= list of them somewhere... got it. Bottom of the message, it's fairly=20 long. The most important ones to modularize are the ones in: - device.cpp - fades.cpp - game_window.cpp - item_definitions.cpp - media_definitions.cpp - scenery_definitions.cpp - sound_definitions.cpp Interestingly enough, the number comes out to 7. But more importantly,=20= modularizing these would mimic the functionality of MML in A1. These=20 are smaller things, and should be fairly easy to split off, while=20 other, hairier things (rendering, networking) might take some more time=20= and effort for less of an immediate return. Another thing that should be modularized quickly, and hopefully almost=20= as easily, would be the network game types. I'm not entirely sure how=20 to go about it myself =96 we'd need to split apart the switch-cases that=20= are in most of the network_games.cpp functions in such a way that it=20 handled a variable number of game types. (game_data->parameters and player_data->netgame_parameters should be=20 set to a higher size too) [On your second message] > ENUMS Well, in a lot of instances, we would want to allow modules to define=20 values past those that were originally in the enum. A typedef would=20 prevent anyone from adding _media_milk on to the media types enum, so=20 it we should probably keep things as they are. On your other points, I agree. Typecasts are bad, new is good, obsolete=20= is bad. -Sfiera ---------- device.cpp =96 Control panels fades.cpp =96 Fade effects game_window.cpp =96 Interface weapon definitions lightsource.cpp =96 Light definitions. Probably overridden by Maps. player.cpp =96 Player shape definitions, Damage response definitions vbl.cpp =96 Special flag definitions? For replays, I think effect_definitions.h =96 Effect definitions. Overridden by Physics. extensions.h =96 Definition defintions...? item_definitions.h =96 Item definitions key_definitions.h =96 Standard key definitions (x3) media_definitions.h =96 Media type definitions monster_definitions.h =96 Monster definitions. Overridden by Physics. physics_models.h =96 Running/walking definitions. Overridden by Physics. platform_definitions.h =96 Platform type definitions projectile_definitions.h =96 Projectile definitions. Overridden by=20 Physics. scenery_definitions.h =96 Scenery definitions shape_definitions.h =96 Something important? song_definitions.h =96 Outdated M1 music stuff? sound_definitions.h =96 Sound behavior definitions, Ambient sound=20 definitions, Random sound definitions, Sound definitions weapon_definitions.h =96 Shell casing definitions, Weapon Definitions.=20= WDs overridden by physics= |
|
From: Br'fin <br...@ma...> - 2002-12-30 01:17:13
|
Ok, in CVS I've managed to get nearly all shorts and longs sorted over to int16 and int32s so that we know they all have an explicit length. 0.3 is the target for all the simple but important changes to the codebase. While Chris has suggested classifying things, I don't know if we want to do a first pass now or within the first stages of 0.4 Things still on my plate: LIMITING OF WARNINGS I've loosened up a little from initial goals as some warnings (Like around function pointers in preferences.cpp) seem a little too ingrained to eradicate. But other areas should be possible. For instance, signed versus unsigned variable comparisons and warnings of junk at the end of pragma unused. Dealing with all the existing warnings will make any new warnings that we cause so much more apparent. Other things I would like some feed back on: ENUMS Certain Enums, such as the list of weapons in weapons.h strike me as candidates for being typedef'd types. Creating typedefs for enums like this one could enlist the compiler in making sure that reasonable values were past for these elements. On the flip side, I don't know what trouble this would cause if we wanted to have something that was one of these values or NONE (-1) TYPECASTS In general I would like to limit typecasts. Mainly because I was bitten by SetPort((GrafPtr)WindowPtr) during the initial carbonization. If we have to typecast, I'd prefer doing it C++ style casting mechanisms for a combination of clarity and letting the compiler catch more issues. I'm going by advice in http://www.cs.rpi.edu/~wiseb/xrds/ovp3-1.html For most cases we would be using static_cast. I'm not necessarily married to the idea, but I would like to enforce it for code changes in such areas. NEW INSTEAD OF MALLOC As part of limiting typecasts, I would prefer to use new[] over malloc to allow the compiler to give us pre-typed chunks of data. No typecasting needed. In the future, as we turn to classes instead of structures, we would also be able to have our constructors called. OBSOLETE CODE REMOVAL In the code we have, we currently have parts of coded surrounded by #if 0, #ifdef NEW_AND_BROKEN, #ifdef OBSOLETE, #ifdef CYBERMAXX as well as code for Classic Mac APIS (Non-carbon) and Valkyrie video accelerators. Chris suggested dumping all pre-carbon support. I myself am ambivalent, but I can't support it. I don't have the compilers for making a PPC MacOS 9 build, nevermind even attempting any kind of 68k build. If you want or need MacOS 9 support, don't just ask for it, try to find someone to get this project building under MacOS 9 and then ask this project to continue to support it. Now is the best time as I haven't tried to remove anything yet. So everything should still be available. Obsolete code removal would also remove all of the mpw build files and the 68k assembler files. OTHER IDEAS Is there anything I haven't mentioned that fits the criteria for 0.3? Simple yet important changes which are best served by handling them now? -Jeremy Parsons --------------------- +------------------------------------------------------ Br'fin | TIMSter, MU*er, Web Programmer, ... Insane? The Denim Warrior | You be the judge... br...@ma... | --------------------- +------------------------------------------------------ |
|
From: Br'fin <br...@ma...> - 2002-12-30 00:39:17
|
AlephModular is supposed to be, well, modular. I think it would be great if we could have a set of base definitions. (all the components of a map for instance) and then a bunch of high level modules that only depend upon the base definitions without depending on each other. For instance, game physics doesn't need rendering or a GUI. And rendering itself only cares about the current game state. (It doesn't need a GUI so much as a buffer to draw into) These high level modules are the ones that you be should be able to break off and put into another project. You should be able to compile one of these modules into a library that only depends on the base definitions. What sort of independent pieces would people like to see? -Jeremy Parsons --------------------- +------------------------------------------------------ Br'fin | TIMSter, MU*er, Web Programmer, ... Insane? The Denim Warrior | You be the judge... br...@ma... | --------------------- +------------------------------------------------------ |
|
From: Steve K. <blu...@ho...> - 2002-12-29 16:35:06
|
Hello everyone. I've just joined this list. I've always loved Marathon...this project seems to have merit. As far as my computing backgrounds go, I know basic C/C++, among some other, older languages...but the knowlege is self-taught. I don't know much about programming for OSX at all, but am trying to learn...most of my knowlege pertains to the non-graphical DOS-like environment (darn books...lol)...so I'm going to try to help as much as possible, however little that may result in in the end. As for some other issues that have popped up in the list recently, I'd like to put in my 2 cents... As for the 3D/2.5D issue... I look at it in this respect: When trying to make my own new scenario, my artisitic friend draws me up a new monster....which takes her, oh, about 2 days (if she works at it...lol). It takes me 10 minutes max to scan it in, and not too long to actually get it into the editors... Then, I think of how much longer it takes to make a 3D model. *shiver* Look at Diablo II..yes, it was released a while ago, but it is still played to this day... 2.5D simplifies things very much...I'd like to see a 3D version of Marathon as much as the next guy...but why not just let Bungie modify the Halo (I love how it's set in the Marathon universe...but I'd still like to see the link between the two...more than the Marathon symbols everywhere) engine, and be done with it...or someone else liscensing the Quake or Unreal engines and doing 3D with those ones... As for networking... I dont know the best way to do it. But at least, I would like to be able to set up a game against someone over the internet. Even if it is a one on one, TCP/IP game, whatever. Remember, not all of us are blessed wtih LANs... _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 |
|
From: Br'fin <br...@ma...> - 2002-12-28 21:23:28
|
After all you guys discussion about networking, I was amused to stumble across this note in physics.cpp. Even more amusing, didn't they implement something more like the first method then the second method in the end? :) -Jeremy Parsons > Sunday, May 22, 1994 11:14:55 AM > there are two viable methods of running a synchronized network game. > thefirst is doom's, where each player shares with each other player > only his control information for that tick (this imposes a maximum > frame rate, as the state-of-the-world will be advanced at the same > time on all machines). the second is the continuous lag-tolerant > model where each player shares absolute information with each other > player as often as possible and local machines do their best at > guessing what everyone else in the game is doing until they get better > information. whichever choice is made will change the physics > drastically. we're going to take the latter approach, and cache the > KeyMap at interrupt time to be batch-processed later at frame time. |
|
From: Chris P. <sf...@ma...> - 2002-12-27 03:13:18
|
On Thursday, December 26, 2002, at 07:05 PM, Br'fin wrote:
> I'm certainly curious to know how you are doing with GetMouse and if =20=
> it's giving you any other kind of problems.
Well, it moves a little slowly, but the entire game moves a little =
=20
slowly, and that's OK ;) I'll record my old function (just in case=99), =20=
and see about a CoreGraphics-based version.
Hmm, that version doesn't seem to handle the mouse as well; I see =20=
what you mean about GetMouse acting slowly. My code for Carbon =20
mouse_idle() is at the end of this email - to use it:
1- "#if !TARGET_API_MAC_CARBON" out the original mouse_idle() =20
function
2- #if out the set_mouse_position() prototype and function.
3- Make get_mouse_position() call GetMouse() #if we're in Carbon
Try it and see if the results you get feel any different. It =20
certainly seemed smoother to me, even if it wasn't really a good =20
solution. Perhaps the problem is with CGWarp...() instead?
Oh, and "way back when," I used the keyboard too. Except that "way =
=20
back when," Kindergarten was a challenge, and that's not a memory I =20
like to remember.
-Sfiera
----------
#if TARGET_API_MAC_CARBON
void mouse_idle(
short type)
{
Point where;
static Point last_mouse_pos;
static bool inited =3D false;
static long last_tick_count;
long tick_count=3D TickCount();
long ticks_elapsed=3D tick_count-last_tick_count;
get_mouse_location(&where);
if (!inited)
{
last_mouse_pos =3D where;
inited =3D true;
}
if (ticks_elapsed)
{
/* calculate axis deltas */
fixed vx=3D =20
INTEGER_TO_FIXED(where.h-last_mouse_pos.h)/=20
(ticks_elapsed*MAXIMUM_MOUSE_VELOCITY);
fixed vy=3D - =20
INTEGER_TO_FIXED(where.v-last_mouse_pos.v)/=20
(ticks_elapsed*MAXIMUM_MOUSE_VELOCITY);
/* pin and do nonlinearity */
vx=3D PIN(vx, -FIXED_ONE/2, FIXED_ONE/2), vx>>=3D 1, =
vx*=3D (vx<0) ? -vx : =20
vx, vx>>=3D 14;
vy=3D PIN(vy, -FIXED_ONE/2, FIXED_ONE/2), vy>>=3D 1, =
vy*=3D (vy<0) ? -vy : =20
vy, vy>>=3D 14;
// vx=3D PIN(vx, -FIXED_ONE/2, =
FIXED_ONE/2);
// vy=3D PIN(vy, -FIXED_ONE/2, =
FIXED_ONE/2);
snapshot_delta_yaw=3D vx;
switch (type)
{
case _mouse_yaw_pitch:
snapshot_delta_pitch=3D vy, =
snapshot_delta_velocity=3D 0;
break;
case _mouse_yaw_velocity:
snapshot_delta_velocity=3D vy, =
snapshot_delta_pitch=3D 0;
break;
default:
halt();
}
snapshot_button_state=3D Button();
last_tick_count=3D tick_count;
last_mouse_pos=3D where;
// dprintf("%08x %08x %08x;g;", =
snapshot_delta_yaw, =20
snapshot_delta_pitch, snapshot_delta_velocity);
}
return;
}
#endif=
|
|
From: Br'fin <br...@ma...> - 2002-12-27 00:04:33
|
On Thursday, December 26, 2002, at 05:23 PM, Chris Pickel wrote: > I'm new too, so I suppose now is as good a time as ever to say hello - > and voice a few of my opinions too, of course. (Note that a few of my > opinions could be incorrect) Welcome aboard as well. :) >> Modular vs. Marathon: >> However I don't think the Marathon map >> file format should be more than another module that >> can be poped in and out. > Not something that had ever occurred to me, but it sounds like a > good idea. However, we'd be limited in our choices of alternate map > formats; a 3D map will require a 3D engine, and if that has to be > coded too, you might as well just use the original game. There is the possibility that in the future AM will get more efficient or more featureful map internals. At that point it becomes more important to make sure map loaders for different formats continue to import their maps with all appropriate flags set. > Just a note: I managed to stick some code into mouse.cpp that > allows you to use the mouse - sort of. Carbon has a "GetMouse(point > *mouseLoc)" function that can grab the mouse's position for you, but > as far as I can tell, it doesn't have a corresponding SetMouse > function. > I rewrote the mouse_idle function to work with this, but you'll > stop turning when your mouse hits the side of the screen. It's not a > permanent fix, but at least it's no longer a pain to walk around. Go figure, I always used the keyboard, way back when ;) Right now I'm not doing much with patching the existing GUI. It's definitely not perfect, but it runs well enough on MacOSX to check that the game is continuing to work. I had decided to save any polishing until after GUI code had been modularized. On the actual details. I managed to get the mouse working under AlephOne. But I had some problems with GetMouse, like it never seemed to update as frequently as you think it might or should. Also, there is a way to jump the mouse to a location, but it's hidden down in the CoreGraphics libraries. CGWarpMouseCursorPosition(CGPointMake(where.h, where.v)); AlephOne currently tries to use a more 'recommended' way of getting mouse movement events. It has some CarbonEvent handlers that catch and use the values of MouseMoved and MouseDragged events, so it doesn't need to warp the mouse at all. I say tries to use, because I had trouble dealing with application events like these in the input thread while rendering had control of the main thread. I'm certainly curious to know how you are doing with GetMouse and if it's giving you any other kind of problems. -Jeremy Parsons |
|
From: Br'fin <br...@ma...> - 2002-12-26 23:43:40
|
On Thursday, December 26, 2002, at 04:12 PM, Michael Adams wrote: > Hello, I've joined the AlephModular list and thought > I'd introduce myself. A pleasure to have you aboard. :) > Now I would like to mention a few of my concerns/goals > for AM. These may be a little bit contraversial and > may offend some (I have trouble with that). > > Crossplatform: > Something that you may hear me whine about often is > being cross platform. I think AM is already moving in > this direction, but I want to reenforce and encourage > it. With A1 it happened to often that sometime would > get implemented on one platform but not another. > Please try to orginize the code so we only have one > code base. A good example is the preference dialogs. > A new crosshair chaging feature was added, but only on > the Mac version. It was never added to the SDL > version. The preference file actually has hackable to > change it, but because of the way the preferences > dialog was split between platforms it wasn't in the > GUI. Please avoid this. Using a good crossplatform > foundation library (like SDL or whatever) and having > everyone write for that foundation would prevent the > need to rewrite code for every new platform that comes > along. If you have to write some utility functions > like makeButtion that are #ifdef'ed for multiple > platforms that's alright, but please don't do #ifdef > platform tricks with stuff like a showPeferencesDialog > function. Based on the mailing list archives I think > you are leaning towards this, but I think it should be > made clear. I admit, I'm currently mixed on the issues of how platform specific UI is handled. On the one hand, I hear what you're saying. And it would be great, especially for things derived from AlephModular, if someone just made some preferences changes on their app. Made sure it worked on their platform of choice, and knew that if someone compiled it for another platform, it would be just fine. On the other hand, I'm worrying about some issues of polish. For instance, AlephOne-SDL runs on MacOSX, but never felt like a Macintosh Application. I don't know how it felt on other platforms compared with what you expect of your programs and games. For the current term, I would have to say platform specific GUIs are a go. (Though all platform GUIs would speak to the same underlying preferences objects) It keeps things moving and if someone can get enough polish into a cross-platform GUI, then we can adopt that as the default in the future. > Modular vs. Marathon: > I must agree and dissagree with some things that have > been expressed earlyer. In order for AM to be > sucessful it will have to be able to read and run the > old Marathon maps. What good is a game with no maps > it can run. However I don't think the Marathon map > file format should be more than another module that > can be poped in and out. Suppose someone writes a > Doom map file reader. Then the Marathon and Doom > modules would be equals as far as how the code works, > but the Marathon module is still takes presidence in > cronology and maintinance. I do agree with this sentiment. And we may need to devise a solution to this sooner than you might think. As I've been tweaking headers I came to realize that Marathon has a few more game definitions (Like the physics stuff) but not all of it is actually loaded from the physics file. For instance, some sound definitions. -Jeremy Parsons |
|
From: Br'fin <br...@ma...> - 2002-12-26 23:16:26
|
In addition to his email, I had a nice little chat with Chris via ichat last night to help flesh things out my response further. WHAT IS MY VISION OF THIS PROJECT? My initial vision is 'it runs marathon great', 'it has the networking that people have been craving since the source code was first released', 'its been decomposed into nice clean building blocks to work with' right I happen to agree with Mark's post. Keep the application working with Marathon's files through all stages of development (Currently Marathon 2) I didn't release 0.2 until I had the code base just plain running Marathon 2 albeit unpolishedly in the GUI. (Mark, Sourceforge does have an archive of the mailing list as well if you want to see what led to Chris's post :) ) My goals for 1.0 are fairly feature light to the end user. But if we can release a nice solid app in running and network play, it's going to get decent coverage. WHO ARE MY TARGET USERS? Myself, Marathon Die-hards, and developers. The core release package may be able to play more than Marathon files, but it has to handle Marathon. For developers, I want to throw the code wide open. Give them nice clean code. Give them seperated parts so that 'rendering' can be compiled seperately from 'physics model' and seperately from 'UI'. Mods that make use of AlephModular are nice. Projects which use AlephModular as a base to springboard to something beyond Marathon are better. WHY 2.5D OVER 3D? Oddly enough, Marathon is a 2.5D engine. I don't think this is a shameful thing, or a bad thing. I also think it still has a lot of potential in and of itself. I feel that the 2.5D is a strength to be enhanced. It still has room for enhancement, it still has room to be exploited. In the context of Marathon, going 3D seems a waste of time. It's a lot of work to reach a stage which other projects all already ahead of in some form or another. There is Quake, there is Crystal Space. There are other 3D engines out there. What is so compelling about 3D or Marathon that people seem compelled to force Marathon's engine to that level? IN SUMMARY: Requirements before a 1.0 release Networking Polished Code state Polished UI state Runs at least Marathon 2 and Marathon infinity Niceties before a 1.0 release OpenGL Cross-platform support -Jeremy Parsons |
|
From: Chris P. <sf...@ma...> - 2002-12-26 22:19:12
|
I'm new too, so I suppose now is as good a time as ever to say hello -
and voice a few of my opinions too, of course. (Note that a few of my
opinions could be incorrect)
On Thursday, December 26, 2002, at 04:12 PM, Michael Adams wrote:
> Using a good cross-platform
> foundation library (like SDL or whatever) and having
> everyone write for that foundation would prevent the
> need to rewrite code for every new platform that comes
> along.
Personally, I think AlephModular's core shouldn't be founded upon
*any* platform/library. If a particular feature can't be made
platform-independent, it should probably be modular.
The modules are another issue. The set of Carbon modules could
differ from the SDL modules, forcing them to be recoded each time. Then
again, I don't think this would become as much of an issue with AM - a
particular feature would never be implemented into platform-specific
code first. It would be implemented into the core, then made usable by
the modules on each platform.
> 2.5D vs. 3D:
> I feel that while AM should remain a true 2.5D map
> format, moving to a 3D rendering would be no great
> loss.
Yes - there's no reason we should have to support two map formats
(Portal/True 3D). OpenGL rendering would be a nice thing for the
future, but before anyone starts work on that, AM should be
modularized, so that we can just swap out software rendering for OpenGL.
B&B and slope code could possibly be closer, since (if functional
and stable) they would be better suited for AM's core.
> Modular vs. Marathon:
> However I don't think the Marathon map
> file format should be more than another module that
> can be poped in and out.
Not something that had ever occurred to me, but it sounds like a
good idea. However, we'd be limited in our choices of alternate map
formats; a 3D map will require a 3D engine, and if that has to be coded
too, you might as well just use the original game.
> Have a merry Christmas,
Happy boxing day.
-----
Just a note: I managed to stick some code into mouse.cpp that
allows you to use the mouse - sort of. Carbon has a "GetMouse(point
*mouseLoc)" function that can grab the mouse's position for you, but as
far as I can tell, it doesn't have a corresponding SetMouse function.
I rewrote the mouse_idle function to work with this, but you'll
stop turning when your mouse hits the side of the screen. It's not a
permanent fix, but at least it's no longer a pain to walk around.
-Sfiera
|
|
From: Michael A. <mdm...@ya...> - 2002-12-26 21:13:04
|
Hello, I've joined the AlephModular list and thought I'd introduce myself. I'm running on a WinXP machine with MSVC7/.Net on it. So most of my stuff will come from that perspective. I have been working with A1 to do the windows builds and would be glad to do so here if that is needed. I enjoy debugging and hope to contribute in that area also. I will probably install GNU/Hurd in the near future so I may beable to do some work over there. I have a buisy schedule with my collidge studies. So I am unlikely to be able to contribute large new features, but I am eager to assist in anyway I can even if that only be tweeking existing features (either as bug fix or porting) or fixing stuff like '#ifndef's around header files. Now I would like to mention a few of my concerns/goals for AM. These may be a little bit contraversial and may offend some (I have trouble with that). Crossplatform: Something that you may hear me whine about often is being cross platform. I think AM is already moving in this direction, but I want to reenforce and encourage it. With A1 it happened to often that sometime would get implemented on one platform but not another. Please try to orginize the code so we only have one code base. A good example is the preference dialogs. A new crosshair chaging feature was added, but only on the Mac version. It was never added to the SDL version. The preference file actually has hackable to change it, but because of the way the preferences dialog was split between platforms it wasn't in the GUI. Please avoid this. Using a good crossplatform foundation library (like SDL or whatever) and having everyone write for that foundation would prevent the need to rewrite code for every new platform that comes along. If you have to write some utility functions like makeButtion that are #ifdef'ed for multiple platforms that's alright, but please don't do #ifdef platform tricks with stuff like a showPeferencesDialog function. Based on the mailing list archives I think you are leaning towards this, but I think it should be made clear. 2.5D vs. 3D: I feel that while AM should remain a true 2.5D map format, moving to a 3D rendering would be no great loss. That is maybe the algorithms to render are 3D (e.g. hand it off to OpenGL), but the game play and map editing are still the ease of 2.5D. As it is now making a map is *very* easy. Just look at the number of scenarios, many of which are very high quality, for Marathon that have been built by ordinary people. I don't see this for other 3D engines. I don't mean to exclude by this 3D models, sloped floors or 3D objects, but the easy editing that Marathon has should be preserved. By 3D objects (anyone have a better name?) I mean something that you can stand on instead of falling through. You could emulate B&B using something like this. Modular vs. Marathon: I must agree and dissagree with some things that have been expressed earlyer. In order for AM to be sucessful it will have to be able to read and run the old Marathon maps. What good is a game with no maps it can run. However I don't think the Marathon map file format should be more than another module that can be poped in and out. Suppose someone writes a Doom map file reader. Then the Marathon and Doom modules would be equals as far as how the code works, but the Marathon module is still takes presidence in cronology and maintinance. Well, I think I've kicked over enough hornet's nets for now. I'm busy reinstalling Windows onto a new hard drive, but once everything is up maybe I can assist in porting. Have a merry Christmas, Michael D. Adams mdm...@ya... P.S. Please forgive my spelling. I'm to busy to spellcheck right now. __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Mark L. <hav...@ma...> - 2002-12-26 07:05:09
|
> Again this is just my thoughts, and jeremy gets to make the decisions > on this, but i think it makes more sense (for now) to have it working > well for the developers than it does to try and make it polished for > the end users. I guess it depends if the project #1 priority is (1) > making marathon work as-is, quickly, or (2) developing the code-base > and making it modular. Unfortunately I missed the beginning of this argument, but I vote for priority #1. The ability to drop the app into an existing Marathon scenario and have it just plain work at all stages of development would be a very Good Thing (it would certainly make testing easier). Perhaps the executable could include a default config file that works with the MI scenario. Once the code has been transformed to something worthy of the name "modular", it should be much easier to go back and add new features for the users (from the perspective of us, the coders, this refers to both players and scenario authors). --Mark "If you're going to break the eggs, make the damn omlette." |
