Looking for allegro expert, that would help us with development

I hope I'm in the right forum for this kind of question.
Basically we are looking for someone, who is experienced with allegro development and internals to help us develop allegro to support features we need, to fix some specific problems, optimise some parts, refactor/comment some code when needed etc.

The work would be paid and the changes, if accepted, would be pushed to the public allegro rep to let others use it.

Things we would like to have for sure:

  • Provide texture compression in allegro.

  • Optimise the sprite drawing in opengl (we did some optimisations for d3d already making it two times the fast).

  • Solve bug with al_create_bitmap not failing correctly on apple. It results in creation of corrupted bitmaps instead.

  • Try to implemenet 1bpp bitmap format

  • Solve the severe performance problems when drawing bitmap that doesn't fit the target completely in some modes

  • Changes in the sound system, to allow perfect matching for tiled sounds.

Things that we would like to experiment in the future

  • Allow simple 3d rendering in combination with the 2d rendering

  • Allow multithreaded rendering

  • Allow post-draw antialiasing (I don't know if this is possible, but the
    issue is with tiled graphics and antialising)

Thomas Fjellstrom

I think it would depend on what you're willing to pay.


It depends on the model we would agree on (we prefer to pay per-hour) and on the amount you ask for :)
It shouldn't be less than what you would get in regular programming job.

TL;DR Fair amount :)


Thanks for your list of features you'd like. Actually, I'd say that I think all of the features or bug fixes you're asking for sound reasonable, and some of them could even be implemented by us non-paid programmers. Personally I'm currently unable to accept payment for working on Allegro, but I'd be willing to look into certain of these features you'd like out of own interest, after I finish the port of the force feedback subsystem to windows.

In the interest of the development of Allegro though, could you please complete your list of desired features and bug fixes and if possible assign your priorities? Then we can see how this would fit into the road map of Allegro.

beoran said:

Personally I'm currently unable to accept payment for working.

What do you mean by unable? :)

I added few things I remembered we wanted, I could edit it in the future to add things that I remember later, but it won't be possible in this forum system, as the thread will be locked automatically soon :)


Yes, I'm "unable" to receive payment as in "legally unable". Taxes and labour laws can complicate things, certainly outside the USA.

As for the feature list, thank you for detailing it. You can make a new page in the Wiki with your feature requests and link the Roadmap to it.

Now for the features already on the list:

I'm interested myself in texture compression, but I'm unsure how the API should look like, and also, we need to use compression code that is zlib license compatible.

Optimizations are always welcome, as long as they don't threaten the stability of allegro.

Bugs should be fixed, and I hope someone who has OSX will see into why al_create_bitmap doesn't fail correctly.

Monochrome bitmaps could be interesting for masking effects or simple shadows. I'm also somewhat interested in this.

In Allegro, bitmaps should be loaded after setting the display mode. There's not much that can be done about that, and IIRC, SDL2 has the same limitation...

Which changes does the sound system need? Is it currently not accurate enough to play perfectly matching "tiled" sounds? What are "Tiled" sounds anyway?

Simple 3d rendering is already possible in 5.1 with perspective transformations and al_draw_prim, etc. There was a thread in the "programming" forum that had examples on how to do this.

Multi threaded rendering is likely to be impossible since that is a limitation imposed by the Windows API. The rendering thread must be the one that opened the display window. SDL2 also has the same limitation for the same reasons.

I'm not quite clear what you mean with "post-draw" antialiasing. Could you describe the problem more in detail, as well as what kind of effect you'd like to achieve?

Thomas Fjellstrom
kovarex said:

Allow simple 3d rendering in combination with the 2d rendering

As beoran said, already possible with 5.1.


Allow multithreaded rendering

It is technically possible to render to the same display or bitmap with multiple threads. But due to api limitations in Direct3D and OpenGL, only one thread can "own" and thus render into a given target at a time.


Allow post-draw antialiasing (I don't know if this is possible, but the
issue is with tiled graphics and antialising)

Assuming you mean the type that just renders a much larger offscreen backbuffer, and the card then scales that down to get cheap AA, well that should be possible by enabling MSAA and other similar options.

kovarex said:

Solve the severe performance problems when drawing bitmap that doesn't fit the target completely in some modes

What does that mean? There should be no penalty for not fitting at all.


Allow post-draw antialiasing (I don't know if this is possible, but the
issue is with tiled graphics and antialising)

What kind of issue? It certainly is possible to do tiled drawing with anti aliasing already.


I made performance tests, and when I was drawing from memory bitmap to video bitmap, it was quite fast (only 3 times slower than video->video bitmap drawing) as long as source image fitted the target.

Once the source image was larger, the drawing time got dramatically slower, directly depending on the count of the pixels not fitting the target image.

It was tested in the last allegro version.

The tiling problem is best to be explained on examples.

Zoomed-in tiled ground without multisampling.

Zoomed-in tiled group with multisampling:

You can see, in the multisampling version the edges between individual tiles, it is more visible in closer zooms. The same problems are with any tiled graphics we use. Maybe it is not solvable normal way, I was just asking if there isn't some way to solve it.

Thomas Fjellstrom

I'd suggest never using memory bitmaps if you can help it.


Which option are you using for your tiled graphics? And how are you drawing them? It looks more like texture filtering than multisampling to me.


Actually, we plan to use memory bitmaps a lot, because the video memory is very limiting factor.

