Please login or register.

Login with username, password and session length
Advanced search  

News:

This forum provides RSS feed. To query recent posts use this url. More...


Author Topic: Game Vs. Monitor Aspect Ratios  (Read 10457 times)

0 Members and 1 Guest are viewing this topic.

Kaz

  • Arberth Studios
  • Regular poster
  • ***
  • Karma: 1
  • Offline Offline
  • Posts: 228
  • The story is the game
    • View Profile
    • Info on 'Rhiannon' & 'Coven'
Game Vs. Monitor Aspect Ratios
« on: September 13, 2009, 07:07:05 PM »

Hi all

The latest version of WME supports widescreen, which is brilliant - thanks Mnem. The documentation says "If the engine detects that the game aspect ratio is different from monitor aspect ratio..." I'm interested in this. During this detection, is the monitor aspect ratio stored anywhere that can be accessed by a script and then compared with the game aspect ratio?

The reason for knowing is that if 1) ProjectMan is set to a widescreen ratio and 2) the game is running on a 4:3 or 5:4 monitor, I wondered if the black bands top and bottom could be used by the game, eg to accommodate the inventory window. Or is that achievable by some deft use of Viewport?

Any thoughts or knowledge?

Cheers
Logged
\"Fans of popular horror adventures like Scratches and Barrow Hill should start bracing themselves for another haunting experience, as independent developer Arberth Studios has announced production on its debut title Rhiannon - Curse of the Four Branches.\" - AdventureGamers.com

mRax

  • Occasional poster
  • **
  • Karma: 0
  • Offline Offline
  • Posts: 55
    • View Profile
Re: Game Vs. Monitor Aspect Ratios
« Reply #1 on: September 14, 2009, 09:42:34 AM »

Good timing! :) I also think about that black border. But my possible solution is laid in the sources (export new Game properties RealWidth and RealHeight in CBGame::ScGetProperty with standard ScreenWidth and ScreenHeight, modify CBRenderer::SetScreenViewport method and provide it in CBGame::ScCallMethod as "SetScreenViewport"). Since the border isn't my option only, it'll be interesting to listen to what Mnemonic said.
Logged

Mnemonic

  • WME developer
  • Administrator
  • Addicted to WME forum
  • *
  • Karma: 41
  • Offline Offline
  • Gender: Male
  • Posts: 5683
    • View Profile
    • Dead:Code Site
Re: Game Vs. Monitor Aspect Ratios
« Reply #2 on: September 14, 2009, 10:12:03 AM »

Now WME clips everything that's outside the main viewport. If you wanted to paint to the black borders, you'd need to disable the clipping, but that would result in unwanted artifacts (things supposed to be hidden would become visible). That would need to be solved (some special drawing mode, e.g. non-in-game windows wouldn't respect the screen viewport). Also, the borders can vary in size, depending on monitor capabilities/ratio so anything you'd want to display in that area would need to deal with variable dimensions. Not worth the hassle, IMO.
Logged
Yes, I do have a twitter account
Please don't send me technical questions in private messages, use the forum. ::wave

mRax

  • Occasional poster
  • **
  • Karma: 0
  • Offline Offline
  • Posts: 55
    • View Profile
Re: Game Vs. Monitor Aspect Ratios
« Reply #3 on: October 08, 2009, 12:09:04 PM »

I thought, that only window-type objects were needed in black bars. And made some progress.

1) Changed viewport in CUIWindow::Display
Code: [Select]
  .
  .
  .
  if(!m_Visible) return S_OK;

#ifdef WME_D3D9
  CBRenderD3D* rend = (CBRenderD3D*)Game->m_Renderer;
  D3DVIEWPORT old_vp;
  if(!m_ClipByScreen)
  {
    rend->m_Device->GetViewport(&old_vp);
    D3DVIEWPORT vp = old_vp;
    vp.X = 0;
    vp.Y = 0;
    vp.Width = rend->m_RealWidth;
    vp.Height = rend->m_RealHeight;
    rend->m_Device->SetViewport(&vp);
  }
#endif
  .
  .
  .
#ifdef WME_D3D9
  if(!m_ClipByScreen)
  {
    rend->m_Device->SetViewport(&old_vp);
  }
#endif
  return S_OK;
}
m_ClipByScreen is new window bool property describing of whether the current window should be clipped by screen rectangle (I mean, ScreenRect = MonitorRect - BlackBars). Default value is TRUE. Also m_ClipByScreen was provided in scripts through ScGetProperty/ScSetProperty.

