| Re: [AD] Proposed changes for Allegro 5 (6?) |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Sven Sandberg wrote:
[snip]
- `bmp_read8()' & co currently use longs instead of pointers. I think
this is an old djgpp-ism, because `_farnspokew()' take longs as
arguments. If someone knows a good reason why it must be this way,
please say it. Otherwise, can we please replace `unsigned long' by
`unsigned char *', `unsigned short *', and `unsigned long *'? It scares
me a bit because there's no reason to think that
sizeof(long)==sizeof(void*) on all platforms, plus there's apparently no
reason to store a pointer in a long.
Good idea. I'll add it to the list.
[snip]
- Possible merge of AllegroGL (as an OpenGL driver only, to keep it
Why can't it be in AllegroGL?
Well for one thing, it makes porting Allegro a lot easier. Many more
platforms have OpenGL support than they have SVGAlib support (for one
thing). So if I wanted to port Allegro to (let's say) the Playstation, I
almost don't have to worry about the graphics. GL is also accelerated on
just about every platform, so it's an added bonus.
- merge blit and sprite API
What do you mean? This sounds like "remove `draw_sprite()' and add an
extra parameter to `blit()' indicating whether transparent pixels should
be masked out",
You mean like masked_blit()? :DD
I mean that draw_sprite is equivalent to masked_blit already, but it less
flexible. I *think* they both use the same code (minus the extra clipping),
so I don't see why it wouldn't be done.
[snip]
- is_*_bitmap collapsed to a single function - get_bitmap_type()
Why? I think the bit field that such a function would have to return
would be a bit complicated, and some of those functions are very
different from each other.
Yes, but it makes it nicer for the assembly code to figure out if a bitmap
is a memory linear bitmap so that it can do some things which may not be
permitted on other bitmap types. Hahving it return a testable constant is
nice. We'd also get rid of the function entry points to is_*_bitmap. There
are 7 of them, and I don't see any users using them appart for some add-ons
which do specific things on those bitmaps.
- Dump draw_character
Why? It needs to be in the library because we need to draw text, so it
doesn't hurt to have it in the API, right?
Oh I see. I wasn't aware of it being used by the text code. It just didn't
seem that useful when reading back the description of the function :)
- Unified rotate_flip_pivot_stretch routine
There is already one: `_pivot_scaled_sprite_flip()' in aintern.h
Yep, so make this one public, then remove some of the other ones.
pivot_sprite and rotate_sprite could be kept as shortcuts to the
pivot_scaled_flip_sprite, but the others just bloat the API IMO.
- hsv_to_rgb and rgb_to_hsv in a separate lib
- Remove not-so-useful blenders (dissolve, dodge, hue, invert,
luminance, multiply, saturation, screen)
Why? They are all small and can't hurt much?
There are a lot of small things which can't hurt much which will make
Allegro be crushed under its own weight :)
hsv_to_rgb is somewhat useful, but I really don't see the others ever being
used at all.
- Fix this whole 32bpp == int, 16bpp == short thing. Use int16_t and
int32_t instead?
Why? I think this would break too much code, both in Allegro and in
user's code. Btw, 32bpp == long, not int.
So on 64 bit machines, 32bpp bitmaps waste twice the memory and memory
bandwidth - just great :)
I'd rather have them as type INT32, where INT32 can be defined as whatever
fits 32 bits in the current machine.
- true color fade in/out (Nathan)
Yes, this is probably such a frequent faq that it is worth implementing.
I was planning on adding those to FBlend, so the code can be merged in at
some later point :)
Text Drawing:
- textout should not use -1 for colored fonts.
Why? What else?
AllegroGL - makeacol(255, 255, 255, 255) is a perfectly valid color for a
font (which with no alpha blending), but gets interpreted by Allegro as
"Draw colored fonts". I'd rather have text_out split into two functions, or
at lesat have something like text_mode() but for enabling/disabling colored
fonts.
Packfiles:
- Allow registering of new compression and encryption libs.
Good idea, but nothing we need to wait for if nobody writes it.
I thought Peter Wang had already written it, but it was left as a patch on
Allegro.
- save_datafile() and save_datafile_object() (Nathan Smith)
I think these already exist in libaldat.a.
Yes, but it would be nice to have those in the main library, or at least
documented as being in aldat.
[snip]
- Move as much as possible to VTables
Any specific ideas on which functions this should include?
I did say everything :) polygon2d/3d (and family), and perhaps the Allegro
mixer.
- Drop DOS.
No, please! There are so many people who use djgpp, and there are no
problems with that port.
Then they can use Allegro 4.0 :)
Or switch to Mingw (see previous post).
[snip]
Documentation:
- Generated from source via Doxygen or Javadoc
Why? _tx files work perfectly, can generate more file formats than
anything else, and are self-contained, i.e. no need for user to download
another package with the help compiler. And some add-ons actually use
makedoc.
Documentation can be generated by one of the devs when making releases.
Also, it will help keep the docs in sync with the code.
[snip]
- Software 3D code
- 3D Math
I think these are too widely used to be removed.
Appart from some of the *Hack entries, I really don't see them being used at
all. Really. The 3d math one would most probably do better as a separate
package, and gain extra functionality. The software 3d is too slow to be of
any real use, and is still more complicated to use than OpenGL (IMHO).
[snip]
--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/