|
|
|
This thread is locked; no one can reply to it.
|
| Looking for allegro expert, that would help us with development |
|
kovarex
Member #14,203
April 2012
|
Hello, 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 that we would like to experiment in the future
www.factorio.com - a factory building game. |
|
Thomas Fjellstrom
Member #476
June 2000
 |
I think it would depend on what you're willing to pay. -- |
|
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 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
|
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 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. -- |
|
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 What kind of issue? It certainly is possible to do tiled drawing with anti aliasing already. -- |
|
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. ------------------------------------------ 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. www.factorio.com - a factory building game. |
|
Thomas Fjellstrom
Member #476
June 2000
|
I'd suggest never using memory bitmaps if you can help it. -- |
|
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. -- |
|
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
|
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). -- |
|
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). 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"} -- |
|
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
|
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? -- |
|
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 -- |
|
Arvidsson
Member #4,603
May 2004
 |
Hey, I bought factorio
|
|
|
