I have some questions about how the design of the Allegro library. I know these questions have an answer somewhere deep in the forum, but it's very difficult to find them (I have to read entire discussions in order to get the answers I am seeking for). So, if anyone has a little spare time, it would be greatly appreciated if the following questions are answered (with simple sort explanations, nothing fancy or heavily detailed):
there are string functions that convert primitive types to UTF8 strings, but there are no functions to convert strings to primitive types. Is there any plan for functions that convert UTF8 strings to primitives, or are C's functions enough? I know UTF8 is compatible with ASCII, so most probably the existing functions are ok (strtol etc), but I would like a confirmation.
why the add-ons? perhaps this has been debated to death, but I see no reason why necessary functionality like fonts, audio, colors, primitive drawing and image I/O are add-ons. Are the add-ons so big that they bloat the core library so much that they have to be add-ons? or is there some other reason?
what is the difference between al_draw_line and al_draw_line_ex? Is al_draw_line not accelerated, while al_draw_line_ex is?
I saw that the examples do not make use of the function al_wait_for_vsync, except for ex_prim. Is it not really required? I did not see the shearing effect in other examples. Most examples use al_rest. Is it because the examples are in windowed mode that I do not see the shearing effect?
are displays and bitmaps thread safe? can I draw onto them using different threads?
Thank you for your attention.
1. there are string functions that convert primitive types to UTF8 strings, but there are no functions to convert strings to primitive types. Is there any plan for functions that convert UTF8 strings to primitives, or are C's functions enough? I know UTF8 is compatible with ASCII, so most probably the existing functions are ok (strtol etc), but I would like a confirmation.
al_cstr(). Later we will add conversions to/from UTF-16 and (probably) UCS-4. Non-unicode encodings will not be supported.
2. why the add-ons? perhaps this has been debated to death, but I see no reason why necessary functionality like fonts, audio, colors, primitive drawing and image I/O are add-ons. Are the add-ons so big that they bloat the core library so much that they have to be add-ons? or is there some other reason?
Lots of reasons. Bloat you have mentioned. Pulling in external dependencies is another.
Modularity: we try to not use too many library internals inside addons, which improves understandability, maintainability and confirms our designs.
You can choose to not use any addon that you feel is inadequate, e.g. some people require a more advanced audio library than we provide.
Also, we like to trip up newbies.
3. what is the difference between al_draw_line and al_draw_line_ex? Is al_draw_line not accelerated, while al_draw_line_ex is?
al_draw_line used to be in the core before the primitives addon was added (which had its own function, al_draw_line_ex). Now the one in the core has been deleted in favour of the primitives addon, and al_draw_line_ex renamed to al_draw_line.
4. I saw that the examples do not make use of the function al_wait_for_vsync, except for ex_prim. Is it not really required? I did not see the shearing effect in other examples. Most examples use al_rest. Is it because the examples are in windowed mode that I do not see the shearing effect?
Or your video card driver waits for vsync? Or maybe because most of the examples are quite static so you're unlikely to see shearing? Not sure.
5. are displays and bitmaps thread safe? can I draw onto them using different threads?
Not simultaneously, at least for the foreseeable future.
Actually, I'm never sure about the restrictions either so hopefully someone can explain it to me again.
Quote:
4. I saw that the examples do not make use of the function al_wait_for_vsync, except for ex_prim. Is it not really required? I did not see the shearing effect in other examples. Most examples use al_rest. Is it because the examples are in windowed mode that I do not see the shearing effect?
Or your video card driver waits for vsync? Or maybe because most of the examples are quite static so you're unlikely to see shearing? Not sure.
al_flip_display() already waits for vsync, so calling al_wait_for_vsync will wait for another vsync - it would be a mistake to use it. The documentation needs to be clearer in both al_flip_display() and al_wait_for_vsync(). As was discussed on the mailing list, there will be a flag to al_set_new_display_options() to disable automatic vsync (if the driver supports it). And there also is a feature request to support triple buffering (again if the driver support it).
With all of those solutions, you never call al_wait_for_vsync. It's only use would be to time the monitor frequency I guess. But right now only the D3D driver has it implemented as far as I know, so better to call al_flip_display if you want to time the monitor frequency.
Quote:
5. are displays and bitmaps thread safe? can I draw onto them using different threads?
Not simultaneously, at least for the foreseeable future.
Actually, I'm never sure about the restrictions either so hopefully someone can explain it to me again.
For OpenGL, this is what the GLX specification says:
Note that when multiple threads are using their current contexts to render to
the same drawable, OpenGL does not guarantee atomicity of fragment update operations. In particular, programmers may not assume that depth-buffering will automatically work correctly; there is a race condition between threads that read and update the depth buffer. Clients are responsible for avoiding this condition. They may use vendor-specific extensions or they may arrange for separate threads to
draw in disjoint regions of the framebuffer, for example.
However, I wouldn't be sure the same is true for OSX - it already is problematic there processing events not from the main thread, so they might have more threading restrictions also in their OpenGL implementation.
Also not sure about WGL or DirectX, but I'd expect them to be more like Linux. To be on the safe side, use locking for now.
As for using our software routines - all state like new bitmap settings or the current blending mode are stored per-thread and all functions should be thread safe in that they don't modify or depend on any other global state. However, you should not access the same ALLEGRO_BITMAP (including the display backbuffer) simultaneously. So if you have to do that, use a lock. Two threads can work on two different bitmaps without problems and without locking though.