alephmodular-devel Mailing List for AlephModular (Page 11)
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-02-24 11:39:12
|
On Monday, February 24, 2003, at 02:16 AM, Mark Levin wrote: >> Typical usage would be: >> Request current buffer from display system >> (it is limited as in dimensions, display system knows this) >> Lock down the buffer >> Get a bitmap from the buffer >> Render operations on the bitmap >> Release the bitmap >> Perform drawing operations on the buffer (access to platform native >> elements available?) >> Unlock the buffer >> Ask display system to swap buffers > > Add "Obtain the dimensions of the buffer" (oh, you got to that later). > > What do you think about the ability to move the origin of a context? > Aleph One does the main screen layout with this; it makes the game > view size and screen size essentially independent, but I personally > find it very confusing to do layout in this fashion. Perhaps it would > be better to do some complex calculations and rebuilding of buffers > when the screen is resized instead of a large number of simple (but > annoying) calculations every frame. I'm definitely looking at locking these two values together. Why? So that for MacOS X I can effectively set world_pixels to essentially be a clipped-rectangle version of the screen_window. In other words, I get a back buffer from someplace else, either a window's back buffer, display sprockets, or something equivalent, and then manage it with CDisplay and CBuffer. My Vindication comment the other day was in building a clipped-rectangle version of a CBitmap and passing it through the renderer so that the renderer was using a 640 x 320 portion of a 1024 x 768 window's buffer. >> Locking pixels. > > Are you talking about the original MacOS LockPixels() concept (which > IIRC was meant to protect pixmaps from memory manager housekeeping) or > some sort of mutex for multithreaded drawing? The former is probably > obsolete on everything except OS9. Lock Pixels is very much alive and well in Carbon. I don't know about normal buffers and maybe one or two existing LockPixels calls were misplaced in the Marathon code, but I definitely needed to call LockPixels on the window before I could access it's pixels. Otherwise I wrote directly to the screen. >> Ponder... Setting the drawing context should occur seperately > > Maybe this should be changed to a stack-based mechanism (like Quartz) > instead of requiring the program itself to cache and restore the > previous state. I haven't seen Quartz's method, but I feel you're right. I just haven't figured out who should own the drawing context yet. It does seem that some other class to encapsulate drawing options is appropriate. (A singleton CDrawingContext with the auto-releasing method I'd mentioned?) >> world_pixels is used as the offscreen buffer for saved game preview >> pictures :/ > > With proper abstraction it should be trivial to temporarily point the > renderer at an offscreen buffer instead. True. And in this one case I'd look into having the saved game preview possibly create its own buffer, wrap it in a CBuffer and ask it to have its thumbnail map rendered. It seems kinda low-priority. Creating the thumbnails as I do worked under 10.1.*, but while the navigation preview resources are created under 10.2, the finder and Navigation Services dialogs won't use them anymore :/ > > Rectangle representation: Do we use OS9-style absolute boundaries > (left/top/right/bottom) or "relative" rectangles (x/y/width/height)? > Is the origin at the physical top or bottom of a buffer? (Carbon and > OpenGL disagree on this last bit, which has caused me its share of > confusion too. How do Windows and SDL work?) screen_rectangle as used by Marathon is a left/top/right/bottom affair. Which is annoying as x/y/width/height feels like it suits my needs for CBitmap clipping control better. And yes that does place the origin at the physical top and left of the buffer, expanding down and to the right. -Jeremy Parsons |
|
From: Mark L. <hav...@ma...> - 2003-02-24 06:20:08
|
> Typical usage would be: > Request current buffer from display system > (it is limited as in dimensions, display system knows this) > Lock down the buffer > Get a bitmap from the buffer > Render operations on the bitmap > Release the bitmap > Perform drawing operations on the buffer (access to platform native > elements available?) > Unlock the buffer > Ask display system to swap buffers Add "Obtain the dimensions of the buffer" (oh, you got to that later). What do you think about the ability to move the origin of a context? Aleph One does the main screen layout with this; it makes the game view size and screen size essentially independent, but I personally find it very confusing to do layout in this fashion. Perhaps it would be better to do some complex calculations and rebuilding of buffers when the screen is resized instead of a large number of simple (but annoying) calculations every frame. > Locking pixels. Are you talking about the original MacOS LockPixels() concept (which IIRC was meant to protect pixmaps from memory manager housekeeping) or some sort of mutex for multithreaded drawing? The former is probably obsolete on everything except OS9. > Ponder... Setting the drawing context should occur seperately Maybe this should be changed to a stack-based mechanism (like Quartz) instead of requiring the program itself to cache and restore the previous state. > world_pixels is used as the offscreen buffer for saved game preview > pictures :/ With proper abstraction it should be trivial to temporarily point the renderer at an offscreen buffer instead. Rectangle representation: Do we use OS9-style absolute boundaries (left/top/right/bottom) or "relative" rectangles (x/y/width/height)? Is the origin at the physical top or bottom of a buffer? (Carbon and OpenGL disagree on this last bit, which has caused me its share of confusion too. How do Windows and SDL work?) --Mark "Notice the fine lines, the attention to detail, the overall craftsmanship... You just don't see that in giant evil robot planes any more." Random acts of programming: http://homepage.mac.com/haveblue |
|
From: Br'fin <br...@ma...> - 2003-02-24 05:39:47
|
And more brainstorming: -Jeremy Parsons Buffers A buffer is a complete description of a surface that one can draw upon. It is an abstract base class with platform specific implementations. For instance, under Macintosh, a buffer would wrap around a GWorldPtr/CGraftPtr/GrafPtr. Typical usage would be: Request current buffer from display system (it is limited as in dimensions, display system knows this) Lock down the buffer Get a bitmap from the buffer Render operations on the bitmap Release the bitmap Perform drawing operations on the buffer (access to platform native elements available?) Unlock the buffer Ask display system to swap buffers A buffer helps support higher level options such as copying portions and displaying text using OS specific calls. world_pixels would be a buffer. Here is a set of methods for buffers suggested by how existing Marathon code uses world_pixels: Locking pixels. (std::auto_ptr<CBuffer::PixelLock> get_pixel_lock) When dealing with buffers on Macintosh, one must lock down pixels before doing certain operations. Such as rendering onto the bitmap or using copybits. With an auto_ptr based mechanism, the lock is automatically freed once out of scope. A corrolary of this is that directly requesting a buffer's bitmap should make sure the corresponding bitmap has locked the buffer and has control of the lock. Trying to double lock or doubly unlock a buffer should assert. Instantiating and updating the internal buffer. Both myUpdateGWorld and myNewGWorld are called, depending on whether or not world_pixels already exists. Updates included depth, bounds, clut and associated screen device and flags. This may be protected functionality handled by the display abstraction. Since we are adding funtionality to the buffer (like by being able to use pre-existing buffers as if we had allocated them, such as the natural back buffer of a window) these may not have direct correlations to the outside world anymore. Accessing pixels. (std::auto_ptr<CBitmap> or facsimile) Gets a bitmap preconfigured by the buffer. Trying to access the pixels with another access on the pixels outstanding is a failure and should assert. Setting as target of drawing operations (std::auto_ptr<CBuffer::DrawbleLock> get_drawing_lock). Encapsulation for MacOS concepts of setting/swapping current drawing target with our buffer, then restoring the old drawing target afterwards. Attempts to perform drawing operations without this lock should assert. Attempts to get a second drawing lock should work though, in assumption of attempts to nest calls to drawing to different buffers. Ponder... Setting the drawing context should occur seperately Boundary requests: aka GetPortBounds world_pixels usage: game_window_macintosh.cpp used within draw_panels HUD is drawn in back buffer copy bits called to send it to the screen preprocess_map_mac.cpp world_pixels is used as the offscreen buffer for saved game preview pictures :/ screen.cpp world_pixels is setup during initialize_screen world_pixels provides the pixels for use in render_screen world_pixels clut is updated to sync with screen in change_screen_clut world_pixels is used in render_computer_interface world_pixels is used in render_overhead_map world_pixels is copied from in update_screen (and used as source for quadruple_screen!) screen_drawing.cpp _set_port_to_gworld encapsulates swapping to world_pixels for gWorld foo. |
|
From: Br'fin <br...@ma...> - 2003-02-22 10:49:35
|
Additional information on buffers and bitmaps, here's my initial definitions of each. -Jeremy Parsons Buffers A buffer is a complete description of a surface that one can draw upon. It is an abstract base class with platform specific implementations. For instance, under Macintosh, a buffer would wrap around a GWorldPtr/CGraftPtr/GrafPtr. Typical usage would be: Request current buffer from display system (it is limited as in dimensions, display system knows this) Lock down the buffer Get a bitmap from the buffer Render operations on the bitmap Release the bitmap Perform drawing operations on the buffer (access to platform native elements available?) Unlock the buffer Ask display system to swap buffers A buffer helps support higher level options such as copying portions and displaying text using OS specific calls. world_pixels would be a buffer. Bitmaps A bitmap, in contrast to a buffer, is a low level object that explicitly describes the pixels associated with a buffer. It knows very little, but is a stream of bytes in memory with precalculated row-addresses for jumping quickly to a scan line. RLE encoded shapes are also implemented as a bitmap that is owned by a collection. world_pixels_structure would be a bitmap. |
|
From: Br'fin <br...@ma...> - 2003-02-21 20:38:01
|
On Friday, February 21, 2003, at 02:23 PM, Woody Zenfell, III wrote: > On Friday, February 21, 2003, at 01:01 PM, Br'fin wrote: > >> Seems like there should be a less memory intensive way of fading out >> the other monitors, go figure. > > FWIW when I wrote a small Mac game many, many years ago, the preferred > way to fade the screen was through "gamma fades"; IIRC, there was a > small freeware library called ColorGamma or something that I used. > Anyway, my game simply left the non-game displays faded down to black > (except when the menu was displayed or the program switched out, of > course). This may have other unpleasant effects (esp. in the case of > a disorderly program exit), might not have worked on all Macs, or may > not even be relevant anymore... but it didn't require the creation of > any additional windows etc. At least MacOS X wise, a failed program is just tossed out and system Gamma resets on its own it would seem. Though a consideration for other platforms. My biggest problem, if anything, is that I never got multiple monitors working on MacOS X, then again I don't have a second monitor to play with. A bigger color related problem is 256 colors under MacOS X, oof. > Oh and on the main window being stretched to fill the screen - is that > a good thing? (Note to the casual reader - this is entirely different > from the "Fill the Screen" checkbox which adjusts the display's > resolution (in some cases).) Would it be cheaper memory-wise, > blitting-wise, etc. to use a totally black window in the background, > whose contents might be able to be represented very efficiently, and > whose contents never change, and a smaller full-color window that is > sized to fit the portion of the display that's actually used? (I'm > sort of making this up as I go along... :) not sure how these things > really work out in practice.) > Cheaper memory wise, probably makes changing screen-size mid game a touch problematic. Especially for AlephOne and it's larger screen sizes. Doesn't really add any excess to copying because update_screen was already focusing on only a part of the screen. The bigger overhead for software mode comes in the accidental triple buffering since AlephOne Carbon doesn't account for the MacOS X window back buffer -Jeremy Parsons |
|
From: Woody Z. I. <woo...@sb...> - 2003-02-21 19:23:55
|
On Friday, February 21, 2003, at 01:01 PM, Br'fin wrote: > Seems like there should be a less memory intensive way of fading out > the other monitors, go figure. FWIW when I wrote a small Mac game many, many years ago, the preferred way to fade the screen was through "gamma fades"; IIRC, there was a small freeware library called ColorGamma or something that I used. Anyway, my game simply left the non-game displays faded down to black (except when the menu was displayed or the program switched out, of course). This may have other unpleasant effects (esp. in the case of a disorderly program exit), might not have worked on all Macs, or may not even be relevant anymore... but it didn't require the creation of any additional windows etc. Just a thought. Oh and on the main window being stretched to fill the screen - is that a good thing? (Note to the casual reader - this is entirely different from the "Fill the Screen" checkbox which adjusts the display's resolution (in some cases).) Would it be cheaper memory-wise, blitting-wise, etc. to use a totally black window in the background, whose contents might be able to be represented very efficiently, and whose contents never change, and a smaller full-color window that is sized to fit the portion of the display that's actually used? (I'm sort of making this up as I go along... :) not sure how these things really work out in practice.) Woody |
|
From: Br'fin <br...@ma...> - 2003-02-21 19:01:33
|
On Friday, February 21, 2003, at 10:34 AM, Mark Levin wrote: > > On Thursday, February 20, 2003, at 08:27 PM, Br'fin wrote: > >> Does anyone happen to know what the point of the backdrop window >> under Macintosh is? I ask because it doesn't seem to do anything... >> not when the main window is normally stretched to fill the screen in >> the first place! > > It covers the entire monitor when the window is not stretched to fill > the screen, and it covers additional monitors when running on a system > with more than 1. > > --Mark > Ahhh, so it's kind of redundant when you have only one screen, (what with the main window being stretched to fill that screen) but is very useful for the case of multiple monitors. Ahhh. Gotcha. Seems like there should be a less memory intensive way of fading out the other monitors, go figure. -Jeremy Parsons |
|
From: Mark L. <hav...@ma...> - 2003-02-21 14:38:50
|
On Thursday, February 20, 2003, at 08:27 PM, Br'fin wrote: > Does anyone happen to know what the point of the backdrop window under > Macintosh is? I ask because it doesn't seem to do anything... not when > the main window is normally stretched to fill the screen in the first > place! It covers the entire monitor when the window is not stretched to fill the screen, and it covers additional monitors when running on a system with more than 1. --Mark "May pre house the seamy side volitation!" Random acts of programming: http://homepage.mac.com/haveblue |
|
From: Br'fin <br...@ma...> - 2003-02-21 05:06:47
|
Alright, I'm no where near ready to check this in yet. But it's a lovely proof of concept at the moment. I managed to set things up to have the renderer write directly to the window's back buffer, followed by a QDFlushPortBuffer. *whistle* What a difference that makes. Unfortunately, I've broken Low-res mode in the process so I can't directly compare the two yet. Software rendering mode, high-resolution, smooth FPS. (Marathon's max of 30 fps at most, but what the hey :)) -Jeremy Parsons |
|
From: Br'fin <br...@ma...> - 2003-02-21 02:27:19
|
Does anyone happen to know what the point of the backdrop window under Macintosh is? I ask because it doesn't seem to do anything... not when the main window is normally stretched to fill the screen in the first place! -Jeremy Parsons |
|
From: Woody Z. I. <woo...@sb...> - 2003-02-20 19:07:26
|
On Thursday, February 20, 2003, at 12:37 PM, Kevin Walker wrote: > jumping is in no configuration of the action flags Right, so a "jump" executed with the cheat code (I don't know much about this myself, never tried it, but there is no "jump" action_flag) would not be replayed on a film (resulting in incorrect playback), and would cause instant out-of-sync in a netgame. > On Monday, February 17, 2003, at 04:55 PM, Br'fin wrote: >> Still, at some point (far distant, alas) I'd not mind trying to expand >> the action flags. Thus letting some sub-project have more available >> actions and be able to map them to normal keys and have them handled >> in a way which works with both network and replay facilities. > And also, on 2/18/2002, Woody Zenfell, III talked about being able to > change some of the currently-hardcoded (I think) key presses. > > All I have to say is that, if you allow the user to remap volume keys, > etc., I don't think that you should put them in the action flags. Right, clearly this sort of thing has no business in action_flags. action_flags describe what a player is doing, not what a user is doing. I brought it up because we were also talking about key configuration - and if these preferences keys could be unified with game-control keys at some level, it would be easier to make them configurable, to add more of them, etc. Woody |
|
From: Br'fin <br...@ma...> - 2003-02-20 18:50:31
|
On Thursday, February 20, 2003, at 01:37 PM, Kevin Walker wrote: On Monday, February 17, 2003, at 04:19 PM, Jamie White wrote: >>> On Sunday, Feb 16, 2003, at 00:47 Europe/London, Kevin Walker wrote: >>> >>>> 4) Jumping (I've thought of a workaround, but it makes all weapons >>>> single-firing mode only, and would be pretty ugly) >>> >>> This is already in there. it's a cheat code. If you make your own >>> build, it shouldn't be too hard to re-arrange this to make it more >>> readily useable. > > The way you say this, it sounds like you assume I CAN make my own > build and re-arrange stuff. I basically signed up for this list > because I wanted to see how a new stab at the Marathon 2 Open Source > Project would go, and so I could make the occasional, um, "Public > Service Announcement" (:p). My function on this list is probably more > of a beta tester than anything else, though with a dash of mapmaker > thrown in. And I certainly don't mind at all. I want AlephModular well tested :) > Also, though, how is jumping handled in the cheat code? (and how do > you activate/use it?) This is actually the first time I've ever heard > it referenced as a fact (I vaguely remember, back in the day, that > people found that jumping is in no configuration of the action flags, > and that Jason and Alex decided that jumping wasn't realistic in > current implementations and that jumping wouldn't led to better > gameplay), so forgive my confusion. Is it the same as the Forge > "jump" key (allowing for indefinite flight), or is it actually > honest-to-goodness "attain parabolic trajectory through air by shoving > off from the ground with legs"? I forget offhand, but essentially with cheats enable, the game engine recognizes local patterns of keys and then tweaks the game world. So, typing certain codes will give you weapons and gear and one key set triggers a jump. Here is the code that 'jumps' you: accelerate_monster(local_player->monster_index, WORLD_ONE/10, 0, 0); Just outright gives you an upwards speed boost :)... probably arcs as well as the game handles gravity. But the cheats have no effect on network play, they just affect the local player. Instant Out of sync, I imagine in network play. > On Monday, February 17, 2003, at 04:55 PM, Br'fin wrote: >> Still, at some point (far distant, alas) I'd not mind trying to >> expand the action flags. Thus letting some sub-project have more >> available actions and be able to map them to normal keys and have >> them handled in a way which works with both network and replay >> facilities. > And also, on 2/18/2002, Woody Zenfell, III talked about being able to > change some of the currently-hardcoded (I think) key presses. > > All I have to say is that, if you allow the user to remap volume keys, > etc., I don't think that you should put them in the action flags. > Why? Because, if I were watching a replay, I wouldn't really want my > volume adjusted during the game by the players. Not really a big > thing, but something I thought of. > *Laugh* Yes yes, remapping the local system keys would *not* be included in Action Key handling or shouldn't be :) -Jeremy Parsons |
|
From: Kevin W. <lu...@ea...> - 2003-02-20 18:38:01
|
> > On Monday, February 17, 2003, at 04:19 PM, Jamie White wrote: >> On Sunday, Feb 16, 2003, at 00:47 Europe/London, Kevin Walker wrote: >> >>> 4) Jumping (I've thought of a workaround, but it makes all weapons >>> single-firing mode only, and would be pretty ugly) >> >> This is already in there. it's a cheat code. If you make your own >> build, it shouldn't be too hard to re-arrange this to make it more >> readily useable. The way you say this, it sounds like you assume I CAN make my own build and re-arrange stuff. I basically signed up for this list because I wanted to see how a new stab at the Marathon 2 Open Source Project would go, and so I could make the occasional, um, "Public Service Announcement" (:p). My function on this list is probably more of a beta tester than anything else, though with a dash of mapmaker thrown in. Also, though, how is jumping handled in the cheat code? (and how do you activate/use it?) This is actually the first time I've ever heard it referenced as a fact (I vaguely remember, back in the day, that people found that jumping is in no configuration of the action flags, and that Jason and Alex decided that jumping wasn't realistic in current implementations and that jumping wouldn't led to better gameplay), so forgive my confusion. Is it the same as the Forge "jump" key (allowing for indefinite flight), or is it actually honest-to-goodness "attain parabolic trajectory through air by shoving off from the ground with legs"? On Monday, February 17, 2003, at 04:55 PM, Br'fin wrote: > Still, at some point (far distant, alas) I'd not mind trying to expand > the action flags. Thus letting some sub-project have more available > actions and be able to map them to normal keys and have them handled > in a way which works with both network and replay facilities. And also, on 2/18/2002, Woody Zenfell, III talked about being able to change some of the currently-hardcoded (I think) key presses. All I have to say is that, if you allow the user to remap volume keys, etc., I don't think that you should put them in the action flags. Why? Because, if I were watching a replay, I wouldn't really want my volume adjusted during the game by the players. Not really a big thing, but something I thought of. -Lunair |
|
From: Br'fin <br...@ma...> - 2003-02-20 16:53:21
|
Still trying to deal with display foo in my head. And working from the
leaves in that leaves me trying to manage 'what is a bitmap' before I
can handle how to dole them out to other areas.
The part I've been having the most trouble with, up til now, was trying
to cope with the arbitrary sizes that bitmaps uses. C++ classes aren't
generally geared to being flexible in length, but I have some ideas and
I think I can make this basis work for bitmaps.
Still got my fingers crossed on that one, but even so I think I got my
head wrapped around the basics and the offset table to have that table
be a separate allocation if need be.
-Jeremy Parsons
Bitmaps
Here is the current layout of a bitmap.
enum /* bitmap flags */
{
_COLUMN_ORDER_BIT= 0x8000,
_TRANSPARENT_BIT= 0x4000
};
const unsigned int FILE_SIZEOF_bitmap_definition = 30;
struct bitmap_definition
{
int16 width, height; /* in pixels */
int16 bytes_per_row; /* if ==NONE this is a transparent RLE shape */
int16 flags; /* [column_order.1] [unused.15] */
int16 bit_depth; /* should always be ==8 */
int16 unused[8];
pixel8 *row_addresses[1];
//serialization
friend AIStream& operator>>(AIStream&, struct bitmap_definition&);
friend AOStream& operator<<(AOStream&, struct bitmap_definition&);
};
/* ---------- prototypes/TEXTURES.C */
/* assumes pixel data follows bitmap_definition structure immediately */
pixel8 *calculate_bitmap_origin(struct bitmap_definition *bitmap);
/* initialize bytes_per_row, height and row_address[0] before calling */
void precalculate_bitmap_row_addresses(struct bitmap_definition
*texture);
void map_bytes(uint8 *buffer, uint8 *table, int32 size);
void remap_bitmap(struct bitmap_definition *bitmap, pixel8 *table);
We could work within this to provide working on a subset of the bitmap.
Such work would create create the following needs. Such a workd would
also only apply to a non RLE bitmap.
width is width of subset
height is height of subset
offset_column, offset_row is added for subsets
bytes_per_row is unchanged
flags is unchanged
bit_depth is unchanged
row_addresses
Is unchanged for shapes
for a subset
row_address[0] points to the resultant byte due to offsetting. This
position is base_address+(offset_row*bytes_per_row)+offset_column.
Adding
bytes_per_row to this will hit each subsequent row with the handy
offsets already applied.
What is interesting to note is that making a class of bitmap_definition
is fairly hard. Between my requirements that limit our ability to
subclass and derive.
...
Strike that, looks like subclassing can be handled 'nicely'
When loading collections, the first pass of shapes allocates size based
upon sizeof bitmap_definition, and then copies the existing stream into
place. We can intercedede in this by doing an 'in place new' (new(void
*) T(val); ) that allocates and constructs the bitmap at the desired
point. Roughly this would look something like
void *source= (raw_collection + OffsetTable[k]);
void *destination= (NewCollection + NewCollLocation);
int32 length= OffsetTable[k+1] - OffsetTable[k];
shape_bitmap_definition *bitmap= new (destination)
shape_bitmap_definition(source, length);
*(NewOffsetPtr++) = NewCollLocation;
NewCollLocation +=
AdjustToPointerBoundary(bitmap->sizeof());
Note that it is an inplace new.
The arguments are a spot in memory and and a length to process.
The sizeof method performs calculation to determine the actual length
of the the bitmap + its offset pointers + its actual data
Remember that something that frees up a collection should call delete
on each bitmap just in case for the future :)
On a similar sort of note, a screen based bitmap can be pre-allocated,
then created in place with one of its elments holding an auto_ptr to
own its own allocation buffer.
So now, the base code can deal with bitmap_definition, and higher level
code can deal with the specifics of a shape_bitmap_definition and a
display(screen?)_bitmap_definition, which is mostly useful for
construction in either case. Mmm, might want to add the control of its
own managment to shape_bitmap_definition as well for someone wanting to
create-edit bitmaps. If the memory doesn't need to be freed or is freed
elsewhere, then the auto_ptr can be left not holding anything.
|
|
From: Nathan F. <nf...@co...> - 2003-02-18 19:38:57
|
> This is in Aleph one. Although I couldn't to get it to run at any > reasonable speed on either a 800mhz G4 with a 64 mb geforce 4mx, or a > 800 G3 with a 32 mb raedon! There was a very cool site by someone > called spnk'r-ghol that showed how to use it! But I seem to have > misplaced the link somewhere... http://spnkrghol.forerunners.org/ |
|
From: Br'fin <br...@ma...> - 2003-02-18 08:01:36
|
On Tuesday, February 18, 2003, at 02:25 AM, Woody Zenfell, III wrote: > On Monday, February 17, 2003, at 03:55 PM, Br'fin wrote: > >> Still, at some point (far distant, alas) I'd not mind trying to >> expand the action flags. Thus letting some sub-project have more >> available actions and be able to map them to normal keys and have >> them handled in a way which works with both network and replay >> facilities. > > In the meantime there should at least be (if there aren't already! :) > ) code changes like, giving them their own type and custom methods for > duplicating, packing, and unpacking them, accessing their contents > through a macro or inline function or something, etc. And maybe at > some point just doubling the number of bits to make some room would be > sufficient. Agreed, though for my priorities I'm still trying to wrestle my head around bitmap support and Display Abstraction. > Random thought: it would be nice if structures that are re-used are > explicitly invalidated somehow. For example, my recent A1 work in > resuming saved-games as netgames led me through the initialization > stuff, where I just have to kind of hope/trust (thanks to the overall > complexity in there) that all the relevant parts of the game state are > getting reinitialized somehow (and that, specifically, none are being > overlooked and letting stale values from the previous game bleed > through). If all this stuff were, say, destroyed when a game ends and > reallocated (using something like MallocScribble of course) when > another game begins, or all allocated from some big contiguous memory > region that could be memsetted, I wouldn't have to worry so much about > stale stuff - anything I missed should be reasonably apparent and > should cause the same problem every time (rather than, say, working as > long as I happened to play that level first as a single-player game, > but exhibiting weird behaviors if I played some other particular level > first, etc.). > > Shrug, maybe the Marathon code base is already pretty good about this > and I just don't realize it. > Unknown on this, though with all the changes AlephOne went though, I've no idea yet on how to audit or account for this to make sure that AlephModular is 'doing the right thing tm' with respect to managing its memory. -Jeremy Parsons |
|
From: Woody Z. I. <woo...@sb...> - 2003-02-18 07:25:48
|
On Monday, February 17, 2003, at 03:55 PM, Br'fin wrote: > Still, at some point (far distant, alas) I'd not mind trying to expand > the action flags. Thus letting some sub-project have more available > actions and be able to map them to normal keys and have them handled in > a way which works with both network and replay facilities. In the meantime there should at least be (if there aren't already! :) ) code changes like, giving them their own type and custom methods for duplicating, packing, and unpacking them, accessing their contents through a macro or inline function or something, etc. And maybe at some point just doubling the number of bits to make some room would be sufficient. Oh and it would probably be nice (this is not action_flags of course, but) if the various game-option keys (adjust screen size, adjust volume, etc. etc.) were sort of generalized at some point too, so they could be configured and new ones added etc. with minimal fuss. (I don't remember whether A1/Carbon (or AM, indeed) is among the builds that does this, but... I use the Dvorak keyboard layout rather than QWERTY, and so when I use the key labelled "E" on my keyboard to move forward, well that's really the "period" key, so some versions of A1 won't let me use it (and some others let me configure it, somehow, but in the game, running forward turns up the volume). So anyway it'd be awfully nice to be able to configure, say, "volume up" to be something else... and being able to do so of course suggests generalizing the keyboard-handling stuff.) Random thought: it would be nice if structures that are re-used are explicitly invalidated somehow. For example, my recent A1 work in resuming saved-games as netgames led me through the initialization stuff, where I just have to kind of hope/trust (thanks to the overall complexity in there) that all the relevant parts of the game state are getting reinitialized somehow (and that, specifically, none are being overlooked and letting stale values from the previous game bleed through). If all this stuff were, say, destroyed when a game ends and reallocated (using something like MallocScribble of course) when another game begins, or all allocated from some big contiguous memory region that could be memsetted, I wouldn't have to worry so much about stale stuff - anything I missed should be reasonably apparent and should cause the same problem every time (rather than, say, working as long as I happened to play that level first as a single-player game, but exhibiting weird behaviors if I played some other particular level first, etc.). Shrug, maybe the Marathon code base is already pretty good about this and I just don't realize it. Woody |
|
From: Br'fin <br...@ma...> - 2003-02-18 06:56:50
|
On Tuesday, February 18, 2003, at 01:27 AM, Br'fin wrote: > > On Monday, February 17, 2003, at 06:04 PM, Jamie White wrote: > >> >> On Monday, Feb 17, 2003, at 22:50 Europe/London, Matt Lee wrote: >> >>> >>> My build out of CVS from February 13 runs fine. I don't seem to be >>> able to update right now from SF.net so I can't test more recent >> >>> code. >>> >>> Are you able to run the 0.3 release build properly? >> >> Yeah.. I just downloaded it! Actually, I think I've found your first >> "non-bungie" bug! :-) >> >> After running 0.3, cvs checkout ran fine... Which I thought was odd! >> So, I deleted the preferences, and tried to run it again, which >> didn't work! I got the error: >> >> ../../marathon2/Support/CFiles.cpp:209: Assertion failed: is_file() >> >> If I run 0.3, and then cvs again, it's fine! cvs obviously doesn't >> like creating the preference files... :-/ >> >> Jamie >> > Oops, I've been doing a lot of file rearranging stuff, so it's > probably my fault. Thanks for the report and I'm looking into it now. > :) > Yeah, it was my bad. Even with the zealous asserts I've sprinkled through the system, opening a file for reading that doesn't exist, should get a proper error. I've already checked in a fix for this. Thanks again :) -Jeremy Parsons |
|
From: Br'fin <br...@ma...> - 2003-02-18 06:27:29
|
On Monday, February 17, 2003, at 06:04 PM, Jamie White wrote: > > On Monday, Feb 17, 2003, at 22:50 Europe/London, Matt Lee wrote: > >> >> My build out of CVS from February 13 runs fine. I don't seem to be >> able to update right now from SF.net so I can't test more recent >> code. >> >> Are you able to run the 0.3 release build properly? > > Yeah.. I just downloaded it! Actually, I think I've found your first > "non-bungie" bug! :-) > > After running 0.3, cvs checkout ran fine... Which I thought was odd! > So, I deleted the preferences, and tried to run it again, which didn't > work! I got the error: > > ../../marathon2/Support/CFiles.cpp:209: Assertion failed: is_file() > > If I run 0.3, and then cvs again, it's fine! cvs obviously doesn't > like creating the preference files... :-/ > > Jamie > Oops, I've been doing a lot of file rearranging stuff, so it's probably my fault. Thanks for the report and I'm looking into it now. :) -Jeremy Parsons |
|
From: Jamie W. <jam...@bl...> - 2003-02-17 23:05:03
|
On Monday, Feb 17, 2003, at 22:50 Europe/London, Matt Lee wrote: > > My build out of CVS from February 13 runs fine. I don't seem to be > able to update right now from SF.net so I can't test more recent code. > > Are you able to run the 0.3 release build properly? Yeah.. I just downloaded it! Actually, I think I've found your first "non-bungie" bug! :-) After running 0.3, cvs checkout ran fine... Which I thought was odd! So, I deleted the preferences, and tried to run it again, which didn't work! I got the error: ../../marathon2/Support/CFiles.cpp:209: Assertion failed: is_file() If I run 0.3, and then cvs again, it's fine! cvs obviously doesn't like creating the preference files... :-/ Jamie |
|
From: Matt L. <ze...@ze...> - 2003-02-17 22:50:59
|
>I could build modular off the bat though, which is fantastic! >Can't run the currently compiled cvs checkout, but I guess >this is to be expected with 'work in progress', right? :-) My build out of CVS from February 13 runs fine. I don't seem to be able to update right now from SF.net so I can't test more recent code. Are you able to run the 0.3 release build properly? -Zebe -- Matt Lee | PGP key available: ze...@ze... | http://zebe.net/pgp.asc |
|
From: Jamie W. <jam...@bl...> - 2003-02-17 22:30:31
|
On Monday, Feb 17, 2003, at 21:55 Europe/London, Br'fin wrote: > > According to SF.net's status page > (https://sourceforge.net/docman/display_doc.php?docid=2352&group_id=1) > their servers are currently under heavy load. It took me a couple of > tries to check out alephModular anonymously from the command line. > Judging from their description of the limits, it looks like integrated > Project Builder CVS support may be spotty as long as the their limits > are in place :/ > Sorry, I should have mentioned, but, I could check out obsoletely fine from the command line, and I could check out aleph one fine from project builder (i couldn't build, but that's a different story for a different list :-) . I could build modular off the bat though, which is fantastic! Can't run the currently compiled cvs checkout, but I guess this is to be expected with 'work in progress', right? :-) . Jamie |
|
From: Br'fin <br...@ma...> - 2003-02-17 21:55:38
|
On Monday, February 17, 2003, at 04:19 PM, Jamie White wrote: > On Sunday, Feb 16, 2003, at 00:47 Europe/London, Kevin Walker wrote: > >> 4) Jumping (I've thought of a workaround, but it makes all weapons >> single-firing mode only, and would be pretty ugly) > > This is already in there. it's a cheat code. If you make your own > build, it shouldn't be too hard to re-arrange this to make it more > readily useable. Still, at some point (far distant, alas) I'd not mind trying to expand the action flags. Thus letting some sub-project have more available actions and be able to map them to normal keys and have them handled in a way which works with both network and replay facilities. > PS. Does anyone know why I can't do a CVS checkout from within Project > Builder? The connection is always reset by peer... :-/ According to SF.net's status page (https://sourceforge.net/docman/display_doc.php?docid=2352&group_id=1) their servers are currently under heavy load. It took me a couple of tries to check out alephModular anonymously from the command line. Judging from their description of the limits, it looks like integrated Project Builder CVS support may be spotty as long as the their limits are in place :/ -Jeremy Parsons |
|
From: Jamie W. <jam...@bl...> - 2003-02-17 21:19:09
|
On Sunday, Feb 16, 2003, at 00:47 Europe/London, Kevin Walker wrote: > 4) Jumping (I've thought of a workaround, but it makes all weapons > single-firing mode only, and would be pretty ugly) This is already in there. it's a cheat code. If you make your own build, it shouldn't be too hard to re-arrange this to make it more readily useable. > 9) 3D models instead of sprites (not necessary at all, though could > be cool) This is in Aleph one. Although I couldn't to get it to run at any reasonable speed on either a 800mhz G4 with a 64 mb geforce 4mx, or a 800 G3 with a 32 mb raedon! There was a very cool site by someone called spnk'r-ghol that showed how to use it! But I seem to have misplaced the link somewhere... J White PS. Does anyone know why I can't do a CVS checkout from within Project Builder? The connection is always reset by peer... :-/ |
|
From: Br'fin <br...@ma...> - 2003-02-17 16:07:25
|
Still debating about what to do for Display Abstraction and bitmap abstraction and the like. Hard time trying to juggle wants and perceived needs there. Though in poking around I did find another site with good C++ articles. Herb Sutter - Publications (http://www.gotw.ca/publications/index.htm) So I finally figured out just what an auto_ptr is and how to use it. Also some other details such as why you might want to go with a non-volatile-interface on a class. Which I liked. Consequently, I reworked CFileTypes and CFileDescs to use these new approaches, and in general I liked how they turned out. The interface in the primary class seems much more detailed to me. And I feel that the use of auto_ptrs generally feels right. the only sticky spot resulted in things like IFileRefPtr (std::auto_ptr<std::istream>) and IFileRef(std::auto_ptr<std::istream>&) where IFileRef is used throughout the code when passing the argument around. But IFileRefPtr is used when actual ownership of the auto_ptr wants to be managed. In accompaniment, I did update CFileDesign.txt -Jeremy Parsons |
