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/



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/