alephmodular-devel — AlephModular Developers Mailing List

Re: [Alephmodular-devel] Kiosk mode

[Br'fin <br...@ma...>]

On Sunday, March 16, 2003, at 01:05  PM, Mark Levin wrote:

>>> OmniGroup only does Cocoa; it's nice, but I wouldn't recommend it 
>>> for games.
>>>
>> Their ports seem to be doing well. And there's still things from the 
>> paper that I could potentially apply just in terms of overall API 
>> usage and the like.
>>
>> -Jeremy Parsons
>
> Their ports do well on Mac OS X, but Alex is correct that it's not 
> really suited for cross-platform games.
>
> Plus, to use it in AM we'd have to use Apple's Objective-C++ compiler, 
> which is (from what I hear) slow and buggy.

Heh, I am *not* planning on introducing any Object-C/C++ style things 
into AM. But the paper does have good ideas and/or adaptable ideas that 
still apply. Even in a Carbon type environment.

It was from their white paper that I picked up on some of the 
CoreGraphics routines. Such as CGGetLastMouseDelta(&deltax, &deltay) 
after receiving notification that the mouse has been moved or dragged.

The discussions of certain cocoa specifics may note apply, but other 
OSX strategies do as they make use of Core-level API-stuff. The most 
notable of stuff there that hasn't been applied that I'm aware of 
involves mouse-scaling settings.

... Then again, maybe I should reread it as it has some examples for 
dealing with Core Graphics display handling stuff too.

Alas, this is mostly a series of slides that accompanied a 
presentation, so I tend to look up the more information elsewhere too.

-Jeremy Parsons

Re: [Alephmodular-devel] Kiosk mode

[Alexander S. <ast...@it...>]

On Sunday, March 16, 2003, at 01:05  PM, Mark Levin wrote:
> Plus, to use it in AM we'd have to use Apple's Objective-C++ compiler, 
> which is (from what I hear) slow and buggy.
>
> --Mark

The Objective-C++ compiler *is* the C++ compiler, which we're already 
using. This isn't to say it's not slow and buggy :)

Re: [Alephmodular-devel] Kiosk mode

[Mark L. <hav...@ma...>]

>>> And other notes, like Omni's paper on porting games to OSX 
>>> (typically with Cocoa) seemed to indicate no such ability at all to 
>>> disable Cmd-Tab.
>>
>> OmniGroup only does Cocoa; it's nice, but I wouldn't recommend it for 
>> games.
>>
> Their ports seem to be doing well. And there's still things from the 
> paper that I could potentially apply just in terms of overall API 
> usage and the like.
>
> -Jeremy Parsons

Their ports do well on Mac OS X, but Alex is correct that it's not 
really suited for cross-platform games.

Plus, to use it in AM we'd have to use Apple's Objective-C++ compiler, 
which is (from what I hear) slow and buggy.

--Mark

"I would feel infinitely more comfortable in your presence if you would 
agree to treat gravity as a law, rather than one of a number of 
suggested options."

Random acts of programming: http://homepage.mac.com/haveblue

Re: [Alephmodular-devel] Kiosk mode

[Br'fin <br...@ma...>]

On Sunday, March 16, 2003, at 12:52  AM, Alexander Strange wrote:

>
> On Saturday, March 15, 2003, at 10:51  PM, Br'fin wrote:
>> And while good and useful, the SystemUIMode API only seems to apply 
>> to 10.2. So at some point I'll try and see about mastering 
>> weaking-linking and OSX.
>
> Weak-linking also only applies to 10.2.

The document that talks about weak-linking also talks about other 
features you can use to be able to use some 10.2 features while 
skipping them and running without them on 10.1.x

Ensuring Backwards Binary Compatibility - Weak Linking and Availability 
Macros on Mac OS X
http://developer.apple.com/technotes/tn2002/tn2064.html


>> And other notes, like Omni's paper on porting games to OSX (typically 
>> with Cocoa) seemed to indicate no such ability at all to disable 
>> Cmd-Tab.
>
> OmniGroup only does Cocoa; it's nice, but I wouldn't recommend it for 
> games.
>
Their ports seem to be doing well. And there's still things from the 
paper that I could potentially apply just in terms of overall API usage 
and the like.

-Jeremy Parsons

Re: [Alephmodular-devel] Kiosk mode

[Alexander S. <ast...@it...>]

On Saturday, March 15, 2003, at 10:51  PM, Br'fin wrote:
> And while good and useful, the SystemUIMode API only seems to apply to 
> 10.2. So at some point I'll try and see about mastering 
> weaking-linking and OSX.

Weak-linking also only applies to 10.2.

> And other notes, like Omni's paper on porting games to OSX (typically 
> with Cocoa) seemed to indicate no such ability at all to disable 
> Cmd-Tab.

OmniGroup only does Cocoa; it's nice, but I wouldn't recommend it for 
games.

Re: [Alephmodular-devel] Kiosk mode