2) That wasn't enough for inventory box (as well as for response box, I thought). Changed CAdInventoryBox::Display as like as CUIWindow::Display. The conditions were only modified
Code: [Select]
if(m_Window)if(!m_Window->m_ClipByScreen)
3) Changed viewport for mouse cursor
Code: [Select]
HRESULT CBGame::DrawCursor(CBSprite* Cursor)
{
  if(!Cursor) return E_FAIL;
  if(Cursor!=m_LastCursor)
  {
    Cursor->Reset();
    m_LastCursor = Cursor;
  }
#ifdef WME_D3D9
  CBRenderD3D* rend = (CBRenderD3D*)Game->m_Renderer;
  D3DVIEWPORT old_vp;
  rend->m_Device->GetViewport(&old_vp);
  D3DVIEWPORT vp = old_vp;
  vp.X = 0;
  vp.Y = 0;
  vp.Width = rend->m_RealWidth;
  vp.Height = rend->m_RealHeight;
  rend->m_Device->SetViewport(&vp);
#endif
  HRESULT res = Cursor->Draw(m_MousePos.x, m_MousePos.y);
#ifdef WME_D3D9
  rend->m_Device->SetViewport(&old_vp);
#endif
  return res;
}

By the way, do you know, that mouse cursor can be moved under black bars? I think, it's someway strange to have ability to move cursor, while can't see it. Before changing CBGame::DrawCursor I tried
Code: [Select]
Game.LockMouseRect(0, 0, Game.ScreenWidth, Game.ScreenHeight)but it didn't have any effect. I'm not sure, but will not be better replace last part in CBGame::GetMousePos with
Code: [Select]
if(m_MouseLockRect.left != 0 || m_MouseLockRect.right != 0 || m_MouseLockRect.top != 0 || m_MouseLockRect.bottom != 0)
{
  .
  .
  .
}
"||"-version doesn't conflict with Game.LockMouseRect() behavior, but dislike "&&"- one can take parameter 0.

4) In Game object there were provided new properties RealWidth and RealHeight. Scripts were changed a little
Code: [Select]
var Inventory = Game.GetInventoryWindow();
if((Game.RealHeight-Game.ScreenHeight)/2>=Inventory.Height)
{
  Inventory.ClipByScreen = FALSE;
  Inventory.Y = -Inventory.Height;
  Game.InventoryVisible = TRUE;
  Game.LockMouseRect(0, Inventory.Y, Game.ScreenWidth, Game.ScreenHeight);
}else{
  Game.AttachScript("scripts\game_loop.script");
  Game.LockMouseRect(0, 0, Game.ScreenWidth, Game.ScreenHeight);
}
Of course, that's not beginner level, but not bad ability, I suppose.

5) Current problem is in transparency of objects in black bars region: Game.ActiveObject doesn't detect objects out of ScreenRect. For example, if Inventory.Y is equal to -Inventory.Height/2, the window has transparent upper half of itself but active lower half. I have stuck in CBRenderer::GetObjectAt method. And here I pass. I can't understand clearly how m_RectList works with: why/where/when object-candidate for ActiveObject become transparent?

6*) May back buffer size be not (m_RealWidth x m_RealHeight)? (for example, (m_Width+m_DrawOffsetX x m_Height+m_DrawOffsetY)) Would it ever possible?
Logged

Mnemonic

  • WME developer
  • Administrator
  • Addicted to WME forum
  • *
  • Karma: 41
  • Offline Offline
  • Gender: Male
  • Posts: 5683
    • View Profile
    • Dead:Code Site
Re: Game Vs. Monitor Aspect Ratios
« Reply #4 on: October 08, 2009, 12:47:09 PM »

Ok, firstly, you don't want to use the #ifdef WME_D3D9 here. This contant only determines if the engine is being compiled for Direct3D 8 or 9. This functionality should be available in both versions.
Secondly, I'd name the properties RealScreenWidth / RealScreenHeight, to be consistent with the original ScreenWidth / ScreenHeight.

To your questions. Yes, the cursor can be moved within the black bars and yes, it's not ideal. IMO the cursor should change to system pointer when it's above the black bars (like it changes when you move it over the title bar in windowed mode).

Backbuffer size should always be m_RealWidth x m_RealHeight as far as I can tell.

The active rectangles is an array, which is built in every frame. As the scene is being painted, every interactive object adds itself into the list. It adds its bounding rectagle and a reference to itself.
When the game queries an active object, it browses through the list of active rectangles (from top to bottom), and when it hits a bounding box, it examines the object further (it checks texture transparency for sprites, polygon hit for 3D objects etc.) to see if the cursor is really above the object.

So I'd suppose the bounding box gets clipped for windows, I'm not really sure.
Logged
Yes, I do have a twitter account
Please don't send me technical questions in private messages, use the forum. ::wave
 

Page created in 0.019 seconds with 21 queries.