alephmodular-devel Mailing List for AlephModular (Page 23)
Status: Pre-Alpha
Brought to you by:
brefin
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-16 01:30:20
|
On Sunday, December 15, 2002, at 03:59 PM, Matt Lee wrote: >> Happen to have any ideas for the project? Either details or testing >> suggestions? I admit I don't have a test plan or even much in the way >> of documents for the current state of AlephModular. > > Well, I think it would be best to model AM after successful open > source projects, as opposed to those that are less organized. (not > naming any names :) As such, since AM is just starting out, a roadmap > or similar idea in the manner of Mozilla might be good. > > I know you laid out some possible targets on the A1 list, but perhaps > a Web version that could be updated as things get accomplished. I can > help with this. Which leads me to my next question... does AM have a > Web site or just the sourceforge project page? That's a grand idea. I have concepts in mind for the roadmap. But haven't really figured out *where* and *how* to display them. For instance, most of the info on milestone 0.3 is simply in the list archive on SourceForge for this mailing list. The highlights of the roadmap are roughly 0.1 it compiles 0.2 it runs (current state) 0.3 beat the code into shape 0.4 beat platform handling into shape 0.5 begin modularization Somewhere around 0.5-0.6 is probably the right place to get networking working initially. It's far enough out that anything beyond that for milestones is flexible for priorities. (For instance Marathon infinity compatibility, open GL support, blowing the limits off maps, and/or AlephOne compatibility (which strikes me as a post 1.0 type goal) AM does have a website, http://alephmodular.sourceforge.net/. I didn't really have anything to say yet or any idea how to arrange it so it's just blank. Enough there to say 'Yeah, we should have something here' > In the way of documentation, I haven't looked at the source yet, but > from what I know already, there's not much to say other than what > works right now (covered in the Read Me), what's changed in the code, > and targets for the next release or two. Right? There's also a documentation directory in the source tree. I put a couple of notes within it. One is a description of how I've been doing serializing of data to/from files in AM. The other was a report on how different parts of Marathon used files. The README that accompanies the source also has a rough FAQ, trying to explain 'Why AlephModular?' instead of just working within AlephOne. -Jeremy --------------------- +------------------------------------------------------ Br'fin | TIMSter, MU*er, Web Programmer, ... Insane? The Denim Warrior | You be the judge... br...@ma... | --------------------- +------------------------------------------------------ |
From: Br'fin <br...@ma...> - 2002-12-16 01:12:21
|
On Sunday, December 15, 2002, at 04:14 PM, Matt Lee wrote: > I decided to try the level on Normal instead of Total Carnage, and > this time I managed to crash it. > > I was doing my thing and I got into the area in which you jump into > the big pool of water to hit the elevator and go back up into the > first area. I jumped in the water and floated at the top for a second, > since I had my run key held down. I released it and sunk to the > bottom. > > As I got up to the elevator and started thinking about how to push the > buttons (I really suck without the mouse), I realized the mouse cursor > had just become visible. Then AM unexpectedly quit. > > Here's the relevant excerpt from the crash log. Let me know if you > need more info. (again, I'm on 10.2.2 with the carbon sound manager > update) I don't think I've applied the Sound Manager update. But seeing as I found a bug like that in sound_add_ambient_sources_proc earlier today, it's probably the same glitch we saw. I think turning off ambient sounds will work around it. But the code within CVS should be fixed. Another part that I only just uploaded a fix to is external physics files. They weren't being read in properly before. You'd need to compile from a CVS update of the sources to see the fixes. -Jeremy --------------------- +------------------------------------------------------ Br'fin | TIMSter, MU*er, Web Programmer, ... Insane? The Denim Warrior | You be the judge... br...@ma... | --------------------- +------------------------------------------------------ |
From: Matt L. <ze...@ze...> - 2002-12-15 21:15:13
|
I decided to try the level on Normal instead of Total Carnage, and this time I managed to crash it. I was doing my thing and I got into the area in which you jump into the big pool of water to hit the elevator and go back up into the first area. I jumped in the water and floated at the top for a second, since I had my run key held down. I released it and sunk to the bottom. As I got up to the elevator and started thinking about how to push the buttons (I really suck without the mouse), I realized the mouse cursor had just become visible. Then AM unexpectedly quit. Here's the relevant excerpt from the crash log. Let me know if you need more info. (again, I'm on 10.2.2 with the carbon sound manager update) Thread 0 Crashed: #0 0x0001fef0 in sound_add_ambient_sources_proc(void*, void (*)(ambient_sound_data*, world_location3d*, world_location3d*, short, short)) (map.cpp:2127) #1 0x00055ad8 in update_ambient_sound_sources() (sound.cpp:1038) #2 0x000539a0 in cause_ambient_sound_source_update() (sound.cpp:307) #3 0x00053908 in sound_manager_idle_proc() (sound.cpp:293) #4 0x00056840 in global_idle_proc() (shell.cpp:302) #5 0x00059778 in try_for_event(bool*) (interface_macintosh.cpp:436) #6 0x000586b0 in main_event_loop() (shell.cpp:1158) #7 0x000565e0 in main (shell.cpp:156) #8 0x00003c4c in _start (crt.c:267) #9 0x00003acc in start -- Matt Lee | PGP key available: ze...@ze... | http://zebe.net/pgp.asc |
From: Matt L. <ze...@ze...> - 2002-12-15 20:59:50
|
>Happen to have any ideas for the project? Either details or testing >suggestions? I admit I don't have a test plan or even much in the >way of documents for the current state of AlephModular. Well, I think it would be best to model AM after successful open source projects, as opposed to those that are less organized. (not naming any names :) As such, since AM is just starting out, a roadmap or similar idea in the manner of Mozilla might be good. I know you laid out some possible targets on the A1 list, but perhaps a Web version that could be updated as things get accomplished. I can help with this. Which leads me to my next question... does AM have a Web site or just the sourceforge project page? In the way of documentation, I haven't looked at the source yet, but from what I know already, there's not much to say other than what works right now (covered in the Read Me), what's changed in the code, and targets for the next release or two. Right? -- Matt Lee | PGP key available: ze...@ze... | http://zebe.net/pgp.asc |
From: Br'fin <br...@ma...> - 2002-12-15 14:44:48
|
On Sunday, December 15, 2002, at 06:13 AM, Matt Lee wrote: > Hello, > > Just wanted to make known that I've joined this list as well. My name > is Matt Lee, aka "Zebe." > > I did some initial testing just for the heck of it. On my G4/400 AGP, > running 10.2.2, I was able to run AlephModular 0.2 as the Read Me > indicates (by installing my Marathon2 data files, and not using the > mouse, etc). I played through as much of the first level as I could -- > total carnage mode isn't so easy when you can't use the mouse! Good to hear it. I've just been lame and been leaving it on the default difficulty. Heck, I don't think I've tried reconfiguring the keys yet. Certainly Marathon's default isn't what I used to use. Though back at that time I never did use the mouse typically to begin with :) > As per sourceforge tradition, my skills are: > - extensive experience with commercial software beta testing > - coordinated one devel/beta/prerelease/release cycle of the > distributed.net client, including managing Bugzilla and building > binaries for FreeBSD and Mac OS X > - knowing people with actual talents I can annoy/coerce into helping > - Web stuff > - introductory C and some Java experience. Want to learn Carbon/C++. > > I think this project has a lot of merit. Whether I can contribute > anything other than testing and/or release target suggestions remains > to be seen, but I'll do what I can. > > Thanks, > Zebe > Welcome. And to me those skills certainly seem useful. Happen to have any ideas for the project? Either details or testing suggestions? I admit I don't have a test plan or even much in the way of documents for the current state of AlephModular. -Jeremy Parsons --------------------- +------------------------------------------------------ Br'fin | TIMSter, MU*er, Web Programmer, ... Insane? The Denim Warrior | You be the judge... br...@ma... | --------------------- +------------------------------------------------------ |
From: Matt L. <ze...@ze...> - 2002-12-15 11:14:00
|
Hello, Just wanted to make known that I've joined this list as well. My name is Matt Lee, aka "Zebe." I did some initial testing just for the heck of it. On my G4/400 AGP, running 10.2.2, I was able to run AlephModular 0.2 as the Read Me indicates (by installing my Marathon2 data files, and not using the mouse, etc). I played through as much of the first level as I could -- total carnage mode isn't so easy when you can't use the mouse! As per sourceforge tradition, my skills are: - extensive experience with commercial software beta testing - coordinated one devel/beta/prerelease/release cycle of the distributed.net client, including managing Bugzilla and building binaries for FreeBSD and Mac OS X - knowing people with actual talents I can annoy/coerce into helping - Web stuff - introductory C and some Java experience. Want to learn Carbon/C++. I think this project has a lot of merit. Whether I can contribute anything other than testing and/or release target suggestions remains to be seen, but I'll do what I can. Thanks, Zebe -- Matt Lee | PGP key available: ze...@ze... | http://zebe.net/pgp.asc |
From: Br'fin <br...@ma...> - 2002-12-15 07:06:05
|
Mmm, got partly distracted. Debated with myself then began trying to get the command line tools that the marathon2 source code came with to compile and work. I figured let's get them operation now as targets that ProjectBuilder can compile for, just as I got Marathon running. Anyhow, doing that for export_definitions revealed that not only wasn't physics being serialized when being written out, but that it wasn't being serialized when reading it all in. So, been working on serializing physics in/out. Tussling issues surrounding the definitions being nigh on private to the one .cpp file that mainly uses them (For instance, weapon_definitions is defined in weapons_definitions and only included by export_definitions and weapons.cpp and I'm trying to make parts accessible to import_definitions for now. Sigh sigh sigh, erf :) -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-14 06:38:38
|
The most recent ADC mail mentions a new Technote. Ensuring Backwards Binary Compatibility - Weak Linking and Availability Macros on Mac OS X http://developer.apple.com/technotes/tn2002/tn2064.html Now I admit my own ability to grok this is limited at the moment. However it seems worth reading over for all of us dealing with 10.2 and wanting things to work under 10.1 (or adding 10.2 specific features when on 10.2) I probably need to read this paper over a couple times when I'm awake. --------------------- +------------------------------------------------------ Br'fin | TIMSter, MU*er, Web Programmer, ... Insane? The Denim Warrior | You be the judge... br...@ma... | --------------------- +------------------------------------------------------ |
From: Br'fin <br...@ma...> - 2002-12-13 02:57:44
|
The correct list to send to is ale...@li.... Unfortunately, networking wasn't in a form to just Carbonize. It's=20 using calls and code that went out of style with the advent of Open=20 Transport. As such it wasn't just a case of a few casts and accessors,=20= but it needed a rewrite to work under Carbon in the first place. As=20 such it missed the cut for getting AlephModular to work. Stability is definitely a goal. The actual details of feature freeze=20 and polish are still up in the air. But believe me, I want to iron out=20= all the issues before I have a true release. And yes, I agree about using the SourceForge things. I still need to=20 learn them, but I definitely want them used. -Jeremy Parsons On Thursday, December 12, 2002, at 09:34 PM, Timothy Collett wrote: >> If people have basic principles they'd like to see implemented in the=20= >> code. Now's generally the time to voice them. Check my heads up on=20= >> 0.3 to see the sorts of things I'm currently taking under=20 >> consideration. >> > > Not sure how basic you mean...keeping networking working seems like a=20= > good idea; really cool would be B&B, but I doubt the feasibility of=20 > that. (Unless you think you can do it, in which case go!) Something=20= > which isn't precisely in the code, but more in the coding process: I=20= > think it would be a good idea to make AM fully stable more often--that=20= > is, every so often (once the initial rocky period is over), feature=20 > freeze and work only on getting what's there working right. I have=20 > been unable to use most of the recent OS X builds of A1 for various=20 > reasons, and there have been various problems mentioned on the=20 > list...it just seems like a good idea to try our best to avoid this. =20= > And managing such things through SourceForge, rather than just the=20 > list, seems like it would help a lot. > > Just my 2=A2. > > Hope this list doesn't bounce me! > > Timothy Collett > > "...that which we are, we are; > One equal temper of heroic hearts > Made weak by time and fate, but strong in will > To strive, to seek, to find, and not to yield." > =97Alfred Lord Tennyson > > > |
From: Br'fin <br...@ma...> - 2002-12-12 04:13:50
|
Here's my current list of goals for 0.3 Code cleanup Basic development practices Basic application identification Cleanup and Basic development practices go hand in hand It consists of No warnings except what we put in with #warning Consistency of variable definition Do we use short or uint16? I must admit the latter is very clear for each platform. Consistency of memory allocation Do we use new/delete or malloc/free I'm inclined to go new/delete if just becuase the resulting memory allocation is already typed (no typecast needed) Adding #ifdefs to header files to prevent multiple inclusion Branding each file with a CVS $Id line Limiting of typecasts if possible I'd much rather fix the various type conversion warnings by using the correct type instead of using casts. I got burned by some during the Carbonization process. (This mostly applies to fixing variable conversion warnings as opposed to auditing code for this currently) Basic application identification License/Distribution boilerplate on text files Application Type meta-data (MacOS builds only) Refinement of basic release package -Jeremy Parsons --------------------- +------------------------------------------------------ Br'fin | TIMSter, MU*er, Web Programmer, ... Insane? The Denim Warrior | You be the judge... br...@ma... | --------------------- +------------------------------------------------------ |