From: Jon R. <wo...@cc...> - 2004-11-29 02:24:18
|
While talking with a chap on IRC it came to my attention that there is no way to change the masking color for a given color depth. Now, I cant think of a whole lot of reasons to change the masking color but maybe someone( as this fellow tried to do ) would like to. Is it worth it supply the user with a function with a set_mask_color() function or possibly add another parameter to all functions using the masking color, like masked_blit(), to change the masking color? Right now the masking color is #define'd for each color depth. All that would need to happen is to make this a global int. come to think of it, I think I could make some neat effects if I could change the masking color on the fly. What do yall think? |
From: Evert G. <eg...@dd...> - 2004-11-29 09:06:57
|
> While talking with a chap on IRC it came to my attention that there is > no way to change the masking color for a given color depth. Now, I cant > think of a whole lot of reasons to change the masking color but maybe > someone( as this fellow tried to do ) would like to. I think this has been discussed several times already. I'm sure there hav= e been long discussions about it on ACC at least. > Is it worth it > supply the user with a function with a set_mask_color() function or > possibly add another parameter to all functions using the masking color= , > like masked_blit(), to change the masking color? Right now the masking > color is #define'd for each color depth. All that would need to happen > is to make this a global int. I'm not so sure. Have you tried if this is true? A lot of the blitting code is hand-optimized assembly. It may not react properly if you change the define to an int. > come to think of it, I think I could make some neat effects if I could > change the masking color on the fly. What do yall think? I don't think we want to change this for 4.2. Maybe for 4.3 when the graphics subsystem is going to be changed anyway. Depending on what others think. Personally, I'm pretty much indifferent t= o this feature... Evert |
From: Thomas F. <tfj...@st...> - 2004-11-29 12:53:31
|
On November 29, 2004 02:06 am, Evert Glebbeek wrote: > > come to think of it, I think I could make some neat effects if I could > > change the masking color on the fly. What do yall think? > > I don't think we want to change this for 4.2. Maybe for 4.3 when the > graphics subsystem is going to be changed anyway. > Depending on what others think. Personally, I'm pretty much indifferent to > this feature... Ditto, but its had more than enough interest to date to warant the change. Also theres no reason NOT to support it. Maybe some people like using alot of magenta :o > Evert -- Thomas Fjellstrom tfj...@st... http://strangesoft.net |
From: Elias P. <el...@us...> - 2004-11-29 13:25:28
|
On Mon, 2004-11-29 at 05:54 -0700, Thomas Fjellstrom wrote: > > I don't think we want to change this for 4.2. Maybe for 4.3 when the > > graphics subsystem is going to be changed anyway. > > Depending on what others think. Personally, I'm pretty much indifferent to > > this feature... > > Ditto, but its had more than enough interest to date to warant the change. > Also theres no reason NOT to support it. Maybe some people like using alot of > magenta :o > I think it is addressed in Bob's A5 gfx API. For A4, it probably requires too much changes to be feasible, unless someone submits a working patch of course. -- Elias Pschernig |
From: aj <aj...@vi...> - 2004-11-29 15:37:28
|
i remember years'n'years'n'years ago.. maybe way back in the 3.12 days.. i made the mask color for the 8 bit code a global var and then just set it to which ever value i wanted. had to do something like extern int _mask_color8; somewhere.. hehhee.. funny thing is, that code from those days is probably still in the allegro src. > > > come to think of it, I think I could make some neat effects if I could > > > change the masking color on the fly. What do yall think? > > > > I don't think we want to change this for 4.2. Maybe for 4.3 when the > > graphics subsystem is going to be changed anyway. > > Depending on what others think. Personally, I'm pretty much indifferent to > > this feature... > >Ditto, but its had more than enough interest to date to warant the change. >Also theres no reason NOT to support it. Maybe some people like using alot of >magenta :o > > > Evert |
From: Elias P. <el...@us...> - 2004-11-29 15:47:33
|
On Tue, 2004-11-30 at 02:37 +1100, aj wrote: > i remember years'n'years'n'years ago.. maybe way back in the 3.12 days.. > i made the mask color for the 8 bit code a global var and then just set it > to which ever value i wanted. > had to do something like extern int _mask_color8; somewhere.. > hehhee.. funny thing is, that code from those days is probably still in the > allegro src. > Yes, many parts already could easily deal with it. There's also the bitmap_mask_color funcion which is the preferred way to get the mask color. I guess, really the only place is asm optimization of things like masked_blit, where there's no register left to hold the mask color. But we have an asm developer even less than a windows developer. I wonder if this wouldn't have been a good use of self-modifying code, at the time it was written, just put an immediate value into the asm code where needed :) But now, I guess a proper solution would be an mmx or the likes version, which has the mask color in some extra register, or something like that. Or is cached memory as fast as constants/registers? -- Elias Pschernig |
From: Evert G. <eg...@dd...> - 2004-11-29 17:38:46
|
On Monday 29 November 2004 16:48, Elias Pschernig wrote: > I wonder if this wouldn't have been a good use of self-modifying code, > at the time it was written, just put an immediate value into the asm > code where needed :) Awesome idea! I think that should be feasable too, although you'd need to be very careful: the code as it is now is probably in the shared library, meaning you can't change it without affecting other programs using Allegro. If I had the time I'd look into this... oh well, it's probably no longer worth it anyway. Evert |
From: aj <aj...@vi...> - 2004-11-29 19:39:02
|
>But now, I guess a proper solution would be an mmx or the likes version, >which has the mask color in some extra register, or something like that. >Or is cached memory as fast as constants/registers? for a really really tight loop, like masked blit, keeping it in a register would be a good idea. it does sound like a job for MMX. look at /alg_4_1_16/src/i386/iblit32.s line 221 movl $MASK_COLOR_32, %eax just change the #define MASK_COLOR_32 to volatile unsigned int MASK_COLOR_32 = 0xff00ff; then in the allegro.h somewhere but extern unsigned int MASK_COLOR_32; and the user can then set which ever colour they want. |
From: Elias P. <el...@us...> - 2004-11-29 20:48:55
|
On Tue, 2004-11-30 at 06:38 +1100, aj wrote: > >But now, I guess a proper solution would be an mmx or the likes version, > >which has the mask color in some extra register, or something like that. > >Or is cached memory as fast as constants/registers? > > > for a really really tight loop, like masked blit, keeping it in a register > would be a good idea. > it does sound like a job for MMX. > > look at > /alg_4_1_16/src/i386/iblit32.s line 221 > > movl $MASK_COLOR_32, %eax > > just change the > #define MASK_COLOR_32 > > to > > volatile unsigned int MASK_COLOR_32 = 0xff00ff; > > then in the allegro.h somewhere but > > extern unsigned int MASK_COLOR_32; > > and the user can then set which ever colour they want. Well, someone would need to find out if MASK_COLOR_32 is always used when the mask color is needed, or if some places use makecol(...). And also need to check if it in all cases is written to a register outside of a loop. I don't know too much asm, but I guess there could also be cmpl $MASK_COLOR_32, %eax. And in that case, you can't use a variable. But maybe that never i the case. Then, also need to check this for all other color depths. Actually, in 8-bit we could probably leave 0, since I assume checking against 0 will always be faster in asm code than any other value. Well, and then, someone would need to create a patch with the change. I put it into todo.txt as a wishlist item. -- Elias Pschernig |