Allegro.cc - Online Community

Allegro.cc Forums » Allegro Development » Looking for allegro expert, that would help us with development

This thread is locked; no one can reply to it. rss feed Print
Looking for allegro expert, that would help us with development
kovarex
Member #14,203
April 2012

Hello,
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.

Edit:
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)

www.factorio.com - a factory building game.

Thomas Fjellstrom
Member #476
June 2000
avatar

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

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

kovarex
Member #14,203
April 2012

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 :)

www.factorio.com - a factory building game.

beoran
Member #12,636
March 2011

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.

kovarex
Member #14,203
April 2012

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 :)

www.factorio.com - a factory building game.

beoran
Member #12,636
March 2011

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
Member #476
June 2000
avatar

kovarex said:

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

As beoran said, already possible with 5.1.

Quote:

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.

Quote:

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.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Elias
Member #358
May 2000

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.

Quote:

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.

--
"Either help out or stop whining" - Evert

kovarex
Member #14,203
April 2012

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.
{"name":"zoomed-in-area-no-antialiasing.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/8\/2\/82d6da9e02ba694e1062281aab3472b6.png","w":627,"h":513,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/8\/2\/82d6da9e02ba694e1062281aab3472b6"}zoomed-in-area-no-antialiasing.png

Zoomed-in tiled group with multisampling:
{"name":"zoomed-in-area-antialiasing.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/7\/9774608512ffc1de0770ba0532311ceb.png","w":690,"h":559,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/7\/9774608512ffc1de0770ba0532311ceb"}zoomed-in-area-antialiasing.png

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.

www.factorio.com - a factory building game.

Thomas Fjellstrom
Member #476
June 2000
avatar

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

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Elias
Member #358
May 2000

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.

--
"Either help out or stop whining" - Evert

kovarex
Member #14,203
April 2012

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.

www.factorio.com - a factory building game.

Thomas Fjellstrom
Member #476
June 2000
avatar

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).

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

beoran
Member #12,636
March 2011

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.

Elias
Member #358
May 2000

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).

#SelectExpand
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}

{"name":"608694","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/2\/929111a407115be54cd5fb6ea1919540.png","w":640,"h":704,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/2\/929111a407115be54cd5fb6ea1919540"}608694

--
"Either help out or stop whining" - Evert

beoran
Member #12,636
March 2011

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

kovarex
Member #14,203
April 2012

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

www.factorio.com - a factory building game.

beoran
Member #12,636
March 2011

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

Thomas Fjellstrom
Member #476
June 2000
avatar

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?

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Elias
Member #358
May 2000

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

--
"Either help out or stop whining" - Evert

Arvidsson
Member #4,603
May 2004

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

Go to: