I was just wondering if it is possible to render the OpenTK gamewindow in a Linux Console (Raspberry Pi Raspbian) without any X11 Desktop?
If it possible, how do you do it?
Yes, it's experimental since 1.1 or 1.2. Adjust OpenTK.dll.config if some dll could not be found, and maybe you'll have to find correct libinput version (libinput-0.2.0 is working on my debian) to match api binding in opentk. I'm not fully sure, but I think that it's only working with modern GL (>3.0).
Ensure you have libdrm, libgbm and correct libinput on your system and latest mesa.
OpenTK will automaticaly detect linux console environment if program is launched from a console.
If you face trouble finding missing dll's, enable full debug messages in Otk.
I have this working but it took a bit of work. First I created a c library to call through to the native libraries for controlling the gl chipset on the PI and exposed these so that I could call them from C#.
Secondly I had to recompile the opentk with the switch to not use dynamic bindings. In the end I stripped out most of the game window logic and just used the bindings and the maths code from opentk.
More details and code here:
http://www.opentk.com/node/4024
Basically this is enough to get you clearing / swapping the screen etc and you can then add the binding code through to the GL ES 2.0 spec which you can generate in the opentk project / solution tools.
Related
I have a Unable to find an entry point named 'glBindFramebuffer' in DLL 'opengl32.dll' when running a MonoGame Windows OpenGL project, So it seems the only way to solve this problem is to wrap a try and catch around it and then it will let you compile and run the program so my question is since I know that the new GraphicsDeviceManager fails will that result in a problem later on when deploying my game?.
I recently had the exact same error when I was trying to run my game in a virtual machine. It's essentially because you don't have the correct version of OpenGL installed. OpenGL normally comes with your graphics card drivers.
There is a discussion about this issue here:
https://github.com/mono/MonoGame/issues/998
In terms of deployment you basically have 3 options:
Use DirectX instead (plain old Microsoft XNA) or you can try MonoGame's DirectX implementation, but I'm not sure if it's complete.
If you are targeting other platforms (Android, iOS, etc) you'll be using OpenGL on the devices, but this should be okay.
Ensure your game has minimum requirements specified somewhere and handle the errors gracefully when it fails telling your users to update their graphics drivers.
That said, testing in different machine configurations is still a good idea.
Currently, i'm developing an app for the Windows 8 Store, Windows 8 Desktop and also Windows 7. The App should run smoothly on a Tablet and also on a "normal" Windows 7/8 Device. So, i got a tablet from my work and installed Windows 8 on it, just to realize, that the creepy Intel Graphics Media Accellerator (600) only supports DirectX 9.0c.
So, i tried for hours now to get my DirectX10/11 Effects/Shaders working on DirectX9, but nothing seems to work.. a Test with NVidia's FxComposer shows me, that DirectX9 Effects run good.
I'm programming with SharpDX / C#, and the technique10's and technique11's both are valid (MyTechnique.IsValid == true). To load the effect, i use theese lines of code:
var EffectByteCode = ShaderBytecode.CompileFromFile("DirectX/Shaders/"+FxFile, "fx_5_0", ShaderFlags.None, EffectFlags.None);
var Effect = new Effect(GraphicsProvider.Device, EffectByteCode, EffectFlags.None);
mEffect = FxEffect;
mTechnique11 = mEffect.GetTechniqueByName("main_11"); //works
mTechnique10 = mEffect.GetTechniqueByName("main_10"); //works
mTechnique9 = mEffect.GetTechniqueByName("main_9"); //doesn't work
I pasted the effect source code here: http://pastebin.com/KPxBN1DD.. excluded "main_11" and "main_10", in my tests, i commented them out, so i just removed those comment blocks.. i think dx9 should understand this very simple code..
So my final questions are:
- Is the parameter "fx_5_0" valid for loading technique, technique10 and technique11?
- Is my shader code correct? Or have i done something terribly wrong?
- Do i have to specify any other/additional information/functions/parameters for loading DX9 technique's?
- Maybe its a bug of SharpDX? I will take look on the code for this now i think..
Edit: Tried to make the question(s) a bit clearer..
The legacy Effect framework is not supported on Windows 8 Metro (because D3DCompiler_xx.dll is not supported), so you should better work with another solution. Also, Effect is deprecated by Microsoft and no longer supported.
The old Direct3D9 technique(compiled with vs_2_0 or ps_2_0) are not stored in FX files compiled with fx_5_0 (just check the output of fxc.exe compiler and you won't see them).
You have to use vs_4_0_level_9_x or ps_4_0_level_9_x in order to compile them for 9.x down level hardware support using technique10/11 syntax. Also, if all your original shaders could work with vs_4_0_level_9_x and you don't have any specific optimized version for 10.0 or 11.1, then you wouldn't have to compile a main_10 or main_11, as level_9_x shaders are working on any hardware from 9.x to 11.x.
You can probably have a look at SharpDX.Toolkit, not yet official, but It is supporting an Effect framework (with some XNA stock effects like BasicEffect or SpriteBatch). A beta of the toolkit will be available later this month.
Try replacing the SV_TARGET semantic with COLOR0. I've never seen SV_TARGET semantic in D3D9 shaders so far.
My C# application uses DirectShow and requires DirectX to run. I would like check that DirectX is enabled at start-up, can anyone advise the correct method to do so?
Thanks
DirectShow is not a part of DirectX. There is only some intersection in video renderer using DirectDraw and Direct3D, and wrappers over audio APIs which are in fact no longer independent but wrappers over other APIs. I would say there is nothing to check for and DirectShow is already an OS core component, but if you have some specific concerns then what are they? Maybe you could attempt to create some DirectX object directly on app startup and see if this attempt is successful.
I think I'm right in saying if the DirectX DLLs aren't installed on the host machine, your application wont even start. Beyond that, you should always be checking that creation of DirectX objects succeeds before attempting to use them.
I am now facing one problem which to get the live image from Camera (eg. Sony, Canon) into winform and also control the camera capture button from a button in the form.
have Anyone build something like this, or are there any similar project like this which is done in C#?
This hardly depends on the capabilities of the camera and its driver. Your biggest chance might be the Windows Image Acquisition (WIA) framework.
Take a look at this article or the MSDN reference.
Emgu cv is a project that provides all the bindings for OpenCV. I've used it on both Windows and Linux platforms (Mono) with great success.
http://emgu.com/
http://emgu.com/wiki/index.php/Camera_Capture_in_7_lines_of_code
You can also take a look on Intel OpenCV.
It's C++, but you can use use PInvoke to use it from c#
This project supports even high-end PTZ camera. Code Project - Versatile WebCam C# library.
It uses Touchless.Vision and WebCamLib
I got a quick question about running a directX application (C++) in a managed environment. I'm attempting to write a MDI tool (in C#) where the background of the parent window would be an embedded render window of directX (C++).
I've read ways that involved writing the C++ into a native dll, however it would be prefered to be able to have the C++ projects included within the solution (I dont even know if that's possible though). Eitherway, if you know of some helpful steps, hints, or if this is a bad idea in general, please let me know. Thanks!
The easiest way to do this would be to add a C++/CLI project to your solution. This would then enable you to use the DirectX COM interfaces directly and create a managed wrapper that's easy to call from your C# code. I've taken this approach a few times and it's by far the easiest way of mixing DirectX and .Net that I've ever tried. Managed DirectX used to be an option, but it's no longer supported and it was a fairly small subset of the full COM API anyway.
First of all writing the C++ part in a different dll file doesn't mean that it couldn't be at the same solution as the C# project.
In order to use native DX to render on a managed window you need to pass the HWND window id (use form.WindowId.ToInt32) to the C++ D3Ddevice c'tor. after that each time you'll render using that device it would render on the .NET window.
To do this you probably need two saparate projects - a C++ dll & .NET project. use COM wrapper or p-invoke to pass the HWND to the C++ dll.
If you don't want to spend too much time on writing C++ code for DirectX, you can consider using
SlimDX, since Managed DirectX 1.0 is out of the question, where as 2.0 never leaves the beta and later replace with XNA which has quite different from DirectX itself, and require you to install XNA Game Studio
SlimDX is the opensource version of managed directx with slightly different API and internal structure, but it's easy to use. The recently released version is very stable. I'm currently using it to write a production application.
SlimDX
Managed DirectX