[hlcoders] Full-screen HudElement

2006-07-12 Thread John Sheu
So what's the best way to make a HudElement full-screen?  I've tried out a few
approaches, but I'm not sure which one could be considered correct in the
spirit of VGUI implementation.  Note: just setting it 640x480 in
HudLayout.res won't work for us widescreeners.



Hooking into VidInit(), with SetBounds( 0, 0, ScreenWidth(), ScreenHeight() ).
(Or should that be Init() ?)  Hopefully this is called every time the video
mode changes, so things resize appropriately should the player decide to
change video sizes.

Setting xpos to something ridiculous like 800 in HudLayout.res.  This then
introduces issues with placement of sub-panels.

The solution I'm using now: overriding ApplySettings() and setting the bounds
to maximum after the baseclass ApplySettings() is called.  In my experience,
this is called after video mode changes as well, so it holds well.



So which one?

-John Sheu

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders



Re: [hlcoders] Full-screen HudElement

2006-07-12 Thread Garry Newman

I use OnScreenSizeChanged

ISurface.h

// video mode changing
virtual void OnScreenSizeChanged( int nOldWidth, int nOldHeight ) = 0;

Does the job I think.

On 7/12/06, John Sheu [EMAIL PROTECTED] wrote:

So what's the best way to make a HudElement full-screen?  I've tried out a few
approaches, but I'm not sure which one could be considered correct in the
spirit of VGUI implementation.  Note: just setting it 640x480 in
HudLayout.res won't work for us widescreeners.



Hooking into VidInit(), with SetBounds( 0, 0, ScreenWidth(), ScreenHeight() ).
(Or should that be Init() ?)  Hopefully this is called every time the video
mode changes, so things resize appropriately should the player decide to
change video sizes.

Setting xpos to something ridiculous like 800 in HudLayout.res.  This then
introduces issues with placement of sub-panels.

The solution I'm using now: overriding ApplySettings() and setting the bounds
to maximum after the baseclass ApplySettings() is called.  In my experience,
this is called after video mode changes as well, so it holds well.



So which one?

-John Sheu

___
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] Physical Mayhem bug again! Death by Touch considered harmful??

2006-07-12 Thread bloodykenny
Looks like another symptom of this new Physical Mayhem bug is the Object 
attached to Physcannon has no physics object error I mentioned earlier.  I 
added an assert for it, and it hit it on an ordinary barrel that somehow was 
lacking a physics object.

+   m_ModelName {pszValue=0x039452d8 
models/props_c17/oildrum001_explosive.mdl }  string_t
+   m_pPhysicsObject0x  IPhysicsObject *



   server.dll!CGrabController::ComputeError()  Line 413 + 0x91 C++
