Jump to content

  • Log In with Google      Sign In   
  • Create Account

Erik Rufelt

Member Since 17 Apr 2002
Online Last Active Today, 12:01 PM

#5292631 Antialiasing in 3D with Core OpenGL (Windows)

Posted by Erik Rufelt on 20 May 2016 - 08:05 AM

You should be able to smooth edges with alpha-blended lines or similar after all your regular geometry is drawn (using depth-testing but not depth-writes). I would imagine GL_LINE_SMOOTH could work fine there with depth-testing..

Your question is tagged with OpenGL ES but the title says Windows, do you do OpenGL ES on desktop or regular OpenGL?




#5291579 Screen tearing when using OpenGL on Windows

Posted by Erik Rufelt on 14 May 2016 - 10:55 AM

VSync is often unreliable in windowed mode. If you create a window filling the entire screen with its client area and nothing obscuring it (WS_POPUP / WS_EX_TOPMOST) the Nvidia driver should switch to exclusive fullscreen mode.

For perfect VSync you actually want pre-rendered frames, so it should not be set to 1, that would break VSync if even a single frame happened to lag behind because of some background process or similar that is out of application control




#5290828 Manually loading OpenGL functions on Windows

Posted by Erik Rufelt on 09 May 2016 - 10:59 AM

I also use the fallback method to get pointers for the old functions.. I think that's what common extension libraries do as well, though I haven't actually checked..

If including a recent glcorearb.h header without the prototypes-define it won't define the old prototypes either, but will define the function pointer types for the 1.0 functions etc. as well. And with the prototypes-define it will add prototypes for all functions including newer ones.

On Linux all function pointers can be obtained with glXGetProcAddress so there no fallback is required.

If still linking to opengl32.lib one could of course do another fallback, something like mynamespace::glClear = ::glClear instead of GetProcAddress...




#5290766 bezier curve character

Posted by Erik Rufelt on 09 May 2016 - 02:46 AM

No.




#5290106 how good is rand() ?

Posted by Erik Rufelt on 04 May 2016 - 12:37 PM

 

"The rand function returns a pseudorandom integer in the range 0 to RAND_MAX (32767). "  so it returns 0 thru 32766, but not 32767, right?

 

Correct.  In modern math notation this type of function works with [0,x)  meaning it includes zero but stops just short of x.  This is also common in many other systems.  Graphics, for example, typically draw segments in the [A,B) form, starting exactly at A and ending the instant before B.

 

 

I tried this in VS2015 and it does return RAND_MAX.. is it not supposed to?

#include <iostream>
int main() {
	for(int i = 0; i < 200000; ++i) {
		int r = rand();
		if(r == RAND_MAX)
			std::cout << "MAX\n";
		else if(r == (RAND_MAX - 1))
			std::cout << "ALMOST\n";
		else if(r == 0)
			std::cout << "ZERO\n";
	}
}



#5290079 how good is rand() ?

Posted by Erik Rufelt on 04 May 2016 - 10:14 AM

Not too good..

If you Google for its implementation you get a few results. Something like next = (current * A) + B with overflow wrapping around.

 

EDIT: And it does return the value RAND_MAX at times, not just RAND_MAX-1.




#5289282 Lol, IDirectDrawSurface7::Blt changes Aero scheme to Windows 7 Basic

Posted by Erik Rufelt on 29 April 2016 - 12:26 PM

Not sure if it can be fixed.. OpenGL apps does that sometimes too. I think it's fixed in OpenGL by selecting a pixel-format with the PFD_SUPPORT_COMPOSITION flag. Maybe you can set the pixel-format on the window before creating the DD surface or somehow specify that flag in your caps when you create the primary surface..




#5287807 Window Creation in Win 7

Posted by Erik Rufelt on 20 April 2016 - 12:21 PM

glClearBufferfv and glClear both clear the buffer.. so glClear will overwrite glClearBufferfv with whatever color is set by glClearColor (defaults to black if glClearColor has never been called).




#5286828 Window Creation in Win 7

Posted by Erik Rufelt on 14 April 2016 - 02:03 AM

//The docs say the second arg to glClearBufferfv should be GL_DRAW_BUFFERi to clear and if it is GL_NONE then the operation does nothing. GL_NONE = 0, which you use, so try using GL_DRAW_BUFFER0 instead of 0 as the second arg.(incorrect)