[Br'fin <br...@ma...>]

On Saturday, March 15, 2003, at 10:25  PM, Mark Levin wrote:

>
> On Saturday, March 15, 2003, at 03:02  PM, Br'fin wrote:
>
>> Hmm, what 'system' should be responsible for Kiosk mode?
>>
>> Kiosk mode being a mode (typically used while fullscreen is active) 
>> where the ability to switch processes is disabled. For instance, on 
>> MacOS X 10.2 this would entail disabling Cmd-Tab to switch process 
>> and Cmd-` to switch windows.
>>
>> On one hand it's only kicked in during fullscreen mode, on the other 
>> it affects system behaviour without being directl tied to display 
>> mode. Hsm
>>
>> -Jeremy Parsons
>
> OS X automatically disabled command-tab when a display capture is 
> performed (using CoreGraphics), so this would be a "free" side effect 
> of AM's classes supporting fullscreen mode. I can only assume that 
> Aleph One currently doesn't do this "properly", so cmd-tab is still 
> active.
>
> --Mark
>

Actually, I'm trying to find a reference to that effect. I've heard it 
before but I haven't seen it documented. When I actually went looking 
for disabling cmd-tab I found this tech note:
TN2062 - Guide to Creating Kiosks on Mac OS
http://developer.apple.com/technotes/tn2002/tn2062.html

And while good and useful, the SystemUIMode API only seems to apply to 
10.2. So at some point I'll try and see about mastering weaking-linking 
and OSX.

And other notes, like Omni's paper on porting games to OSX (typically 
with Cocoa) seemed to indicate no such ability at all to disable 
Cmd-Tab.

AO appears to use a neat little set of DisplayManager related classes, 
but still uses screen_window and backdrop window for the actual display 
of things.

AM at best seemed to luck out and have existing classic code still 
capable of doing depth switches, but which drops the ball on resolution 
switches. But itself still has the screen_window and backdrop_window. 
(Though in my current branch few things directly know about 
screen_window anymore)

-Jeremy Parsons

Re: [Alephmodular-devel] Kiosk mode

[Mark L. <hav...@ma...>]

On Saturday, March 15, 2003, at 03:02  PM, Br'fin wrote:

> Hmm, what 'system' should be responsible for Kiosk mode?
>
> Kiosk mode being a mode (typically used while fullscreen is active) 
> where the ability to switch processes is disabled. For instance, on 
> MacOS X 10.2 this would entail disabling Cmd-Tab to switch process and 
> Cmd-` to switch windows.
>
> On one hand it's only kicked in during fullscreen mode, on the other 
> it affects system behaviour without being directl tied to display 
> mode. Hsm
>
> -Jeremy Parsons

OS X automatically disabled command-tab when a display capture is 
performed (using CoreGraphics), so this would be a "free" side effect 
of AM's classes supporting fullscreen mode. I can only assume that 
Aleph One currently doesn't do this "properly", so cmd-tab is still 
active.

--Mark

"If you're going to break the eggs, make the damn omlette."

Random acts of programming: http://homepage.mac.com/haveblue

[Alephmodular-devel] Kiosk mode

[Br'fin <br...@ma...>]

Hmm, what 'system' should be responsible for Kiosk mode?

Kiosk mode being a mode (typically used while fullscreen is active) 
where the ability to switch processes is disabled. For instance, on 
MacOS X 10.2 this would entail disabling Cmd-Tab to switch process and 
Cmd-` to switch windows.

On one hand it's only kicked in during fullscreen mode, on the other it 
affects system behaviour without being directl tied to display mode. Hsm

-Jeremy Parsons

[Alephmodular-devel] Re: [M-dev]Warnings Patch

[Br'fin <br...@ma...>]

I was updating and recompiling my code. And personally I found these 
warnings disconcerting. Perhaps more so than the original warnings :)

-Jeremy Parsons

../Source_Files/ModelView/Model3D.cpp: In member function `bool 
Model3D::FindPositions_Frame(bool, short int, float, short int)':
../Source_Files/ModelView/Model3D.cpp:722: warning: initialization of 
negative value `NONE' to `size_t'
../Source_Files/ModelView/Model3D.cpp:722: warning: argument of 
negative value `NONE' to `long unsigned int'
../Source_Files/ModelView/Model3D.cpp:734: warning: assignment of 
negative value `NONE' to `size_t'
../Source_Files/ModelView/Model3D.cpp:734: warning: argument of 
negative value `NONE' to `long unsigned int'
../Source_Files/ModelView/Model3D.cpp:743: warning: comparison between 
signed and unsigned integer expressions
	../Source_Files/ModelView/Model3D.cpp:722: warning: initialization of 
negative value `NONE' to `size_t'
	../Source_Files/ModelView/Model3D.cpp:722: warning: argument of 
negative value `NONE' to `long unsigned int'
	../Source_Files/ModelView/Model3D.cpp:734: warning: assignment of 
negative value `NONE' to `size_t'
	../Source_Files/ModelView/Model3D.cpp:734: warning: argument of 
negative value `NONE' to `long unsigned int'
	../Source_Files/ModelView/Model3D.cpp:743: warning: comparison between 
signed and unsigned integer expressions

../Source_Files/ModelView/Dim3_Loader.cpp:237: warning: initialization 
of negative value `-1' to `size_t'
../Source_Files/ModelView/Dim3_Loader.cpp:237: warning: argument of 
negative value `-1' to `long unsigned int'
../Source_Files/ModelView/Dim3_Loader.cpp:242: warning: initialization 
of negative value `-1' to `size_t'
../Source_Files/ModelView/Dim3_Loader.cpp:242: warning: argument of 
negative value `-1' to `long unsigned int'
../Source_Files/ModelView/Dim3_Loader.cpp:297: warning: assignment of 
negative value `-1' to `size_t'
../Source_Files/ModelView/Dim3_Loader.cpp:297: warning: argument of 
negative value `-1' to `long unsigned int'
../Source_Files/ModelView/Dim3_Loader.cpp:998: warning: assignment of 
negative value `NONE' to `size_t'
../Source_Files/ModelView/Dim3_Loader.cpp:998: warning: argument of 
negative value `NONE' to `long unsigned int'

[Alephmodular-devel] CDisplay setup

[Br'fin <br...@ma...>]

I'm strongly considering a setup where a CDisplay is 
initialized/changed via a CDisplayInfo class. A class with all the raw 
info about a display. For instance:
	Bit depth
	Dimensions
	Window vs FullScreen
	TopLeft offset (0, 0 for fullscreen, window position for a window)
	Hardware acceleration
	Screen

Screen might not ignored if we're windowed. Fades should be limited to 
that screen only. Though for a window that might be updated on the fly 
for which screen the window is deemed to be on. :)

At any rate, this information isn't so important for being stored like 
this within CDisplay. Instead, it's important for setting up the 
CDisplay, getting information from it and updating it.

Thoughts, comments, alternatives? This is along the lines of the GDspec 
in the current code.

-Jeremy Parsons

Re: [Alephmodular-devel] Drawsprockets?

[Br'fin <br...@ma...>]

*Laugh* What a splendid concept.

Seems a couple Carbon calls...
Some corresponding application services calls, also with carbon apis
And a whole bunch of CGDirectDisplay and CGDirectPalette APIs also in 
application services.

-Jeremy Parsons

On Tuesday, March 11, 2003, at 04:22  PM, Alexander Strange wrote:

>
> On Tuesday, March 11, 2003, at 01:57  AM, Br'fin wrote:
>
>> Is there yet a more appropriate API than DrawSprockets for going 
>> right to the display hardware of MacOS X? Right now CDisplay is very 
>> centered towards the way AlephModular currently uses a single back 
>> buffer that is always getting copied forward (A window back buffer 
>> and appropriate flush to display calls) I'm sure this will turn up 
>> cases of flicker (Places where info needs to be updated on both 
>> buffers not getting updated properly) Hooking it up with 
>> DisplaySprokects should help flush out those areas in need of 
>> improvement. But I really don't know if DrawSprockets is the Apple 
>> recommended way of going about this anymore.
>>
>> -Jeremy Parsons
>
> Well, I assume a "more appropriate" API would be whatever 
> DrawSprockets uses.
> Run 'otool -LHV 
> /System/Library/Frameworks/DrawSprocket.framework/DrawSprocket' and 
> see.

Re: [Alephmodular-devel] Drawsprockets?

[Alexander S. <ast...@it...>]

On Tuesday, March 11, 2003, at 01:57  AM, Br'fin wrote:

> Is there yet a more appropriate API than DrawSprockets for going right 
> to the display hardware of MacOS X? Right now CDisplay is very 
> centered towards the way AlephModular currently uses a single back 
> buffer that is always getting copied forward (A window back buffer and 
> appropriate flush to display calls) I'm sure this will turn up cases 
> of flicker (Places where info needs to be updated on both buffers not 
> getting updated properly) Hooking it up with DisplaySprokects should 
> help flush out those areas in need of improvement. But I really don't 
> know if DrawSprockets is the Apple recommended way of going about this 
> anymore.
>
> -Jeremy Parsons

Well, I assume a "more appropriate" API would be whatever DrawSprockets 
uses.
Run 'otool -LHV 
/System/Library/Frameworks/DrawSprocket.framework/DrawSprocket' and see.

Re: [Alephmodular-devel] Drawsprockets?

[Br'fin <br...@ma...>]

On Tuesday, March 11, 2003, at 10:45  AM, Woody Zenfell, III wrote:
>> Right, the current environment is not page-flipped. But I don't know 
>> how DrawSprockets or SDL or Windows handles fast screen updates. 
>> DrawSprockets appears to use concepts of fore and back buffers with a 
>> swap command. CGDirectDisplay actually seems to act like the classic 
>> Mac-way of handling fast screen updates, go figure. :)
>
> Are there really any alternatives (that protect us from flashing and 
> tearing) to render-offscreen-then-blit and render-offscreen-then-flip? 
>  (I assume the former is what you're calling the classic Mac-way.)  
> Well ok if your application were really carefully timed and quick to 
> render, I guess you could render straight to the screen when the 
> raster's not looking, but in practice that's going to be quite a pain 
> I think?

AlephModular does not currently hit either time point... careful timing 
or amazing speed rendering... I've set it to draw directly to the 
screen before. IT hurts your eyes and everything about the display 
flickers differently (walls and floors and then things flickering over 
already drawn areas :))

> FWIW, IIRC SDL and DirectDraw both use page-flipping if possible, and 
> emulate a flip() with a blit if flipping is not available.  I think.  
> Of course you can find out which is actually going to happen by 
> querying capabilities and examining flags etc.

That was the sort of target I was aiming for in my API. Aim for the 
flip and otherwise setup for the blip. Since the overall syntax follows 
the same flow... draw to this buffer and then tell it you're done :)


>> If any one of those environments is page-flipped, then I bet that I 
>> will find some flicker problems. Most notable around the HUD which 
>> has classically been drawn to the screen_window instead of using the 
>> world_pixels that actual rendering used.
>
> Agreed the HUD is going to be the main concern in a flipping 
> environment.  Well, and the GUI (dialogs etc.).  Terminals might be an 
> issue I guess but also very well may not; IIRC they tend to redraw the 
> entire terminal area on each update (even if updates only come once 
> per terminal page instead of at 30fps or whatever).

Terminals would still need to be setup to both buffers. Kind of amusing 
when you turn FPS on and the terminal is only drawn once, but other 
updates may occur. So it keeps drawing and redrawing the fps in the one 
corner, repeatedly overwriting itself :)

> So I assume currently world_pixels is typically a ClippingBuffer of 
> the offscreen buffer, and HUD updates etc. are rendered into another 
> part of this bigger offscreen buffer (ah, probably via another 
> ClippingBuffer, yes I am seeing it), and once per frame either the 
> world_pixels rect or the entire drawable area's rect (depending on 
> whether the HUD updated) is blitted ("flushed") to the front buffer?

That's fairly correct. I still need to work through the path that HUD 
updates are done in, but as of my update, both rendering and HUD are 
now drawn into the same buffer. And only one update needs to be flushed 
forward. The biggest issue right now is that HUD updates don't occur at 
the same time that the world is rendered in. So there's a very mild 
tear when you switch from full_screen to the 100% window (that is you 
toggle the HUD from being off to on) ... you have your 100% rendered 
view, then you have the remnant of the full_screen rendering and then 
the HUD appears in all its glory.

I am trying to emulate the page-flipping mode, so currently flushing is 
only clipped to the general drawing area. (That is, all of my current 
flushes cover the entire 640x480 space used for drawing) No attempts 
are made to handle dirty rectangles or the like. Though I may wish to 
make sure both fades and flushes are VBL synced.

-Jeremy Parsons

Re: [Alephmodular-devel] Drawsprockets?

[Woody Z. I. <woo...@sb...>]

On Tuesday, March 11, 2003, at 09:11  AM, Br'fin wrote:

> On Tuesday, March 11, 2003, at 09:57  AM, Woody Zenfell, III wrote:
>
>> On Tuesday, March 11, 2003, at 12:57  AM, Br'fin wrote:
>>
>>> ... AlephModular currently uses a single back buffer that is always 
>>> getting copied forward (A window back buffer and appropriate flush to 
>>> display calls) I'm sure this will turn up cases of flicker (Places 
>>> where info needs to be updated on both buffers not getting updated 
>>> properly) ...
>>
>> Maybe it's because I just got up, but I don't see how this scheme 
>> could result in flicker?  ...
>
> Right, the current environment is not page-flipped. But I don't know 
> how DrawSprockets or SDL or Windows handles fast screen updates. 
> DrawSprockets appears to use concepts of fore and back buffers with a 
> swap command. CGDirectDisplay actually seems to act like the classic 
> Mac-way of handling fast screen updates, go figure. :)