server.dll!CGrabController::UpdateObject(CBasePlayer * 
pPlayer=0x264b8f38, float flError=12.00)  Line 2334 + 0xeC++
server.dll!CWeaponPhysCannon::UpdateObject()  Line 2460 + 0x16  C++
server.dll!CWeaponPhysCannon::ItemPreFrame()  Line 2632 C++
server.dll!CBasePlayer::ItemPreFrame()  Line 90 + 0x24  C++
server.dll!CHL2_Player::PreThink()  Line 351C++
server.dll!CHL2MP_Player::PreThink()  Line 627  C++
server.dll!CPlayerMove::RunPreThink(CBasePlayer * player=0x264b8f38)  
Line 255 + 0x10   C++
server.dll!CPlayerMove::RunCommand(CBasePlayer * player=0x264b8f38, 
CUserCmd * ucmd=0x1e7f0f30, IMoveHelper * moveHelper=0x2341c3fc)  Line 378  C++
server.dll!CBasePlayer::PlayerRunCommand(CUserCmd * ucmd=0x1e7f0f30, 
IMoveHelper * moveHelper=0x2341c3fc)  Line 3140C++
server.dll!CHL2_Player::PlayerRunCommand(CUserCmd * ucmd=0x1e7f0f30, 
IMoveHelper * moveHelper=0x2341c3fc)  Line 840 C++
server.dll!CBasePlayer::PhysicsSimulate()  Line 3032 + 0x23 C++
server.dll!Physics_SimulateEntity(CBaseEntity * pEntity=0x264b8f38)  
Line 2064 + 0x10   C++
server.dll!Physics_RunThinkFunctions(bool simulating=true)  Line 2120 + 
0xf C++
server.dll!CServerGameDLL::GameFrame(bool simulating=true)  Line 907 + 
0x9  C++
engine.dll!0dab0d91()
engine.dll!0daab617()
engine.dll!0daad1d5()
engine.dll!0da0e277()
engine.dll!0da0e976()
engine.dll!0da1b8c5()
engine.dll!0da1b9f3()
user32.dll!77d496b8()
engine.dll!0da1ba9f()
engine.dll!0dabf4f3()
engine.dll!0dabd28d()
dedicated.dll!100056f4()
engine.dll!0da2e0ab()
engine.dll!0dabeea9()
engine.dll!0dabe3d0()
engine.dll!0dabe3e3()
engine.dll!0db218d1()
engine.dll!0dabed25()
engine.dll!0dc304bb()
dedicated.dll!10005ba4()
materialsystem.dll!00d0d4e2()
materialsystem.dll!00cc552e()
materialsystem.dll!00cd1cfe()
materialsystem.dll!00cd1e88()
materialsystem.dll!00cd1cfe()
materialsystem.dll!00d115de()
materialsystem.dll!00cdaac2()
tier0.dll!0089357f()
ntdll.dll!7c90d4ea()
kernel32.dll!7c809ad2()
kernel32.dll!7c809ae9()
tier0.dll!00897c55()
tier0.dll!008910b8()
tier0.dll!00897c55()
datacache.dll!00e800ab()
datacache.dll!00e714c9()
datacache.dll!00e73c5e()
datacache.dll!00e7490e()
engine.dll!0db85d38()
engine.dll!0db8596c()
engine.dll!0d9b030d()
dedicated.dll!1001fd6b()
dedicated.dll!10020c41()
dedicated.dll!10020c41()
dedicated.dll!10005d81()
ntdll.dll!7c9146c3()
ntdll.dll!7c914481()
ntdll.dll!7c919bd3()
ntdll.dll!7c910895()
tier0.dll!008a24e9()
tier0.dll!00891db0()
dedicated.dll!1000613d()
ntdll.dll!7c91056d()
kernel32.dll!7c801be6()
kernel32.dll!7c801bf6()
ntdll.dll!7c919aeb()
ntdll.dll!7c919ba0()
kernel32.dll!7c80ac66()
srcds.exe!004011bc()


At 2006/07/03 06:28 PM, [EMAIL PROTECTED] wrote:
Ok, the too many convex pieces message only occurs on that one spot in 
dm_steamlab.  It appears to be a feature of the map and has no affect on the 
critical vphysics issues.

I tried host_framerate set to 0, 1, 10 and 100.  I didn't notice any 
difference in physics interactions, or any difference in anything else at all, 
at any setting.  The vphysics continued to be broken at all host_framerate 
settings with a debug mod dll and high cpu usage.  The vphysics continued to 
work fine at host_framerate settings with a release mode dll, regardless of 
cpu usage.

I speculated that maybe the ShouldCollide_Default assert code you recommended 
might be what was causing debug builds to break, so I tried taking that out as 
well, but it still broke.

Has this not reprod for anyone else?  Does Valve run large stresstests on 
debug HL2DM?

At 2006/07/02 12:19 PM, Jay Stelly wrote:
The function that controls this is in src/dlls/physics_collisionevent.h:

int AdditionalCollisionChecksThisTick( int
currentChecksDone )
{
//CallbackContext check(this);
if ( currentChecksDone  1200 )
{
DevMsg(1,VPhysics Collision detection getting