Also remember to remove the glClear after your if-statement so that you don't re-clear it to the default clear color again before swap.

You seem to run into many of these weird problems caused by small mistakes in the details. Make it a habit to read the docs for the functions you use if they don't work right away, as well as use the debugger to single-step through the code, which is extremely helpful to solve these problems a hundred times faster than posting on GD.net about them.

I like this site for GL docs: http://docs.gl/

 

Do you use Visual Studio? If you don't use the debugger then start doing so, by default just press F9 on a particular line of code and then F5 to run with the debugger and the debugger will break on that line, where you can single-step with F10 and inspect variables with mouse-over. Faster than ExitProcess and std::cout.




#5286608 Window Creation in Win 7

Posted by Erik Rufelt on 13 April 2016 - 02:05 AM

You don't seem to be linking to or initializing GLEW.

Read this page: https://www.opengl.org/wiki/OpenGL_Loading_Library

 

As well as this one: http://glew.sourceforge.net/basic.html




#5285834 X11 + OpenGL causes segfault

Posted by Erik Rufelt on 08 April 2016 - 10:41 AM

glXMakeCurrent also has a return-code, like the single one you don't check.. :)

Probably the context isn't properly made current there.

If it is, try getting the function pointers for the normal GL functions instead of relying on them by linking.




#5283671 heightmap sample in vertex shader

Posted by Erik Rufelt on 27 March 2016 - 12:06 AM

Sounds like your texture isn't correctly loaded or bound, and your SampleLevel always returns 0.

0 is the default that will be returned if no texture is available to read from.

If you run your game from Visual Studio with the debugger and create your device with D3D11_CREATE_DEVICE_DEBUG you should get debug output in the Output window in Visual Studio if that is the case.




#5277254 Correct way of doing Mouse Picking

Posted by Erik Rufelt on 21 February 2016 - 03:25 AM

One thing that looks like a mistake is this:

"-(2 * mouse.Y) / viewport.Height -1"

 

Should be +1 at the end, or your values will be between -3 and -1 instead of -1 and 1.




#5277233 Interstellar trade at a relativistic timescale?

Posted by Erik Rufelt on 20 February 2016 - 11:45 PM

Very interesting scenario, though I find it difficult to think of a realistic setup at all without more information. How big is the colony?

 

If it's something of an off-shore platform out there, that would likely make the colony rather small, and I would expect the crew on the spaceships to also rotate the crew on the colony.

So basically the decision to go work on the colony is a 10-20 year contract in "your time", but a ~ 30-40 year contract in "real time".

 

If it's a major settlement, I would expect their primary objective is to establish self-sufficiency, and after the first century or so these trade missions will probably mostly be about luxury items or scientific exchange that would impact production on the colony during the decade after the ship arrives. (Depending on whether several ships arrive during the 24 years, or if there is just one or a few ships that go back and fourth).

 

There is also the question of political stability in the solar system. Are there still economic problems?

I suspect some competition for a chance to jump 24 years into the future whenever there's some form of unrest. If scientific achievements are still happening at the rate they are now, this would likely be extremely appealing even in good conditions for a lot of people, especially if they could go with their families.




#5277182 Vulkan is Next-Gen OpenGL

Posted by Erik Rufelt on 20 February 2016 - 12:42 PM

I think those semaphores are just copied from the multi-threaded multi-queue example, and aren't actually required when acquiring the image and presenting on the same thread and/or the same queue, even without any Wait, if I understand things correctly.

 

AcquireImage is supposed to block until an image is available or return an error or timeout, and present is supposed to be added to the end of the queue. Queues must be externally synchronized, so the only reason to use a semaphore on AcquireImage is if another thread is about to start submitting command buffers for drawing to the image before AcquireImage returns. (This also makes AcquireImage returning the index of the next buffer redundant, as it must already be known if another thread is already building the command buffer for the frame using that image before it is returned as available).

 

The semaphore on Present makes sense if the present is submitted to a different queue than is drawing the graphics, even in single-threaded apps, as the last actual drawing command must finish executing on its queue before the image is presented on the other queue, but if submitting the Present on the same queue it is redundant, threaded or not (though threading on one queue might not make much sense.. unless submitting a present to the queue is actually expected to be a slow operation and the main thread wants to start processing the next frame or something without using the queue).






PARTNERS