| Re: [AD] New graphics API, take 2 |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Shawn Hargreaves wrote:
[snip]
How is putting things in the bitmap vtable any worse than
in the display vtable? There's no cost from vtables being
huge (only one of them needs to exist per type, so it is
an insignificant space overhead).
Well at first I thought that adding more entries to the vtable would mean
that each bitmap would use more memory for overhead. But then I released
that they keep a pointer to the vtable instead. So yes, you're right, adding
more entries to the vtable comes with (virtually) no cost.
[snip]
Well, I'd consider using the init_dialog/update_dialog/
end_dialog loop for anything more complicated than a simple
dialog
Sure. But my point was that if there is a single polymorphic
type, it can be much more flexible than if there are different
types for slightly different things. In the former case, you
can make the same piece of code do quite different things just
by passing it a different object, but if the types are
different, you have to change code to get the same effect.
This is just an extension of how bitmaps can already be
anything from simple bits of memory to blocks of video memory
to sub regions of other bitmaps to potentially GL textures
or whatever (and people were talking about making RLE and
compiled sprites be special types of bitmaps as well, which
is an appealing idea).
I'm just not seeing what it is about display surfaces in
particular that requires them to be a different type, when
a lot of the power of the current API comes from the fact
that so many different things can be accessed through the
same type. Pretty much everything you can do to a bitmap
also makes sense to do to a display, and every display
object must always have a bitmap associated with it, so
why maintain a difference between them?
You're right, of course.
[snip - D3D8 is crap]
Heh ok, I see what you meant. I'll make the necessary modifications.
[snip]
Finally, there's the icky issue of sub bitmaps. If the user
declares a subbitmap of the 'screen', then passes that to
al_show_dissplay() (al_show_bitmap?), then what? Copy only
that sub-bitmap?
[...]
What if the user passes a non-screen bitmap object?
Obviously, not all operations can be supported on all types
of bitmap. It is nonsense to try to page flip a memory bitmap,
but that doesn't mean you shouldn't be able to use the exact
same code to draw rectangles onto anything, be it a memory
bitmap or a video bitmap or a display surface or whatever...
Right.
--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/