Allegro TODO

Allegro TODO

Thomas Fjellstrom

Member #476

June 2000

Want to help Allegro? Don't know where to start?

http://wiki.allegro.cc/AllegroTODO

I will be happy to mentor anyone needing help working on any of the items in the list. If you are a Dev, please post if you are willing or not willing to help mentor people.

Also, if you are a dev, please try and see if the todo there is up to date and accurate. I'm not sure if "Make the library internally thread-safe." is valid anymore, I remember a large amount of work went into that not too long ago.

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

GullRaDriel

Member #3,861

September 2003

That is a good idea !

Todo said:

Make (at least truecolor) mask color modifyable.

I want this one for years ! If I have time I will contribute !

"Code is like shit - it only smells if it is not yours"
Allegro Wiki, full of examples and articles !!

Matt Smith

Member #783

November 2000

It should be modifiable already. What doesn't work when you change it?

On a similar note, I think we should have one RGBA format which does not depend on the current graphics mode, and can be cast to the matching GL type. If we choose to hardcode the available depths then this should be one of them.

GullRaDriel

Member #3,861

September 2003

It is modifiable, yeah, but not on the fly as they are #defines.

color.h

#define MASK_COLOR_8       0
#define MASK_COLOR_15      0x7C1F
#define MASK_COLOR_16      0xF81F
#define MASK_COLOR_24      0xFF00FF
#define MASK_COLOR_32      0xFF00FF

So you need to recompile the library each time you change.

"Code is like shit - it only smells if it is not yours"
Allegro Wiki, full of examples and articles !!

Matt Smith

Member #783

November 2000

Ah. I thought mask_color was in BITMAP, but it is in GFX_VTABLE so is shared between all bitmaps of the same type. It should be fairly trivial to move it into the BITMAP struct instead.

And for now, you could do bmp->vtable->mask_color = My_Preferred_Color; as long as you are aware that it affects all bitmaps of that type.

EDIT: hmm, maybe not. Several places in the code use these defines directly instead of refering to the vtable. This includes stretch_masked_blit() but not plain masked_blit() which uses bitmap_mask_color() correctly.

Thomas Fjellstrom

Member #476

June 2000

While the asm was still regarded the ASM as important, trying to modify the MASK_COLOR would require some major changes across the C and ASM code. Now its not such an issue I don't think, especially since its been a major wanted feature for years now.

Matt Smith

Member #783

November 2000

Ah good point. the 24/32bit asm version of masked_blit() (IIRC, too busy to check right now) doesn't even honour the define. It compares each byte individually for 255,0,255

But still, it wouldn't take too much to fix up masked_blit(), stretch_masked_blit(), draw_sprite() and rotate_sprite(). Any others I haven't thought of there?

Also, is a function to set the color (without needing a bitmap to refer to for depth and type) necessary? Would you set the individual type (system, memory, video etc) or would the function set the vtable->mask_color of all types? e.g.

void set_mask_color(int depth, int color);

Thomas Fjellstrom

Member #476

June 2000

Ugghh. Sorry about the downtime guys. The IDE card I was using to attach the 80GB disk that's hosting the new Xen images decided to have a fit while I was away at my dads.

May 26 17:39:56 edgar kernel: megaraid: aborting-578928 cmd=2a <c=4 t=0 l=0>
May 26 17:39:56 edgar kernel: megaraid abort: 578928:13[255:128], fw owner
May 26 17:44:57 edgar kernel: megaraid mbox: critical hardware error!
May 26 17:44:57 edgar kernel: megaraid: hw error, cannot reset

Fun times.

I'll attempt to fix it tonight, but if its really a dead card, I'll have to wait till tomorrow to move stuff around.

edit: Rebooted after seeing some similar errors in google. might be a driver bug. God I hope not. But the wiki is fine again.

Michael Jensen

Member #2,870

October 2002

I'd love to help, but it seems that everything is way over my head. If there's anything mindless that can't be done with a tool (or maybe needs a tool made for it to be done) I wouldn't mind helping.

EDIT: WAIT! I totally did something on the wish list, or at least part, thick primitives were easy to make! I bet they're slow as all hell, but I totally attached code. Hope it wasn't a waste of time on my part.

EDIT2: Corrected an error, so I had to reattach.

EDIT3: Third time's a charm.

GullRaDriel

Member #3,861

September 2003

You should provide a diff with integration inside allegro

"Code is like shit - it only smells if it is not yours"
Allegro Wiki, full of examples and articles !!

Timorg

Member #2,028

March 2002

I saw Michael's thick circle code, and it got me thinking about how a thick lined
circle could be drawn, and I came up with the following solution

1#include <allegro.h>
2 
3#include <math.h>
4 
5void thick_circle(BITMAP *bmp, int x, int y, int radius, int thickness, int color)
6{
7   int outer_radius, inner_radius;
8   int or2, ir2;
9   int yo, yo2;
10   int outer_x, inner_x;
11   int odd;
12 
13   if (thickness <= 0)
14      return;
15 
16   if (thickness == 1) {
17      circle(bmp, x, y, radius, color);
18      return;
19  }
20 
21   odd = ((thickness + 1) % 2);
22   outer_radius = radius + ((thickness - odd) / 2);
23   inner_radius = radius - ((thickness - odd) / 2) - odd;
24 
25   or2 = outer_radius * outer_radius;
26   ir2 = inner_radius * inner_radius;
27 
28   for (yo = outer_radius; yo > inner_radius; yo--) {
29      yo2 = yo * yo;
30      outer_x = sqrt(or2 - yo2);
31      hline(bmp, x - outer_x, y - yo, x + outer_x, color);
32      hline(bmp, x - outer_x, y + yo, x + outer_x, color);
33   }
34 
35   for (yo = inner_radius; yo >= -inner_radius; yo--) {
36      yo2 = yo * yo;
37      inner_x = sqrt(ir2 - yo2);
38      outer_x = sqrt(or2 - yo2);
39      hline(bmp, x + inner_x, y - yo, x + outer_x, color);
40      hline(bmp, x - inner_x, y - yo, x - outer_x, color);
41   }
42 
43}
44 
45int main()
46{
47  allegro_init();
48  install_keyboard();
49 
50  set_color_depth(8);
51  set_gfx_mode(GFX_AUTODETECT_WINDOWED, 800, 600, 0, 0);
52 
53  thick_circle(screen, 400, 300, 150, 10, makecol(255,255,255));
54 
55  readkey();
56 
57  return 0;
58}
59END_OF_MAIN()