The plan is to have the main atlas as video bitmap and it would work as cache for the pictures needed.

Thomas Fjellstrom

Ok, I think that's a valid use if video ram is that tight for you. But these days even cheap gpu's have 1GB+ ram. Why is video ram so tight you can only use a single main atlas?

I really meant that you shouldn't use memory bitmaps to draw regularly to the display (rather than to preload into memory to copy into an atlas).


Ok, if large memory bitmaps blit very slowly this is probably due to clipping being done very conservatively. Also, the software drawing routines could do with some optimizing. No guarantees, but I think perhaps something could be done about this problem.

As for the multisampling, I think the issue here is that after the video bitmaps applies the effect, the tiles edges become perturbed and don't tile well anymore. I'd say that multisampling probably isn't a good idea for tiled graphics. In stead, a classic pixel art scaling algorithm like 2SAI, etc, or Siegelord's lovely pixel scaler here: https://www.allegro.cc/forums/thread/612318 might give better results.


I'd say the issue is that bitmap filtering (enabled with ALLEGRO_MAG_LINEAR) at the bitmap border simply does have a seam. Look at the example below.

I create a completely random 16x16 texture. In the upper half of the screen I tile the screen with 16x16 bitmaps made from that texture.

In the lower half I also tile the screen with the same 16x16 texture - except this time I used a texture atlas where the tile has the neighbor tile pixels around itself. Now there is no more seam at all.

Another way to do this programmatically without creating the neighbor pixels in the texture atlas would be to use a shader to do the texture sampling. But I don't think any other change to Allegro will help (you can already use a shader).

1#include <allegro5/allegro5.h> 2 3static void create_random_texture(int s, char *rgba) { 4 for (int y = 0; y < s; y++) { 5 for (int x = 0; x < s; x++) { 6 rgba[y * s * 4 + x * 4 + 0] = rand(); 7 rgba[y * s * 4 + x * 4 + 1] = rand(); 8 rgba[y * s * 4 + x * 4 + 2] = rand(); 9 rgba[y * s * 4 + x * 4 + 3] = 255; 10 } 11 } 12} 13 14static void copy_data_to_bitmap(int s, char *rgba, int sx, int sy, 15 int dx, int dy, int w, int h, ALLEGRO_BITMAP *bitmap) { 16 ALLEGRO_LOCKED_REGION *region = al_lock_bitmap(bitmap, 17 ALLEGRO_PIXEL_FORMAT_ABGR_8888_LE, 18 ALLEGRO_LOCK_WRITEONLY); 19 for (int y = 0; y < h; y++) { 20 for (int x = 0; x < w; x++) { 21 char *p = region->data; 22 p += (dy + y) * region->pitch + 4 * (dx + x); 23 char *q = rgba + ((sy + y) & (s - 1)) * s * 4 + 24 4 * ((sx + x) & s - 1); 25 p[0] = q[0]; 26 p[1] = q[1]; 27 p[2] = q[2]; 28 p[3] = q[3]; 29 } 30 } 31 al_unlock_bitmap(bitmap); 32} 33 34int main(void) { 35 al_init(); 36 al_install_keyboard(); 37 38 ALLEGRO_DISPLAY *display = al_create_display(64 * 10, 64 * 11); 39 al_set_new_bitmap_flags(ALLEGRO_MAG_LINEAR); 40 41 int s = 16; 42 char rgba[s * s * 4]; 43 create_random_texture(s, rgba); 44 45 ALLEGRO_BITMAP *tile = al_create_bitmap(s, s); 46 copy_data_to_bitmap(s, rgba, 0, 0, 0, 0, s, s, tile); 47 48 ALLEGRO_BITMAP *atlas = al_create_bitmap(1024, 1024); 49 copy_data_to_bitmap(s, rgba, -1, -1, 0, 0, s + 2, s + 2, atlas); 50 51 52 for (int y = 0; y < 5; y++) { 53 for (int x = 0; x < 10; x++) { 54 al_draw_scaled_bitmap(atlas, 0, 0, 16, 16, 55 x * 64, y * 64, 64, 64, 0); 56 } 57 } 58 for (int y = 6; y < 11; y++) { 59 for (int x = 0; x < 10; x++) { 60 al_draw_scaled_bitmap(atlas, 1, 1, 16, 16, 61 x * 64, y * 64, 64, 64, 0); 62 } 63 } 64 65 al_flip_display(); 66 while (true) { 67 ALLEGRO_KEYBOARD_STATE key; 68 al_get_keyboard_state(&key); 69 if (al_key_down(&key, ALLEGRO_KEY_ESCAPE)) 70 break; 71 al_rest(0.01); 72 } 73 74 return 0; 75}



Elias, that's interesting but I see in the code that you are using the atlas in both cases. Isn't that a mistake?


Elias, but we have the neighbour tile pixels around pictures in atlas already. It was needed to avoid different, bigger kind of problmes.


kovarex, maybe a code snippet could demonstrate what you are doing exactly in your game?

Thomas Fjellstrom
kovarex said:

Elias, but we have the neighbour tile pixels around pictures in atlas already. It was needed to avoid different, bigger kind of problmes.

Maybe it needs a larger boarder to cover for the extra amount of sampling those filters use?


Beoran: yeah, first version was supposed to use the tile. But since it's the atlas border the mistake is the same :p


Hey, I bought factorio :) Awesome game, never realized you made it with allegro - that is cool!

Thread #614329. Printed from Allegro.cc