|
|
|
| Allegro 4.9.8 |
|
Thomas Fjellstrom
Member #476
June 2000
 |
It wouldn't be out of place in an addon. We accept patches -- |
|
Don Freeman
Member #5,110
October 2004
 |
Here is the al_draw_filled_rounded_rect function: void al_draw_filled_rounded_rect( float x, float y, float w, float h, float r, ALLEGRO_COLOR c, int t ) { /////////////////////////////////////////////////////////////////////////// al_draw_filled_rectangle(x+r,y,(x+w)-r,(y+h),c); al_draw_filled_rectangle(x,y+r,(x+w),(y+h)-r,c); al_draw_filled_circle(x+r,y+r,r,c); // top left al_draw_filled_circle((x+w)-r,y+r,r,c); // top right al_draw_filled_circle(x+r,(y+h)-r,r,c); // bottom left al_draw_filled_circle((x+w)-r,(y+h)-r,r,c); // bottom right /////////////////////////////////////////////////////////////////////////// } /////////////////////////////////////////////////////////////////////////////// Again, needs to be optimized like the unfilled version, but it works.8-) Edit: -- |
|
Elias
Member #358
May 2000
|
Quote: Is there no easy way to set the text color besides using the blender? Just make a function like this: void text_color(float r, float g, float b) { al_set_blender(ALLEGRO_ALPHA, ALLEGRO_INVERSE_ALPHA, al_map_rgb_f(r, g, b)); } And then in the rest of your code do this: Might be worth adding such a function to the font addon actually - but I'm not sure. Quote: If not, is this not slow???? How so? I'd say it's a much faster method than the real-time pixel-by-pixel recoloring used in A4... -- |
|
Don Freeman
Member #5,110
October 2004
|
You have to reset the blender though...I found that out after setting the font color that way, my images got 'colorized' as well.:-/ -- |
|
SiegeLord
Member #7,827
October 2006
 |
Quote: it works.
That is, until you happen to turn on blending Quote: Whats the 3D api going to look like?
It already exists in an unimplemented state, so, basically like it looks like now Or did you not notice that al_set_vbuff_pos takes x, y and z? "For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18 |
|
Don Freeman
Member #5,110
October 2004
|
Yeah...I noticed that with the filled version. I guess it is because of the overlap of the rectangles on the circles. I could probably fix it...but if you will implement it later on, I'll just wait.::) If you make a version, do you plan to keep the same layout and drawing style (The rounded rect will NOT exceed a normal rect)? That would be awesome if so, this way I could just switch my code later to use yours without having to modify that layout of all of my drawings and such.:D -- |
|
SiegeLord
Member #7,827
October 2006
|
Quote: If you make a version, do you plan to keep the same layout and drawing style (The rounded rect will NOT exceed a normal rect)? I was thinking that if the bevel radius is 0, then the output is identical to al_draw_{filled_}rectangle, so I guess, yes I am planning on that. "For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18 |
|
Trent Gamblin
Member #261
April 2000
 |
The titlebar thing is a bug, I swear it worked with 4.9.8 (haven't checked again) but even though there were no changes to the windows window handling code, you can't click on the client area to focus a window. I've looked at it a bit but haven't found the problem.
|
|
Don Freeman
Member #5,110
October 2004
|
I was thinking of using the al_calculate_arc and using a ALLEGRO_VBUFFER to draw the shape with al_draw_prim...maybe even be able to pass in a texture to it as well, since al_draw_prim allows a texture...but hey, whatever works for you.::) Is there any built in anti-aliasing functions for the primitives? That would be awesome as well!:D Trent: No, it is broken in the 4.9.8 version. That is what I am using right now. I can't get a dynamic version of 4.9.9 to compile for visual studio yet... -- |
|
SiegeLord
Member #7,827
October 2006
|
Quote: I was thinking of using the al_calculate_arc and using a ALLEGRO_VBUFFER to draw the shape with al_draw_prim... That's probably how it'll be done. Quote: maybe even be able to pass in a texture to it as well, since al_draw_prim allows a texture...but hey, whatever works for you.::) No high level primitive routines have texture support for one simple reason, there is no unique way to do it. Do you want a rotated/scaled texture or whatnot? For circles, do you want a radial texture mapping, or a rectangular one? Etc etc. I just figured that if you want textures, you go into the source, copy the implementation, and set the uv coordinates to your liking yourself. Quote: Is there any built in anti-aliasing functions for the primitives? That would be awesome as well! There is multi-sampling support in A4.9.8 that supposedly antialiases the entire screen. So far it looked like crud to me, but that's probably because my card is bad. "For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18 |
|
Don Freeman
Member #5,110
October 2004
|
Do you know the name of it, or is it on by default? I do not see it in the docs.:-/ -- |
|
SiegeLord
Member #7,827
October 2006
|
The program that uses it is called ex_multisample. Maybe I am mistaken and it was added after 4.9.8... "For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18 |
|
Trezker
Member #1,739
December 2001
 |
