Menu
▾
▴
quesa-develop
|
From: Daniele C. <dca...@in...> - 2007-10-02 10:58:14
|
There is a little problem with rayshade
In function RSRasterizer_Rasterize_RGB_Span_PM when you compile for
windows in
case kQ3PixelTypeRGB32:
case kQ3PixelTypeARGB32:
is always
pixel = ( correct ( rgbaPixels[i][3] ) << 24) | // Alpha
( correct ( rgbaPixels[i][0] ) << 16) |
( correct ( rgbaPixels[i][1] ) << 8) |
( correct ( rgbaPixels[i][2] ) << 0 ) ;
*((unsigned int *)rowAddr) = pixel;
regardless of /QUESA_HOST_IS_BIG_ENDIAN/ .
Same for kQ3PixelTypeRGB24
|
|
From: Roger H. <rog...@mi...> - 2007-10-02 12:43:45
|
Er, yes. I have a big #if for those two cases. I have some other changes too if anyone would like to check them in for me. Most important one is that there is an unitialised field in one of the records which causes speckling which I've fixed in my version. Roger. On 2 Oct, 2007, at 11:58, Daniele Cavallini wrote: > There is a little problem with rayshade > In function RSRasterizer_Rasterize_RGB_Span_PM when you compile for > windows in > case kQ3PixelTypeRGB32: > case kQ3PixelTypeARGB32: > > is always > pixel = ( correct ( rgbaPixels[i][3] ) << 24) | // Alpha > ( correct ( rgbaPixels[i][0] ) << > 16) | > ( correct ( rgbaPixels[i][1] ) << > 8) | > ( correct ( rgbaPixels[i][2] ) << > 0 ) ; > *((unsigned int *)rowAddr) = pixel; > > regardless of /QUESA_HOST_IS_BIG_ENDIAN/ . > > > Same for kQ3PixelTypeRGB24 > > > > ---------------------------------------------------------------------- > --- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Quesa-develop mailing list > Que...@li... > https://lists.sourceforge.net/lists/listinfo/quesa-develop |
|
From: Daniele C. <dca...@in...> - 2007-10-02 12:50:39
|
Is your version downloadable from cvs? I can try it. Roger Holmes ha scritto: > Er, yes. I have a big #if for those two cases. I have some other > changes too if anyone would like to check them in for me. > > Most important one is that there is an unitialised field in one of > the records which causes speckling which I've fixed in my version. > > Roger. > > > > > On 2 Oct, 2007, at 11:58, Daniele Cavallini wrote: > > >> There is a little problem with rayshade >> In function RSRasterizer_Rasterize_RGB_Span_PM when you compile for >> windows in >> case kQ3PixelTypeRGB32: >> case kQ3PixelTypeARGB32: >> >> is always >> pixel = ( correct ( rgbaPixels[i][3] ) << 24) | // Alpha >> ( correct ( rgbaPixels[i][0] ) << >> 16) | >> ( correct ( rgbaPixels[i][1] ) << >> 8) | >> ( correct ( rgbaPixels[i][2] ) << >> 0 ) ; >> *((unsigned int *)rowAddr) = pixel; >> >> regardless of /QUESA_HOST_IS_BIG_ENDIAN/ . >> >> >> Same for kQ3PixelTypeRGB24 >> >> >> >> ---------------------------------------------------------------------- >> --- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2005. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Quesa-develop mailing list >> Que...@li... >> https://lists.sourceforge.net/lists/listinfo/quesa-develop >> > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Quesa-develop mailing list > Que...@li... > https://lists.sourceforge.net/lists/listinfo/quesa-develop > > |
|
From: Roger H. <rog...@mi...> - 2007-10-02 12:56:11
|
No but I can do a comparison and e-mail the changes. On 2 Oct, 2007, at 13:50, Daniele Cavallini wrote: > Is your version downloadable from cvs? > I can try it. > Roger Holmes ha scritto: >> Er, yes. I have a big #if for those two cases. I have some other >> changes too if anyone would like to check them in for me. >> >> Most important one is that there is an unitialised field in one of >> the records which causes speckling which I've fixed in my version. >> >> Roger. >> >> >> >> >> On 2 Oct, 2007, at 11:58, Daniele Cavallini wrote: >> >> >>> There is a little problem with rayshade >>> In function RSRasterizer_Rasterize_RGB_Span_PM when you compile for >>> windows in >>> case kQ3PixelTypeRGB32: >>> case kQ3PixelTypeARGB32: >>> >>> is always >>> pixel = ( correct ( rgbaPixels[i][3] ) << 24) | // Alpha >>> ( correct ( rgbaPixels[i][0] ) << >>> 16) | >>> ( correct ( rgbaPixels[i][1] ) << >>> 8) | >>> ( correct ( rgbaPixels[i][2] ) << >>> 0 ) ; >>> *((unsigned int *)rowAddr) = pixel; >>> >>> regardless of /QUESA_HOST_IS_BIG_ENDIAN/ . >>> >>> >>> Same for kQ3PixelTypeRGB24 >>> >>> >>> >>> -------------------------------------------------------------------- >>> -- >>> --- >>> This SF.net email is sponsored by: Microsoft >>> Defy all challenges. Microsoft(R) Visual Studio 2005. >>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>> _______________________________________________ >>> Quesa-develop mailing list >>> Que...@li... >>> https://lists.sourceforge.net/lists/listinfo/quesa-develop >>> >> >> >> --------------------------------------------------------------------- >> ---- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2005. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Quesa-develop mailing list >> Que...@li... >> https://lists.sourceforge.net/lists/listinfo/quesa-develop >> >> > > ---------------------------------------------------------------------- > --- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Quesa-develop mailing list > Que...@li... > https://lists.sourceforge.net/lists/listinfo/quesa-develop |
|
From: Daniele C. <dca...@in...> - 2007-10-02 13:05:34
|
My e-mail is dca...@in... In rayshade I set a big #if but Your idea to use longAndFourChars seem good and elegant Roger Holmes ha scritto: > No but I can do a comparison and e-mail the changes. > > > > On 2 Oct, 2007, at 13:50, Daniele Cavallini wrote: > > >> Is your version downloadable from cvs? >> I can try it. >> Roger Holmes ha scritto: >> >>> Er, yes. I have a big #if for those two cases. I have some other >>> changes too if anyone would like to check them in for me. >>> >>> Most important one is that there is an unitialised field in one of >>> the records which causes speckling which I've fixed in my version. >>> >>> Roger. >>> >>> >>> >>> >>> On 2 Oct, 2007, at 11:58, Daniele Cavallini wrote: >>> >>> >>> >>>> There is a little problem with rayshade >>>> In function RSRasterizer_Rasterize_RGB_Span_PM when you compile for >>>> windows in >>>> case kQ3PixelTypeRGB32: >>>> case kQ3PixelTypeARGB32: >>>> >>>> is always >>>> pixel = ( correct ( rgbaPixels[i][3] ) << 24) | // Alpha >>>> ( correct ( rgbaPixels[i][0] ) << >>>> 16) | >>>> ( correct ( rgbaPixels[i][1] ) << >>>> 8) | >>>> ( correct ( rgbaPixels[i][2] ) << >>>> 0 ) ; >>>> *((unsigned int *)rowAddr) = pixel; >>>> >>>> regardless of /QUESA_HOST_IS_BIG_ENDIAN/ . >>>> >>>> >>>> Same for kQ3PixelTypeRGB24 >>>> >>>> >>>> >>>> -------------------------------------------------------------------- >>>> -- >>>> --- >>>> This SF.net email is sponsored by: Microsoft >>>> Defy all challenges. Microsoft(R) Visual Studio 2005. >>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>>> _______________________________________________ >>>> Quesa-develop mailing list >>>> Que...@li... >>>> https://lists.sourceforge.net/lists/listinfo/quesa-develop >>>> >>>> >>> --------------------------------------------------------------------- >>> ---- >>> This SF.net email is sponsored by: Microsoft >>> Defy all challenges. Microsoft(R) Visual Studio 2005. >>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>> _______________________________________________ >>> Quesa-develop mailing list >>> Que...@li... >>> https://lists.sourceforge.net/lists/listinfo/quesa-develop >>> >>> >>> >> ---------------------------------------------------------------------- >> --- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2005. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Quesa-develop mailing list >> Que...@li... >> https://lists.sourceforge.net/lists/listinfo/quesa-develop >> > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Quesa-develop mailing list > Que...@li... > https://lists.sourceforge.net/lists/listinfo/quesa-develop > > |
|
From: Jose' C. <cru...@ce...> - 2007-10-02 13:35:05
|
Il giorno 02/ott/07, alle ore 15:05, Daniele Cavallini ha scritto: > My e-mail is dca...@in... pls email it to the list and I'll put it in CVS Pax et Bonum # Dott. Jos=E9 Cruanyes Aguilar - C.E. Soft srl # Pzza. Firenze,4 MILANO - XX Settembre 10, CREMONA # 02,3923101 0372,460602 |
|
From: Roger H. <rog...@mi...> - 2007-10-02 17:23:56
|
I cannot make out if some of the changes are things I have done to my code or thing you guys have done to the master version. I thought I had kept a baseline version from which I had derived my version but I can't find it. Anyway, by far the most important change is this one: Inside surface.cpp Inside the routine SurfaceCreate After: stmp->reflect = stmp->transp = 0.; I inserted: stmp->translucency = 0.0 ; which fixes a bug with white speckling on second and subsequent renders, so particularly noticeable when generating QuickTime movies from animations. It seems the changes for the endian issue have already been incorporated. Roger. |
|
From: Roger H. <rog...@mi...> - 2007-10-02 12:54:21
|
On the other hand, if we define
union longAndFourChars
{
char fourChars [ 4 ] ;
unsigned long int anUnsignedInt ;
}
longAndFourChars pixel ;
then
pixel. fourChars [ 0 ] = correct ( rgbaPixels [ i ] [ 3 ] ) ;// Alpha
pixel. fourChars [ 1 ] = correct ( rgbaPixels [ i ] [ 2 ] ) ;
pixel. fourChars [ 2 ] = correct ( rgbaPixels [ i ] [ 1 ] ) ;
pixel. fourChars [ 3 ] = correct ( rgbaPixels [ i ] [0 ] ) ;
* ( ( unsigned int* ) rowAddr ) = pixel. anUnsignedInt ;
Then won't that work on either endian machine?
Roger.
|
|
From: Daniele C. <dca...@in...> - 2008-03-14 11:27:04
|
I tried to implement this solution but it don't work well. (I set anUnsignedInt like TQ3Uns32 ) The create colors aren't correct. You can see As it would have to be http://www.interstudio.net/quesa/init.jpg as it is http://www.interstudio.net/quesa/res.jpg I use imac intel. I don't know why doesn't work. It isn't a good solution to use #define /QUESA_HOST_IS_BIG_ENDIAN /because there are mac with intel and powerpc processor. How I know in runtime if computer have an intel or powerpc processor? Have you Some ideas? // Roger Holmes ha scritto: > On the other hand, if we define > > union longAndFourChars > { > char fourChars [ 4 ] ; > unsigned long int anUnsignedInt ; > } > > longAndFourChars pixel ; > > then > > pixel. fourChars [ 0 ] = correct ( rgbaPixels [ i ] [ 3 ] ) ;// Alpha > pixel. fourChars [ 1 ] = correct ( rgbaPixels [ i ] [ 2 ] ) ; > pixel. fourChars [ 2 ] = correct ( rgbaPixels [ i ] [ 1 ] ) ; > pixel. fourChars [ 3 ] = correct ( rgbaPixels [ i ] [0 ] ) ; > > * ( ( unsigned int* ) rowAddr ) = pixel. anUnsignedInt ; > > > > Then won't that work on either endian machine? > > Roger. > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Quesa-develop mailing list > Que...@li... > https://lists.sourceforge.net/lists/listinfo/quesa-develop > > |
|
From: Roger H. <rog...@mi...> - 2008-03-14 19:42:48
|
It looks like Red has gone to Alpha, green has gone to Red, Blue has gone to green and Alpha has gone to Blue. Try this: pixel. fourChars [ 3 ] = correct ( rgbaPixels [ i ] [ 3 ] ) ; pixel. fourChars [ 0 ] = correct ( rgbaPixels [ i ] [ 2 ] ) ; pixel. fourChars [ 1 ] = correct ( rgbaPixels [ i ] [ 1 ] ) ; pixel. fourChars [ 2 ] = correct ( rgbaPixels [ i ] [0 ] ) ; and if that doesn't work it must be: pixel. fourChars [ 1 ] = correct ( rgbaPixels [ i ] [ 3 ] ) ; pixel. fourChars [ 2 ] = correct ( rgbaPixels [ i ] [ 2 ] ) ; pixel. fourChars [ 3 ] = correct ( rgbaPixels [ i ] [ 1 ] ) ; pixel. fourChars [ 0 ] = correct ( rgbaPixels [ i ] [0 ] ) ; Roger. On 14 Mar, 2008, at 11:26, Daniele Cavallini wrote: > I tried to implement this solution but it don't work well. > (I set anUnsignedInt like TQ3Uns32 ) > The create colors aren't correct. > You can see > As it would have to be > http://www.interstudio.net/quesa/init.jpg > as it is > http://www.interstudio.net/quesa/res.jpg > I use imac intel. > > I don't know why doesn't work. > It isn't a good solution to use #define /QUESA_HOST_IS_BIG_ENDIAN > /because there are mac with intel and powerpc processor. > How I know in runtime if computer have an intel or powerpc processor? > > > Have you Some ideas? > // > Roger Holmes ha scritto: >> On the other hand, if we define >> >> union longAndFourChars >> { >> char fourChars [ 4 ] ; >> unsigned long int anUnsignedInt ; >> } >> >> longAndFourChars pixel ; >> >> then >> >> pixel. fourChars [ 0 ] = correct ( rgbaPixels [ i ] [ 3 ] ) ;// Alpha >> pixel. fourChars [ 1 ] = correct ( rgbaPixels [ i ] [ 2 ] ) ; >> pixel. fourChars [ 2 ] = correct ( rgbaPixels [ i ] [ 1 ] ) ; >> pixel. fourChars [ 3 ] = correct ( rgbaPixels [ i ] [0 ] ) ; >> >> * ( ( unsigned int* ) rowAddr ) = pixel. anUnsignedInt ; >> >> >> >> Then won't that work on either endian machine? >> >> Roger. >> >> >> --------------------------------------------------------------------- >> ---- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2005. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Quesa-develop mailing list >> Que...@li... >> https://lists.sourceforge.net/lists/listinfo/quesa-develop >> >> > > ---------------------------------------------------------------------- > --- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Quesa-develop mailing list > Que...@li... > https://lists.sourceforge.net/lists/listinfo/quesa-develop |
|
From: Daniele C. <dca...@in...> - 2008-03-18 17:12:05
|
I wrote:
case kQ3PixelTypeRGB32:
case kQ3PixelTypeARGB32:
{
unsigned int pixel;
pixel = ( correct ( rgbaPixels[i][3] ) << 24) |
// Alpha
( correct ( rgbaPixels[i][0] ) << 16) |
( correct ( rgbaPixels[i][1] ) << 8) |
( correct ( rgbaPixels[i][2] ) << 0 ) ;
*((unsigned int *)rowAddr) = pixel;
}
break;
For all the configuration same code.
For mac osx powerPC.............OK
For mac osx Intel.....................OK
For Windows XP.....................OK
For Windows Vista..................OK
It is not so clear but the result are correct.
Roger Holmes ha scritto:
> It looks like Red has gone to Alpha, green has gone to Red, Blue has
> gone to green and Alpha has gone to Blue.
>
>
> Try this:
>
> pixel. fourChars [ 3 ] = correct ( rgbaPixels [ i ] [ 3 ] ) ;
> pixel. fourChars [ 0 ] = correct ( rgbaPixels [ i ] [ 2 ] ) ;
> pixel. fourChars [ 1 ] = correct ( rgbaPixels [ i ] [ 1 ] ) ;
> pixel. fourChars [ 2 ] = correct ( rgbaPixels [ i ] [0 ] ) ;
>
> and if that doesn't work it must be:
>
>
> pixel. fourChars [ 1 ] = correct ( rgbaPixels [ i ] [ 3 ] ) ;
> pixel. fourChars [ 2 ] = correct ( rgbaPixels [ i ] [ 2 ] ) ;
> pixel. fourChars [ 3 ] = correct ( rgbaPixels [ i ] [ 1 ] ) ;
> pixel. fourChars [ 0 ] = correct ( rgbaPixels [ i ] [0 ] ) ;
>
> Roger.
>
>
> On 14 Mar, 2008, at 11:26, Daniele Cavallini wrote:
>
>
>> I tried to implement this solution but it don't work well.
>> (I set anUnsignedInt like TQ3Uns32 )
>> The create colors aren't correct.
>> You can see
>> As it would have to be
>> http://www.interstudio.net/quesa/init.jpg
>> as it is
>> http://www.interstudio.net/quesa/res.jpg
>> I use imac intel.
>>
>> I don't know why doesn't work.
>> It isn't a good solution to use #define /QUESA_HOST_IS_BIG_ENDIAN
>> /because there are mac with intel and powerpc processor.
>> How I know in runtime if computer have an intel or powerpc processor?
>>
>>
>> Have you Some ideas?
>> //
>> Roger Holmes ha scritto:
>>
>>> On the other hand, if we define
>>>
>>> union longAndFourChars
>>> {
>>> char fourChars [ 4 ] ;
>>> unsigned long int anUnsignedInt ;
>>> }
>>>
>>> longAndFourChars pixel ;
>>>
>>> then
>>>
>>> pixel. fourChars [ 0 ] = correct ( rgbaPixels [ i ] [ 3 ] ) ;// Alpha
>>> pixel. fourChars [ 1 ] = correct ( rgbaPixels [ i ] [ 2 ] ) ;
>>> pixel. fourChars [ 2 ] = correct ( rgbaPixels [ i ] [ 1 ] ) ;
>>> pixel. fourChars [ 3 ] = correct ( rgbaPixels [ i ] [0 ] ) ;
>>>
>>> * ( ( unsigned int* ) rowAddr ) = pixel. anUnsignedInt ;
>>>
>>>
>>>
>>> Then won't that work on either endian machine?
>>>
>>> Roger.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> ----
>>> This SF.net email is sponsored by: Microsoft
>>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>> _______________________________________________
>>> Quesa-develop mailing list
>>> Que...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>>>
>>>
>>>
>> ----------------------------------------------------------------------
>> ---
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Quesa-develop mailing list
>> Que...@li...
>> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>
>
|
|
From: Roger H. <rog...@mi...> - 2008-03-18 19:57:57
|
On 18 Mar, 2008, at 17:11, Daniele Cavallini wrote:
> I wrote:
> case kQ3PixelTypeRGB32:
> case kQ3PixelTypeARGB32:
> {
> unsigned int pixel;
>
> pixel = ( correct ( rgbaPixels[i][3] ) <<
> 24) |
> // Alpha
> ( correct ( rgbaPixels[i][0] ) <<
> 16) |
> ( correct ( rgbaPixels[i][1] ) <<
> 8) |
> ( correct ( rgbaPixels[i][2] ) <<
> 0 ) ;
> *((unsigned int *)rowAddr) = pixel;
> }
> break;
> For all the configuration same code.
>
> For mac osx powerPC.............OK
> For mac osx Intel.....................OK
> For Windows XP.....................OK
> For Windows Vista..................OK
> It is not so clear but the result are correct.
Well that is the main thing. Well done.
Have you seen any problems with spot lights? In the RayShade renderer
they behave identically to point lights. Maybe my source is not right
up to date but I have not noticed any relevant bug fixes being
checked in since I checked out my copy.
Roger
|
|
From: Daniele C. <dca...@in...> - 2008-03-19 14:10:26
|
Spot light don't work fine, and I remember it is not never worked well with rayshade. www.interstudio.net/quesa/spot.jpg Direction is wrong because it never change. Point light seem work fine www.interstudio.net/quesa/point.jpg Roger Holmes ha scritto: > On 18 Mar, 2008, at 17:11, Daniele Cavallini wrote: > > >> I wrote: >> case kQ3PixelTypeRGB32: >> case kQ3PixelTypeARGB32: >> { >> unsigned int pixel; >> >> pixel = ( correct ( rgbaPixels[i][3] ) << >> 24) | >> // Alpha >> ( correct ( rgbaPixels[i][0] ) << >> 16) | >> ( correct ( rgbaPixels[i][1] ) << >> 8) | >> ( correct ( rgbaPixels[i][2] ) << >> 0 ) ; >> *((unsigned int *)rowAddr) = pixel; >> } >> break; >> For all the configuration same code. >> >> For mac osx powerPC.............OK >> For mac osx Intel.....................OK >> For Windows XP.....................OK >> For Windows Vista..................OK >> It is not so clear but the result are correct. >> > > > Well that is the main thing. Well done. > > Have you seen any problems with spot lights? In the RayShade renderer > they behave identically to point lights. Maybe my source is not right > up to date but I have not noticed any relevant bug fixes being > checked in since I checked out my copy. > > Roger > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Quesa-develop mailing list > Que...@li... > https://lists.sourceforge.net/lists/listinfo/quesa-develop > > |
|
From: Sean M. <se...@ro...> - 2007-10-02 15:17:28
|
On 10/2/07 1:54 PM, Roger Holmes said:
>On the other hand, if we define
>
>union longAndFourChars
>=09{
>=09char fourChars [ 4 ] ;
>=09unsigned long int anUnsignedInt ;
>=09}
UInt32 would be better, since 'unsigned long int' is 64 bit when
building 64 bit, and 32 bit when building 32 bit.
--
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Sean McBride, B. Eng se...@ro...
Rogue Research www.rogue-research.com
Mac Software Developer Montr=E9al, Qu=E9bec, Canada
|
|
From: James W. W. <os...@jw...> - 2007-10-02 15:42:08
|
On Oct 2, 2007, at 8:16 AM, Sean McBride wrote:
> On 10/2/07 1:54 PM, Roger Holmes said:
>
>> On the other hand, if we define
>>
>> union longAndFourChars
>> {
>> char fourChars [ 4 ] ;
>> unsigned long int anUnsignedInt ;
>> }
>
> UInt32 would be better, since 'unsigned long int' is 64 bit when
> building 64 bit, and 32 bit when building 32 bit.
UInt32 isn't defined on platforms other than Mac, is it?
|
|
From: Sean M. <se...@ro...> - 2007-10-02 16:36:50
|
On 10/2/07 8:41 AM, James W. Walker said: >UInt32 isn't defined on platforms other than Mac, is it=3F Probably not. Popular choices are 1) C99's uint32=5Ft 2) typedef your own, based on platform/compiler. 3) assume 32 bit CPUs. -- =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Sean McBride, B. Eng se...@ro... Rogue Research www.rogue-research.com Mac Software Developer Montr=E9al, Qu=E9bec, Canada |
|
From: Roger H. <rog...@mi...> - 2007-10-02 16:33:58
|
On 2 Oct, 2007, at 16:41, James W. Walker wrote:
>
> On Oct 2, 2007, at 8:16 AM, Sean McBride wrote:
>
>> On 10/2/07 1:54 PM, Roger Holmes said:
>>
>>> On the other hand, if we define
>>>
>>> union longAndFourChars
>>> {
>>> char fourChars [ 4 ] ;
>>> unsigned long int anUnsignedInt ;
>>> }
>>
>> UInt32 would be better, since 'unsigned long int' is 64 bit when
>> building 64 bit, and 32 bit when building 32 bit.
>
> UInt32 isn't defined on platforms other than Mac, is it?
Would 'unsigned int' be safest?
|
|
From: Sean M. <se...@ro...> - 2007-10-02 19:50:22
|
On 10/2/07 5:33 PM, Roger Holmes said: >>> UInt32 would be better, since 'unsigned long int' is 64 bit when >>> building 64 bit, and 32 bit when building 32 bit. >> >> UInt32 isn't defined on platforms other than Mac, is it=3F > >Would 'unsigned int' be safest=3F Actually, seems like "TQ3Uns32" is ideal. :) -- =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Sean McBride, B. Eng se...@ro... Rogue Research www.rogue-research.com Mac Software Developer Montr=E9al, Qu=E9bec, Canada |