1. RE: poke4 won't accept my 32bit values
- Posted by Chris Bensler <bensler at mailops.com>
Mar 18, 2001
-
Last edited Mar 19, 2001
So as to clarify..
I am still using WinMain, but how it is supposed to work..
WinMain takes the Init, Main and Exit routines as handles..
With My Lib, I have split WinMain, into the 3 seperate components..
WinMain is Initialized, in the users Init code, Then the message loop is
called through the users Main code... and there is no Exit components
for WinMain, they are already internal..
The problem lies, where I split the message loop from the WinMain code..
For all practical purposes, this works OK, only when I try to pass a
32bit value to my seperated version do I run into problems..
It's difficult to explain, you really just need to see my examples to
understand..
FYI: the range I am using is #00000000 - #FFFFFFFF . 32bit color values
I think, it's something along the lines of what you're saying.. I
believe the values are being cropped to 8bit integer values.. Thus
returning an error saying the value must be a 32bit integer.
Chris
Robert Craig wrote:
> Chris Bensler writes:
> > ...when the code does not pass through WinMain,
> > it doesn't allow me to poke4 the values, resulting
> > in incorrect colors..
>
> I'm not sure what you are doing, but
> keep in mind that Euphoria routines, such as poke4(),
> deal with data in Euphoria's internal format.
> Euphoria integers and C integers are the same,
> as long as you are in the range of (roughly) -1 billion
> to +1 billion. Outside of this range a Euphoria library
> routine will interpret the number to be a kind of pointer to
> a double or a sequence. To pass a 32-bit integer,
> outside of the range, you would have to create a pointer
> to a double, like what NewDouble() returns, and pass that.
> This is very tricky, not for the faint of heart.
>
> Also, WinMain() causes a lot of necessary stuff to
> be initialized. If you skip it, some things won't work right.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
>
>
2. RE: poke4 won't accept my 32bit values
- Posted by Derek Parnell <derekp at solace.com.au>
Mar 18, 2001
-
Last edited Mar 19, 2001
In the call to TranslateMsg etc... are you using C_INT/C_LONG or
C_UINT/C_ULONG as the signature?
> -----Original Message-----
> From: Chris Bensler [mailto:bensler at mailops.com]
> Sent: Monday, 19 March 2001 3:50 PM
> To: EUforum at topica.com
> Subject: RE: poke4 won't accept my 32bit values
>
>
>
>
> So as to clarify..
>
> I am still using WinMain, but how it is supposed to work..
> WinMain takes the Init, Main and Exit routines as handles..
>
> With My Lib, I have split WinMain, into the 3 seperate components..
> WinMain is Initialized, in the users Init code, Then the
> message loop is
> called through the users Main code... and there is no Exit components
> for WinMain, they are already internal..
>
> The problem lies, where I split the message loop from the
> WinMain code..
>
> For all practical purposes, this works OK, only when I try to pass a
> 32bit value to my seperated version do I run into problems..
>
> It's difficult to explain, you really just need to see my examples to
> understand..
>
> FYI: the range I am using is #00000000 - #FFFFFFFF . 32bit
> color values
>
> I think, it's something along the lines of what you're saying.. I
> believe the values are being cropped to 8bit integer values.. Thus
> returning an error saying the value must be a 32bit integer.
>
>
> Chris
>
>
> Robert Craig wrote:
> > Chris Bensler writes:
> > > ...when the code does not pass through WinMain,
> > > it doesn't allow me to poke4 the values, resulting
> > > in incorrect colors..
> >
> > I'm not sure what you are doing, but
> > keep in mind that Euphoria routines, such as poke4(),
> > deal with data in Euphoria's internal format.
> > Euphoria integers and C integers are the same,
> > as long as you are in the range of (roughly) -1 billion
> > to +1 billion. Outside of this range a Euphoria library
> > routine will interpret the number to be a kind of pointer to
> > a double or a sequence. To pass a 32-bit integer,
> > outside of the range, you would have to create a pointer
> > to a double, like what NewDouble() returns, and pass that.
> > This is very tricky, not for the faint of heart.
> >
> > Also, WinMain() causes a lot of necessary stuff to
> > be initialized. If you skip it, some things won't work right.
> >
> > Regards,
> > Rob Craig
> > Rapid Deployment Software
> > http://www.RapidEuphoria.com
> >
> >
>
>
>
3. RE: poke4 won't accept my 32bit values
- Posted by Chris Bensler <bensler at mailops.com>
Mar 18, 2001
-
Last edited Mar 19, 2001
C_INT, what should it be?
But even if this is the problem.. it is exclusive to my code.. No
problems in the original Exotica demos..
Chris
Derek Parnell wrote:
> In the call to TranslateMsg etc... are you using C_INT/C_LONG or
> C_UINT/C_ULONG as the signature?
>
> > -----Original Message-----
> > From: Chris Bensler [mailto:bensler at mailops.com]
> > Sent: Monday, 19 March 2001 3:50 PM
> > To: EUforum at topica.com
> > Subject: RE: poke4 won't accept my 32bit values
> >
> >
> >
> >
> > So as to clarify..
> >
> > I am still using WinMain, but how it is supposed to work..
> > WinMain takes the Init, Main and Exit routines as handles..
> >
> > With My Lib, I have split WinMain, into the 3 seperate components..
> > WinMain is Initialized, in the users Init code, Then the
> > message loop is
> > called through the users Main code... and there is no Exit components
> > for WinMain, they are already internal..
> >
> > The problem lies, where I split the message loop from the
> > WinMain code..
> >
> > For all practical purposes, this works OK, only when I try to pass a
> > 32bit value to my seperated version do I run into problems..
> >
> > It's difficult to explain, you really just need to see my examples to
> > understand..
> >
> > FYI: the range I am using is #00000000 - #FFFFFFFF . 32bit
> > color values
> >
> > I think, it's something along the lines of what you're saying.. I
> > believe the values are being cropped to 8bit integer values.. Thus
> > returning an error saying the value must be a 32bit integer.
> >
> >
> > Chris
> >
> >
> > Robert Craig wrote:
> > > Chris Bensler writes:
> > > > ...when the code does not pass through WinMain,
> > > > it doesn't allow me to poke4 the values, resulting
> > > > in incorrect colors..
> > >
> > > I'm not sure what you are doing, but
> > > keep in mind that Euphoria routines, such as poke4(),
> > > deal with data in Euphoria's internal format.
> > > Euphoria integers and C integers are the same,
> > > as long as you are in the range of (roughly) -1 billion
> > > to +1 billion. Outside of this range a Euphoria library
> > > routine will interpret the number to be a kind of pointer to
> > > a double or a sequence. To pass a 32-bit integer,
> > > outside of the range, you would have to create a pointer
> > > to a double, like what NewDouble() returns, and pass that.
> > > This is very tricky, not for the faint of heart.
> > >
> > > Also, WinMain() causes a lot of necessary stuff to
> > > be initialized. If you skip it, some things won't work right.
> > >
> > > Regards,
> > > Rob Craig
> > > Rapid Deployment Software
> > > http://www.RapidEuphoria.com
> > >
> > >
> >
> >
> >
>
>
4. RE: poke4 won't accept my 32bit values
I tried changing the TranslateMessage Param to C_UINT,C_LONG,C_ULONG,
etc.. but no go..
Also, I've never attempted to convert the examples to C.. not really any
point seeing as the original demos were FROM C.
Chris
just a bit of psuedo-code to maybe help you to uderstand my problem
better...
not functional code.
procedure names aren't even accurate..
This is how the original demos work..
<ORIGINAL PSUEDO CODE>
function Init_Loop()
EXOTICA_INIT()
etc...
etc...
end function
procedure Animate_Scene()
Set_Color(#FFFFFFFF)
end procedure
function Main_Loop()
CLEAR_SURFACE(0)
Animate_Scene() -- This contains the calls to set the color of the
objects etc..
etc...
etc...
if KeyPress() = ESCAPE then return 1 end if
return 0
end function
function Exit_Loop()
EXOTICA_EXIT()
return 0
end function
<END OF ORIGINAL PSUEDO CODE>
On calling WinMain,
the Init_Loop() will be executed immediately only once,
the Main_Loop() will be executed in the message loop, exiting the loop
if it returns True..
the Exit_Loop is called at the very end(Not really nessecary to be
called from WinMain as it is called at the very end of WinMain with no
code specific to WinMain..)
<EXOTICAX PSUEDO CODE>
exotica_init() -- WinMain is initialized here..
procedure Animate_Scene()
Set_Color(#FFFFFFFF)
end procedure
while not KeyPress() = ESCAPE do
clear_surface(0)
Animate_Scene()
etc...
etc...
etc...
--- exotica_error() contains the message loop to poll for windows
messages
if exotica_error() then exotica_abort(1) end if
end while
exotica_exit()
<END OF EXOTICAX PSUEDO CODE>
This works fine as long as I don't need to poke the color values
directly to memory..
But when I do try to poke the values, it says the value is not 32bit.
I hope this helps you to understand my dilemna..
Chris
Derek Parnell wrote:
> >
> > C_INT, what should it be?
> >
> > But even if this is the problem.. it is exclusive to my code.. No
> > problems in the original Exotica demos..
> >
>
> I'm not sure, maybe Robert can chip in here, but C_UINT is a 32-bit
> unsigned
> integer and C_INT is a 32-bit signed integer. Maybe when Euphoria
> invokes
> the c_func() routine it converts the supplied parameters based on these
> signatures. If it uses C_INT, it might be chopping off the high bits.
>
> This is just a guess.
>
> I'm also guessing that its Euphoria interpreter you are having trouble
> with.
> Is it? Or is this the translated C code?
>
> ------
> Derek Parnell
> Melbourne, Australia
> "To finish a job quickly, go slower."
>
>
>
>
5. RE: poke4 won't accept my 32bit values
GAUH!! I can't win!!
Can't post from my normal mail client, and my web client posts garbage
for attachments..
Here is the EX.ERR...
(The path is funky cause it's supposed to be in Korean.. nothing to do
with the problem)
Chris
zp = 0
wp = 0
test = 4294967296 <<<<<<<<< this is the value being
poked... (#FFFFFFFF)
vEyePt = {0.02499989504,3,4.999937536}
vLookatPt = {0.4192286976,2.5,3.977970432}
vUpVec = {0,1,0}
mat_seq2 =
-0.2927047936,5.48124672,1}
mat1 = {}
mat2 = {}
mat3 = {}
matSet = {}
. irrelavent info stripped....
6. RE: poke4 won't accept my 32bit values
When I do the exact same test in Todds Demo, it returns the proper
value!? What the ....
Why would my changing the execution of WinMain affect this?
Chris
Robert Craig wrote:
> Chris Bensler writes:
> > test = 4294967296 <<<<<<<<< this is the value being
> > poked... (#FFFFFFFF)
>
> Not quite....
>
> #FFFFFFFF = 4294967295
>
> Your "test" variable is 1 higher than
> the maximum 32-bit (unsigned) integer,
> so poke4() gives you an error.
>
> To get the low-order 32-bits you could do:
>
> test = remainder(test, 4294967296)
>
> which in this case is 0. In general you'll get
> the low-order 32-bits, which is what a C program would
> give you, since C doesn't worry about integer overflow.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
>
>
7. RE: poke4 won't accept my 32bit values
Oh yeah,,
Why would my demos be reporting one higher?
The info I gave was straight from the EX.ERR
Chris
Robert Craig wrote:
> Chris Bensler writes:
> > test = 4294967296 <<<<<<<<< this is the value being
> > poked... (#FFFFFFFF)
>
> Not quite....
>
> #FFFFFFFF = 4294967295
>
> Your "test" variable is 1 higher than
> the maximum 32-bit (unsigned) integer,
> so poke4() gives you an error.
>
> To get the low-order 32-bits you could do:
>
> test = remainder(test, 4294967296)
>
> which in this case is 0. In general you'll get
> the low-order 32-bits, which is what a C program would
> give you, since C doesn't worry about integer overflow.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
>
>
8. RE: poke4 won't accept my 32bit values
- Posted by Chris Bensler <bensler at mailops.com>
Mar 19, 2001
-
Last edited Mar 20, 2001
If it's a bug, it's a VERY clever one.. it's modifying hard code
I'm poking code embedded values not variables..
> This example you gave works fine. Are you saying you have the line ...
>
> > poke4(Color_Value,#FFFFFFFF)
>
> in two programs. It works in one and fails in the other?
>
Esentially, YES, other than the address..
> According to the ex.err file, there is a variable called 'test'
> involved.
>
'test' was just so it would show up in the EX.ERR, not actually apart of
my demo...
> You can send me the source code if you wish me to debug it.
I'll do that.. TY very much...
Chris
9. RE: poke4 won't accept my 32bit values
Yeah, I agree, this doesn't make any sense whats so ever. The 'C'
translated code is:
// Fill the array of TL vertices with untransformed data for the
cube
g_pvCube[0] = D3DTLVERTEX( D3DVECTOR(-1,-1,-1 ), 0, 0xffffffff, 0,
0, 0 );
g_pvCube[1] = D3DTLVERTEX( D3DVECTOR( 1,-1,-1 ), 0, 0xff00ffff, 0,
0, 0 );
g_pvCube[2] = D3DTLVERTEX( D3DVECTOR(-1, 1,-1 ), 0, 0xffff00ff, 0,
0, 0 );
g_pvCube[3] = D3DTLVERTEX( D3DVECTOR( 1, 1,-1 ), 0, 0xff0000ff, 0,
0, 0 );
g_pvCube[4] = D3DTLVERTEX( D3DVECTOR(-1,-1, 1 ), 0, 0xffffff00, 0,
0, 0 );
g_pvCube[5] = D3DTLVERTEX( D3DVECTOR( 1,-1, 1 ), 0, 0xff00ff00, 0,
0, 0 );
g_pvCube[6] = D3DTLVERTEX( D3DVECTOR(-1, 1, 1 ), 0, 0xffff0000, 0,
0, 0 );
g_pvCube[7] = D3DTLVERTEX( D3DVECTOR( 1, 1, 1 ), 0, 0xff000000, 0,
0, 0 );
definition of D3DTLVERTEX is:
typedef struct _D3DTLVERTEX {
union {
D3DVALUE sx;
D3DVALUE dvSX;
};
union {
D3DVALUE sy;
D3DVALUE dvSY;
};
union {
D3DVALUE sz;
D3DVALUE dvSZ;
};
union {
D3DVALUE rhw;
D3DVALUE dvRHW;
};
union {
D3DCOLOR color;
D3DCOLOR dcColor;
};
union {
D3DCOLOR specular;
D3DCOLOR dcSpecular;
};
union {
D3DVALUE tu;
D3DVALUE dvTU;
};
union {
D3DVALUE tv;
D3DVALUE dvTV;
};
} D3DTLVERTEX, *LPD3DTLVERTEX;
Definition of D3DVECTOR is:
typedef struct _D3DVECTOR {
union {
D3DVALUE x;
D3DVALUE dvX;
};
union {
D3DVALUE y;
D3DVALUE dvY;
};
union {
D3DVALUE z;
D3DVALUE dvZ;
};
} D3DVECTOR, *LPD3DVECTOR;
Definition of D3DVALUE is:
typedef float D3DVALUE, *LPD3DVALUE;
This code in question works fine how I set up "windows" code
to get the Exotica dll working with Euphoira. Chris uses a diferent
method to set up "windows" to get the Exotica dll working in
Euphoria using his ExoticaX sdk.
the translated code of what is at the very top of this page
in Euphoira is:
poke( pvCube ,atom_to_float32(-1.0))
poke( pvCube+4 ,atom_to_float32(-1.0))
poke( pvCube+8 ,atom_to_float32(-1.0))
poke( pvCube+12,atom_to_float32(0.0))
poke4(pvCube+16,{#FFFFFFFF,0}) -- *DP* This is where the
program will crash in the adverse file
--poke(pvCube+20,0)
poke( pvCube+24,atom_to_float32(0.0))
poke( pvCube+28,atom_to_float32(0.0))
poke( pvCube+32,atom_to_float32( 1.0))
poke( pvCube+36,atom_to_float32(-1.0))
poke( pvCube+40,atom_to_float32(-1.0))
poke( pvCube+44,atom_to_float32(0.0))
poke4(pvCube+48,{#FF00FFFF,0})
--poke(pvCube+52,0)
poke( pvCube+56,atom_to_float32(0.0))
poke( pvCube+60,atom_to_float32(0.0))
poke( pvCube+64,atom_to_float32(-1.0))
poke( pvCube+68,atom_to_float32( 1.0))
poke( pvCube+72,atom_to_float32(-1.0))
poke( pvCube+76,atom_to_float32(0.0))
poke4(pvCube+80,{#FFFF00FF,0})
--poke(pvCube+84,0)
poke( pvCube+88,atom_to_float32(0.0))
poke( pvCube+92,atom_to_float32(0.0))
poke( pvCube+96,atom_to_float32( 1.0))
poke( pvCube+100,atom_to_float32( 1.0))
poke( pvCube+104,atom_to_float32(-1.0))
poke( pvCube+108,atom_to_float32(0.0))
poke4(pvCube+112,{#FF0000FF,0})
--poke(pvCube+116,0)
poke( pvCube+120,atom_to_float32(0.0))
poke( pvCube+124,atom_to_float32(0.0))
poke( pvCube+128,atom_to_float32(-1.0))
poke( pvCube+132,atom_to_float32(-1.0))
poke( pvCube+136,atom_to_float32( 1.0))
poke( pvCube+140,atom_to_float32(0.0))
poke4(pvCube+144,{#FFFFFF00,0})
--poke(pvCube+148,0)
poke( pvCube+152,atom_to_float32(0.0))
poke( pvCube+156,atom_to_float32(0.0))
poke( pvCube+160,atom_to_float32( 1.0))
poke( pvCube+164,atom_to_float32(-1.0))
poke( pvCube+168,atom_to_float32( 1.0))
poke( pvCube+172,atom_to_float32(0.0))
poke4(pvCube+176,{#FF00FF00,0})
--poke(pvCube+180,0)
poke( pvCube+184,atom_to_float32(0.0))
poke( pvCube+188,atom_to_float32(0.0))
poke( pvCube+192,atom_to_float32(-1.0))
poke( pvCube+196,atom_to_float32( 1.0))
poke( pvCube+200,atom_to_float32( 1.0))
poke( pvCube+204,atom_to_float32(0.0))
poke4(pvCube+208,{#FFFF0000,0})
--poke(pvCube+212,0)
poke( pvCube+216,atom_to_float32(0.0))
poke( pvCube+220,atom_to_float32(0.0))
poke( pvCube+224,atom_to_float32( 1.0))
poke( pvCube+228,atom_to_float32( 1.0))
poke( pvCube+232,atom_to_float32( 1.0))
poke( pvCube+236,atom_to_float32(0.0))
poke4(pvCube+240,{#FF000000,0})
--poke(pvCube+244,0)
poke( pvCube+248,atom_to_float32(0.0))
poke( pvCube+252,atom_to_float32(0.0))
At the *DP* statement is where Euphoria says the error code:
C:\Programming\Exotica_users\chris_b\poke4 bug\Failing Demo.exw:167 in
procedure FrameMove()
poke4 is limited to 32-bit numbers
vx = 0
vy = 1
vz = 0
dwNumVertices = <no value>
xp = 0
yp = 0
zp = 0
wp = 0
vEyePt = {0.02499989504,3,4.999937536}
vLookatPt = {0.4192286976,2.5,3.977970432}
vUpVec = {0,1,0}
mat_seq2 =
-0.2927047936,5.48124672,1}
mat1 = {}
mat2 = {}
mat3 = {}
matSet = {}
/snip/
in " poke4(pvCube+16,{#FFFFFFFF,0})" , #FFFFFFFF is a 32bit number.
So why this works in how I handle DirectX applications with Euphoria
and not for how Chris does it, baffles the heck out of me.
As far as what Chris showed me, nothing else is different except
how he calls windows. He's way of doing it simply *should* work.
Sorry Chris, I'm as stoked as you are... I'm looking for some
asprins at the moment... :\
-------------------------------------
Todd Riggins
-------------------------------------
Exotica DX Game Library For Euphoria
-------------------------------------
Exotica Website:
http://exotica.iwarp.com/exotica.html
-------------------------------------
Exotica Forum:
http://pub19.ezboard.com/bexoticadxgamelibrary
-------------------------------------
10. RE: poke4 won't accept my 32bit values
Rob, I think maybe you should take a look at this one..
I can send you the code, it's pretty straight forward..
I am thinking it has something to do with calling routines through
call_func()
I don't know if anyone can solve this one for me..
I see no reason why my code shouldn't work..
Oddly enough, I am quite sure I had it working before when I first
released my code.. but I then found out that I had this bug, and now, I
can't get rid of it..
Chris
11. RE: poke4 won't accept my 32bit values
Let's see...
#FFFFFFFF is a 4-byte integer value...
Hmm...
I tried doing this;
poke4(#A0000, {#FFFFFFFF,0})
and it works...
#FFFFFFFF = 429,496,729,5
so no problem there...
Two causes if you ask me;
poke4() is using a 31 bit integer as parameter, not a
32 bit one (As #FFFFFFFF =
11111111111111111111111111111111 in binary notation).
atom_to_float32(0.0) is screwing up memory...
Mike The Spike
PS. If I see the code I can find out the cause of the
error, but no doubt; poke4() is getting a value passed
to it bigger than it can poke. Sollution:
change 'poke4(pvCube+16,{#FFFFFFFF,0})' into
'poke(pvCube+16,{#FF,#FF,#FF,#FF})' ...
--- Todd Riggins <triggins at ev1.net> wrote:
> Yeah, I agree, this doesn't make any sense whats so
> ever. The 'C'
> translated code is:
>
> // Fill the array of TL vertices with
> untransformed data for the
> cube
> g_pvCube[0] = D3DTLVERTEX( D3DVECTOR(-1,-1,-1 ),
> 0, 0xffffffff, 0,
> 0, 0 );
> g_pvCube[1] = D3DTLVERTEX( D3DVECTOR( 1,-1,-1 ),
> 0, 0xff00ffff, 0,
> 0, 0 );
> g_pvCube[2] = D3DTLVERTEX( D3DVECTOR(-1, 1,-1 ),
> 0, 0xffff00ff, 0,
> 0, 0 );
> g_pvCube[3] = D3DTLVERTEX( D3DVECTOR( 1, 1,-1 ),
> 0, 0xff0000ff, 0,
> 0, 0 );
> g_pvCube[4] = D3DTLVERTEX( D3DVECTOR(-1,-1, 1 ),
> 0, 0xffffff00, 0,
> 0, 0 );
> g_pvCube[5] = D3DTLVERTEX( D3DVECTOR( 1,-1, 1 ),
> 0, 0xff00ff00, 0,
> 0, 0 );
> g_pvCube[6] = D3DTLVERTEX( D3DVECTOR(-1, 1, 1 ),
> 0, 0xffff0000, 0,
> 0, 0 );
> g_pvCube[7] = D3DTLVERTEX( D3DVECTOR( 1, 1, 1 ),
> 0, 0xff000000, 0,
> 0, 0 );
>
> definition of D3DTLVERTEX is:
>
> typedef struct _D3DTLVERTEX {
> union {
> D3DVALUE sx;
> D3DVALUE dvSX;
> };
> union {
> D3DVALUE sy;
> D3DVALUE dvSY;
> };
> union {
> D3DVALUE sz;
> D3DVALUE dvSZ;
> };
> union {
> D3DVALUE rhw;
> D3DVALUE dvRHW;
> };
> union {
> D3DCOLOR color;
> D3DCOLOR dcColor;
> };
> union {
> D3DCOLOR specular;
> D3DCOLOR dcSpecular;
> };
> union {
> D3DVALUE tu;
> D3DVALUE dvTU;
> };
> union {
> D3DVALUE tv;
> D3DVALUE dvTV;
> };
> } D3DTLVERTEX, *LPD3DTLVERTEX;
>
> Definition of D3DVECTOR is:
>
> typedef struct _D3DVECTOR {
> union {
> D3DVALUE x;
> D3DVALUE dvX;
> };
> union {
> D3DVALUE y;
> D3DVALUE dvY;
> };
> union {
> D3DVALUE z;
> D3DVALUE dvZ;
> };
> } D3DVECTOR, *LPD3DVECTOR;
>
>
>
> Definition of D3DVALUE is:
>
> typedef float D3DVALUE, *LPD3DVALUE;
>
> This code in question works fine how I set up
> "windows" code
> to get the Exotica dll working with Euphoira. Chris
> uses a diferent
> method to set up "windows" to get the Exotica dll
> working in
> Euphoria using his ExoticaX sdk.
>
> the translated code of what is at the very top of
> this page
> in Euphoira is:
>
> poke( pvCube ,atom_to_float32(-1.0))
> poke( pvCube+4 ,atom_to_float32(-1.0))
> poke( pvCube+8 ,atom_to_float32(-1.0))
> poke( pvCube+12,atom_to_float32(0.0))
> poke4(pvCube+16,{#FFFFFFFF,0}) -- *DP*
> This is where the
> program will crash in the adverse file
> --poke(pvCube+20,0)
> poke( pvCube+24,atom_to_float32(0.0))
> poke( pvCube+28,atom_to_float32(0.0))
>
> poke( pvCube+32,atom_to_float32( 1.0))
> poke( pvCube+36,atom_to_float32(-1.0))
> poke( pvCube+40,atom_to_float32(-1.0))
> poke( pvCube+44,atom_to_float32(0.0))
> poke4(pvCube+48,{#FF00FFFF,0})
> --poke(pvCube+52,0)
> poke( pvCube+56,atom_to_float32(0.0))
> poke( pvCube+60,atom_to_float32(0.0))
>
> poke( pvCube+64,atom_to_float32(-1.0))
> poke( pvCube+68,atom_to_float32( 1.0))
> poke( pvCube+72,atom_to_float32(-1.0))
> poke( pvCube+76,atom_to_float32(0.0))
> poke4(pvCube+80,{#FFFF00FF,0})
> --poke(pvCube+84,0)
> poke( pvCube+88,atom_to_float32(0.0))
> poke( pvCube+92,atom_to_float32(0.0))
>
> poke( pvCube+96,atom_to_float32( 1.0))
> poke( pvCube+100,atom_to_float32( 1.0))
> poke( pvCube+104,atom_to_float32(-1.0))
> poke( pvCube+108,atom_to_float32(0.0))
> poke4(pvCube+112,{#FF0000FF,0})
> --poke(pvCube+116,0)
> poke( pvCube+120,atom_to_float32(0.0))
> poke( pvCube+124,atom_to_float32(0.0))
>
> poke( pvCube+128,atom_to_float32(-1.0))
> poke( pvCube+132,atom_to_float32(-1.0))
> poke( pvCube+136,atom_to_float32( 1.0))
> poke( pvCube+140,atom_to_float32(0.0))
> poke4(pvCube+144,{#FFFFFF00,0})
> --poke(pvCube+148,0)
> poke( pvCube+152,atom_to_float32(0.0))
> poke( pvCube+156,atom_to_float32(0.0))
>
> poke( pvCube+160,atom_to_float32( 1.0))
> poke( pvCube+164,atom_to_float32(-1.0))
> poke( pvCube+168,atom_to_float32( 1.0))
> poke( pvCube+172,atom_to_float32(0.0))
> poke4(pvCube+176,{#FF00FF00,0})
> --poke(pvCube+180,0)
> poke( pvCube+184,atom_to_float32(0.0))
> poke( pvCube+188,atom_to_float32(0.0))
>
> poke( pvCube+192,atom_to_float32(-1.0))
> poke( pvCube+196,atom_to_float32( 1.0))
> poke( pvCube+200,atom_to_float32( 1.0))
> poke( pvCube+204,atom_to_float32(0.0))
> poke4(pvCube+208,{#FFFF0000,0})
> --poke(pvCube+212,0)
> poke( pvCube+216,atom_to_float32(0.0))
> poke( pvCube+220,atom_to_float32(0.0))
>
> poke( pvCube+224,atom_to_float32( 1.0))
> poke( pvCube+228,atom_to_float32( 1.0))
> poke( pvCube+232,atom_to_float32( 1.0))
> poke( pvCube+236,atom_to_float32(0.0))
> poke4(pvCube+240,{#FF000000,0})
> --poke(pvCube+244,0)
> poke( pvCube+248,atom_to_float32(0.0))
> poke( pvCube+252,atom_to_float32(0.0))
>
>
> At the *DP* statement is where Euphoria says the
> error code:
>
> C:\Programming\Exotica_users\chris_b\poke4
> bug\Failing Demo.exw:167 in
> procedure FrameMove()
> poke4 is limited to 32-bit numbers
> vx = 0
> vy = 1
> vz = 0
> dwNumVertices = <no value>
>
=== message truncated ===
12. RE: poke4 won't accept my 32bit values
Hi Derek,
Tried and Failed... That's what the Test variable was about...
On the note of the Failing Demo.. I forgot to mention an important
factor... The demo Does fail and complete execution, but the console
window stays behind the DX window, thus yhou can't see it, just press
ENTER and it will complete and report to EX.ERR
Derek Parnell wrote:
> How about chnaging the code like this ...
>
> FROM:
>
> poke4(pvCube+16, {#FFFFFFFF,0})
>
> TO:
> atom spareatom
> . . .
> spareatom = #FFFFFFFF
> poke4(pvCube+16, {spareatopm, 0})
> just as an experiment.
> ------
> Derek Parnell
> Melbourne, Australia
> "To finish a job quickly, go slower."
>
>
>
13. RE: poke4 won't accept my 32bit values
I am NOT skipping WinMain, I've simply implemented it differently, all
the code is still there... Just broken up to different sections..
I'll send you the code..
Chris
Robert Craig wrote:
> Chris Bensler writes:
> > Rob, I think maybe you should take a look at this one..
> > I can send you the code, it's pretty straight forward..
>
> I don't know what you are trying to do,
> but I think you mentioned something about
> skipping WinMain(), and I warned that you can't
> necessarily do that, since WinMain() calls eu_startup()
> and other routines which initialize a bunch of
> important data structures. Data structures that you
> might not need for integer (31-bit) calculations,
> but you will definitely need for larger numbers.
>
> If that's not what you are doing,
> then please send me the code.
>
> Thanks,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
>
>
>
14. RE: poke4 won't accept my 32bit values
- Posted by Al Getz <Xaxo at aol.com>
Mar 20, 2001
-
Last edited Mar 21, 2001
Hi Chris,
Sounds like your doing something fundamentally incorrect.
Sometimes in haste we skip over something very simple
because it seems so familiar.
When a problem like this occurs, its usually advisable
to develop a simple test to challenge all the basic
premises. The results of the test will shed light on the
problem in most cases.
(see simple test routine below also)
In this case it seems all we need to do is
indentify the "universe of possible inputs", and then
determine what part of the universe works, and what part
doesnt. This often provides enough info to understand
the solution immediately.
In this case you want to see what is being stored with
poke4() because apparently you get an error in that
line?
1. Since you are dealing with 32 bit numbers, the universe
of inputs is simply #00000000 to #FFFFFFFF (hex).
2. Since the error seems to occur with one value and not
another, the next step is to find the "threshold of error".
Some numbers between 0 and #FFFFFFFF work, while others
cause an error. Somewhere in between you may reach a single
number that doesnt work, where all numbers after that point
fail, while the others up to that point all work fine, or
you may find a pattern in the numbers that work and those
that dont work.
3. Start with a reasonable number, say #0FFFFFFF and see if that
works. Then try #0FFFFFFF + 16 and see if that works. When you get
a failure, note the number that it failed at and restart the test
from that number minus 16 with the increment set to 1 instead of 16.
When you get a failure again, you should know at least the first
number it fails at.
(Of course you use a programmed loop to do the testing, untill a
failure and then you must restart the test loop with different start
values.)
This should shed much light on the problem.
A simple test routine might look like this:
----------------------
integer inc
atom n,m
address a
a=allocate(4)
with trace
n=#0FFFFFFF --starting number
inc=16 --starting increment
while n<=#FFFFFFFF do
poke4(a,n)
m=peek4u(a)
if m!=n then
puts(1,"didnt peek the same number!\n")
?n
trace(1)
end if
n=n+inc
end while
free(a)
----------------------
Important notes:
1. Naturally you need to insert this test in the EXACT location
in the file where your error occurs, NOT JUST ANYWHERE.
2. If your code is being translated, you will have to find the
appropriate position in the Euphoria file.
If you can modify the translated file, you can always insert
an appropriatly modified version of the test loop above.
3. If you cant indentify the number n after an error you may
have to print values to a file so that when the error occurs,
you may read the file to see the number.
4. Of course if that fails on the first n, you need to lower the
start value of n and possibly increase the initial increment to speed
up the test.
This kind of test really does help in most situations. The neat
thing is, if it turns out to be something else, it usually becomes
apparent after the test is run.
Good luck with it.
--Al
15. RE: poke4 won't accept my 32bit values
Thanks Derek, but it still doesn't explain why it would work for the
original Exotica Demos, and not for ExoticaX.. Tells me it has something
to do with my code, but I can't find it..
I even used the original Exotica demo, and changed only the necessities
to ExoticaX.. that would be: exotica_init(), and exotica_error().
That's why I looked there..
create3D_device doesn't cause the program to fail, only when I change
the lines.. c_proc(EXOTICA_INIT,{NULL}) to exotica_init(), and
c_func(ON_ERROR,{NULL}) to exotica_error().. the respective ExoticaX
counterparts.. does the program give me that error..
Only when I split the WinMain function like I have in ExoticaX do I get
that error..
Chris
Derek Parnell wrote:
> Hi Al,
> it's still early yet, but just before you posted this I'd tracked down
> the
> location of the problem. Superficially it appears to be a bug in the
> direct
> draw library (create3d_device) that is corrupting a part of the
> interpreter.
>
> I found this out but placing the offending line of code in various parts
> of
> the program until I isolated the line of code that was causing the
> effect.
>
> I appears that once the call to create3d_device has been executed,
> poke4()
> would no longer work for any values between #FFFFFF01 and #FFFFFFFF.
> Instead
> it would also convert these to #100000000, even if the values were in
> variables or expressions (eg. #FFFFFF00 + #FF).
>
> The workaround was to place all the code containing the poke4()
> statements
> physically before the create3d_device function was executed.
>
> Of course, none of this is conclusive yet. I've given this info to
> Robert as
> well and maybe he can confirm it or find a deeper reason.
>
> ----- Original Message -----
> From: "Al Getz" <Xaxo at aol.com>
> To: "EUforum" <EUforum at topica.com>
> Sent: Wednesday, March 21, 2001 4:39 PM
> Subject: RE: poke4 won't accept my 32bit values
>
>
> [big snip]
> >
> > Good luck with it.
> > --Al
> >
>
> ------
> Derek Parnell
> Melbourne, Australia
> "To finish a job quickly, go slower."
>
>
>
>
16. RE: poke4 won't accept my 32bit values
Derek Parnell wrote:
> Well, except that the problem seems to start happening if
> create3d_device()
> is EXECUTED before Euphoria intepreter has PROCESSED (but not executed)
> the
> FrameMove() procedure definition. And this is the case in the original
> demo
> but in your modified demo.
Your right, I thought of that just after my last post..
Must find a way around this... without forcing the user to code thier
apps a certain way...
Todd, would you PLEASE send your DLL code for CREATE3D_DEVICE to Rob, so
maybe he can explain why this is happening.. I know you don't want to
release your source, but this smells like a bug to me...
Chris
17. RE: poke4 won't accept my 32bit values
Hi again Derek,
Very interesting problem there.
Derek wrote:
>>It appears that once the call to create3d_device has been executed,
>>>>poke4()
>>would no longer work for any values between #FFFFFF01 and >>#FFFFFFFF.
>>Instead
>>it would also convert these to #100000000, even if the values were >>in
>>variables or expressions (eg. #FFFFFF00 + #FF).
Sounds like some bad code in create3d_device, but i still have
to ask the question:
"What happens when you substitute poke(addr,{#FF,#FF,#FF,#FF})
for poke4(addr,#FFFFFFFF) ?"
This would be a very interesting experiment.
Does poke() fail as well?
Another question is:
where exactly is all the poking being done?
Could the poking itself be 'corrupting' the resident interpreter
because of writing beyond the validly allocated region?
This could happen if one allocates say, 4 bytes of mem and
pokes 5 bytes in consecutive mem and it doesnt trigger a memory
exception because the original 4 bytes just happens to border
other allocated memory perfectly.
Wishing you all luck with it.
--Al
18. RE: poke4 won't accept my 32bit values
Al Getz wrote:
> "What happens when you substitute poke(addr,{#FF,#FF,#FF,#FF})
> for poke4(addr,#FFFFFFFF) ?"
It works, but not a fix, just a work around, already have a few of
those...
> Another question is:
> where exactly is all the poking being done?
> Could the poking itself be 'corrupting' the resident interpreter
> because of writing beyond the validly allocated region?
> This could happen if one allocates say, 4 bytes of mem and
> pokes 5 bytes in consecutive mem and it doesnt trigger a memory
> exception because the original 4 bytes just happens to border
> other allocated memory perfectly.
Memory is allocated correctly.. only fails in a specific situation..
Like Derek described..
19. RE: poke4 won't accept my 32bit values
I discovered something else...
This bug only happens when poking HEX values.
If I try..
poke4(pvCube+16 ,4294967295)
Guess what? It works!???
Gotta be an EU problem somehow..
Chris
20. RE: poke4 won't accept my 32bit values
Hi again Chris,
Chris Bensler wrote:
> I discovered something else...
>
> This bug only happens when poking HEX values.
> If I try..
> poke4(pvCube+16 ,4294967295)
>
> Guess what? It works!???
>
> Gotta be an EU problem somehow..
>
> Chris
Hmmm, now it sounds like whatever converts "#n" formats
into atoms for large hex numbers is screwing up the conversion.
That would also explain how #FFFFFFFF gets converted into
#100000000 as Derek was saying.
Another test would be to create the number by adding
two values together that do convert correctly, such as:
n=#FFFF0000+#FFFF to create #FFFFFFFF
or build the number up separately:
n1=#FFFF0000
n2=#FFFF
n=n1+n2
If its always larger numbers, you could try:
n1=#80000000 --do high bit separate
n2=#7FFFFFFF
n=n1+n2
If these last two methods work, i would assume the
"#n" conversion routine was suspect for n greater than
some large value. Of course i have no idea why, without
seeing all the code.
Q. Could it be its trying to convert to a negative signed atom
instead of a large positive atom, interpreting the high bit
as a sign bit?
A. Not if it really does convert #FFFFFFFF to #100000000 (which
im not sure how #100000000 was verified).
In any case, i hope you find the problem, and its solution.
--Al
21. RE: poke4 won't accept my 32bit values
Al Getz wrote:
> Another test would be to create the number by adding
> two values together that do convert correctly, such as:
> n=#FFFF0000+#FFFF to create #FFFFFFFF
> or build the number up separately:
> n1=#FFFF0000
> n2=#FFFF
> n=n1+n2
> If its always larger numbers, you could try:
> n1=#80000000 --do high bit separate
> n2=#7FFFFFFF
> n=n1+n2
>
The only way to poke #FFFFFFFF as HEX correctly is in byte form..
Any way I slice it, trying to poke the HEX value as a DWORD, fails..
in an expression, passed by reference, or hard coded, same result..
> If these last two methods work, i would assume the
> "#n" conversion routine was suspect for n greater than
> some large value. Of course i have no idea why, without
> seeing all the code.
>
Derek said he resolved that poke4 fails between #FFFFFF00 and #FFFFFFFF.
I don't see how this could be happening..
And I am certainly not skilled enough to figure this one out..
Chris
22. RE: poke4 won't accept my 32bit values
- Posted by Chris Bensler <bensler at mailops.com>
Mar 21, 2001
-
Last edited Mar 22, 2001
Thank you Rob,
I fixed that bug..
instead of poking all four bytes, I changed it to only poke the first
two bytes from int_to_bytes.. This works with Safe.e
But like you said, after this fix, the system hangs on Safe.e
When I run the fixed demo with Machine.e, I get the same error..
poke4 is limited to 32-bit numbers
I think what you found was just ANOTHER bug, not the one I'm trying to
solve..
Todd, you should update that lib.. for the poke_words fix
Chris
Robert Craig wrote:
> Chris:
> I finally got around to trying your program.
>
> Since you aren't using Win32Lib,
> I tried your program using safe.e in place
> of the regular machine.e.
>
> I did the following:
>
> copy \euphoria\include\safe.e .
> rename safe.e machine.e
>
> Then I ran Derek's "working demo.exw".
>
> After a few seconds safe.e reported a call
> to poke() that is poking out of bounds, and it gave
> me an ex.err dump (attached).
>
> Here's what's happening.
>
> In poke_words() in exotica_api.ew
> you have a loop that is poking values.
> On the final iteration of the loop you (or Todd?) are
> stepping out of bounds. Although you are
> storing 2-byte values, you are actually poking
> 4-bytes at a time (from int_to_bytes()), while
> advancing the address only by 2.
> This is strange, but it works, except
> that on the final iteration you write 2 bytes
> out of bounds. pwCubeIndices is allocated a block
> that's 2-bytes too small. I gave it a couple of extra
> bytes and the safe.e report went away. However,
> I think I have an old version of directx, so my system
> hangs beyond that point.
>
> What does this have to do with poke4 and FFFFFFFF?
> Well, the interpreter can't store FFFFFFFF as a
> Euphoria 31-bit integer, so it allocates a place in the heap
> memory for a double. It's just possible that you are
> overwriting this double, thereby changing the value
> of this literal "constant" in the program.
> Any change to the program, such as shuffling statements
> around, do things in a slightly different way, could possibly
> change what is stored just after your block of memory,
> and could make the program either work or not.
> This naturally leads to all sorts of wild theories as
> to what might be happening.
>
> Anyway, fix this bug and carry on.
> There may be other bugs. I can't tell.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
>
>
