Jump to content

  • Log In with Google      Sign In   
  • Create Account

Armion

Member Since 19 Aug 2010
Offline Last Active Feb 02 2014 03:49 AM

Posts I've Made

In Topic: Sprite is resized

06 November 2012 - 12:27 PM

Something else comes to my mind.

Let's say your resolution is WxH. So you are creating a window with dimensions WxH and you are creating a backbuffer with size WxH. Then you are drawing the backbuffer to the client rect of the window. The catch is that the client area of the window is usually smaller than the window itself - the dimensions of the window also include the title bar and all the borders. This way you are trying to draw an image onto an area that can't contain it without distorting it first.

If that's the case you want to resize the window and make it larger so that it can contain client area that has the exact same size of the backbuffer. To do it you call the AdjustWindowRect system function.

Hope that helps Posted Image

In Topic: Elica and 3D graphics - is it worth it ?

09 September 2012 - 09:10 AM

Hi, Getov Posted Image

Judging from your name and the course you are asking about, I can tell you are most likely studying at FMI, Sofia University. If that's the case, I can assure you it's a complete waste of time if you are trying to learn something about computer graphics. I enrolled the course several years ago, because there was no one who could tell me that the name was quite inappropriate, given the things that one can learn from it - defining simple shapes and objects with certain properties(like texture and size) and applying simple operations to them. Keep in mind all of these things are not done in a general way that can help you in other situations. It's strongly Elica specific and Elica is a very high-level language/framework, so it certainly will not help you grasp the concepts of 3D programming. Ah, one more thing - Elica is slow, so it's very, very poor choice when it comes to game development.

With that made clear, it still was an interesting experience, especially if you take into account the lack of gamedev-related courses at the Faculty Posted Image

In Topic: [DX9] Vsync Lag

21 August 2010 - 10:10 AM

I'm sorry i've misunderstood you :) Here is the code you asked for:

	
POINT coords;
::GetCursorPos(&coords);
::ScreenToClient(handle, &coords);

RECT client;
GetClientRect(handle, &client);

// This works correctly for windowed
D3DXVECTOR3 pos(coords.x, coords.y, 0);

sprite->Begin(D3DXSPRITE_ALPHABLEND);
HRESULT test = sprite->Draw(texture, 0, 0, &pos, 0xFFFFFFFF);
sprite->End();




[Edited by - Armion on August 21, 2010 5:10:59 PM]

In Topic: [DX9] Vsync Lag

21 August 2010 - 08:49 AM

Hi Matias :)

As you can see in the source code above i fill my D3DPRESENT_PARAMETERS structure with the following code:


D3DPRESENT_PARAMETERS d3dpp;
d3dpp.BackBufferWidth = width;
d3dpp.BackBufferHeight = height;
d3dpp.BackBufferFormat = D3DFMT_A8R8G8B8;
d3dpp.BackBufferCount = 1;
d3dpp.MultiSampleType = D3DMULTISAMPLE_NONE;
d3dpp.MultiSampleQuality = 0;
d3dpp.SwapEffect = D3DSWAPEFFECT_DISCARD;
d3dpp.hDeviceWindow = hwnd;
d3dpp.Windowed = windowed;
d3dpp.EnableAutoDepthStencil = true;
d3dpp.AutoDepthStencilFormat = D3DFMT_D24S8;
d3dpp.Flags = 0;
d3dpp.FullScreen_RefreshRateInHz = D3DPRESENT_RATE_DEFAULT;
d3dpp.PresentationInterval = D3DPRESENT_INTERVAL_ONE;



What part of it could be the problem? Checking the created device with PIX the only strange thing i see is that Windowed is set to true if we have specified fullscreen. Still i guess this interesting thing is happening because of the internal workings of PIX - even if i force Windowed to false Pix still tells me that Windowed is false. So i can't really see what could be messing with my application for i-don't-know-how-much-time. I tried playing with the settings and the once that gave me problems didn't return S_OK when creating the device so even if i wanted i couldn't use them.

For your next assumption - yes, clamping the FPS through CPU remedies the problem in fullscreen. Windowed mode still lags but it's not as bad as before.

As for how i'm rendering the cursor:
The windows cursor is on. Additionally that's what i'm doing in my render procedure:

// This source is almost the same as the in the book of Frank Luna,
// called Introduction to 3D Game Programming With DirectX 9.0
// For complete source code see my first post - 3rd code file

Device->Clear(some parameters);
Device->BeginScene();

//Get the current cursor position according to screen coordinates
//Render a texture representing a second cursor in that exact place

Device->EndScene();
Device->Present(0, 0, 0, 0);



No matter how i think about it in the worst case scenario the difference in the position should be at most 1/60 of the second. I don't see how the difference in time between moment 2 and 3 can be more that.
moment 1: Present() at retrace period
moment 2: Render cursor
moment 3: Present() at retrace period

And still the drawn cursor is lagging behind...

In Topic: [DX9] Vsync Lag

20 August 2010 - 10:22 PM

Hi again and thanks for the replies :)

@Scoob Droolins: One frame of lag is acceptable. The problem in the case is that there is much more delay(in my opinion). I tried the query method and the result was the same. Playing with "render frames ahead"... no improvement i can feel.

@Matias Goldberg: Hmm... I will test if there is any error in my arguments when creating the fullscreen. Could this be related to the Ex version of interfaces and calls(IDirect3DDevice9Ex, PresentEx())? I don't think low fps is the problem - getting more than 4000 with D3DPRESENT_INTERVAL_IMMEDIATE - my app is just rendering its own cursor below the real one. I also tried one solution that was rumored to fix this lag in commercial games(Unreal Tournament, Battlefield 2 Bad Company) - limiting your fps to one or two below the refresh rate - let's say 58fps for 60Hz refresh rate... And it works like a charm. Can someone explain to me this STRANGE behavior? I also read there was some kind of bug in Win7 that was related to the difference between the actual refresh rate and the one that the OS reports to apps. I think i need to find a WinXP PC so i can test if things work the same way... Also i mistake on my part - i wanted to write "NOT USING MULTITHREADING", instead i wrote "now using multithreading" and this changes the thing a lot. I'm sorry for this silly mistake on my part.

@Hazard_X: Dragging something in the interface with this method produces very unsatisfactory results. It's like the object i'm dragging is tied to the cursor with some kind of rubber leash - always lagging behind a lot. I know that this is true even when dragging something in windows, selecting text in Firefox or text editor or selecting multiple icons on the desktop with selection rectangle, but it certainly is MUCH LESS laggy than the simple app i wrote to demonstrate the problem...

[Edited by - Armion on August 21, 2010 4:22:32 AM]

PARTNERS