[openbeos] Re: Source Control

  • From: "Robert Medeiros" <robert.medeiros@xxxxxxxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Thu, 01 Nov 2001 14:39:24 EST

Hey Axel,

>>typedef Point<int32> XPoint;
>>typedef Rect<int32> XRect;
>>are (or will be) used by game kit surfaces. Haven't ironed out the 
>>naming convention to use yet - they should prolly be B[something], 
>Put them in a namespace

Sadly, namespaces fall into the category of one of my infrequently used 
C++ features. I'll dig out the 'ol language reference and brush up, and 
then I'll do as you suggest. Thanks for the feedback. Btw, Axel - you 
have a cool name. :)

I have another more general question to cast into the void: what is our 
minimum supported PC hardware going to be? I ask because, if the 
minimum is sufficiently speedy, and requires at least 16+ M of VRAM, 
AGP, etc. then I'll be less inclined to worry about supporting surfaces 
with less than 24-bits. Ideally, all surfaces would be 32-bits with 
alpha support, to make things nice and uniform. IMO palettized video 
modes kinda suck, notwithstanding the fun things you can do using 
palette animation (which can always be emulated with a fast enough 
machine if you really want that old skool flava). For the interested, 
compare OpenPTC and TinyPTC; TinyPTC is a cut-down version of OpenPTC 
that its users wanted because they didn't need support for anything but 
32-bit surfaces (also getting rid of keyboard and timer support). Just 
having a single surface format should ease the learning curve quite a 
bit, I'd think, as well as simplifying the API. <shrug>

Down with cruft, I say. :) Of course, this all relates to the "new" 
stuff I'm working on. R5 functionality for the GameKit remains the 
underlying goal.


Other related posts: