alephmodular-devel Mailing List for AlephModular (Page 8)
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...> - 2003-08-16 15:56:04
|
On Monday, July 28, 2003, at 10:14 PM, Alexander Strange wrote: > > On Monday, July 28, 2003, at 06:24 PM, Br'fin wrote: > >> Yes, I know it's old and crusty in here. But I never know quite what >> to do aside from occasionally making some headway on the Display >> Abstraction. >> >> The general business I see CDContext dealing with will mainly be >> drawing lines, text, and filling areas. As such it will provide the >> support/features needed and provided by screen_drawing.cpp. As well >> as other areas where direct drawing commands are done upon a buffer. >> (For instance, asking a buffer to be erased/filled to a color) > > It would be useful if it also supported basic transforms like scaling > (so we can read terminals comfortably at high screen resolutions, > although we may not want to scale the pictures); Quartz and OpenGL > will handle this for you in OSX. > >> But that is probably fairly rare to begin with. And in the future may >> allow us to shift to a Quartz based drawing scheme. (Heh, >> anti-aliased text and map lines?) > > I would definetely recommend starting out with Quartz/CoreGraphics > instead of a QuickDraw API. > Well, I need more of the drawing context stuff in place before I can supersede it with Quartz stuff I think. Given the current layout of the code, I don't think there's any problems with using Quickdraw APIs. They would just break things in the drawing abstraction that aren't currently used by the code. I do like the concept of a CScaledBuffer though. Something where you set it up like: scaled_buffer= buffer.get_scaled_buffer(Rectangle(640, 480, 0, 0)); And intervening code around things like the associated drawing context manipulates graphic commands; transforms things like the font used and the actual pixel locations. -Jeremy Parsons |
|
From: Timothy C. <tco...@ha...> - 2003-08-16 13:27:52
|
Hey! It's good to know you're still working on AM, Br'fin. I don't know about the rest of the A1 group, but I still think that AM is the future. Keep up the good work! Timothy Collett "Sufficient Stupidity combined with enough Power is effectively indistinguishable from Evil." dpilot, Slashdot |
|
From: Br'fin <br...@ma...> - 2003-08-16 07:04:30
|
I just committed basic drawing context setup on the devel-display-abstraction. The only thing the context does right now is manage the already existing pixel and drawing lock elements and implement the infrastructure for managing drawing contexts. That is, a drawing context is initially asked for, and is then reference counted for each further request for a drawing context. When all the references go bye bye, so does the context altogether. Hopefully I'll get around to further updates that actually put the responsibility to drawing in methods of the context. -Jeremy Parsons |
|
From: Br'fin <br...@ma...> - 2003-07-30 19:57:49
|
On Monday, July 28, 2003, at 10:14 PM, Alexander Strange wrote: > > On Monday, July 28, 2003, at 06:24 PM, Br'fin wrote: > >> Yes, I know it's old and crusty in here. But I never know quite what >> to do aside from occasionally making some headway on the Display >> Abstraction. >> >> The general business I see CDContext dealing with will mainly be >> drawing lines, text, and filling areas. As such it will provide the >> support/features needed and provided by screen_drawing.cpp. As well >> as other areas where direct drawing commands are done upon a buffer. >> (For instance, asking a buffer to be erased/filled to a color) > > It would be useful if it also supported basic transforms like scaling > (so we can read terminals comfortably at high screen resolutions, > although we may not want to scale the pictures); Quartz and OpenGL > will handle this for you in OSX. > >> But that is probably fairly rare to begin with. And in the future may >> allow us to shift to a Quartz based drawing scheme. (Heh, >> anti-aliased text and map lines?) > > I would definetely recommend starting out with Quartz/CoreGraphics > instead of a QuickDraw API. > Mmm, point on the scaling or handling of terminals. I admit I haven't put much thought into other resolutions yet. I want to keep it in mind, but haven't done anything about it yet. I'm more likely to lean towards the first implementation using the QuickDraw API just because that's what all of the existing code tends to expect. Once the code is encapsulated then the work of pushing it towards Quartz would be clearer. Especially if I'm the one who has to code things :) -Jeremy Parsons |
|
From: Alexander S. <ast...@it...> - 2003-07-29 02:53:03
|
On Monday, July 28, 2003, at 06:24 PM, Br'fin wrote: > Yes, I know it's old and crusty in here. But I never know quite what > to do aside from occasionally making some headway on the Display > Abstraction. > > The general business I see CDContext dealing with will mainly be > drawing lines, text, and filling areas. As such it will provide the > support/features needed and provided by screen_drawing.cpp. As well as > other areas where direct drawing commands are done upon a buffer. (For > instance, asking a buffer to be erased/filled to a color) It would be useful if it also supported basic transforms like scaling (so we can read terminals comfortably at high screen resolutions, although we may not want to scale the pictures); Quartz and OpenGL will handle this for you in OSX. > But that is probably fairly rare to begin with. And in the future may > allow us to shift to a Quartz based drawing scheme. (Heh, anti-aliased > text and map lines?) I would definetely recommend starting out with Quartz/CoreGraphics instead of a QuickDraw API. |
|
From: Br'fin <br...@ma...> - 2003-07-28 22:24:19
|
Yes, I know it's old and crusty in here. But I never know quite what to do aside from occasionally making some headway on the Display Abstraction. The general business I see CDContext dealing with will mainly be drawing lines, text, and filling areas. As such it will provide the support/features needed and provided by screen_drawing.cpp. As well as other areas where direct drawing commands are done upon a buffer. (For instance, asking a buffer to be erased/filled to a color) CDContext A CDContext, aka a Drawing Context, would own all of the high-level operations for operating on a buffer. For instance, using line primitives and displaying text. Some systems, such as Macintosh, use a method of drawing commands that works as follows. Store the current drawing context Use the desired graphics port as the context perform drawing operations Swap the ports back to where they were before. Modern systems are much more object orientated which helps also when dealing with threads and multiple processors. So we will have a CDContext for each buffer we wish to draw to. (However, each buffer will only have one context, but may have multiple copies of that context floating around (via reference counting)) In practice, using a CDContext would be like: std::auto_ptr<CDContext> context= CBuffer.get_drawing_context() context.draw_line... context.draw_text (context automatically freed) Since the Macintosh scheme currently uses Quickdraw, the existing Macintosh method predates multithreading and other modern issues. We should accept that the Carbon based drawing methods may have problems with performing drawing operations between sets of drawing contexts all at once. ( for instance: dc1.draw_line dc2.draw_line dc1.draw_line ) But that is probably fairly rare to begin with. And in the future may allow us to shift to a Quartz based drawing scheme. (Heh, anti-aliased text and map lines?) If a CBuffer already has an existing CDContext, then it should return the same drawing context. Hence, CDContext should be reference counted. Refer to the C++ faq for the basics: http://www.parashift.com/c++-faq-lite/freestore-mgmt.html#faq-16.21 -Jeremy Parsons |
|
From: Br'fin <br...@ma...> - 2003-06-27 16:38:18
|
You know. I think I have been completely remiss in mentioning this. AlephModular has not been receiving a lot of updates. I know this and apologize. This does not mean it has been completely neglected. I frequently refer back to it when I encounter some problem or another in AlephOne. And I have been fixing issues that affect both. Beyond that, I still want to wrap up Display Abstraction before trying anything cute like merging in Woody's A1 networking code. Now the matter I should have mentioned after Alexander set it up is that AlephModular has its own CVS list. https://lists.sourceforge.net/lists/listinfo/alephmodular-cvs -Jeremy Parsons AlephModular Project Administrator |
|
From: Br'fin <br...@ma...> - 2003-05-13 03:04:39
|
Mostly fallen into a period of 'eh'. I'm still checking on things, but work on the display abstraction rather ground to a halt as I fiddled with the APIs and couldn't quite figure out a good solution at all. That said, Woody did ask about using AStreams for a facet of AlephOne and I went in, added the features and added a lot more defensive programming for the classes. -Jeremy Parsons On Monday, May 12, 2003, at 10:30 PM, lu...@ea... wrote: > Hey, all, has work on Aleph Modular ceased? I wouldn't ask but for > the fact that I haven't seen any activity at all since April 3, more > than a month ago now. > > Is it just a lull in the list, or is there something more going on? > Like, say, discussion has moved to SourceForge fora, or I > inadvertently got dropped off the list? > > If this list is still active and all but people have lost interest, > I'd like to encourage Br'fin and the rest of you guys with the > know-how to keep on with the project. I don't know if and when Aleph > One will ever see B&B, whereas there seems to me a very real > possibility of Aleph Modular getting this sort of capability (plus > others, I hope). > > Keep this humble mapmaker's dream alive, > -Lunair > |
|
From: <lu...@ea...> - 2003-05-13 02:30:52
|
Hey, all, has work on Aleph Modular ceased? I wouldn't ask but for the fact that I haven't seen any activity at all since April 3, more than a month ago now. Is it just a lull in the list, or is there something more going on? Like, say, discussion has moved to SourceForge fora, or I inadvertently got dropped off the list? If this list is still active and all but people have lost interest, I'd like to encourage Br'fin and the rest of you guys with the know-how to keep on with the project. I don't know if and when Aleph One will ever see B&B, whereas there seems to me a very real possibility of Aleph Modular getting this sort of capability (plus others, I hope). Keep this humble mapmaker's dream alive, -Lunair |
|
From: Br'fin <br...@ma...> - 2003-05-04 00:33:50
|
At Woody's request and to his suggested specs I upgraded the AStreams used for de/serialization of objects between in memory format and their disk based format. AStreams now take a length and will go into a fail state with an optional exception (on by default) if an operation would go past the end of that length. -Jeremy Parsons |
|
From: Br'fin <br...@ma...> - 2003-04-07 16:19:41
|
I'm poking through things (slowly, I know,) and it seems like Marathon has two main functions for dealing with color tables. The first is assert_world_color_table who's primary responsibility is setting the color table of the GDevice shared between the screen and the offscreen buffer. Or to put it another way, this seems to be responsible for setting up the offscreen color table. And it only does real work when in 8 bit mode. The other function is animate_screen_clut. Which is responsible for altering the screen. This can occur in any bit depth as things like gamma correction and fades are implemented through it. I'm thinking of implementing these two functions on CDisplay as void CDisplay::set_buffer_clut(color_table *) Which sets up the drawing clut for when in 8 bit mode. But which is ignored the rest of the time. (No, it doesn't assert) void CDisplay::adjust_screen_clut(color_table *) Which immediately alters the screen by using the provided color table. In 8-bit mode this is also when the color table is expressed onto the screen. Thoughts or comments? -Jeremy Parsons |
|
From: Aaron D. <ada...@ho...> - 2003-04-04 07:30:02
|
On Thursday, April 3, 2003, at 12:13 PM, Br'fin wrote:
> On Thursday, April 3, 2003, at 01:07 AM, Aaron Davies wrote:
>
>> Just two caveats: first, the menu screen system dialog boxes (open
>> game, save film) come up on the main monitor even when I have second
>> one selected. I don't know if this is fixable, but it's annoying.
>
> I don't think anything really specifies a screen for the dialog boxes,
> so they just come up centered on the screen that would normally hold
> the menu bar. No clue about fixability myself. (I presume its fixable,
> but I don't know how.) ... by the way what screen do the preferences
> and network dialog boxes show up on?
Prefs comes up on whatever screen I selected in the graphics panel.
Presumably network would too, tho I don't believe I tried it. Perhaps
there's a clue in the fact that custom dialogs come up on the right
screen, but not generic system dialogs? The confirm dialog for closing
a game also comes up on the right screen.
>> Second, I seem to be getting significantly worse framerates on the
>> secondary screen than on the primary. With A1 on the Infinity map, I
>> got about 9fps on the second screen and 15fps on the first, without
>> changing any graphics settings. (This is of course with OGL off, as
>> the second screen isn't plugged into a card.)
>
> Try switching the game down into Low-resolution for a better frame
> rate. Software rendering is known to be extra-slow in both A1 and the
> main trunk of AM. (Improper usage of a window's back buffer.) But with
> low-resolution mode on the game should be trying to blit directly to
> the screen more or less. So it tends to fly even when high-resolution
> has no legitimate reason to be sluggish.
I did, they work fine it low-res, but god is it ugly. Reminds me of
Wolfenstein!
> Technically, Low-resolution mode is doing the WRONG thing, so I don't
> advocate making everything blit to the screen that way. :)
>
>> Oh, one other thing--in AM, a new game would sometimes come up with
>> the HUD but no game graphics, and I'd have to change the screen size
>> (F1-F4) to get the graphics to show. I don't know if this is specific
>> to the patch or not.
>
> Hmm, most curious, does this problem ever show up without the patch
> applied? On one hand the patch is in a different file and area, but
> it's a close enough realm that something could have been missed when
> the screens were being organized internally.
I haven't played around with AM a lot, so I'm not sure.
--
__ __
/ ) / )
/--/ __. __ ________ / / __. , __o _ _
/ (_(_/|_/ (_(_) / / <_ /__/_(_/|_\/ <__</_/_)_
|
|
From: Mark L. <hav...@ma...> - 2003-04-04 01:19:41
|
> Try switching the game down into Low-resolution for a better frame > rate. Software rendering is known to be extra-slow in both A1 and the > main trunk of AM. (Improper usage of a window's back buffer.) But with > low-resolution mode on the game should be trying to blit directly to > the screen more or less. So it tends to fly even when high-resolution > has no legitimate reason to be sluggish. Actually, I've noticed that when running on my secondary monitor (temporarily set to main, since I haven't applied the patch yet) the game window is misaligned by a pixel or two, and spills onto the other monitor. This forces OS X to do a copy across the two graphics cards every frame, which is an enormous speed drain. I tried to get a screenshot but the extra pixels didn't show up on the blank monitor's image, even though I could clearly see them when playing the game. (A1 was running on a Radeon PCI hooked up to a 14" as main, with a 17" on an AGP R7500 as secondary, arranged with tops aligned and the 14" on the left. This doesn't seem to happen with the monitors reversed, although it's possible the R7500 is simply fast enough that it has enough excess capacity at 30fps to squeeze in the copy without slowing down.) --Mark "...and remember, a friend is just an enemy who hasn't tried to kill you!" Random acts of programming: http://homepage.mac.com/haveblue |
|
From: Br'fin <br...@ma...> - 2003-04-03 18:13:48
|
On Thursday, April 3, 2003, at 01:07 AM, Aaron Davies wrote: > OK, so I finally got around to testing Br'fin's multi-monitor patch, > and I'm happy to report that it works great. I have a ColorSync 17 > plugged into my ATI Radeon Mac Edition card and an ancient Magnavox > 15" 640x480 plugged into the motherboard monitor port. I selected the > second screen in both A1 and AM and played a few seconds, and it looks > fine. Oh thank you very much, Aaron, that's great to hear. Alexander, do you need the patch again to apply to A1? > Just two caveats: first, the menu screen system dialog boxes (open > game, save film) come up on the main monitor even when I have second > one selected. I don't know if this is fixable, but it's annoying. I don't think anything really specifies a screen for the dialog boxes, so they just come up centered on the screen that would normally hold the menu bar. No clue about fixability myself. (I presume its fixable, but I don't know how.) ... by the way what screen do the preferences and network dialog boxes show up on? > Second, I seem to be getting significantly worse framerates on the > secondary screen than on the primary. With A1 on the Infinity map, I > got about 9fps on the second screen and 15fps on the first, without > changing any graphics settings. (This is of course with OGL off, as > the second screen isn't plugged into a card.) Try switching the game down into Low-resolution for a better frame rate. Software rendering is known to be extra-slow in both A1 and the main trunk of AM. (Improper usage of a window's back buffer.) But with low-resolution mode on the game should be trying to blit directly to the screen more or less. So it tends to fly even when high-resolution has no legitimate reason to be sluggish. Technically, Low-resolution mode is doing the WRONG thing, so I don't advocate making everything blit to the screen that way. :) > Oh, one other thing--in AM, a new game would sometimes come up with > the HUD but no game graphics, and I'd have to change the screen size > (F1-F4) to get the graphics to show. I don't know if this is specific > to the patch or not. Hmm, most curious, does this problem ever show up without the patch applied? On one hand the patch is in a different file and area, but it's a close enough realm that something could have been missed when the screens were being organized internally. -Jeremy Parsons |
|
From: Aaron D. <ad...@ra...> - 2003-04-03 06:08:38
|
OK, so I finally got around to testing Br'fin's multi-monitor patch,
and I'm happy to report that it works great. I have a ColorSync 17
plugged into my ATI Radeon Mac Edition card and an ancient Magnavox 15"
640x480 plugged into the motherboard monitor port. I selected the
second screen in both A1 and AM and played a few seconds, and it looks
fine.
Just two caveats: first, the menu screen system dialog boxes (open
game, save film) come up on the main monitor even when I have second
one selected. I don't know if this is fixable, but it's annoying.
Second, I seem to be getting significantly worse framerates on the
secondary screen than on the primary. With A1 on the Infinity map, I
got about 9fps on the second screen and 15fps on the first, without
changing any graphics settings. (This is of course with OGL off, as the
second screen isn't plugged into a card.)
Oh, one other thing--in AM, a new game would sometimes come up with the
HUD but no game graphics, and I'd have to change the screen size
(F1-F4) to get the graphics to show. I don't know if this is specific
to the patch or not.
--
__ __
/ ) / )
/--/ __. __ ________ / / __. , __o _ _
/ (_(_/|_/ (_(_) / / <_ /__/_(_/|_\/ <__</_/_)_
|
|
From: Br'fin <br...@ma...> - 2003-03-31 04:19:50
|
After some double-checking. Chris seems to be right. While I can't find any documentation of this behavior I did find the following: References on GetCTable() in PB and on Apple's website that mirrors Inside Macintosh: Quickdraw both refer to the resource IDs that are documented. However, Apple's Sample code from similar to later time periods also uses GetCTable(8) ... Aha, finally finally found a reference... How the Palette Manager Restores the Color Environment http://developer.apple.com/techpubs/mac/ACI/ACI-20.html Resources: 1, 2, 4, 8 are the default color resources for each depth Add 32 to get the default greyscale resources for each depth Add 64 to get the default colors resources + highlight color for each depth Hsm, adding that in to the mix, then 72 would still be the proper value to make sure the highlight color is properly set as well. But aside from the highlight color, there's zilch wrong in using resource id 8. -Jeremy Parsons On Sunday, March 30, 2003, at 10:37 PM, Chris Bergmann wrote: > It would appear that this is correct behavior. It may have been > depreciated some time ago (carbon? system 9?) however there seems to > be a fair bit of code around which uses this approach and run fine. I > have a suspicion that if we looked up the original inside mac series > it would specify 8 as being the system-standard 256 color table and 40 > (8+32) as being the standard 256 grayscale table. 'course i don't have > it in front of me at work so ymmv :-) > > that said, you may as well fix it to use the new constants. sooner or > later they may drop the old stuff. > > chris > > > On Monday, March 31, 2003, at 07:32 AM, Br'fin wrote: > >> I was poking through AlephModular while trying to rehandle how cluts >> were used. And I stumbled upon the usage of GetCTable(8). Which, upon >> checking PB's docs for GetCTable seemed wrong. And so I checked in >> AlephOne and found the same issue (It dates back to the Marathon2 >> code originally) >> >> Both things call GetCTable with an argument of 8 ... it seems like >> the correct argument should be 72. I don't know of any tech notes >> that would say that 8 should also work for a 256 color system clut. >> >> Can anyone confirm or deny that this is some kind of 256 color >> problem? |
|
From: Chris B. <ce...@ma...> - 2003-03-31 03:37:20
|
It would appear that this is correct behavior. It may have been depreciated some time ago (carbon? system 9?) however there seems to be a fair bit of code around which uses this approach and run fine. I have a suspicion that if we looked up the original inside mac series it would specify 8 as being the system-standard 256 color table and 40 (8+32) as being the standard 256 grayscale table. 'course i don't have it in front of me at work so ymmv :-) that said, you may as well fix it to use the new constants. sooner or later they may drop the old stuff. chris On Monday, March 31, 2003, at 07:32 AM, Br'fin wrote: > I was poking through AlephModular while trying to rehandle how cluts > were used. And I stumbled upon the usage of GetCTable(8). Which, upon > checking PB's docs for GetCTable seemed wrong. And so I checked in > AlephOne and found the same issue (It dates back to the Marathon2 code > originally) > > Both things call GetCTable with an argument of 8 ... it seems like the > correct argument should be 72. I don't know of any tech notes that > would say that 8 should also work for a 256 color system clut. > > Can anyone confirm or deny that this is some kind of 256 color problem? |
|
From: Br'fin <br...@ma...> - 2003-03-30 21:31:57
|
I was poking through AlephModular while trying to rehandle how cluts
were used. And I stumbled upon the usage of GetCTable(8). Which, upon
checking PB's docs for GetCTable seemed wrong. And so I checked in
AlephOne and found the same issue (It dates back to the Marathon2 code
originally)
Both things call GetCTable with an argument of 8 ... it seems like the
correct argument should be 72. I don't know of any tech notes that
would say that 8 should also work for a 256 color system clut.
Can anyone confirm or deny that this is some kind of 256 color problem?
-Jeremy Parsons
From AlephOne: FileHandler.h
void GetSystemColorTable()
{Unload(); RsrcHandle = Handle(GetCTable(8));}
From PB's reference docs:
GetCTable
Obtains a color table stored in a 'clut' resource.
CTabHandle GetCTable (
SInt16 ctID
);
Parameter descriptions
ctID
The resource ID of a 'clut' resource.
function result
A handle to the color table. If the 'clut' resource with that ID is not
found, GetCTable returns NULL.Before you place this handle in the
pmTable field of a PixMap structure, first use the DisposeCTable
function to dispose of the handle already there.
Discussion
Before you modify a ColorTable structure, change its ctSeed field to
invalidate it. To do this, use the CTabChanged function.
The GetCTable function recognizes a number of standard 'clut' resource
IDs. You can obtain the default grayscale color table for a given pixel
depth by calling GetCTable , adding 32 (decimal) to the pixel depth,
and passing these values in the ctID parameter:
* A pixel depth of 1
Pass a resource ID of 33. Color table composition: black, white.
* A pixel depth of 2
Pass a resource ID of 34. Color table composition: black, 33% gray, 66%
gray, white.
* A pixel depth of 3
Pass a resource ID of 35. Color table composition: black, 14 shades of
gray, white.
* A pixel depth of 4
Pass a resource ID of 36. Color table composition: black, 254 shades of
gray, white.
For full color, obtain the default color tables by adding 64 to the
pixel depth and passing these values in the ctID parameter:
* A pixel depth of 2
Pass a resource ID of 66. Color table composition: black, 50% gray,
highlight color, white.
* A pixel depth of 4
Pass a resource ID of 68. Color table composition: black, 14 colors
including the highlight color, white.
* A pixel depth of 8
Pass a resource ID of 72. Color table composition: black, 254 colors
including the highlight color, white.
Availability
Supported in Carbon. Available in CarbonLib 1.0 and later when running
Mac OS 8.1 or later. Available in Mac OS X 10.0 and later.
Special Considerations
The GetCTable function may move or purge memory blocks in the
application heap; do not call this function at interrupt time.
|
|
From: Br'fin <br...@ma...> - 2003-03-26 14:52:52
|
Some more CVS checkins on the devel-display-abstraction branch. I've managed to isolate good chunks of the usage of world_device and CDisplay/CDisplay_Carbon are responsible for locating the best screen and altering the resolution of it. I'm still doing some swapping back and forth between CScreenInfo and GDSpec as I'm not yet ready to change the format of the preferences file. -Jeremy Parsons |
|
From: Aaron D. <ag...@co...> - 2003-03-20 05:05:08
|
On Tuesday, March 18, 2003, at 11:22 PM, Br'fin wrote: > On Wednesday, March 19, 2003, at 12:05 AM, Aaron Davies wrote: > >> I'm actually just now getting around to building AM for the first >> time (I'm going to try to test Br'fin's multiple monitor code), but >> it's not working. I checked out the source as instructed on SF.net >> and built it with PB, but when I start AM, it says >> >> ../../marathon2/game_errors.h:37: Assertion failed: good() >> >> So I don't get anywhere. I've placed the content files from Marathon >> Infinity in the build folder to satisfy the requirement for content >> files, BTW. > > Hmm, seems I may have a mis-errorcheck somewhere. I'll go check into > it. > > However, AM doesn't currently support Marathon Infinity files. It > should run with either M2 or M2 demo files though. I'll give it a try with M2 then. > PS. Aaron, you making it out to Lunacon again? No, I'm afraid not. I still haven't found a job, almost a year after graduation, so I'm living at home in Kentucky, and I have no money for getting back to New York. -- __ __ / ) / ) /--/ __. __ ________ / / __. , __o _ _ / (_(_/|_/ (_(_) / / <_ /__/_(_/|_\/ <__</_/_)_ |
|
From: Br'fin <br...@ma...> - 2003-03-19 20:47:43
|
Is there anyone interested in working on a reorganization of the marathon2.resource file? It seems like it should be split into 3 distinct files: marathon2.shared.r All simple resources that are used by AlephModular stored in Rez format. For instance, the STR# and nrect resources. Potentially this could cover all of the non-pictoral resources including dialog layout, CNTL and MENU resources. But I don't know of the tradeoffs/arguments. and it still might be that carbon dialogs definitions should be put in yet another file so that they follow the proper metrics for Aqua. Then again after tweaking for Carbon they should still work properly for classic if anyone can actually pot this project back to classic. marathon2.classic.resource A flat file of a resource fork. All resources used by the classic application. This would cover the icons and other stray classic resources, such as the cicn, SIZE, BNDL, and 52.4 resources. marathon2.resource A flat file of a resource fork. All of the resources that continue to make more sense as elements in a classic resource fork. Such as the PICT resources for the images used in the preferences dialogs. I will admit that I do not have a good grasp of where to draw the line between what should go in marathon2.shared.r and what should stay in marathon2.resource. So anybody interested in helping here better be able to explain their decisions before they go and do it. :) I suppose that telling me to ditch resource files and use nib files is a possibility, but you better have a good argument and perhaps be willing to do the required work to actually do so. :) -Jeremy Parons |
|
From: Br'fin <br...@ma...> - 2003-03-19 07:01:38
|
On Wednesday, March 19, 2003, at 12:22 AM, Br'fin wrote: > > On Wednesday, March 19, 2003, at 12:05 AM, Aaron Davies wrote: > >> I'm actually just now getting around to building AM for the first >> time (I'm going to try to test Br'fin's multiple monitor code), but >> it's not working. I checked out the source as instructed on SF.net >> and built it with PB, but when I start AM, it says >> >> ../../marathon2/game_errors.h:37: Assertion failed: good() >> >> So I don't get anywhere. I've placed the content files from Marathon >> Infinity in the build folder to satisfy the requirement for content >> files, BTW. > > Hey Aaron, > > Hmm, seems I may have a mis-errorcheck somewhere. I'll go check into > it. > Found the mis-check. Errors were being raised when checksums were being checked and then not handled. For now I've adjusted it so that neither checksum routine can raise an error (they clean up any errors they encounter). And if the error matters, then it can show up when the wad file is being actively processed. For instance, if you feed AM files from M-infinity, then it will pop up a dialog stating that the map or other files couldn't be read with an error id of 4. The error code for UNKNOWN_WAD_VERSION. Which, for now, is a perfectly acceptable response to being passed M-infinity files. -Jeremy Parsons |
|
From: Br'fin <br...@ma...> - 2003-03-19 05:21:36
|
On Wednesday, March 19, 2003, at 12:05 AM, Aaron Davies wrote: > I'm actually just now getting around to building AM for the first time > (I'm going to try to test Br'fin's multiple monitor code), but it's > not working. I checked out the source as instructed on SF.net and > built it with PB, but when I start AM, it says > > ../../marathon2/game_errors.h:37: Assertion failed: good() > > So I don't get anywhere. I've placed the content files from Marathon > Infinity in the build folder to satisfy the requirement for content > files, BTW. Hey Aaron, Hmm, seems I may have a mis-errorcheck somewhere. I'll go check into it. However, AM doesn't currently support Marathon Infinity files. It should run with either M2 or M2 demo files though. PS. Aaron, you making it out to Lunacon again? -Jeremy Parsons |
|
From: Aaron D. <ag...@co...> - 2003-03-19 05:05:19
|
I'm actually just now getting around to building AM for the first time (I'm going to try to test Br'fin's multiple monitor code), but it's not working. I checked out the source as instructed on SF.net and built it with PB, but when I start AM, it says ../../marathon2/game_errors.h:37: Assertion failed: good() So I don't get anywhere. I've placed the content files from Marathon Infinity in the build folder to satisfy the requirement for content files, BTW. -- __ __ / ) / ) /--/ __. __ ________ / / __. , __o _ _ / (_(_/|_/ (_(_) / / <_ /__/_(_/|_\/ <__</_/_)_ |
|
From: Br'fin <br...@ma...> - 2003-03-17 07:30:59
|
On Sunday, March 16, 2003, at 09:56 AM, tiennou wrote: > Hello ! > > First, I found your work on AM excellent ! I'm glad to see someone > really trying to make the code usable, and if there is times where I > don't understand very well what you are talking about, I like the > overall results... > > Today, I got the lastest source from CVS and it compiled fine ! This > is the first time I get anything built with PB. > > I looked through the changes you've made, and the stuff you've added. > It's cool ! Thank you, and I'm glad it compiled too. :) > Anyway, I wanted to know if there was a need for something to be > coded, because I'm kinda lacking interest in AO. It's too much complex > for me ;-). I saw there were things to be done (#warnings at compile) > mainly around serialization. Maybe I could do that ? Well, most of the warnings about serialization are warnings I put in during a phase of time where getting things working was a higher priority then getting things clean. In otherwords, until we're ready to redo the entire aspect of shapes to clean it up, cleaning up the serialization warnings for aspects that might not be used is low priority so far. > I have a few questions on Marathon and it's source ... > > What is serialization ? Everyone is talking about it, but I never > really grasped its purpose. Has something to do with file saving. Serialization is the process of transforming between a disk based format (a string of bytes in order, ala 2 bytes for height, 2 bytes for width, then 10 bytes for a 9 character name) and the format of the data in memory. In memory values may be in different locations due to processer data alignments or between Mac and PC singular data values may be in different order (big-endian versus little-endian) What it comes down to is that Bungie's original code would save data something like this struct foo; write(file, foo, sizeof(foo)); And when I was first compiling things under MacOS X, well, struct foo is not necessarily the same size or configuration between platforms or compilers. Hence both AM and AO have strategies for decoding the data in the Bungie files into the native structures that the compilers generate. > What is the purpose of the cseries files ? They are around since a > long time, but I don't know why they are needed. The original Bungie source code referred to an external library of some sort that they were unable to include in their release. Essentially a missing but required library known as CSeries. I do not know where their library originated from. One of the earliest efforts in the Marathon community with the source code was to fill in those missing files so that Marathon would actually run. The majority of the missing functions fortunately seemed to fall into the category of 'dumb but routine things you always need to do in a Macintosh program.' Various tricks for dealing with common low-level application details. The first complete set of working CSeries files seems to have come from Bo Lindbergh. AM's own set of CSeries is essentially taken from AO with some minor changes. Minor enough that I was able to fold in some of their recent fixes to the CSeries files. > Actually, I'm trying to find the origins of the original limitations > (Stateless lightning (in AO, the logic seemed to work, but I never > tried), different media types per level, and such). All original limitations should be present in the AM code still. For better or for worse. I haven't had anything in mind to address the limits (Low priority/under my radar) > Hmm, about OpenGL... > I understand there is a need to keep the existing rendering engine, > but it would be much easier to add real 3D support in Marathon if we > could let OpenGL handle the rendering part. (This is an advice from > someone that never done something is OGL, and that doesn't know what > OGL need to function properly). I also think that Low-res mode and 256 > colors mode support should be dropped. All the newer machines are now > able to do more advanced things. Real 3D support is currently a non-target for AM. I would not mind adding OpenGL support, though. As I agree that it could be useful to make things nice and pretty at the larger screen sizes. As well as hopefully rendering everything a lot faster. I'm hoping that OpenGL support can be settled within the framework of the display abstraction at a later point in time. 256 colors mode I'm hazy on. But has proven problematic so far under OSX (My machine does switch to a 256 color mode, but some other AM users were having problems, so AM tends to default to 16 bit if 8-bit fails under OSX) I'll see if further work with Display Abstraction fixes that up at least on my machine. Low-resolution mode isn't too hard to maintain now. I do have it accommodated and working within the graphics framework that's developing. It may be debatable if it's useful or not, but as long as it's working I don't see any problems with keeping it. Newer machines might be able to do more advanced things, but the hooks in the engine aren't there yet. One of the later goals of the display abstraction is to blow-away the 640x480 limit of the current code. Though in such a world it may no longer be relevant to support the 75% and 50% windowed modes that currently exist in the code. My own personal machine is probably a middle of the road MacOS X box as a 450 Mhz G4. Not the newest of machines, but not the lowest end machine that is supported either. > I'm in no way trying to change the path you've chosen. Just trying to > confront my opinion against someone's else. > > Good luck with Display Abstraction ! > Thank you, and I'm glad for the questions too. Currently display abstraction is going slowly, I'm trying to muck out initial setup and calls so I can push more responsibility onto it. In other words, my next goal is to have the display abstraction itself allocate and manage screens and windows as necessary :) -Jeremy Parsons |
