Thread: Re: [Alephmodular-devel] MacOS X 10.1 users?
Status: Pre-Alpha
Brought to you by:
brefin
Menu
▾
▴
alephmodular-devel
|
From: Timothy C. <tco...@ha...> - 2003-01-09 03:32:00
|
On Wednesday, January 8, 2003, at 07:18 PM, Br'fin wrote: > Is there anyone here on the list who has access to OSX 10.1 and is > willing to be a guinea pig? > Love to! I've ordered Jaguar, but it hasn't come yet. Also, I have access to computers at my college that have 10.1 on them, in case we still need to test after I (finally!) have Jaguar. Anyway, I am more than happy to help keep compatibility for folks like I was until yesterday, who haven't bitten the bullet yet, for whatever reason. Timothy Collett I just think it's rather odd that a nation that prides itself on its virility should feel compelled to strap on forty pounds of protective gear just in order to play rugby. --Giles, "Buffy" |
|
From: Timothy C. <tco...@ha...> - 2003-01-13 23:11:43
|
> ough perhaps. I myself just used the preferences mostly to get 50%, > can't remember if the F4 key was working for me. Simple case. My own > testing isn't really all that thorough as what you guys have been > running it through. :) > > The vertical lines should show up in millions of colors+low resolution. > Okay, that they do. I was on Thousands because of a problem I forgot (heh!) to mention: when I started it up, it changed the screen to black, then quit, with just the generic "AlephModular has unexpectedly quit" message, not the failed assert on wad file message; I deleted the prefs and it ran fine. But on my machine, when I had it in lo-res, at 50% size, it still ran fine, in Thousands and Millions. Oh, how are we supposed to stop a game without quitting? Cmd-Q just quits, and Esc doesn't appear to do anything, currently. Timothy Collett How do you know the chosen ones? No greater love hath a man than he lay down his life for his friend. Not for millions, not for glory, not for fame... for one person. In the dark. Where no one will ever know or see. --Sebastian, aka Jack, "Comes the Inquisitor" |
|
From: Br'fin <br...@ma...> - 2003-01-13 23:16:43
|
On Monday, January 13, 2003, at 06:11 PM, Timothy Collett wrote: >> ough perhaps. I myself just used the preferences mostly to get 50%, >> can't remember if the F4 key was working for me. Simple case. My own >> testing isn't really all that thorough as what you guys have been >> running it through. :) >> >> The vertical lines should show up in millions of colors+low >> resolution. >> > > Okay, that they do. I was on Thousands because of a problem I forgot > (heh!) to mention: when I started it up, it changed the screen to > black, then quit, with just the generic "AlephModular has unexpectedly > quit" message, not the failed assert on wad file message; I deleted > the prefs and it ran fine. Oy, happen to have a crash log for that failure? Or has it repeat? > But on my machine, when I had it in lo-res, at 50% size, it still ran > fine, in Thousands and Millions. Oh, how are we supposed to stop a > game without quitting? Cmd-Q just quits, and Esc doesn't appear to do > anything, currently. > > Timothy Collett > Command-W (Close Window) to quit a game or replay in progress and jump back to the main menu. -Jeremy |
|
From: Timothy C. <tco...@ha...> - 2003-01-13 23:50:31
Attachments:
AlephModular.crash.log
|
> Oy, happen to have a crash log for that failure? Or has it repeat? > Umm...yeah, I do. Here it is. |
|
From: Br'fin <br...@ma...> - 2003-01-14 00:40:48
|
On Monday, January 13, 2003, at 06:50 PM, Timothy Collett wrote: >> Oy, happen to have a crash log for that failure? Or has it repeat? >> > > Umm...yeah, I do. Here it is. > <AlephModular.crash.log> > And yes, it did repeat; I tried opening AM twice before throwing out > the preferences. > Well, I've opened a bug on SF for this: http://sourceforge.net/tracker/ index.php?func=detail&aid=667491&group_id=69003&atid=523091 So if anyone else has a crash and gets a log entry that looks like: Thread 0 Crashed: #0 0x00087ed8 in _Z32match_modification_date_callbackP6FSSpecPv #1 0x00022cc4 in _Z15enumerate_filesP12find_file_pbl #2 0x000228e4 in _Z10find_filesP12find_file_pb ... Do feel free to post anything you find to that bug, and if you can't post files to the bug, then send them to me directly. This includes not just the log, but the Prefs file you were about to trash anyways. -Jeremy Parsons |
|
From: Matt L. <ze...@ze...> - 2003-01-14 00:02:52
|
[resend because I sent it directly to Tim, heh] Timothy Collett wrote: >And yes, it did repeat; I tried opening AM twice before throwing out >the preferences. It sounds a lot like the crash I had with the prefs recently as well. >Oh, and I noticed that same fading problem that Woody mentioned, >when fading either to or from the menu. Is that the one in which it "cuts" over to the new image immediately, then fades up from black? I have that too, on all the chapter screens and such. I'm running 10.2.3 on a G4/400. -Zebe -- Matt Lee | PGP key available: ze...@ze... | http://zebe.net/pgp.asc |
|
From: Woody Z. I. <woo...@sb...> - 2003-01-14 00:13:22
|
Actually it's almost exactly the opposite - a screen (like the main menu) fades out when you click something, then fades back in while it plays the "thunder"y sound for the chapter screen, say. Then as soon as the fade reaches 100% brightness, it suddenly "pops" to show the chapter screen. IIRC the chapter screen may pop back again at 100% brightness after it fades out but before the game proper starts. Something similar happens when you click "replay saved film". iceBook 500MHz, 384MB RAM, Mac OS X 10.1.5 here. Woody On Monday, January 13, 2003, at 06:02 PM, Matt Lee wrote: >> Oh, and I noticed that same fading problem that Woody mentioned, when >> fading either to or from the menu. > > Is that the one in which it "cuts" over to the new image immediately, > then fades up from black? I have that too, on all the chapter screens > and such. |
|
From: Br'fin <br...@ma...> - 2003-01-14 00:28:25
|
It's all part of the same problem. AM doesn't yet have any code to tell OSX 'Update the screen NOW' So AM changes the window buffer and OSX updates the window at some point where system events are being processed. I haven't addressed the issue because one of the areas I really want to redo things involves the management of the buffers AM draws into. A display module if you will, that on the platform specific side could do things like 'use this window's back buffer' or 'Go full screen (and use the DisplaySprocket unbuffered buffers)' In other words, I didn't want to sprinkle random OSX-only polishing QDFlushBuffer calls throughout the code when what I really want is to abstract buffer management and kill the abysmal and unreasonable framerates we're getting. Especially since the game really is rendering more frames per second than is showing up on the screen. -Jeremy Parsons On Monday, January 13, 2003, at 07:13 PM, Woody Zenfell, III wrote: > Actually it's almost exactly the opposite - a screen (like the main > menu) fades out when you click something, then fades back in while it > plays the "thunder"y sound for the chapter screen, say. Then as soon > as the fade reaches 100% brightness, it suddenly "pops" to show the > chapter screen. IIRC the chapter screen may pop back again at 100% > brightness after it fades out but before the game proper starts. > > Something similar happens when you click "replay saved film". > > iceBook 500MHz, 384MB RAM, Mac OS X 10.1.5 here. > > Woody > > On Monday, January 13, 2003, at 06:02 PM, Matt Lee wrote: > >>> Oh, and I noticed that same fading problem that Woody mentioned, >>> when fading either to or from the menu. >> >> Is that the one in which it "cuts" over to the new image immediately, >> then fades up from black? I have that too, on all the chapter screens >> and such. > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: FREE SSL Guide from Thawte > are you planning your Web Server Security? Click here to get a FREE > Thawte SSL guide and find the answers to all your SSL security issues. > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en > _______________________________________________ > Alephmodular-devel mailing list > Ale...@li... > https://lists.sourceforge.net/lists/listinfo/alephmodular-devel > |
|
From: Woody Z. I. <woo...@sb...> - 2003-01-14 02:18:08
|
On Monday, January 13, 2003, at 06:29 PM, Br'fin wrote: > It's all part of the same problem. AM doesn't yet have any code to tell > OSX 'Update the screen NOW' So AM changes the window buffer and OSX > updates the window at some point where system events are being > processed. Aha, so when AM is busy horking the processor continuously in hi-res mode for its rendering, the system hardly ever gets to step in and blit results to the screen. (Does lo-res drawing somehow bypass this mechanism? It seems to not suffer from this restriction, and also tends to "tear", both of which suggest that it might?) > I haven't addressed the issue because one of the areas I really want to > redo things involves the management of the buffers AM draws into. A > display module if you will, that on the platform specific side could do > things like 'use this window's back buffer' or 'Go full screen (and use > the DisplaySprocket unbuffered buffers)' Ah but surely you mean (by telling SDL to SetVideoMode to a full-screen mode with page-flipping), or something like that. ;) > In other words, I didn't want to sprinkle random OSX-only polishing > QDFlushBuffer calls throughout the code when what I really want is to > abstract buffer management and kill the abysmal and unreasonable > framerates we're getting. Especially since the game really is rendering > more frames per second than is showing up on the screen. Makes sense. Woody |
|
From: Br'fin <br...@ma...> - 2003-01-14 03:13:12
|
On Monday, January 13, 2003, at 09:17 PM, Woody Zenfell, III wrote: > On Monday, January 13, 2003, at 06:29 PM, Br'fin wrote: > >> It's all part of the same problem. AM doesn't yet have any code to >> tell OSX 'Update the screen NOW' So AM changes the window buffer and >> OSX updates the window at some point where system events are being >> processed. > > Aha, so when AM is busy horking the processor continuously in hi-res > mode for its rendering, the system hardly ever gets to step in and > blit results to the screen. (Does lo-res drawing somehow bypass this > mechanism? It seems to not suffer from this restriction, and also > tends to "tear", both of which suggest that it might?) lo-res doesn't bypass it. But by being less strain on the processer (render postage stamp, then custom blit to window buffer) instead of (render 640x480, then copy to window buffer) the window server just might get more chances. By tear, if you mean white bite occasionally between polygons, I see some of that even in high rez, might just be more noticable in low res since the resolution is so much less and white spots become more noticable. >> I haven't addressed the issue because one of the areas I really want >> to redo things involves the management of the buffers AM draws into. >> A display module if you will, that on the platform specific side >> could do things like 'use this window's back buffer' or 'Go full >> screen (and use the DisplaySprocket unbuffered buffers)' > > Ah but surely you mean (by telling SDL to SetVideoMode to a > full-screen mode with page-flipping), or something like that. ;) That is certainly the SDL implementation of the display module. I honestly can't be as harsh on SDL as a generic display library as opposed to a generalrized UI element. I don't know Windows' API here, or SDL's, or even OSX's. On the other hand, treating SDL as a separate platform helps keep the display module's interface cleaner with fewer includes across everything.(ADisplayModule.h doesn't #include SDL, but the file that implements the SDL functionality for ADisplayModule.h can include whatever SDL headers it wants) -Jeremy Parsons |
|
From: Woody Z. I. <woo...@sb...> - 2003-01-14 04:00:44
|
On Monday, January 13, 2003, at 09:13 PM, Br'fin wrote: > lo-res doesn't bypass it. But by being less strain on the processer > (render postage stamp, then custom blit to window buffer) instead of > (render 640x480, then copy to window buffer) the window server just > might get more chances. By tear, if you mean white bite occasionally > between polygons, I see some of that even in high rez, might just be > more noticable in low res since the resolution is so much less and > white spots become more noticable. By 'tear', I mean that some parts of the window are updated to a new frame during one display refresh, and others are updated during the next refresh, so what are effectively vertical lines that appear in different places in consecutive frames end up looking like disjointed segments. I guess if there's no bypass, it must just be that the tearing is more noticeable at the higher frame rate. >> Ah but surely you mean (by telling SDL to SetVideoMode to a >> full-screen mode with page-flipping), or something like that. ;) > > That is certainly the SDL implementation of the display module. > > I honestly can't be as harsh on SDL as a generic display library as > opposed to a generalrized UI element. I don't know Windows' API here, > or SDL's, or even OSX's. > > On the other hand, treating SDL as a separate platform helps keep the > display module's interface cleaner with fewer includes across > everything.(ADisplayModule.h doesn't #include SDL, but the file that > implements the SDL functionality for ADisplayModule.h can include > whatever SDL headers it wants) I have no problem with hiding SDL details from the game's interface to its facilities. But I hope that AM will take a different course from A1, and will write its implementations in SDL rather than Mac OS, sparing the Mac OS-specific code for when it's absolutely needed. This way we have much more common code. I assume when you're referring to SDL as a "UI element" that you mean the custom UI widgets library that Christian Bauer wrote for A1 and that I extended to have some additional capabilities. Agreed, Aqua is better. :) But I think we (I should primarily credit Christian) did at least adequately for a "baseline", works-everywhere system. Anyway basically I'm saying, don't think of Mac as one platform and SDL as another platform. SDL is the generic baseline target, and works on all platforms, including Mac OS X and Mac OS 9 as well as Solaris, Linux, Windows, Dreamcast, etc. There are Mac OS-specific routines to present the UI with Aqua (or Platinum Appearance, under 9) rather than our little widgets, just as there may eventually be Win32-specific routines to present a Windows UI rather than the little widgets. (Though code to get/set control values, enable/disable controls, respond to control clicks, etc. is shared, at a higher level than this UI presentation layer - a lot of this work is already done in A1 as well, at least in the netgame dialogs.) But sound playback is handled on all platforms by SDL (or SDL_mixer atop SDL). So you don't have Sound Manager code in there. (Though you might eventually have, say, DirectSound3D code as an alternative to the SDL base, so that Windows users get 3D positional audio.) Please think about it. A lot of the work is already done (in the A1 project). We can finally end this "I write/debug everything twice!" business, and things like network audio playback will work the same way on all platforms (unlike the current situation). I mean I guess you could retain the non-SDL Mac stuff for a while as a sort of "reference implementation", since that code's also already written in most cases, but the real movement should be toward SDL-based, Mac-polished code instead, letting the non-SDL Mac stuff rot (and slicing it away when it does, leaving a cleaner, simpler product that's easier to maintain and friendlier for new developments). Woody |
|
From: Br'fin <br...@ma...> - 2003-01-14 04:59:12
|
On Monday, January 13, 2003, at 11:00 PM, Woody Zenfell, III wrote: > > On Monday, January 13, 2003, at 09:13 PM, Br'fin wrote: > >> lo-res doesn't bypass it. But by being less strain on the processer >> (render postage stamp, then custom blit to window buffer) instead of >> (render 640x480, then copy to window buffer) the window server just >> might get more chances. By tear, if you mean white bite occasionally >> between polygons, I see some of that even in high rez, might just be >> more noticable in low res since the resolution is so much less and >> white spots become more noticable. > > By 'tear', I mean that some parts of the window are updated to a new > frame during one display refresh, and others are updated during the > next refresh, so what are effectively vertical lines that appear in > different places in consecutive frames end up looking like disjointed > segments. I guess if there's no bypass, it must just be that the > tearing is more noticeable at the higher frame rate. Ah, gotcha. Certainly a possibility. No one's making any attempt to sync rendering and updates to when OSX actually gets around to updating the visible window from it's buffer :) >> On the other hand, treating SDL as a separate platform helps keep the >> display module's interface cleaner with fewer includes across >> everything.(ADisplayModule.h doesn't #include SDL, but the file that >> implements the SDL functionality for ADisplayModule.h can include >> whatever SDL headers it wants) > > I have no problem with hiding SDL details from the game's interface to > its facilities. But I hope that AM will take a different course from > A1, and will write its implementations in SDL rather than Mac OS, > sparing the Mac OS-specific code for when it's absolutely needed. > This way we have much more common code. Hard to say. Then again my own impression involves pushing both MacOS AND SDL code out to where and when they are absolutely needed. We're already using our own definitions for int32 for instance. > I assume when you're referring to SDL as a "UI element" that you mean > the custom UI widgets library that Christian Bauer wrote for A1 and > that I extended to have some additional capabilities. Agreed, Aqua is > better. :) But I think we (I should primarily credit Christian) did > at least adequately for a "baseline", works-everywhere system. Actually, I was referring to the prior argument on UIs and widgets. Not to "SDL as a UI Element" My overall feeling is. SDL vs MacOSX for displays: Situation hazy MacOSX & platform specific vs Cross-platform GUI: Prove the Cross-platform GUI > I mean I guess you could retain the non-SDL Mac stuff for a while as a > sort of "reference implementation", since that code's also already > written in most cases, but the real movement should be toward > SDL-based, Mac-polished code instead, letting the non-SDL Mac stuff > rot (and slicing it away when it does, leaving a cleaner, simpler > product that's easier to maintain and friendlier for new > developments). A good argument and more compelling than the cross-platform UI. I admit I'm hesitant with some of the issues of outright including SDL as the baseline. Part of it is that I'm unfamiliar with it as a library. Part of it is displeasure with some of how it meshed with things in A1 and some of how it meshes with another project I worked on. For Bochs there's a way to compile with both Carbon and SDL support. And then the GUIs can be treated as plugins with a preference in a config file letting you specify one or the other. However, just by compiling SDL in, it's init code supercedes the normal main. And whenever I use the carbon UI, portions of my application menu is lobotomized (Pretty much missing almost all contents that should be there, like the hide this or other app menu items) This isn't so bad within the game proper. But could be awkward for someone trying to mesh a smaller piece into an editor. My impression of SDL in a nut shell? A good idea, but it doesn't seem to play well with others. I certainly support it as a desirable platform for AM. I don't know if I want to support it as THE Platform for AM. I also don't consider MacOS X The Platform for AM either. It's just a platform that I really don't want to break things on :) -Jeremy Parsons |
|
From: Woody Z. I. <woo...@sb...> - 2003-01-21 01:03:35
|
On Monday, January 13, 2003, at 08:17 PM, Woody Zenfell, III wrote: > Aha, so when AM is busy horking the processor continuously in hi-res > mode for its rendering, the system hardly ever gets to step in and blit > results to the screen. (Does lo-res drawing somehow bypass this > mechanism? It seems to not suffer from this restriction, and also > tends to "tear", both of which suggest that it might?) From: "Br'fin" <br...@ma...> Date: Mon Jan 20, 2003 05:04:30 PM US/Central > I think I found part of why low-resolution mode is so speedy. I was > preparing a build for the a 0.3 preview release. And I happened to have > it compiling then running in the background. Well it's running, I have > low-resolution turned on, and suddenly it starts overwriting my > foreground windows when AM kicks into demo mode. > > Apparently the low-res code doesn't do a copy from back buffer to > foreground window, it's setup to copy directly to the *screen* Glad an explanation materialized. But you're right, AM should do things "by the rules". Woody |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X