alephmodular-devel Mailing List for AlephModular (Page 7)
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-09-18 05:23:23
|
On Wednesday, September 17, 2003, at 10:08 PM, Timothy Collett wrote: >> A Font (CFontSpec) encapsulates choice of font family, style, and >> size. For instance, Monaco, Bold, 10pt. A CFontSpec is a relatively >> lightweight class. >> > > How is color handled? And are we bothering with background color and > justification? > > Just curious...I've been looking at Carbon font-handling stuff, so all > the fields of a ControlFontStyleRec are swimming around in my head > right now... x_x Color is an argument to the function. Background color is ignored (We assume we're drawing ontop of something else and want it to show through.) Justification is ignored/left to higher level routines. We just want to draw a string of text at X,Y. These are the current font related methods on CDContext (The Drawing Context Class) /* Font methods */ short get_font_height(const CBuffer::Font& font) short get_font_line_spacing(const CBuffer::Font& font) short text_width(const CBuffer::Font& font, char *string) short char_width(const CBuffer::Font& font, char c) void draw_text(const CBuffer::Font& font, const CPoint& where, char *string, const CColor& color) I still feel that it's right to pump font metric info through the drawing class as I fully expect to implement a Scaled Buffer at some future point in time. And on the fly it would be tweaking things. We are doing a 2x scale for our buffer. (We tell the system we are a 640x480 buffer, but we're actually drawing to a window much larger then that.) So we'll modify all inputs, including font sizes, by our modifier. Theoretically achieving a mostly unblurred but scaled up result. Yes, the concept of a scaled buffer is mostly getting tossed around in my head in order to do full screen terminal windows at higher resolutions (Crossed fingers.) screen_drawing.cpp and computer_interface.cpp both handle concepts of line wrapping and justification and clipping text to fit. But at a higher level than CDContext handling the basic 'draw string' functionality. I admit I'm keeping things extremely simple. For instance, CDContext currently has no concept of 'current color' or 'current font'. So all of the drawing commands so far include a color argument. This kind of puts it at a 'semi-right' state. Much better than calling platform drawing commands altogether, but not yet full featured to use outside of AM's use of the classes. Or potentially using the classes most efficiently. So far, I'm happy with the display abstraction. Fonts are the last major hurdle, and while there is another minor hurdle or so (DrawPicture(resource_picture) comes to mind) I believe it will be a straightforward procedure to attach that to a CBitmap class and use some of the SDL inclined picture extracting glue from A1 to do it. -Jeremy Parsons |
|
From: Timothy C. <da...@ma...> - 2003-09-18 02:09:07
|
> A Font (CFontSpec) encapsulates choice of font family, style, and > size. For instance, Monaco, Bold, 10pt. A CFontSpec is a relatively > lightweight class. > How is color handled? And are we bothering with background color and justification? Just curious...I've been looking at Carbon font-handling stuff, so all the fields of a ControlFontStyleRec are swimming around in my head right now... x_x Timothy Collett "So we went to Atari and said, 'Hey, we've got this amazing thing, even built with some of your parts, and what do you think about funding us? Or we' ll give it to you. We just want to do it. Pay our salary, we'll come work for you.' And they said, 'No.' So then we went to Hewlett-Packard, and they said, 'Hey, we don't need you. You haven't got through college yet.'" --Apple Computer Inc. founder Steve Jobs on attempts to get Atari and H-P interested in his and Steve Wozniak's personal computer in 1976. |
|
From: Br'fin <br...@ma...> - 2003-09-17 19:05:50
|
A Font (CFontSpec) encapsulates choice of font family, style, and size. For instance, Monaco, Bold, 10pt. A CFontSpec is a relatively lightweight class. You can ask CDisplay if a font is available. You can pass a font to CDContext->draw_text to select the font to draw with. If a font is unavailable, then drawing in that font is undefined (It may have a default font, or may just decline drawing anything at all) From a CFontSpec, you can ask for variants (Such as different sizes or different styles) Before drawing with a font, you should prepare a buffer for receiving it. This allows the buffer to prepare and cache any information it needs for the font. Such as preloading bitmap definitions or setting up OpenGL drawing lists for each glyph. Draw_text will prepare the font itself, but for efficiency reasons, you may wish to precache these things when beginning a level or switching graphic modes. Preparing a buffer with a font that it has already been prepared with should be a no-op. CFontSpec's should test for equality (Does CFontSpec A == CFontSpec B?) Implementation musings: Internally, I'm thinking of some kind of hash_map within a CBuffer for storing prepared font info. How wary should I be that hash_map is a SGI extension to the C++ STL? (gcc appears to support it, as does microsoft) and it seems to have been originally extended as far back as Hewlett Packard, so may be in the most generally available STL downloads. (at the very least, gcc+MS covers a good chunk of our expected targets anyhow) I think I'm finally getting somewhere conceptually. Yay! -Jeremy Parsons |
|
From: Br'fin <br...@ma...> - 2003-09-16 03:59:12
|
Mrrf, mis-sent initially.
Trying to fight with fonts conceptually. Did a first pass of using
CFontSpec in the submitted code. But I've been a little unhappy with
hashing out the issues of ownership and responsibility for fonts.
Drawing Context is the most convenient things to get fonts from
Buffer makes the most sense in terms of getting the right kind of font
(Assuming a given build will have access to both unaccelerated fonts as
well as access to OpenGL and thus need extra font info stored for that.)
Some kind of Font Repository also makes sense too.
Something that you can ask for "Monaco", 10, bold or I want the bold
variant of the font in this CFontSpec. Or that you might be able to ask
for a native representation thereof and it will perform appropriate
things and give you the right CFontSpec back.
I'm currently leaning more towards a platform neutral CFontSpec with
ids that should be known to some kind of central lookup. And you can
ask the lookup for the platform specific variant one needs
I don't know, sigh.
Create Buffer
Associate Buffer with Font Respository (Specific to platform and mode
(accelerate vs non))
Get Drawing Context
// Perform initial queries for required fonts
// (Should pre-load/cache fonts in Font Repository.
// For instance, OpenGL fonts may have overhead and need pre-loading)
globals.font_terminal_bold= buffer.get_font("monaco", 10, bold);
globals.font_hud_normal= buffer.get_font("helvetica", 12, normal);
Release Context
... later ...
Get drawing context
context.draw_text(globals.font_terminal_bold, "Wheee", 10, 10, black);
Sigh, still trying to wrap my head around this.
-Jeremy Parsons
|
|
From: Br'fin <br...@ma...> - 2003-09-16 03:41:32
|
Trying to fight with fonts conceptually. Did a first pass of using CFontSpec in the submitted code. But I've been a little unhappy with hashing out the issues of ownership and responsibility for fonts. Drawing Context is the most convenient things to get fonts from Buffer makes the most sense in terms of getting the right kind of font (Assuming a given build will have access to both unaccerlated fonts as well as access to OpenGL and thus need extra font info stored for that. |
|
From: Alexander S. <ast...@it...> - 2003-09-10 00:49:01
|
On Monday, September 8, 2003, at 10:57 PM, Timothy Collett wrote: > Greetings. > OK, maybe I'm missing something obvious. > And maybe I'm being impossibly dense. > But I *think* I'm following the directions on the website > (am.sf.net/cvshowto) exactly, and all I get is "connection refused". > For a while, I've been getting "connection reset by peer". > If it were only happening when I try to do this, I would probably > chalk it up to me not knowing what I'm doing, as usual. But Fink has > been having the same problem, lately. Anyone here having problems > with Sourceforge's CVS? > Keep going. Sourceforge's CVS servers drop anoncvs connections when they're overloaded. They're always overloaded. |
|
From: Br'fin <br...@ma...> - 2003-09-09 15:29:50
|
I have no idea on that. I can only suggest poking through the sf.net Site Docs link that's on left side of the sourceforge.net homepage. -Jeremy Parsons On Tuesday, September 9, 2003, at 11:02 AM, Timothy Collett wrote: > Nope. Still doesn't work. I copied the line on that page & pasted it > in Terminal, it asked for the password, I pressed "Enter", and it > said: > cvs [login aborted]: connect to cvs.sourceforge.net:2401 failed: > Connection refused > Irritating. This is exactly what it said before, too. Is it possible > that it has anything to do with my firewall (which I've had on for a > long time, and been able to do this through before)? > > Thanks for your help! > > Timothy Collett > > The significant problems we face cannot be solved by the same level of > thinking that created them. > -Albert Einstein |
|
From: Timothy C. <da...@ma...> - 2003-09-09 15:02:26
|
Nope. Still doesn't work. I copied the line on that page & pasted it in Terminal, it asked for the password, I pressed "Enter", and it said: cvs [login aborted]: connect to cvs.sourceforge.net:2401 failed: Connection refused Irritating. This is exactly what it said before, too. Is it possible that it has anything to do with my firewall (which I've had on for a long time, and been able to do this through before)? Thanks for your help! Timothy Collett The significant problems we face cannot be solved by the same level of thinking that created them. -Albert Einstein |
|
From: Woody Z. I. <woo...@sb...> - 2003-09-09 14:34:50
|
On Tuesday, September 9, 2003, at 07:35 AM, Br'fin wrote: > I'm a little hazy on how to correct this for a project you had already > checked out from one server. With all the changes in A1 between down and gromit (and for me, changing from anoncvs to wzenfell), I found it handy to just edit the CVS/Root file in each directory and change the information there. (It's a single line; you'll figure it out. :) ) Actually, it's sufficient to just change it in whatever directory you usually issue commands in. I've just changed mine as they become problems. e.g. I'm sure my aleph/ and Source_Files/ had theirs done early, but it was probably a while before I ran a command while inside RenderOther/ . (Operations on RenderOther were done "from the outside", from a directory that had already been revised - and that's fine.) If you wanted to get fancy, there's probably a clever way to automate that, perhaps using something along the lines of find . -name Root -exec something-like-sed-that-works-in-place -e s/one/the other/ Woody |
|
From: Br'fin <br...@ma...> - 2003-09-09 12:35:19
|
Mm, it looks like sf.net switched over to a bit more focused of a dns scheme for cvs. Checking https://sourceforge.net/cvs/?group_id=69003 (sf.net CVS page for AlephModular) reveals that the login and checkout lines should be using cvs.sourceforge.net and not cvs.alephmodular.sourceforge.net. See that url above for the updated lines. I'm a little hazy on how to correct this for a project you had already checked out from one server. I'm going to update the AM homepage info now. -Jeremy Parsons On Monday, September 8, 2003, at 10:57 PM, Timothy Collett wrote: > Greetings. > OK, maybe I'm missing something obvious. > And maybe I'm being impossibly dense. > But I *think* I'm following the directions on the website > (am.sf.net/cvshowto) exactly, and all I get is "connection refused". > For a while, I've been getting "connection reset by peer". > If it were only happening when I try to do this, I would probably > chalk it up to me not knowing what I'm doing, as usual. But Fink has > been having the same problem, lately. Anyone here having problems > with Sourceforge's CVS? > > Apologies for the somewhat offtopic clutter, but it is about AM! > ...sort of... > Oh, and sorry for sending it straight to Br'fin by accident! I'm not > having a good night... >_< > > Timothy Collett > > "Reality is merely an illusion, albeit a very persistent one " > --Albert Einstein > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Alephmodular-devel mailing list > Ale...@li... > https://lists.sourceforge.net/lists/listinfo/alephmodular-devel > |
|
From: Timothy C. <da...@ma...> - 2003-09-09 02:57:41
|
Greetings. OK, maybe I'm missing something obvious. And maybe I'm being impossibly dense. But I *think* I'm following the directions on the website (am.sf.net/cvshowto) exactly, and all I get is "connection refused". For a while, I've been getting "connection reset by peer". If it were only happening when I try to do this, I would probably chalk it up to me not knowing what I'm doing, as usual. But Fink has been having the same problem, lately. Anyone here having problems with Sourceforge's CVS? Apologies for the somewhat offtopic clutter, but it is about AM! ...sort of... Oh, and sorry for sending it straight to Br'fin by accident! I'm not having a good night... >_< Timothy Collett "Reality is merely an illusion, albeit a very persistent one " --Albert Einstein |
|
From: Br'fin <br...@ma...> - 2003-09-07 20:11:10
|
Merf. I think we could have set this up to be less cryptic.
Why is it:
> typedef struct sorted_node_data *sndp;
And not something that is:
Clear named
Defined adjacent to the structure
I don't know if we want to go as far as
struct sorted_node_data
{
...
typedef struct sorted_node_data *Ptr;
}
But I not mind something adjacent that was like
typedef struct sorted_node_data* sorted_node_data_ptr
-Jeremy Parsons
On Sunday, September 7, 2003, at 01:06 AM, Alexander Strange wrote:
> Update of /cvsroot/alephmodular/alephModular/marathon2
> In directory sc8-pr-cvs1:/tmp/cvs-serv27565
>
> Modified Files:
> Tag: devel-display-abstraction
> render.cpp
> Log Message:
> A one-line change to allow render.cpp to compile under xlC
>
> Index: render.cpp
> ===================================================================
> RCS file: /cvsroot/alephmodular/alephModular/marathon2/render.cpp,v
> retrieving revision 1.9.2.3
> retrieving revision 1.9.2.4
> diff -u -d -r1.9.2.3 -r1.9.2.4
> --- render.cpp 30 Aug 2003 06:48:38 -0000 1.9.2.3
> +++ render.cpp 7 Sep 2003 05:06:26 -0000 1.9.2.4
> @@ -447,7 +447,8 @@
> assert(clipping_windows);
>
> endpoint_x_coordinates= new int16[MAXIMUM_ENDPOINTS_PER_MAP];
> - polygon_index_to_sorted_node= new (struct sorted_node_data
> *)[MAXIMUM_POLYGONS_PER_MAP];
> + typedef struct sorted_node_data *sndp;
> + polygon_index_to_sorted_node= new sndp[MAXIMUM_POLYGONS_PER_MAP];
> assert(endpoint_x_coordinates&&polygon_index_to_sorted_node);
>
> return;
|
|
From: Br'fin <br...@ma...> - 2003-09-03 19:56:44
|
Grunt, Half back to the drawing board on CFontSpec. Not that I don't
want to do the following things. But because CFontSpec itself seemed to
be getting out of hand for a relatively 'simple' class.
I think I'm going to simplify the class, then try to work through
things again, forcing back and around on code paths that currently use
TextSpecs.
-Jeremy Parsons
On Monday, September 1, 2003, at 01:51 AM, Br'fin wrote:
> Following is what I'm currently trying to setup for handling
> CFontSpecs ... a combination of font, size, and style.
>
> Oddly enough, all the details you think might be here aren't.
>
> Constructing a CFontSpec_Impl is left to the drawing context. As are
> most of the ways one would access things such as text width. And most
> of the interesting details are all stored in the platform specific
> implementation (Not yet devised)
>
> Usage might go something like
>
> CBuffer::Context context=buffer.get_drawing_context()
> CFontSpec my_font(context->get_font("Monaco", 24, CFontSpec::bold));
> int height= context->get_font_height(my_font);
> int width= context->get_text_width("Hello world", my_font);
> context->draw_text("Hello world", CPoint(0, 0), my_font,
> CColor::white);
>
> I decided to have all access through the context as the font may be
> specific (and cached) for the current buffer. (An OpenGL font spec,
> for instance, would probably own the storage of the appropriate
> display lists for each character.) Also, the context may have need to
> finesse the resulting values of these functions.
>
> For instance, I'm thinking of a scaled buffer type. (The actual buffer
> is perhaps the whole screen, but only claims to be 640x480) Where the
> drawing context is the main agent performing the transformations.
> Deciding that it should use large point sizes and the like. And
> needing to do two way transformations.
>
> Scaling is 2x
> Request for 24 point font becomes a 48 point font
> Request for text width fetches the actual value, then divides by two
> Request to draw at 0, 10 is changed into drawing at 0, 20
> etc, etc
>
> -Jeremy Parsons
>
|
|
From: Br'fin <br...@ma...> - 2003-09-01 05:50:37
|
Following is what I'm currently trying to setup for handling CFontSpecs
... a combination of font, size, and style.
Oddly enough, all the details you think might be here aren't.
Constructing a CFontSpec_Impl is left to the drawing context. As are
most of the ways one would access things such as text width. And most
of the interesting details are all stored in the platform specific
implementation (Not yet devised)
Usage might go something like
CBuffer::Context context=buffer.get_drawing_context()
CFontSpec my_font(context->get_font("Monaco", 24, CFontSpec::bold));
int height= context->get_font_height(my_font);
int width= context->get_text_width("Hello world", my_font);
context->draw_text("Hello world", CPoint(0, 0), my_font,
CColor::white);
I decided to have all access through the context as the font may be
specific (and cached) for the current buffer. (An OpenGL font spec, for
instance, would probably own the storage of the appropriate display
lists for each character.) Also, the context may have need to finesse
the resulting values of these functions.
For instance, I'm thinking of a scaled buffer type. (The actual buffer
is perhaps the whole screen, but only claims to be 640x480) Where the
drawing context is the main agent performing the transformations.
Deciding that it should use large point sizes and the like. And needing
to do two way transformations.
Scaling is 2x
Request for 24 point font becomes a 48 point font
Request for text width fetches the actual value, then divides by two
Request to draw at 0, 10 is changed into drawing at 0, 20
etc, etc
-Jeremy Parsons
///////////////////////////////////////////////////////////////////////
//
// $Id: CFontSpec.h,v 1.1.2.1 2003/03/26 05:33:30 brefin Exp $
///////////////////////////////////////////////////////////////////////
//
/*
* CFontSpec.h
* AlephModular
*
* Created by Br'fin on Sun Aug 31 2003.
*
*/
#ifndef _CFONTSPEC_H
#define _CFONTSPEC_H
#include "cstypes.h"
#include <memory>
class CFontSpec
{
public:
class CFontSpec_Impl
{
public:
typedef std::auto_ptr<CFontSpec_Impl> Ptr;
protected:
CFontSpec_Impl() {}
CFontSpec_Impl(const CFontSpec_Impl& impl) {}
private:
// Prevent copying/assignment
CFontSpec_Impl& operator=(const CFontSpec_Impl& impl) { return
*this; }
// Private interface, accessed by CFontSpec
friend class CFontSpec;
virtual int16 _get_height() = 0;
virtual int16 _get_line_spacing() = 0;
virtual Ptr _clone() = 0;
friend class std::auto_ptr<CFontSpec_Impl>;
virtual ~CFontSpec_Impl();
};
enum StyleFlag {
normal = 0,
bold = 1,
italic = 2,
underline = 4,
outline = 8,
shadow = 0x10,
condense = 0x20,
extend = 0x40
};
typedef unsigned short Style;
private:
CFontSpec_Impl::Ptr impl;
// Only our factory class (whatever it is) may use this
CFontSpec(CFontSpec_Impl::Ptr _impl) : impl(_impl) {}
// We don't let the user use these routines directly
// instead they need to access relevant functions on the drawing
context.
// Why? So the context can adjust these values by any scaling
properties
// that it might have.
friend class CDContext;
int16 get_height() { return impl->_get_height(); }
int16 get_line_spoacing() { return impl->_get_line_spacing(); }
public:
CFontSpec(const CFontSpec& spec) : impl(spec.impl->_clone()) {}
CFontSpec& operator=(const CFontSpec& spec);
~CFontSpec() {}
};
inline CFontSpec& CFontSpec::operator=(const CFontSpec& spec)
{
if (this == &spec) return *this; // Gracefully handle self assignment
CFontSpec_Impl::Ptr tmp= spec.impl->_clone();
impl= tmp;
return *this;
}
#endif
|
|
From: Br'fin <br...@ma...> - 2003-08-31 05:03:30
|
On Saturday, August 30, 2003, at 10:19 PM, Timothy Collett wrote: > (Having read your summary...) > > Really neat; I even understood more than half of it (yay me!). > > One thing I'm not quite clear on, though: what will this drawing > abstraction layer do with respect to some of the additions to A1 > (OpenGL, 3D models, etc)? > Will it make it easier or harder, or is it a totally separate issue? > I'm curious, because while, like I said, I understand a lot more than > I did, there's still a lot I don't understand :-P > > But I'm trying to learn! > > Thanks a lot! > > Timothy Collett I'm hoping that the Drawing Abstraction is usable for some OpenGL things. Most notably setup and teardown of the OpenGL environment itself and for 2D elements under OpenGL. (Basically I want a derivative of CPlatformBuffer which is a COpenGLBuffer which then roots appropriate CPlatformOpenGL buffers...) This might have some interesting side effects. For one the main menu might end up being run in OpenGL for better for for worse, but I don't know for sure :) On the rendering side of things, stuff would still need to be rewritten to work with an OpenGL accelerated buffer. That's the concept at any rate, no timeframes at all I fear :) -Jeremy Parsons |
|
From: Timothy C. <tco...@ha...> - 2003-08-31 02:20:49
|
(Having read your summary...) Really neat; I even understood more than half of it (yay me!). One thing I'm not quite clear on, though: what will this drawing abstraction layer do with respect to some of the additions to A1 (OpenGL, 3D models, etc)? Will it make it easier or harder, or is it a totally separate issue? I'm curious, because while, like I said, I understand a lot more than I did, there's still a lot I don't understand :-P But I'm trying to learn! Thanks a lot! Timothy Collett Chaos reigns within. Reflect, repent, and reboot. Order shall return. ~haiku~ |
|
From: Br'fin <br...@ma...> - 2003-08-30 17:53:04
|
On Saturday, August 30, 2003, at 12:08 PM, Timothy Collett wrote: >> It's my impression that (in keeping with AM's spirit) these early >> versions of AM are as close to M2 as possible "from the outside". > > Yeah; that's pretty much my understanding, as well. I'd still like to > know what all the under-the-hood changes are, though :-) - Runs on MacOS X (This required appropriate serializers and glue. Sometimes new, sometimes adapted from my work and others upon A1.) - Has very few warnings when compiled 15 known warnings, 11 of which are me putting in #warning messages on things that should be touched upon. - Has basic file abstraction (CFileDesc) File paths are handled by a generic system which, when you open a file, hands you an enhanced iostream for the file. Saved files are also handled 'safely' in that the original file isn't touched until the temporary version of the file has been completely written to. Files implicitly close themselves when they go out of scope. There is a mechanism for handling file types. - Has an improved serializer AStreams replaces packing.h/.cpp and attempts to provide a typed and generally safe serializing facility. It can also raise exceptions if usage goes beyond the end of the stream and has api to process any structure as a list provided the structure has basic operators (<</>>) to read from/write to a stream. The work that I'm currently doing for Display Abstraction all relates to separating the Marathon code from the Mac Quickdraw APIs for it's view port. This consists of changes through many parts of the code. - A new abstraction for bitmaps/textures. (CBitmap) that specifies a potentially encoded array of pixels. (For instance, the bitmap for a wall or the viewport is a basic rectangular bitmap, but others, such as sprites are a bitmap with a distinct CMarathon2RLEDecoder class - A hierarchy of CBuffer classes that translate from a full out native buffer/GrafPtr to specialized abstract buffers which represent sub-parts of other buffers and which can even do pixel-quadrupling on a portion of a buffer. - A display hierarchy to handle asking for a main screen and handling updates of fades, colors, and buffers on that screen. - A drawing context that you can request of a buffer to perform higher level drawing operations on a buffer. Such as painting rectangles and pasting CBitmaps. The display abstraction isn't done yet. I've still got to get text handled by the system, and then bunches of loose ends to track down, such as places using Rect or other direct Quickdraw API. At which point I may land the Drawing Abstraction even though there's further tweaks to do on top of it (Things that are appropriate, but which aren't necessary for basic M2 operation, such as toggling from full screen to window, or fully fleshing out the drawing contexts). One of the builds on sf.net (the 0.3+) version represents the first time I got all of the basic CBuffer hierarchy in place. The results are rather dramatic, in part because that was the first time I had the infrastructure to clean up all of the most obvious graphical bugs. Fades don't flicker previous screens and software mode runs at full speed even in high-resolution mode. -Jeremy Parsons |
|
From: Timothy C. <tco...@ha...> - 2003-08-30 16:08:51
|
> It's my impression that (in keeping with AM's spirit) these early > versions of AM are as close to M2 as possible "from the outside". Yeah; that's pretty much my understanding, as well. I'd still like to know what all the under-the-hood changes are, though :-) As to the rest of your post (long-term vs. short term, etc), I completely agree. There's no doubt that A1 is currently the side that's useful and fun, but the solid foundation work Br'fin is putting in on AM will make it a better choice eventually. The best part, in my mind, about the idea of AM is being able to take the different pieces and stick them together in different ways (eg, just the renderer & map-stuff for a map editor; just the net & core stuff for a headless game server, etc). Well, that and the fact that once it's ready for prime-time, it'll be easier to understand, add to, etc ;-) So, once again, keep up the great work, Br'fin! And you, too, on A1, Woody! 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: Woody Z. I. <woo...@sb...> - 2003-08-30 14:36:07
|
Yeah, neat stuff Br'fin; congratulations! On Saturday, August 30, 2003, at 08:29 AM, Timothy Collett wrote: > Also, perhaps you could give a very brief summary of what AM has that > M2 does not...'cause I'm afraid I've lost track. It's my impression that (in keeping with AM's spirit) these early versions of AM are as close to M2 as possible "from the outside". So I doubt a user would notice much difference (well, except for it running natively under Mac OS X of course). Instead, so far most of the changes would be seen "from the inside"; i.e. in the code. AM is restructuring M2's internals into a strong, rigid framework, a foundation on which to build future additional features without things getting a bit slippery and sloppy as some things have in A1 (especially when cross-platform issues are considered). You know, replacing that wooden beam with this steel girder, drilling down to anchor on bedrock instead of just digging down into the dirt a few feet, etc. I suspect it may be a while before AM has visible feature enhancements over M2, but once it gets to that point, it ought to be fairly easy to add lots of features and have them work correctly on all platforms. I'll of course invite Br'fin himself to fill the gaps in the above and make any corrections... I know I'd also be curious to hear a brief 'state of the project' summary/opinion from the one who can comment best. I should note that one piece of AM technology, "AStreams", is already in use in some parts of Aleph One (principally the star protocol code) to handle data packing/byte-swapping issues. AStreams replace A1's "Packing" mechanism with something that's in most cases more pleasant to work with and easier to use correctly. Though I'd like to see more of this sort of thing - AM cleanliness coming to A1 - I know Br'fin's plan is to focus on the other way around: making AM clean, then moving over A1 features to it... and I certainly can't fault him for wanting to layer the goodies atop a sound foundation rather than trying to swap structural elements out from under a heavy shifting pile of code. I guess we'll just have to be patient :) At some point (if it continues to progress) I think AM will reach a sort of 'critical mass' where users and developers alike will find it more pleasant to work with than A1, at which point AM will quickly take over as the principal open-source descendant of Marathon. (Though, depending on how things go, it may appear more like a merging of the two projects than wholesale supplanting.) At the moment, though, it's awfully hard to overlook A1's allure, what with OpenGL rendering, wide cross-platform-ness, Internet netplay with latency hiding, Lua scripting including netscripts, scenario control over all sorts of things that were hard-coded in M2, etc. In other words, AM offers much more in the long term, I think, but A1 wins the short-run contest currently. Somewhat unfortunately, in this sort of effort, with sporadic contributions from volunteers each with his own wishlist and interests, I suspect the sexy short term is going to win out almost every time. We're lucky indeed to have the rare Br'fin willing to focus on the comparatively unglamorous (but vitally important) long term and work toward those goals. Woody |
|
From: Timothy C. <tco...@ha...> - 2003-08-30 13:29:54
|
Hooray! Real progress!! :-) How far along do you think this puts display abstraction as a whole? Or is it that quantifiable? Also, perhaps you could give a very brief summary of what AM has that M2 does not...'cause I'm afraid I've lost track. Keep up the great work, Br'fin! Timothy Collett No battle is ever won according to plan, but no battle was ever won without a plan, either. |
|
From: Br'fin <br...@ma...> - 2003-08-30 08:34:18
|
I've been plugging away on the Display Abstraction branch as of late. Turning over responsibility for drawing this that and the other thing. With the only major holdouts right now being text and the computer terminals. As an interesting recent detail, I just removed world_pixels completely. World_pixels was used to hold the back buffer used by the original M2 code. And now it's gone, the last bits of code (Notably map previews in saved games) are no longer dependent upon it, so I removed it. -Jeremy Parsons |
|
From: Br'fin <br...@ma...> - 2003-08-24 06:08:22
|
Mmm, curious self debate. Wether or not to chase screen_rectangle through the AM code and squash it in favor of using CBuffer::Rectangle everywhere. That way we don't get three separate views of rectangles screen_rectangle CBuffer::Rectangle platform native view A few things would still be aware of the old screen_rectangle things, but mostly in initialization of areas based around old rectangle dimensions. such as interface rectangles for the HUD and menu buttons for the main menu. -Jeremy Parsons |
|
From: Br'fin <br...@ma...> - 2003-08-19 06:51:48
|
Mmmf, random nuisance. Trying to tie drawing commands to the drawing context and found myself painting myself into a corner, mildly. Getting multiple drawing contexts for a buffer all works when you're accessing the exact same buffer. But there can be breakdowns if you try to access a drawing context for both a buffer and a clipped version of itself. Or worse, two different buffers which are each clipped versions of a third. All of the screen_drawing.cpp stuff assumed a set_port call first. Now that stuff is enveloped in a drawing context. Works fine if everything is working with the normal working buffer. But woe unto the one who was trying to operate with a clipped version of the working_buffer and then calls those routines which then seek the drawing_context of the working buffer (as opposed to the clipped buffer....) Anyhow, my choices are to either try and make it so that once a drawing context is declared, the current clipped buffer, the buffer that is its root and all other clipped buffers off that root just go right to the existing drawing_context. Or to just thread the current drawing_context down through the function stack as an argument. :) I imagine that the latter is rightest, but don't know if I need to be worrying about efficiency... probably not, especially if I pass the drawing context as a reference anyhow. -Jeremy Parsons |
|
From: Br'fin <br...@ma...> - 2003-08-19 06:15:23
|
On Saturday, August 16, 2003, at 01:52 PM, Michael Adams wrote: > I realize you are probably very busy working on other > things, but since AM seems targeted at making "clean" > code, I wonder what you think of targeting it towards > wxWindows. It would eliminate the UI split that > plagues AlephOne. It may be a while down the road but > just a thought. > > From a cross-platform zealot, > Michael D. Adams > mdm...@ya... Heh. For better or worse it seems the path I have chosen is closer to 'reinvent the wheel'. I believe I had a discussion with a similar subject early on in AM's life with Woody over focusing on SDL. Of course SDL had the added penalty of me having seen some of how it was implemented in A1. (Eeek!) And with native SDL being widgetless. (I get the feeling some of the PC titles are easier to shift into SDL just because they were all using game-based widgetry to begin with.) I do however agree with a cross-platform ideal. So I've been trying to set things up in AM where Carbon or wxWindows or SDL is just another supported platform, and the code of the engine is fairly agnostic. I haven't worked on much cross-platform projects before, and I do not know how well some things can be integrated in transitory steps. I admit GUI elements haven't been a priority so far. Trying to beat the Mac-isms out of the basic render_screen is rough :) The flip side is I've been really really happy with how some elements have come out. Such as AM's basic file handling. Or even partial display abstraction, which allowed me to get full speed updates out of the software renderer under MaCOS X. (A1 at best cheats in this area if you use Software rendering) -Jeremy Parsons |
|
From: Michael A. <mdm...@ya...> - 2003-08-16 18:15:50
|
I realize you are probably very busy working on other things, but since AM seems targeted at making "clean" code, I wonder what you think of targeting it towards wxWindows. It would eliminate the UI split that plagues AlephOne. It may be a while down the road but just a thought. From a cross-platform zealot, Michael D. Adams mdm...@ya... __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com |