I added the function to gfx.h and gfx.c, and then compiled allegro under linux (ubuntu 6.2), allegro seemed to compile fine, (I didnt see any errors), but for some reason I cant get allegro programs to run (it can find the shared library and everything, they just dont do anything, and the examples go to a black screen and lock everything up and I need to restart to get out of it)

So I went back to windows and mingw, got a copy of 4.2.1 and applied the patch I made http://www.timorg.net/thick/circlethick.diff

1Index: 4.2/src/gfx.c
2===================================================================
3--- 4.2/src/gfx.c  (revision 7890)
4+++ 4.2/src/gfx.c  (working copy)
5@@ -1083,8 +1083,49 @@
6    bmp->clip = clip;
7 }
8 
9+/* circlethick:
10+ *  Draws a circle of variable thickness.
11+ */
12+void circlethick(BITMAP *bmp, int x, int y, int radius, int thickness, int color)
13+{
14+   int outer_radius, inner_radius;
15+   int or2, ir2;
16+   int yo, yo2;
17+   int outer_x, inner_x;
18+   int odd;
19 
20+   if (thickness <= 0)
21+      return;
22 
23+   if (thickness == 1) {
24+      circle(bmp, x, y, radius, color);
25+      return;
26+   }
27+
28+   odd = ((thickness + 1) % 2);
29+   outer_radius = radius + ((thickness - odd) / 2);
30+   inner_radius = radius - ((thickness - odd) / 2) - odd;
31+
32+   or2 = outer_radius * outer_radius;
33+   ir2 = inner_radius * inner_radius;
34+
35+   for (yo = outer_radius; yo > inner_radius; yo--) {
36+      yo2 = yo * yo;
37+      outer_x = sqrt(or2 - yo2);
38+      hline(bmp, x - outer_x, y - yo, x + outer_x, color);
39+      hline(bmp, x - outer_x, y + yo, x + outer_x, color);
40+   }
41+
42+   for (yo = inner_radius; yo >= -inner_radius; yo--) {
43+      yo2 = yo * yo;
44+      inner_x = sqrt(ir2 - yo2);
45+      outer_x = sqrt(or2 - yo2);
46+      hline(bmp, x + inner_x, y - yo, x + outer_x, color);
47+      hline(bmp, x - inner_x, y - yo, x - outer_x, color);
48+   }
49+}
50+
51+
52 /* do_ellipse:
53  *  Helper function for the ellipse drawing routines. Calculates the points
54  *  in an ellipse of radius rx and ry around point x, y, and calls the 
55Index: 4.2/include/allegro/gfx.h
56===================================================================
57--- 4.2/include/allegro/gfx.h  (revision 7890)
58+++ 4.2/include/allegro/gfx.h  (working copy)
59@@ -203,6 +203,7 @@
60    AL_METHOD(void, rect, (struct BITMAP *bmp, int x1, int y_1, int x2, int y2, int color));
61    AL_METHOD(void, circle, (struct BITMAP *bmp, int x, int y, int radius, int color));
62    AL_METHOD(void, circlefill, (struct BITMAP *bmp, int x, int y, int radius, int color));
63+   AL_METHOD(void, circlethick, (struct BITMAP *bmp, int x, int y, int radius, int thickness, int color));
64    AL_METHOD(void, ellipse, (struct BITMAP *bmp, int x, int y, int rx, int ry, int color));
65    AL_METHOD(void, ellipsefill, (struct BITMAP *bmp, int x, int y, int rx, int ry, int color));
66    AL_METHOD(void, arc, (struct BITMAP *bmp, int x, int y, fixed ang1, fixed ang2, int r, int color));
67

Under mingw I get errors that are all like:

src/vtable15.c:85: warning: initialization from incompatible pointer type

and when I link against the created lib, I get an undefined reference to circlethick, I guess I need to add my function to a vtable or something, but I dont know how to go about that. It might not have come up yet, but if there is something special you need to do, all the would be allegro hackers might come up against this.

Any suggestions or criticisms would be great, its after 5am and I possible could have missed something or done something stupid with the patch.

Thanks again Michael for getting me thinking about this.

____________________________________________________________________________________________
"c is much better than c++ if you don't need OOP simply because it's smaller and requires less load time." - alethiophile
OMG my sides are hurting from laughing so hard ... :D

Thomas Fjellstrom

Member #476

June 2000

That patch seems to be missing a point where the circlethick driver method's are actually set. Without adding the method to the vtable initializations, it'll be setting the wrong functions to the wrong methods.

Usually its best to add new methods to the end of the vtable, that way theres no ordering problems, and binary compatibility can possibly be kept.

GullRaDriel

Member #3,861

September 2003

AFAIK You also should run fixdll.sh after any function/modification to add the declaration inside the dll

"Code is like shit - it only smells if it is not yours"
Allegro Wiki, full of examples and articles !!