Are there really any alternatives (that protect us from flashing and 
tearing) to render-offscreen-then-blit and render-offscreen-then-flip?  
(I assume the former is what you're calling the classic Mac-way.)  Well 
ok if your application were really carefully timed and quick to render, 
I guess you could render straight to the screen when the raster's not 
looking, but in practice that's going to be quite a pain I think?

FWIW, IIRC SDL and DirectDraw both use page-flipping if possible, and 
emulate a flip() with a blit if flipping is not available.  I think.  Of 
course you can find out which is actually going to happen by querying 
capabilities and examining flags etc.

> If any one of those environments is page-flipped, then I bet that I 
> will find some flicker problems. Most notable around the HUD which has 
> classically been drawn to the screen_window instead of using the 
> world_pixels that actual rendering used.

Agreed the HUD is going to be the main concern in a flipping 
environment.  Well, and the GUI (dialogs etc.).  Terminals might be an 
issue I guess but also very well may not; IIRC they tend to redraw the 
entire terminal area on each update (even if updates only come once per 
terminal page instead of at 30fps or whatever).

So I assume currently world_pixels is typically a ClippingBuffer of the 
offscreen buffer, and HUD updates etc. are rendered into another part of 
this bigger offscreen buffer (ah, probably via another ClippingBuffer, 
yes I am seeing it), and once per frame either the world_pixels rect or 
the entire drawable area's rect (depending on whether the HUD updated) 
is blitted ("flushed") to the front buffer?  Hmm no that last bit isn't 
exactly right, what if the player is reading a terminal and gets hurt?  
His HUD needs to update even though his world_pixels didn't.  I guess 
then any of the four combinations of world_pixels and hud_pixels (or 
whatever) could be "flushed" in a given iteration.  How do you keep 
track of which combination needs to be flushed?  Dirty flags?  Or do 
they flush separately, immediately after rendering finishes in one of 
them?  It seems this latter strategy could either result in tearing (if 
the "flush" logic doesn't wait for a time when the raster's not looking) 
or excessive waiting (if it has to wait for the raster once to flush the 
world_pixels, then wait again before it can flush the hud_pixels).  
Maybe.  Depending on how the flush actually works.  Hmm maybe the flush 
routine doesn't really do the flush, but updates a dirty-rectangles list 
for the next raster-safe time.  Oh no, that wouldn't work because then 
you could potentially draw into the back buffer too soon, hmm, unless 
blitting to and locking the back buffer wait for the flush before they 
can start.

BTW random off-topic but related question: anyone know how the concepts 
of raster and refresh rate apply (or don't) on flat-panel displays like 
TFT, plasma, etc.?

Woody

Re: [Alephmodular-devel] Drawsprockets?

[Br'fin <br...@ma...>]

On Tuesday, March 11, 2003, at 09:57  AM, Woody Zenfell, III wrote:

> On Tuesday, March 11, 2003, at 12:57  AM, Br'fin wrote:
>
>> Is there yet a more appropriate API than DrawSprockets for going 
>> right to the display hardware of MacOS X? Right now CDisplay is very 
>> centered towards the way AlephModular currently uses a single back 
>> buffer that is always getting copied forward (A window back buffer 
>> and appropriate flush to display calls) I'm sure this will turn up 
>> cases of flicker (Places where info needs to be updated on both 
>> buffers not getting updated properly) Hooking it up with 
>> DisplaySprokects should help flush out those areas in need of 
>> improvement. But I really don't know if DrawSprockets is the Apple 
>> recommended way of going about this anymore.
>
> Maybe it's because I just got up, but I don't see how this scheme 
> could result in flicker?  There's a strict hierarchy of the back 
> (offscreen) buffer receiving every update from the program and the 
> front (onscreen/frame-) buffer getting copies of the back buffer... so 
> every back buffer you render in has the very most recent rendering 
> changes you've made, no problems.
>
> Now in a page-flipping environment, where you render to the back 
> buffer and then flip it to the front, making the old front buffer your 
> new back buffer, well your new back buffer doesn't have whatever 
> changes you just flipped to the front, and if you don't render the 
> changes again to your new back buffer, those elements will flicker 
> back and forth every time you flip from now on.

Right, the current environment is not page-flipped. But I don't know 
how DrawSprockets or SDL or Windows handles fast screen updates. 
DrawSprockets appears to use concepts of fore and back buffers with a 
swap command. CGDirectDisplay actually seems to act like the classic 
Mac-way of handling fast screen updates, go figure. :)

If any one of those environments is page-flipped, then I bet that I 
will find some flicker problems. Most notable around the HUD which has 
classically been drawn to the screen_window instead of using the 
world_pixels that actual rendering used.

> FWIW my suggestion (not terribly clever, but it should work) for 
> correctly doing occasional updates to nonmoving screen elements (like, 
> the whole oxygen display etc.) in a page-flipping environment is to 
> use a dirty count (set to 2 in a double-buffered page-flipping scheme, 
> decremented once per drawn frame) instead of a dirty flag, so you 
> redraw the element once per buffer before it's clean.  Forcing a draw 
> (e.g. update_interface(NONE), right?) would have to set and use the 
> dirty count also to make sure the forced draw goes into every buffer.
>
> Right?

I certainly agree with the concept of a dirty count.  And I do think 
you're right.

-Jeremy Parsons

Re: [Alephmodular-devel] Drawsprockets?

[Woody Z. I. <woo...@sb...>]

On Tuesday, March 11, 2003, at 12:57  AM, Br'fin wrote:

> Is there yet a more appropriate API than DrawSprockets for going right 
> to the display hardware of MacOS X? Right now CDisplay is very centered 
> towards the way AlephModular currently uses a single back buffer that 
> is always getting copied forward (A window back buffer and appropriate 
> flush to display calls) I'm sure this will turn up cases of flicker 
> (Places where info needs to be updated on both buffers not getting 
> updated properly) Hooking it up with DisplaySprokects should help flush 
> out those areas in need of improvement. But I really don't know if 
> DrawSprockets is the Apple recommended way of going about this anymore.

Maybe it's because I just got up, but I don't see how this scheme could 
result in flicker?  There's a strict hierarchy of the back (offscreen) 
buffer receiving every update from the program and the front 
(onscreen/frame-) buffer getting copies of the back buffer... so every 
back buffer you render in has the very most recent rendering changes 
you've made, no problems.

Now in a page-flipping environment, where you render to the back buffer 
and then flip it to the front, making the old front buffer your new back 
buffer, well your new back buffer doesn't have whatever changes you just 
flipped to the front, and if you don't render the changes again to your 
new back buffer, those elements will flicker back and forth every time 
you flip from now on.

(Of course, page-flipping is probably preferable in most cases, because 
flipping the buffers is much less expensive than blitting the back to 
front - and of course you're making that savings every frame.  OTOH it 
does introduce potential flicker problems with areas that are not either 
completely redrawn every frame or completely static, and it's almost 
certainly not an option in a windowed mode.)

FWIW my suggestion (not terribly clever, but it should work) for 
correctly doing occasional updates to nonmoving screen elements (like, 
the whole oxygen display etc.) in a page-flipping environment is to use 
a dirty count (set to 2 in a double-buffered page-flipping scheme, 
decremented once per drawn frame) instead of a dirty flag, so you redraw 
the element once per buffer before it's clean.  Forcing a draw (e.g. 
update_interface(NONE), right?) would have to set and use the dirty 
count also to make sure the forced draw goes into every buffer.

Right?

Woody

Re: [Alephmodular-devel] Drawsprockets?

[Br'fin <br...@ma...>]

My own understanding is that yes, GameSprockets on a whole are out. 
Full GameSprocket support is only available under classic mode. 
DrawSprockets itself is hamstrung, but still seems to be the primary 
API for direct framebuffer support. It's provided as a OSX Framework on 
its own.

Hsm, looks like some of the functionality is handled by 
CGDirectDisplay. And that API may need to be leveraged if we ever want 
to fix the handling of multiple monitors.

Let's see...

... finding a display for specified screen size
... determining which screen you're working with
... setting a screen palette

Hsm, isn't that interest, basic usage tends to be to work in your own 
offscreen world, then use copybits to a port obtained from the screen's 
address. So very classic Mac-like I guess. :)

-Jeremy Parsons

On Tuesday, March 11, 2003, at 08:08  AM, Timothy Collett wrote:

>> Is there yet a more appropriate API than DrawSprockets for going 
>> right to the display hardware of MacOS X? Right now CDisplay is very 
>> centered towards the way AlephModular currently uses a single back 
>> buffer that is always getting copied forward (A window back buffer 
>> and appropriate flush to display calls) I'm sure this will turn up 
>> cases of flicker (Places where info needs to be updated on both 
>> buffers not getting updated properly) Hooking it up with 
>> DisplaySprokects should help flush out those areas in need of 
>> improvement. But I really don't know if DrawSprockets is the Apple 
>> recommended way of going about this anymore.
>>
>
>
> From what I understand (though I'm not sure how accurate it is), while 
> the GameSprockets are still supported under OS X for backwards 
> compatibility, they are no longer Apple's recommended method of doing 
> things.  I get the impression that they intend OpenGL and Quartz to be 
> the replacements, but I really don't know what all each of those 
> technologies do, so I can't say how sensible that impression is.
>
> But I'm pretty sure that the Sprockets are not what you're "supposed" 
> to use anymore.
>

Re: [Alephmodular-devel] Drawsprockets?

[Timothy C. <tco...@ha...>]

> Is there yet a more appropriate API than DrawSprockets for going right 
> to the display hardware of MacOS X? Right now CDisplay is very 
> centered towards the way AlephModular currently uses a single back 
> buffer that is always getting copied forward (A window back buffer and 
> appropriate flush to display calls) I'm sure this will turn up cases 
> of flicker (Places where info needs to be updated on both buffers not 
> getting updated properly) Hooking it up with DisplaySprokects should 
> help flush out those areas in need of improvement. But I really don't 
> know if DrawSprockets is the Apple recommended way of going about this 
> anymore.
>


 From what I understand (though I'm not sure how accurate it is), while 
the GameSprockets are still supported under OS X for backwards 
compatibility, they are no longer Apple's recommended method of doing 
things.  I get the impression that they intend OpenGL and Quartz to be 
the replacements, but I really don't know what all each of those 
technologies do, so I can't say how sensible that impression is.

But I'm pretty sure that the Sprockets are not what you're "supposed" 
to use anymore.

Timothy Collett

Greater than the death of flesh is the death of hope -- the death of 
dreams -- against this peril we can never surrender.

[Alephmodular-devel] Drawsprockets?

[Br'fin <br...@ma...>]

Is there yet a more appropriate API than DrawSprockets for going right 
to the display hardware of MacOS X? Right now CDisplay is very centered 
towards the way AlephModular currently uses a single back buffer that 
is always getting copied forward (A window back buffer and appropriate 
flush to display calls) I'm sure this will turn up cases of flicker 
(Places where info needs to be updated on both buffers not getting 
updated properly) Hooking it up with DisplaySprokects should help flush 
out those areas in need of improvement. But I really don't know if 
DrawSprockets is the Apple recommended way of going about this anymore.

-Jeremy Parsons

[Alephmodular-devel] Display enhancements available

[Br'fin <br...@ma...>]

Ok, I've posted the 0.3 + Display enhancement binary up on the 
SourceForge site. This is not to be construed as a full release. Just 
an important enough change that the community should see it.

http://sourceforge.net/project/showfiles.php?group_id=69003

I've also committed the corresponding changes into CVS on the 
devel-display-abstraction branch (not the main trunk) For those who 
peek at the code themselves, you should be able to see the changes with 
cvs update -r devel-display-abstraction.

The most interesting set of changes involve the CDisplay and CBuffer 
files under alephmodular/marathon2/Display

I would appreciate comments on them because while I'm happy with the 
syntax and the actual code, I think I could use some feedback on the 
readability and organization of the structures. (I think the methods 
could be organized better and some set of comments could also make 
things clearer)

And I still need to update the corresponding technical document. :)

-Jeremy Parsons

Re: [Alephmodular-devel] Clipping oneself into a corner

[Br'fin <br...@ma...>]

On Monday, March 10, 2003, at 12:33  AM, Alexander Strange wrote:
> On Monday, March 10, 2003, at 12:16  AM, Br'fin wrote:
>> I think this both completely rocks, and I have no idea how to fold it 
>> into AlephOne.
>>
>> -Jeremy Parsons
>
> What's the basic Carbon mechanism it uses? I'd really like to see this 
> in A1, as my primary machine can't do OpenGL...
>

The basic strategy for MacOS X involves rendering directly to the back 
buffer of a Carbon window. At which point updating changes from being a 
copybits to doing QDFlushPortBuffer on the window.

However, setup gets a lot trickier. Marathon's initial assumption is 
that the drawing buffer is exactly the right size to be 
drawing/rendering into. So the normal world_pixels is an offscreen 
buffer that is exactly 640x320 if you're running in 100%.

Rendering is pretty well behaved and it's easy to get it to draw 
someplace else. You don't even need to get the height and width of your 
bitmap all small if you don't want to since the view_data generally 
specifies the desired height and width already. But you do need to 
offset the bitmap.

bitmap.row_addresses[0] =
	bitmap.row_addresses[0] +
	(horizontal_offset * pixel_size) +
	(vertical_offset * bitmap.bytes_per_row);

Where pixel_size is 1 for 8 bit, 2 for 16 bit, and 4 for 32 bit.

Also, you need to muck with the origin of where you are drawing to for 
any drawing based commands (Such as text, the terminal, fps, the map). 
As well as setup appropriate clipping areas for the same.

On top of this, for low-res mode you need to rework where the source 
and destination are. I personally did this by saying... you want 640 x 
480 pixel doubled? Then your effective drawing area is 320 x 240 *AND* 
it is offset within that original area by 320 x 240. In other words, 
everything is initially clipped to the lower-right hand area of the 
total space, and then the normal pixel doubling routine runs with all 
pointers looking into the same effective bitmap space.

The CClippingBuffer I developed was specifically for handling the above 
cases, to make a  portion of a much larger GrafPort seem like it was a 
complete and separate smaller port.

-Jeremy Parsons

Re: [Alephmodular-devel] Clipping oneself into a corner

[Alexander S. <ast...@it...>]

On Monday, March 10, 2003, at 12:16  AM, Br'fin wrote:

> It looks a little funny dragging a window over the AlephModular window 
> and seeing artifacts in the dragged window's shadow (Side effect of 
> doing heavy drawing updates directly in the window's back buffer ;))
>
> But I think I've managed to clean up every single one of the OSX 
> Display update errors now. (Preference dialog boxes are still 
> graphically flawed though ;)) High resolution runs as fast as it 
> claims it is, fades don't misfade, and menu buttons on the menu 
> highlight and track.
>
> I'm going to both try and get this moderately cleaned up for the 
> display abstraction branch (That is, get all these things into CVS 
> somewhere) and to post the corresponding alpha build so you guys can 
> check it out.
>
> I think this both completely rocks, and I have no idea how to fold it 
> into AlephOne.
>
> -Jeremy Parsons

What's the basic Carbon mechanism it uses? I'd really like to see this 
in A1, as my primary machine can't do OpenGL...

Re: [Alephmodular-devel] Clipping oneself into a corner

[Br'fin <br...@ma...>]

It looks a little funny dragging a window over the AlephModular window 
and seeing artifacts in the dragged window's shadow (Side effect of 
doing heavy drawing updates directly in the window's back buffer ;))

But I think I've managed to clean up every single one of the OSX 
Display update errors now. (Preference dialog boxes are still 
graphically flawed though ;)) High resolution runs as fast as it claims 
it is, fades don't misfade, and menu buttons on the menu highlight and 
track.

I'm going to both try and get this moderately cleaned up for the 
display abstraction branch (That is, get all these things into CVS 
somewhere) and to post the corresponding alpha build so you guys can 
check it out.

I think this both completely rocks, and I have no idea how to fold it 
into AlephOne.

-Jeremy Parsons

On Sunday, March 9, 2003, at 10:34  PM, Br'fin wrote:

> Most of the clipping stuff is wonderful and perfect. But I found one 
> construct that was lacking. Clipping when you know you're dealing with 
> a small part of a whole. Most specifically, this means setting the 
> clipping area and redrawing the interface to 'highlight' buttons on 
> the main menu. D'oh.
>
> I think I'm going to need to add a scoped view clipping to the buffer 
> hierarchy. Unlike clipping objects, it doesn't limit you to a part 
> that otherwise ignores the whole. Instead, it sets constraints on the 
> buffer as a whole.
>
> Incidentally, if you have a view clipping and a clipping buffer, 
> drawing commands (but not necessarily pixel editing) are only going to 
> occur in the intersection of the two clippings.
>
> So there will be CClippedBuffer::Ptr get_clipped_buffer(rect) and 
> CBuffer::ViewClipLock get_clipped_view_lock(rect) methinks.
>
> -Jeremy Parsons
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The 
> debugger for complex code. Debugging C/C++ programs can leave you 
> feeling lost and disoriented. TotalView can help you find your way. 
> Available on major UNIX and Linux platforms. Try it free. > www.etnus.com
> _______________________________________________
> Alephmodular-devel mailing list
> Ale...@li...
> https://lists.sourceforge.net/lists/listinfo/alephmodular-devel
>

[Alephmodular-devel] Clipping oneself into a corner

[Br'fin <br...@ma...>]

Most of the clipping stuff is wonderful and perfect. But I found one 
construct that was lacking. Clipping when you know you're dealing with 
a small part of a whole. Most specifically, this means setting the 
clipping area and redrawing the interface to 'highlight' buttons on the 
main menu. D'oh.

I think I'm going to need to add a scoped view clipping to the buffer 
hierarchy. Unlike clipping objects, it doesn't limit you to a part that 
otherwise ignores the whole. Instead, it sets constraints on the buffer 
as a whole.

Incidentally, if you have a view clipping and a clipping buffer, 
drawing commands (but not necessarily pixel editing) are only going to 
occur in the intersection of the two clippings.

So there will be CClippedBuffer::Ptr get_clipped_buffer(rect) and 
CBuffer::ViewClipLock get_clipped_view_lock(rect) methinks.

-Jeremy Parsons

Re: [Alephmodular-devel] More to muse over. Display Abstraction

[Br'fin <br...@ma...>]

CPixelDoubledClippedBuffer is now in my code. In game graphics are much 
the same as before my fixups now. I do still need to work on the menus 
and screens though.

On a lark, I tried 256 color mode, and now that messes up in a 
different way. Seeing as how everything that works with the prior back 
buffer of world_pixels is now directly manipulating bits of an OSX 
buffered window.

Everything gets squeezed off to the left. I'm going to guess that when 
forced to 256 color mode, then all window back buffers end up 
defaulting to millions. No idea if display sprockets would help with 
this :)

-Jeremy Parsons

On Saturday, March 8, 2003, at 02:47  PM, Br'fin wrote:

> Ok, I think the entirety of your description (observers, readonly 
> bitmaps) is much like one of my overblown efforts. However, I think 
> your base idea is workable.
>
> As I was reading your message I'd been thinking 'what if pixel 
> doubling was an attribute of a bitmap.' But, as I thought that 
> through, that would require checks wherever in buffer or what not for 
> this attribute, perhaps building concealed clipping buffers or 
> something. And no, no, that was too much in a different direction.
>
> However, if there was a CDoublingBuffer, and itself was a descendant 
> of CClippingBuffer, then it could accept an input area that's 
> divisible by 2, clip itself even more heavilly, and when it unlocks 
> its pixels, it could inflate them.
>
> This also allows the buffer to position the original clipping 
> optimally for not mis-overwriting when inflating.
>
> ... Hmm, currently to get a clipping buffer, you request one from the 
> current buffer... guess you could add an attribute to that call.
>
> CClippedBuffer::Ptr (auto_ptr) CBuffer::get_clipped_buffer( 
> dimensions, attr = CBuffer::PixelStandard)
>
> But attr could also be CBuffer::PixelQuadruple which would switch it 
> to be allocating a doubling buffer instead of a normal clipped buffer.
>
> -Jeremy Parsons
>