RE: [hlcoders] Works in debug mode, does not it release mode.
Reviving an old thread of a month ago since I'm still not certain what the implications are. So exactly why is it better to avoid complex Paint() methods? Methinks that eventually down the line, the vgui::ISurface calls are still being made, so it would make little difference that it is being called here. Besides, there's gotta be some overhead involved in complicating the hierarchy even more. John Sheu On Thu, 2006-03-30 at 11:00 -0800, Alfred Reynolds wrote: The third arg to ConvertANSIToUnicode() is the size of the output buffer in bytes. In this case you should use sizeof(unicode). This kind of code is the wrong pattern for VGUI2. It will perform really badly (because of the expensive operations you are running every time you paint) and makes your layout really fragile. A better model is to use a label to contain the text you want to draw and use an event to update text. The position, size and font the label uses should be contained in a .res file that is loaded by the base frame that owns the label ( it looks like CBBHudTaskList should be a frame in your case). If you cannot implement an event driven method then at least use the ::OnTick() method and only change the label text if the state changes. You can use the ::SetText() label call to set the string to render, and you don't need to do the unicode translation manually then. - Alfred ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Works in debug mode, does not it release mode.
It is a code maintainence, performance and reuse issue. If you roll your own Paint() code you end up having to rewrite functionality in each paint call and you tend to make your layout logic code rather than data driven. Paint also gets called many times per second, it is easy to blow away performance by making expensive calls on data that rarely changes (like the ConvertANSIToUnicode() call below), the VGUI2 framework is event driven and expensive calls only get made when they need to be. Writing your own complex paint function because of performance sounds like the catch cry of a premature optimiser and you wouldn't want to be one of those would you? In the past any VGUI2 performance problems we have had have been solved by algorithmic changes (mainly moving from a polling model that Paint() enables to an event driven model) and not by optmising individual lines of code. - Alfred John Sheu wrote: Reviving an old thread of a month ago since I'm still not certain what the implications are. So exactly why is it better to avoid complex Paint() methods? Methinks that eventually down the line, the vgui::ISurface calls are still being made, so it would make little difference that it is being called here. Besides, there's gotta be some overhead involved in complicating the hierarchy even more. John Sheu On Thu, 2006-03-30 at 11:00 -0800, Alfred Reynolds wrote: The third arg to ConvertANSIToUnicode() is the size of the output buffer in bytes. In this case you should use sizeof(unicode). This kind of code is the wrong pattern for VGUI2. It will perform really badly (because of the expensive operations you are running every time you paint) and makes your layout really fragile. A better model is to use a label to contain the text you want to draw and use an event to update text. The position, size and font the label uses should be contained in a .res file that is loaded by the base frame that owns the label ( it looks like CBBHudTaskList should be a frame in your case). If you cannot implement an event driven method then at least use the OnTick() method and only change the label text if the state changes. You can use the ::SetText() label call to set the string to render, and you don't need to do the unicode translation manually then. - Alfred ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Works in debug mode, does not it release mode.
On Fri, 2006-04-14 at 12:25 -0700, Alfred Reynolds wrote: It is a code maintainence, performance and reuse issue. If you roll your own Paint() code you end up having to rewrite functionality in each paint call and you tend to make your layout logic code rather than data driven. Paint also gets called many times per second, it is easy to blow away performance by making expensive calls on data that rarely changes (like the ConvertANSIToUnicode() call below), the VGUI2 framework is event driven and expensive calls only get made when they need to be. Premature optimization is the root of all evil -- Donald Knuth (or Tony Hoare, depending on who you talk to) Right then. In any case, my specific issue is with surface()-DrawTexturedRect() calls. Gauges and icons seem to call this one a lot; is it a good idea to do this manually as part of Paint()? Or is there some behind-the-scenes VGUI caching functionality that would make this a bad idea? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Works in debug mode, does not it release mode.
If you only call surface()-DrawTexturedRect() and the like in your Paint() function it won't defeat any VGUI2 functionality, but you will make your code hard to maintain. I would decompose the UI into the basic components, right a class to support each widget you need, put them together using a panel and a .res file for layout and see how it runs. If it is slow then use VPROF() to track down the problem and optimise as needed by crunching down the class hierarchy. - Alfred John Sheu wrote: On Fri, 2006-04-14 at 12:25 -0700, Alfred Reynolds wrote: It is a code maintainence, performance and reuse issue. If you roll your own Paint() code you end up having to rewrite functionality in each paint call and you tend to make your layout logic code rather than data driven. Paint also gets called many times per second, it is easy to blow away performance by making expensive calls on data that rarely changes (like the ConvertANSIToUnicode() call below), the VGUI2 framework is event driven and expensive calls only get made when they need to be. Premature optimization is the root of all evil -- Donald Knuth (or Tony Hoare, depending on who you talk to) Right then. In any case, my specific issue is with surface()-DrawTexturedRect() calls. Gauges and icons seem to call this one a lot; is it a good idea to do this manually as part of Paint()? Or is there some behind-the-scenes VGUI caching functionality that would make this a bad idea? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Works in debug mode, does not it release mode.
Unless someone has defined a valid assignment or conversion path for
this that I don't normally use you have to do this to your constant
strings:
sString = MAKE_STRING(Find the case!);
at least that's why MAKE_STRING exists in the first place.
It's not surprising that ConvertANSIToUnicode() would crash if these
assignments were producing an invalid pointer.
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Benjamin Davison
Sent: Thursday, March 30, 2006 10:50 AM
To: hlcoders@list.valvesoftware.com
Subject: [hlcoders] Works in debug mode, does not it release mode.
--
[ Picked text/plain from multipart/alternative ] Very weird
indeed, I'm working on some VGUI code and for some reason it
works in debug mode with the IDE attatched and fails to work
in release mode, and for the life of me I am stumped for a
soloution. Here is some code to see if you guys have run into
this problem.
void CBBHudTaskList::Paint( void )
{
// getting a pointer to the game rules
CHL2MPRules *pRules = HL2MPRules();
if ( !pRules )
return;
// local player
C_BasePlayer *pPlayer = C_BasePlayer::GetLocalPlayer();
if ( !pPlayer )
return;
string_t sString = ;
wchar_t unicode[256];
int x, y;
int textSizeWide, textSizeTall;
int iShown = 0; // number of lines shown
int fontTall = vgui::surface()-GetFontTall( m_hLargeFont );
int border = 20;
x = border / 2; // ScreenWidth() - border - textSizeWide;
y = iShown * fontTall; // border + iShown * fontTall;
SetSize( 300 + border, 40 );
if (pRules-m_bCaptureObjectActive == true)
{
sString = Find the case!;
}
else if (pRules-m_bCaptureZoneActivated == true)
{
sString = Get to this location and do something;
}
else
{
sString = No mission selected!;
}
vgui::localize()-ConvertANSIToUnicode( sString, unicode, 256);
// --- Set up default font and get character height for
line spacing
vgui::surface()-DrawSetTextFont( m_hLargeFont );
//vgui::surface()-DrawSetTextFont( m_hLargeFont );
vgui::surface()-DrawSetTextPos(x, y);
vgui::surface()-DrawPrintText( unicode, wcslen(unicode)
); // print text
BaseClass::Paint();
}
Now for some reason vgui::localize()-ConvertANSIToUnicode(
sString, unicode, 256); was crashing the release mode(not the
debug) if I put the buffer to 1024
Have any of you guys run into this problem? Or can you see
some error I have overlooked?
--
- Benjamin Davison
--
___
To unsubscribe, edit your list preferences, or view the list
archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Works in debug mode, does not it release mode.
Actually looking at the code you're using, you probably should just skip
string_t entirely (since the unicode conversion takes a char * anyway):
const char *pString = ;
then replace sString with pString...
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jay Stelly
Sent: Thursday, March 30, 2006 11:02 AM
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] Works in debug mode, does not it release mode.
Unless someone has defined a valid assignment or conversion
path for this that I don't normally use you have to do this
to your constant
strings:
sString = MAKE_STRING(Find the case!);
at least that's why MAKE_STRING exists in the first place.
It's not surprising that ConvertANSIToUnicode() would crash
if these assignments were producing an invalid pointer.
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Benjamin
Davison
Sent: Thursday, March 30, 2006 10:50 AM
To: hlcoders@list.valvesoftware.com
Subject: [hlcoders] Works in debug mode, does not it release mode.
--
[ Picked text/plain from multipart/alternative ] Very weird indeed,
I'm working on some VGUI code and for some reason it works in debug
mode with the IDE attatched and fails to work in release
mode, and for
the life of me I am stumped for a soloution. Here is some
code to see
if you guys have run into this problem.
void CBBHudTaskList::Paint( void )
{
// getting a pointer to the game rules
CHL2MPRules *pRules = HL2MPRules();
if ( !pRules )
return;
// local player
C_BasePlayer *pPlayer = C_BasePlayer::GetLocalPlayer();
if ( !pPlayer )
return;
string_t sString = ;
wchar_t unicode[256];
int x, y;
int textSizeWide, textSizeTall;
int iShown = 0; // number of lines shown
int fontTall = vgui::surface()-GetFontTall( m_hLargeFont );
int border = 20;
x = border / 2; // ScreenWidth() - border - textSizeWide;
y = iShown * fontTall; // border + iShown * fontTall;
SetSize( 300 + border, 40 );
if (pRules-m_bCaptureObjectActive == true)
{
sString = Find the case!;
}
else if (pRules-m_bCaptureZoneActivated == true)
{
sString = Get to this location and do something;
}
else
{
sString = No mission selected!;
}
vgui::localize()-ConvertANSIToUnicode( sString, unicode, 256);
// --- Set up default font and get character height for line
spacing
vgui::surface()-DrawSetTextFont( m_hLargeFont );
//vgui::surface()-DrawSetTextFont( m_hLargeFont );
vgui::surface()-DrawSetTextPos(x, y);
vgui::surface()-DrawPrintText( unicode, wcslen(unicode) ); //
print text
BaseClass::Paint();
}
Now for some reason vgui::localize()-ConvertANSIToUnicode(
sString, unicode, 256); was crashing the release mode(not the
debug) if I put the buffer to 1024
Have any of you guys run into this problem? Or can you see
some error
I have overlooked?
--
- Benjamin Davison
--
___
To unsubscribe, edit your list preferences, or view the
list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
___
To unsubscribe, edit your list preferences, or view the list
archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Works in debug mode, does not it release mode.
--
[ Picked text/plain from multipart/alternative ]
Ok guys ;) I'll change it, but I was wondering why it works 100% in debug
but works 0% in release.
On 3/30/06, Jay Stelly [EMAIL PROTECTED] wrote:
Unless someone has defined a valid assignment or conversion path for
this that I don't normally use you have to do this to your constant
strings:
sString = MAKE_STRING(Find the case!);
at least that's why MAKE_STRING exists in the first place.
It's not surprising that ConvertANSIToUnicode() would crash if these
assignments were producing an invalid pointer.
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Benjamin Davison
Sent: Thursday, March 30, 2006 10:50 AM
To: hlcoders@list.valvesoftware.com
Subject: [hlcoders] Works in debug mode, does not it release mode.
--
[ Picked text/plain from multipart/alternative ] Very weird
indeed, I'm working on some VGUI code and for some reason it
works in debug mode with the IDE attatched and fails to work
in release mode, and for the life of me I am stumped for a
soloution. Here is some code to see if you guys have run into
this problem.
void CBBHudTaskList::Paint( void )
{
// getting a pointer to the game rules
CHL2MPRules *pRules = HL2MPRules();
if ( !pRules )
return;
// local player
C_BasePlayer *pPlayer = C_BasePlayer::GetLocalPlayer();
if ( !pPlayer )
return;
string_t sString = ;
wchar_t unicode[256];
int x, y;
int textSizeWide, textSizeTall;
int iShown = 0; // number of lines shown
int fontTall = vgui::surface()-GetFontTall( m_hLargeFont );
int border = 20;
x = border / 2; // ScreenWidth() - border - textSizeWide;
y = iShown * fontTall; // border + iShown * fontTall;
SetSize( 300 + border, 40 );
if (pRules-m_bCaptureObjectActive == true)
{
sString = Find the case!;
}
else if (pRules-m_bCaptureZoneActivated == true)
{
sString = Get to this location and do something;
}
else
{
sString = No mission selected!;
}
vgui::localize()-ConvertANSIToUnicode( sString, unicode, 256);
// --- Set up default font and get character height for
line spacing
vgui::surface()-DrawSetTextFont( m_hLargeFont );
//vgui::surface()-DrawSetTextFont( m_hLargeFont );
vgui::surface()-DrawSetTextPos(x, y);
vgui::surface()-DrawPrintText( unicode, wcslen(unicode)
); // print text
BaseClass::Paint();
}
Now for some reason vgui::localize()-ConvertANSIToUnicode(
sString, unicode, 256); was crashing the release mode(not the
debug) if I put the buffer to 1024
Have any of you guys run into this problem? Or can you see
some error I have overlooked?
--
- Benjamin Davison
--
___
To unsubscribe, edit your list preferences, or view the list
archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
--
- Benjamin Davison
--
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Works in debug mode, does not it release mode.
--
[ Picked text/plain from multipart/alternative ]
Thanks Jay, I'll take those pointers away(rim shot) when I rewrite it in
accordance with Alfred's suggestions.
Still confusing that it worked in debug mode but displayed nothing in
release mode.
On 3/30/06, Jay Stelly [EMAIL PROTECTED] wrote:
Actually looking at the code you're using, you probably should just skip
string_t entirely (since the unicode conversion takes a char * anyway):
const char *pString = ;
then replace sString with pString...
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jay Stelly
Sent: Thursday, March 30, 2006 11:02 AM
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] Works in debug mode, does not it release mode.
Unless someone has defined a valid assignment or conversion
path for this that I don't normally use you have to do this
to your constant
strings:
sString = MAKE_STRING(Find the case!);
at least that's why MAKE_STRING exists in the first place.
It's not surprising that ConvertANSIToUnicode() would crash
if these assignments were producing an invalid pointer.
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Benjamin
Davison
Sent: Thursday, March 30, 2006 10:50 AM
To: hlcoders@list.valvesoftware.com
Subject: [hlcoders] Works in debug mode, does not it release mode.
--
[ Picked text/plain from multipart/alternative ] Very weird indeed,
I'm working on some VGUI code and for some reason it works in debug
mode with the IDE attatched and fails to work in release
mode, and for
the life of me I am stumped for a soloution. Here is some
code to see
if you guys have run into this problem.
void CBBHudTaskList::Paint( void )
{
// getting a pointer to the game rules
CHL2MPRules *pRules = HL2MPRules();
if ( !pRules )
return;
// local player
C_BasePlayer *pPlayer = C_BasePlayer::GetLocalPlayer();
if ( !pPlayer )
return;
string_t sString = ;
wchar_t unicode[256];
int x, y;
int textSizeWide, textSizeTall;
int iShown = 0; // number of lines shown
int fontTall = vgui::surface()-GetFontTall( m_hLargeFont );
int border = 20;
x = border / 2; // ScreenWidth() - border - textSizeWide;
y = iShown * fontTall; // border + iShown * fontTall;
SetSize( 300 + border, 40 );
if (pRules-m_bCaptureObjectActive == true)
{
sString = Find the case!;
}
else if (pRules-m_bCaptureZoneActivated == true)
{
sString = Get to this location and do something;
}
else
{
sString = No mission selected!;
}
vgui::localize()-ConvertANSIToUnicode( sString, unicode, 256);
// --- Set up default font and get character height for line
spacing
vgui::surface()-DrawSetTextFont( m_hLargeFont );
//vgui::surface()-DrawSetTextFont( m_hLargeFont );
vgui::surface()-DrawSetTextPos(x, y);
vgui::surface()-DrawPrintText( unicode, wcslen(unicode) ); //
print text
BaseClass::Paint();
}
Now for some reason vgui::localize()-ConvertANSIToUnicode(
sString, unicode, 256); was crashing the release mode(not the
debug) if I put the buffer to 1024
Have any of you guys run into this problem? Or can you see
some error
I have overlooked?
--
- Benjamin Davison
--
___
To unsubscribe, edit your list preferences, or view the
list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
___
To unsubscribe, edit your list preferences, or view the list
archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
--
- Benjamin Davison
--
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Works in debug mode, does not it release mode.
Debug mode has a lot more padding between memory allocations typically.
This call:
vgui::localize()-ConvertANSIToUnicode( sString, unicode, 1024)
Would cause a random piece of memory 512 bytes beyond the end of
unicode to be zero to 0 (null terminating the unicode string). In
debug you were probably zeroing unused memory so it had no impact, in
release you were smashing the stack or the like causing a crash. Moral
is, use sizeof(variable) when passing in buffer length parameters,
never hard code them :)
- Alfred
Benjamin Davison wrote:
--
[ Picked text/plain from multipart/alternative ]
Thanks Jay, I'll take those pointers away(rim shot) when I rewrite it
in
accordance with Alfred's suggestions.
Still confusing that it worked in debug mode but displayed nothing in
release mode.
On 3/30/06, Jay Stelly [EMAIL PROTECTED] wrote:
Actually looking at the code you're using, you probably should just
skip string_t entirely (since the unicode conversion takes a char *
anyway):
const char *pString = ;
then replace sString with pString...
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jay
Stelly Sent: Thursday, March 30, 2006 11:02 AM
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] Works in debug mode, does not it release
mode.
Unless someone has defined a valid assignment or conversion
path for this that I don't normally use you have to do this
to your constant
strings:
sString = MAKE_STRING(Find the case!);
at least that's why MAKE_STRING exists in the first place.
It's not surprising that ConvertANSIToUnicode() would crash
if these assignments were producing an invalid pointer.
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Benjamin Davison Sent: Thursday, March 30, 2006 10:50 AM
To: hlcoders@list.valvesoftware.com
Subject: [hlcoders] Works in debug mode, does not it release mode.
--
[ Picked text/plain from multipart/alternative ] Very weird indeed,
I'm working on some VGUI code and for some reason it works in debug
mode with the IDE attatched and fails to work in release mode, and
for the life of me I am stumped for a soloution. Here is some code
to see if you guys have run into this problem.
void CBBHudTaskList::Paint( void )
{
// getting a pointer to the game rules
CHL2MPRules *pRules = HL2MPRules();
if ( !pRules )
return;
// local player
C_BasePlayer *pPlayer = C_BasePlayer::GetLocalPlayer(); if
( !pPlayer ) return;
string_t sString = ;
wchar_t unicode[256];
int x, y;
int textSizeWide, textSizeTall;
int iShown = 0; // number of lines shown
int fontTall = vgui::surface()-GetFontTall( m_hLargeFont );
int border = 20;
x = border / 2; // ScreenWidth() - border - textSizeWide;
y = iShown * fontTall; // border + iShown * fontTall;
SetSize( 300 + border, 40 );
if (pRules-m_bCaptureObjectActive == true)
{
sString = Find the case!;
}
else if (pRules-m_bCaptureZoneActivated == true) {
sString = Get to this location and do something; }
else
{
sString = No mission selected!;
}
vgui::localize()-ConvertANSIToUnicode( sString, unicode, 256);
// --- Set up default font and get character height for line
spacing vgui::surface()-DrawSetTextFont( m_hLargeFont );
//vgui::surface()-DrawSetTextFont( m_hLargeFont );
vgui::surface()-DrawSetTextPos(x, y);
vgui::surface()-DrawPrintText( unicode, wcslen(unicode) ); //
print text
BaseClass::Paint();
}
Now for some reason vgui::localize()-ConvertANSIToUnicode(
sString, unicode, 256); was crashing the release mode(not the
debug) if I put the buffer to 1024
Have any of you guys run into this problem? Or can you see some
error I have overlooked?
--
- Benjamin Davison
--
___
To unsubscribe, edit your list preferences, or view the list
archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
___
To unsubscribe, edit your list preferences, or view the list
archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
___
To unsubscribe, edit your list preferences, or view the list
archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
--
- Benjamin Davison
--
___
To unsubscribe, edit your list preferences, or view the list
archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Works in debug mode, does not it release mode.
--
[ Picked text/plain from multipart/alternative ]
Thanks for the tip, but I implemented your sizeof(); suggestion :) It ain't
crashing anymore, but it's not displaying text weirdly enough. Debug is
still working :E
Well anyway I'll be rewriting it anyway :D I'm thinking of how I am gonna do
that. Do you think using an ::OnThink() function like most hud elements use
would be the best way? Possibly in the OnThink(); Check if pRules-foo has
changed. If it has call a function to change the size and text of the label?
And ::OnTick() There are only a couple of examples around the SDK and I was
trying to find the base function and I came across this in
vgui_BasePanel.cpp and found this:
void CBasePanel::OnTick( void )
{
// Nothing
}
How is this function called within the engine? And what is it good for?
On 3/30/06, Alfred Reynolds [EMAIL PROTECTED] wrote:
Debug mode has a lot more padding between memory allocations typically.
This call:
vgui::localize()-ConvertANSIToUnicode( sString, unicode, 1024)
Would cause a random piece of memory 512 bytes beyond the end of
unicode to be zero to 0 (null terminating the unicode string). In
debug you were probably zeroing unused memory so it had no impact, in
release you were smashing the stack or the like causing a crash. Moral
is, use sizeof(variable) when passing in buffer length parameters,
never hard code them :)
- Alfred
Benjamin Davison wrote:
--
[ Picked text/plain from multipart/alternative ]
Thanks Jay, I'll take those pointers away(rim shot) when I rewrite it
in
accordance with Alfred's suggestions.
Still confusing that it worked in debug mode but displayed nothing in
release mode.
On 3/30/06, Jay Stelly [EMAIL PROTECTED] wrote:
Actually looking at the code you're using, you probably should just
skip string_t entirely (since the unicode conversion takes a char *
anyway):
const char *pString = ;
then replace sString with pString...
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jay
Stelly Sent: Thursday, March 30, 2006 11:02 AM
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] Works in debug mode, does not it release
mode.
Unless someone has defined a valid assignment or conversion
path for this that I don't normally use you have to do this
to your constant
strings:
sString = MAKE_STRING(Find the case!);
at least that's why MAKE_STRING exists in the first place.
It's not surprising that ConvertANSIToUnicode() would crash
if these assignments were producing an invalid pointer.
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Benjamin Davison Sent: Thursday, March 30, 2006 10:50 AM
To: hlcoders@list.valvesoftware.com
Subject: [hlcoders] Works in debug mode, does not it release mode.
--
[ Picked text/plain from multipart/alternative ] Very weird indeed,
I'm working on some VGUI code and for some reason it works in debug
mode with the IDE attatched and fails to work in release mode, and
for the life of me I am stumped for a soloution. Here is some code
to see if you guys have run into this problem.
void CBBHudTaskList::Paint( void )
{
// getting a pointer to the game rules
CHL2MPRules *pRules = HL2MPRules();
if ( !pRules )
return;
// local player
C_BasePlayer *pPlayer = C_BasePlayer::GetLocalPlayer(); if
( !pPlayer ) return;
string_t sString = ;
wchar_t unicode[256];
int x, y;
int textSizeWide, textSizeTall;
int iShown = 0; // number of lines shown
int fontTall = vgui::surface()-GetFontTall( m_hLargeFont );
int border = 20;
x = border / 2; // ScreenWidth() - border - textSizeWide;
y = iShown * fontTall; // border + iShown * fontTall;
SetSize( 300 + border, 40 );
if (pRules-m_bCaptureObjectActive == true)
{
sString = Find the case!;
}
else if (pRules-m_bCaptureZoneActivated == true) {
sString = Get to this location and do something; }
else
{
sString = No mission selected!;
}
vgui::localize()-ConvertANSIToUnicode( sString, unicode, 256);
// --- Set up default font and get character height for line
spacing vgui::surface()-DrawSetTextFont( m_hLargeFont );
//vgui::surface()-DrawSetTextFont( m_hLargeFont );
vgui::surface()-DrawSetTextPos(x, y);
vgui::surface()-DrawPrintText( unicode, wcslen(unicode) ); //
print text
BaseClass::Paint();
}
Now for some reason vgui::localize()-ConvertANSIToUnicode(
sString, unicode, 256); was crashing the release mode(not the
debug) if I put the buffer to 1024
Have any of you guys run into this problem? Or can you see some
error I have overlooked?
--
- Benjamin Davison
RE: [hlcoders] Works in debug mode, does not it release mode.
::OnThink() would work as well. You can use the ::OnTick() function by
making the ivgui()-AddTickSignal( GetVPanel() ) to subscribe your panel
to tick events. The AddTickSignal() lets you optionally choose the tick
interval (rather than just once per frame) which can be a useful
feature.
Just make the label large enough to contain any text it could
potentially display rather than dynamically resizing it (or use the
::SizeToContents() function if you really need to resize it).
- Alfred
Benjamin Davison wrote:
--
[ Picked text/plain from multipart/alternative ]
Thanks for the tip, but I implemented your sizeof(); suggestion :) It
ain't crashing anymore, but it's not displaying text weirdly enough.
Debug is
still working :E
Well anyway I'll be rewriting it anyway :D I'm thinking of how I am
gonna do
that. Do you think using an ::OnThink() function like most hud
elements use
would be the best way? Possibly in the OnThink(); Check if
pRules-foo has
changed. If it has call a function to change the size and text of the
label?
And ::OnTick() There are only a couple of examples around the SDK and
I was
trying to find the base function and I came across this in
vgui_BasePanel.cpp and found this:
void CBasePanel::OnTick( void )
{
// Nothing
}
How is this function called within the engine? And what is it good
for?
On 3/30/06, Alfred Reynolds [EMAIL PROTECTED] wrote:
Debug mode has a lot more padding between memory allocations
typically. This call: vgui::localize()-ConvertANSIToUnicode(
sString, unicode, 1024)
Would cause a random piece of memory 512 bytes beyond the end of
unicode to be zero to 0 (null terminating the unicode string). In
debug you were probably zeroing unused memory so it had no impact, in
release you were smashing the stack or the like causing a crash.
Moral is, use sizeof(variable) when passing in buffer length
parameters, never hard code them :)
- Alfred
Benjamin Davison wrote:
--
[ Picked text/plain from multipart/alternative ]
Thanks Jay, I'll take those pointers away(rim shot) when I rewrite
it in accordance with Alfred's suggestions.
Still confusing that it worked in debug mode but displayed nothing
in release mode.
On 3/30/06, Jay Stelly [EMAIL PROTECTED] wrote:
Actually looking at the code you're using, you probably should just
skip string_t entirely (since the unicode conversion takes a char
* anyway):
const char *pString = ;
then replace sString with pString...
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jay
Stelly Sent: Thursday, March 30, 2006 11:02 AM
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] Works in debug mode, does not it release
mode.
Unless someone has defined a valid assignment or conversion
path for this that I don't normally use you have to do this
to your constant
strings:
sString = MAKE_STRING(Find the case!);
at least that's why MAKE_STRING exists in the first place.
It's not surprising that ConvertANSIToUnicode() would crash
if these assignments were producing an invalid pointer.
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Benjamin Davison Sent: Thursday, March 30, 2006 10:50 AM
To: hlcoders@list.valvesoftware.com
Subject: [hlcoders] Works in debug mode, does not it release
mode.
--
[ Picked text/plain from multipart/alternative ] Very weird
indeed, I'm working on some VGUI code and for some reason it
works in debug mode with the IDE attatched and fails to work in
release mode, and for the life of me I am stumped for a
soloution. Here is some code to see if you guys have run into
this problem.
void CBBHudTaskList::Paint( void )
{
// getting a pointer to the game rules
CHL2MPRules *pRules = HL2MPRules();
if ( !pRules )
return;
// local player
C_BasePlayer *pPlayer = C_BasePlayer::GetLocalPlayer();
if ( !pPlayer ) return;
string_t sString = ;
wchar_t unicode[256];
int x, y;
int textSizeWide, textSizeTall;
int iShown = 0; // number of lines shown
int fontTall = vgui::surface()-GetFontTall( m_hLargeFont );
int border = 20;
x = border / 2; // ScreenWidth() - border - textSizeWide;
y = iShown * fontTall; // border + iShown * fontTall;
SetSize( 300 + border, 40 );
if (pRules-m_bCaptureObjectActive == true)
{
sString = Find the case!;
}
else if (pRules-m_bCaptureZoneActivated == true) {
sString = Get to this location and do something; }
else {
sString = No mission selected!;
}
vgui::localize()-ConvertANSIToUnicode( sString, unicode,
256);
// --- Set up default font and get character height for line
spacing vgui::surface()-DrawSetTextFont( m_hLargeFont );
//vgui::surface()-DrawSetTextFont( m_hLargeFont );
vgui::surface()-DrawSetTextPos(x, y);
vgui::surface
RE: [hlcoders] Works in debug mode, does not it release mode.
I have added a new page to the wiki with some VGUI2 programming best
practices to follow:
http://developer.valvesoftware.com/wiki/VGUI2_Programming_Best_Practices
- Alfred
Alfred Reynolds wrote:
OnThink() would work as well. You can use the ::OnTick() function by
making the ivgui()-AddTickSignal( GetVPanel() ) to subscribe your
panel
to tick events. The AddTickSignal() lets you optionally choose the
tick
interval (rather than just once per frame) which can be a useful
feature.
Just make the label large enough to contain any text it could
potentially display rather than dynamically resizing it (or use the
SizeToContents() function if you really need to resize it).
- Alfred
Benjamin Davison wrote:
--
[ Picked text/plain from multipart/alternative ]
Thanks for the tip, but I implemented your sizeof(); suggestion :) It
ain't crashing anymore, but it's not displaying text weirdly enough.
Debug is still working :E
Well anyway I'll be rewriting it anyway :D I'm thinking of how I am
gonna do that. Do you think using an ::OnThink() function like most
hud elements use would be the best way? Possibly in the OnThink();
Check if pRules-foo has changed. If it has call a function to
change the size and text of the label?
And ::OnTick() There are only a couple of examples around the SDK
and I was trying to find the base function and I came across this in
vgui_BasePanel.cpp and found this:
void CBasePanel::OnTick( void )
{
// Nothing
}
How is this function called within the engine? And what is it good
for?
On 3/30/06, Alfred Reynolds [EMAIL PROTECTED] wrote:
Debug mode has a lot more padding between memory allocations
typically. This call: vgui::localize()-ConvertANSIToUnicode(
sString, unicode, 1024)
Would cause a random piece of memory 512 bytes beyond the end of
unicode to be zero to 0 (null terminating the unicode string). In
debug you were probably zeroing unused memory so it had no impact,
in release you were smashing the stack or the like causing a crash.
Moral is, use sizeof(variable) when passing in buffer length
parameters, never hard code them :)
- Alfred
Benjamin Davison wrote:
--
[ Picked text/plain from multipart/alternative ]
Thanks Jay, I'll take those pointers away(rim shot) when I rewrite
it in accordance with Alfred's suggestions.
Still confusing that it worked in debug mode but displayed nothing
in release mode.
On 3/30/06, Jay Stelly [EMAIL PROTECTED] wrote:
Actually looking at the code you're using, you probably should
just skip string_t entirely (since the unicode conversion takes a
char * anyway):
const char *pString = ;
then replace sString with pString...
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jay
Stelly Sent: Thursday, March 30, 2006 11:02 AM
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] Works in debug mode, does not it release
mode.
Unless someone has defined a valid assignment or conversion
path for this that I don't normally use you have to do this
to your constant
strings:
sString = MAKE_STRING(Find the case!);
at least that's why MAKE_STRING exists in the first place.
It's not surprising that ConvertANSIToUnicode() would crash
if these assignments were producing an invalid pointer.
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Benjamin Davison Sent: Thursday, March 30, 2006 10:50 AM
To: hlcoders@list.valvesoftware.com
Subject: [hlcoders] Works in debug mode, does not it release
mode.
--
[ Picked text/plain from multipart/alternative ] Very weird
indeed, I'm working on some VGUI code and for some reason it
works in debug mode with the IDE attatched and fails to work in
release mode, and for the life of me I am stumped for a
soloution. Here is some code to see if you guys have run into
this problem.
void CBBHudTaskList::Paint( void )
{
// getting a pointer to the game rules
CHL2MPRules *pRules = HL2MPRules();
if ( !pRules )
return;
// local player
C_BasePlayer *pPlayer = C_BasePlayer::GetLocalPlayer();
if ( !pPlayer ) return;
string_t sString = ;
wchar_t unicode[256];
int x, y;
int textSizeWide, textSizeTall;
int iShown = 0; // number of lines shown
int fontTall = vgui::surface()-GetFontTall( m_hLargeFont
); int border = 20;
x = border / 2; // ScreenWidth() - border - textSizeWide;
y = iShown * fontTall; // border + iShown * fontTall;
SetSize( 300 + border, 40 );
if (pRules-m_bCaptureObjectActive == true)
{
sString = Find the case!;
}
else if (pRules-m_bCaptureZoneActivated == true) {
sString = Get to this location and do something;
} else { sString = No mission selected!;
}
vgui::localize()-ConvertANSIToUnicode( sString, unicode,
256);
// --- Set up default font and get character
Re: [hlcoders] Works in debug mode, does not it release mode.
--
[ Picked text/plain from multipart/alternative ]
Well I should be flattered that I inspired a best use guide :P Am I really
that bad :P
Well I'm taking what's being written and I've nearlly finished a second
version :)
On 3/30/06, Alfred Reynolds [EMAIL PROTECTED] wrote:
I have added a new page to the wiki with some VGUI2 programming best
practices to follow:
http://developer.valvesoftware.com/wiki/VGUI2_Programming_Best_Practices
- Alfred
Alfred Reynolds wrote:
OnThink() would work as well. You can use the ::OnTick() function by
making the ivgui()-AddTickSignal( GetVPanel() ) to subscribe your
panel
to tick events. The AddTickSignal() lets you optionally choose the
tick
interval (rather than just once per frame) which can be a useful
feature.
Just make the label large enough to contain any text it could
potentially display rather than dynamically resizing it (or use the
SizeToContents() function if you really need to resize it).
- Alfred
Benjamin Davison wrote:
--
[ Picked text/plain from multipart/alternative ]
Thanks for the tip, but I implemented your sizeof(); suggestion :) It
ain't crashing anymore, but it's not displaying text weirdly enough.
Debug is still working :E
Well anyway I'll be rewriting it anyway :D I'm thinking of how I am
gonna do that. Do you think using an ::OnThink() function like most
hud elements use would be the best way? Possibly in the OnThink();
Check if pRules-foo has changed. If it has call a function to
change the size and text of the label?
And ::OnTick() There are only a couple of examples around the SDK
and I was trying to find the base function and I came across this in
vgui_BasePanel.cpp and found this:
void CBasePanel::OnTick( void )
{
// Nothing
}
How is this function called within the engine? And what is it good
for?
On 3/30/06, Alfred Reynolds [EMAIL PROTECTED] wrote:
Debug mode has a lot more padding between memory allocations
typically. This call: vgui::localize()-ConvertANSIToUnicode(
sString, unicode, 1024)
Would cause a random piece of memory 512 bytes beyond the end of
unicode to be zero to 0 (null terminating the unicode string). In
debug you were probably zeroing unused memory so it had no impact,
in release you were smashing the stack or the like causing a crash.
Moral is, use sizeof(variable) when passing in buffer length
parameters, never hard code them :)
- Alfred
Benjamin Davison wrote:
--
[ Picked text/plain from multipart/alternative ]
Thanks Jay, I'll take those pointers away(rim shot) when I rewrite
it in accordance with Alfred's suggestions.
Still confusing that it worked in debug mode but displayed nothing
in release mode.
On 3/30/06, Jay Stelly [EMAIL PROTECTED] wrote:
Actually looking at the code you're using, you probably should
just skip string_t entirely (since the unicode conversion takes a
char * anyway):
const char *pString = ;
then replace sString with pString...
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jay
Stelly Sent: Thursday, March 30, 2006 11:02 AM
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] Works in debug mode, does not it release
mode.
Unless someone has defined a valid assignment or conversion
path for this that I don't normally use you have to do this
to your constant
strings:
sString = MAKE_STRING(Find the case!);
at least that's why MAKE_STRING exists in the first place.
It's not surprising that ConvertANSIToUnicode() would crash
if these assignments were producing an invalid pointer.
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Benjamin Davison Sent: Thursday, March 30, 2006 10:50 AM
To: hlcoders@list.valvesoftware.com
Subject: [hlcoders] Works in debug mode, does not it release
mode.
--
[ Picked text/plain from multipart/alternative ] Very weird
indeed, I'm working on some VGUI code and for some reason it
works in debug mode with the IDE attatched and fails to work in
release mode, and for the life of me I am stumped for a
soloution. Here is some code to see if you guys have run into
this problem.
void CBBHudTaskList::Paint( void )
{
// getting a pointer to the game rules
CHL2MPRules *pRules = HL2MPRules();
if ( !pRules )
return;
// local player
C_BasePlayer *pPlayer = C_BasePlayer::GetLocalPlayer();
if ( !pPlayer ) return;
string_t sString = ;
wchar_t unicode[256];
int x, y;
int textSizeWide, textSizeTall;
int iShown = 0; // number of lines shown
int fontTall = vgui::surface()-GetFontTall( m_hLargeFont
); int border = 20;
x = border / 2; // ScreenWidth() - border - textSizeWide;
y = iShown * fontTall; // border + iShown * fontTall;
SetSize
Re: [hlcoders] Works in debug mode, does not it release mode.
Alfred Reynolds wrote: I have added a new page to the wiki with some VGUI2 programming best practices to follow: http://developer.valvesoftware.com/wiki/VGUI2_Programming_Best_Practices - Alfred Alfred Reynolds wrote: Does this burst of free time creativity mean that voice_speex and the updated SDK are going to be released soon? Or, are you sciving and doing the easy jobs? :p ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Works in debug mode, does not it release mode.
Its definitely sciving. - Alfred Matt Judge wrote: Alfred Reynolds wrote: I have added a new page to the wiki with some VGUI2 programming best practices to follow: http://developer.valvesoftware.com/wiki/VGUI2_Programming_Best_Practices - Alfred Alfred Reynolds wrote: Does this burst of free time creativity mean that voice_speex and the updated SDK are going to be released soon? Or, are you sciving and doing the easy jobs? :p ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Works in debug mode, does not it release mode.
-- [ Picked text/plain from multipart/alternative ] Hey, I'm not an easy job :P On 3/31/06, Alfred Reynolds [EMAIL PROTECTED] wrote: Its definitely sciving. - Alfred Matt Judge wrote: Alfred Reynolds wrote: I have added a new page to the wiki with some VGUI2 programming best practices to follow: http://developer.valvesoftware.com/wiki/VGUI2_Programming_Best_Practices - Alfred Alfred Reynolds wrote: Does this burst of free time creativity mean that voice_speex and the updated SDK are going to be released soon? Or, are you sciving and doing the easy jobs? :p ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- - Benjamin Davison -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