I was thinking about looking into the place where mouse axes events are processed, it seems likely that's where something gets fucked up. As for multiple displays, I'm not really thinking about that yet. I'm just using current display. With the API being as it is now, I think you can only support jumping within one display. Though I'm not sure. I'll have a look at it. I think people might want to be able to jump between displays, even if it's a stretch I'll bet in the future some guy will be wondering about it. But for the time being, I think you could use the patch I attached back there. At least you can move the mouse at all, even if it's buggy and might not work on multiple displays. |
|
Thomas Fjellstrom
Member #476
June 2000
|
At some point someone WILL make a game that can span monitors. Having the mouse move between displays is rather important, regardless of where the actual allegro Display is placed. Hopefully the underlying window manager will do most of the work. -- |
|
Evert
Member #794
November 2000
 |
Quote: As for multiple displays, I'm not really thinking about that yet. I'm just using current display. With the API being as it is now, I think you can only support jumping within one display. Though I'm not sure. I'll have a look at it. I think people might want to be able to jump between displays, even if it's a stretch I'll bet in the future some guy will be wondering about it.
Actually, I think it makes sense if x and y in al_set_mouse_xy() refer to the current display. I don't think there's any other sane way for the function to behave, so supporting multiple displays shouldn't be hard at all if that function works correctly. |
|
Trezker
Member #1,739
December 2001
|
Well, the x warp function takes a parameter of a type called window, but the docs don't link to this mysterious type and I don't feel like looking for it. The code in allegro 4.2 that skips some events was really crazy. It made no sense to me. But I'm trying to skip some events after a warp now to see if I can make that work. So far it's not looking good... On another note, I'd like to know how to skip building the examples when I build allegro. |
|
Thomas Fjellstrom
Member #476
June 2000
|
Quote: That's why I'm using the relative position warp, and that will not work with jumping between displays. In windowed mode I don't think we can even try to say that windows pretend to be beside each other... any XWarp wouldn't move the cursor directly to the next window unless it was directly beside it. That is, the only time moving the mouse should go from one display to another is if the displays are right next to each other. Anything else would be complicated to implement -- |
|
Trezker
Member #1,739
December 2001
|
I fixed it, the jerky thing and event skipping. Now, it skips up to one motion event after warp. The multi display issue is still open. I only have one display sitting on my desk so I don't feel like taking care of that feature. So, it's all smooth now. The attached diff is made against the same revision as the other one. EDIT: Hmm, I got two attachments, I thought I deleted the first one... |
|
count
Member #5,401
January 2005
|
Quote: The titlebar thing is a bug, I swear it worked with 4.9.8 (haven't checked again) but even though there were no changes to the windows window handling code, you can't click on the client area to focus a window. I've looked at it a bit but haven't found the problem.
I currently use 4.9.8 and it doesn't work correctly here too. Once I alt tabbed AWAY from the allegro window I can give focus by clicking inside the window. Regardless how it looses the focus. alt tabing away once fixes the problem for the lifespan of the window. Maybe this helps to track down the bug.
|
|
Thomas Fjellstrom
Member #476
June 2000
|
I am confused as to how that can happen at all. The WM shouldn't be affected by Allegro doing anything.. Any window should get focus when you click on the title bar (not nesesarily the client area, that could be ignored). Though I suppose if our win32 event handling handles NC (non client) area clicks, and handles that case wrong, it might do it, but why the hell would we handle NC area events at all? -- |
|
count
Member #5,401
January 2005
|
Quote: Any window should get focus when you click on the title bar
Did you misunderstand my post or did anyone else say that clikcing on the title doesn't work? For me clikcing on the title always works.
|
|
Thomas Fjellstrom
Member #476
June 2000
|
Quote:
Did you misunderstand my post or did anyone else say that clikcing on the title doesn't work? I'm not sure now. -- |
|
Evert
Member #794
November 2000
|
Are these problems with Allegro windows showing up specifically in one version of Windows? Or does it show up in all of them? |
|
Trent Gamblin
Member #261
April 2000
|
It must have something to do with the code that was added to detect mouse enter/leave events. I'll try to look at it today. [edit]
|
|
Elias
Member #358
May 2000
|
Quote: I fixed it, the jerky thing and event skipping. Now, it skips up to one motion event after warp. The multi display issue is still open. I only have one display sitting on my desk so I don't feel like taking care of that feature. So, it's all smooth now. The attached diff is made against the same revision as the other one. Can you try the attached patch? It adds a modified version of your patch as well as your example to current SVN. Just recompile then run ex_mouse_warp to test. I removed all the mouse skipping stuff as it makes no difference here - I assume it will have to be added back. However, we should describe in more detail how exactly it behaves "weird" without the skipping, and maybe we can figure out which X11 versions show that behavior and only do the skipping for those. -- |
|
|
|
. Well, no worries, I'll implement it later on.
I thought someone did. No it seems I'm just not reading properly 
nm.
