The SharpDX toolkit has been abandoned for 3.0 SharpDX :(
Unfortunately, we need/are using this for a current Windows 10 project.
What we need to do is create a Sphere object as a surface so we can project on to it. Can anybody lead me to some things (or simply provide said things) that might help me out?
Thanks!
I can help you with the toolkit side of things, I'm using this atm for my terrain color map building I'm not sure how it will go if you use it every frame for UI type stuff because the guy that converted it to sharpdx 3 used pinvoke instead of the native fixed call.
https://github.com/tomba/Toolkit
just download as zip, load into VS and remove all the test\projects that fail to load then just build and add a ref to you project like normal.
The title says it all. Can I build and/or run Kivy apps on computers with videocards supporting no more than OpenGL 1.x ?
No, this is not possible. Our graphics engine is built to use modern OpenGL, not the old one. We have no plans for that, and will never do it in the future. If you want to target very old hardware, use another toolkit :)
XInputGetKeyStroke seems to return ERROR_SUCCESS when the specified controller is not plugged in, leaving the supplied XINPUT_KEYSTROKE struct uninitialized:
XINPUT_KEYSTROKE xStroke;
DWORD ret = XInputGetKeyStroke(0, 0, &xStroke);
if (ret == ERROR_SUCCESS)
printf("ERROR_SUCCESS\n");
Am I doing something wrong or is this a bug in XInput? xinput1_3.dll is the version I am using. I am compiling/linking against the headers/libraries in the DirectX 2010 SDK. When the controller is plugged in XInputGetKeyStrokes seems to behave as expected.
I've had the same problem with xinput1_3.dll and from my research it seems it is not implemented. It may be implemented on xinput1_4.dll on Windows 8 but I am unable to test this.
Confirmation that it's not implemented as of 26th April 2014: http://controllermax.com/forums/archive/index.php/t-142531.html
Not the most acceptable of sources but it's all I could find.
Support for XInputGetKeyStroke was added for XInput 1.3 (April 2007), but no Windows driver supports the 'Chatpad' device so it's limited to the controller "button keys".
The source for this function did not change between XInput 1.3 (the last version available down-level on Windows 7 via the legacy DirectX SDK / DirectSetup) and XInput 1.4 (the current version on Windows 8.x), so if there is a bug here it likely repros on XInput 1.4 as well.
This particular API is really only useful on Xbox 360 where the 'Chatpad' might be supported, and due to the down-level story for XInput, you are usually better served using XInput 9.1.0 rather than XInput 1.3 and sticking with the standard XInputGetState methods anyhow. I don't use XInputGetKeyStroke at all for the DirectX Tool Kit GamePad class which is probably a more useful abstraction.
See XINPUT and Windows 8 and DirectX Tool Kit: Now with GamePads
UPDATE: I found the code path that resulted in this condition, and will file a bug, but it's not likely to get fixed for XInput 1.3. One workaround would be to use another function (XInputGetState or XInputGetCapabilities) to check for connected state, and then call XInputGetKeyStroke only if it is connected.
I have been trying to play a video in my Direct3D application and have been trying to do so with the help of DirectShow. My problem is that I cannot find how to get the frame data to put into a texture (ISampleGrabber won't install).
Does anyone know of any methods or examples of this being done?
ISampleGrabber is available in all versions of Windows released last 15+ years
Look for "Microsoft® DirectX® 9.0 SDK Update (October 2004)" which contains sample app, which does exactly what you want:
Texture3D Sample Description
Draws video on a Microsoft® Direct3D texture surface.
Note This sample does not support changing the display properties of
the monitor while the sample is running.
Path
Source: (SDK root)\Samples\C++\DirectShow\Players\Texture3D
Executable: (SDK root)\Samples\C++\DirectShow\Bin\Texture3D.exe
UPDATE. Even though Sample Grabber existed though many many versions of Windows, it was finally removed along with other filters hosted by qedit.dll in most recent versions of operating systems (Windows Server 2008 in particular). Those whose application are dependent on this API, should consider building a replacement using Grabber sample from older SDKs. The same applies to those needing this filter because of so many references on Internet and tutorials on how to use it to get access to media streams.
The filter was removed silently and without any replacement. Microsoft suggests that Media Foundation is an alternate option and successor to DirectShow, which is however hardly helpful.
As perhaps you know already, most probably the next version of Delphi will be cross-platform. Also, here are some polls on the matter.
While writing a cross-compiler isn't a thing which interests us very much now, porting a library which was/is Windows-tied to multiple platforms, certainly does.
You can think, for example at VCL (Delphi's standard library). While it was designed for Windows only, it has value in it, and, of course, there are huge codebases which depend on it.
The question is:
Which would be the best approach to made an application / library cross-platform aware ensuring a smooth conversion / upgrade path (as much as possible of course)?
I stress it again, we are not interested which is the best way to do cross-platform development only (there were questions on this theme). We are interested also in yet another requirement: The old code base / installations management.
PS: Experiences and/or methodologies from similar situations with other languages (eg. C/C++) which are regarded as standard practices are welcomed.
Thanks in advance.
Visual component developer's perspective:
Add levels of functionality to your code, so as to be able to add another platform without changing the "Core" of the component.
The compiler hopefully will have a platform switch. (Preferable more than one, working in conjunction with each other. ex. Windows/ARM, Windows/386, OSX/Cacao/386, Linux/Gnome/386).
The Layout structure might look something like this.
ComponentJ.pas
Linux\ComponentJ.pas
Linux\Gnome\ComponentJ.pas
Linux\KDE\ComponentJ.pas
OSX\ComponentJ.pas
386\ComponentJ.pas
ARM\ComponentJ.pas
As an Application Developer:
I'll start by moving all WIN API calls in my code into a group of libraries in a Windows directory as to be able to IFDEF it at library level and translate it into another platform I'd like to support as soon as the compiler becomes available, but only as I come across them.)
This will also add the possibility to add adapters easier for the new platforms.
It in any case is good practice to remove possible dependencies into a central place.
IMHO you can't build a xplatform Delphi and ensure a smooth transition for current VCL applications. It won't work. VCL was (luckily, because it allowed for great applications) designed with Windows in mind, and trying to design a compatible library working on a different platform would just mean longer development cycles and lots of compromises. The outcome will be a library noone would wish to use. Look at what happened to VCL.NET: it was the wrong choice. And it was working on the same OS!
We know that targeting non-Windows platform with native applications needs a native GUI library. We don't care about creating a GUI from scratch, for our application it's the way to go, we don't need Windows GUIs with all their standards under a different OS using different standards - we need to be able to code a fully native GUI for the target OS.
Other applications may survive a GUI porting, but in the long run you don't get a real xplatform tool - you get a tool that may compile for other platforms but brings one platform paradigms to others - and it will also be not welcome by "native" developers on other platforms. If you're a Linux or Mac developer, why should you learn how to work with a library that carries its Windows inheritance to your platform? You'd find it a pain in the ass. If Embarcadero wants to sell XDelphi outside actual developers base, it has to offer much more than a new CLX.
I will pull from some ancient experience in making a code base cross compilable between windows and dos (Delphi 1/Turbo Pascal 7). The rule of thumb was to separate code into multiple units. Try to code WITHOUT using windows, messages or any visual components. If you find you need to make a call to one of these, then place that call in another unit and write a proxy (abstract class that you descend from works well) to dispatch the calls through. When a cross compatible version is released, all that you should have to do is code the other side of the proxy for the new target.
If you're designing a form based system, then try to stick with as many of the standard components as possible. NEVER implement any "business" rules directly in an event, instead place them in another unit and call into the other unit to perform the logic.
Now, there will definitely be changes required to get your final project cross compatible, but by following these simple patterns you should be able to greatly reduce the amount of work it will take.
Experience so far has shown that the best way to get a Delphi app compatible with future versions is to stick to pure Delphi components, and use nothing third party. Such an app will probably suck, but that's how it seems to me. I use lots of third party components, and the apps are great and successful. But the chances of them moving to this future too are not certain, and that may cause problems with such changes, but I'd rather have a great app now and have the problem than have a poor app now and not need to worry about it.
Compromises should not be done too much to make VCL compatible with Linux and Mac. Windows is VCL's root. I'll prefer a new and very clean GUI framework, even though without any backward compatibility. Make VCL fatter and fatter isn't a good idea!
make a cross-platform Pascal compiler
make a cross-platform RTL
put the QT on top
Well, look at freepascal and lazarus
I don't get it. All .NET looks the same to me providing we don't use any third party.
Delphi using standard control is already fully functional but your app would look
like thousands of others.
I think Embar should go for PDA, IPhone, Andriod as Windows desktop already eat about
98% of the market.
Mac is expensive and Linux is no cost at all. No use to go for Mac and Linux. Not worth
the investment.
Well, aside the things said - thanks all - I do think that there we need some additional things:
we need tooling to do the necessary conversions
we need tooling to help us in programming against a (some form of) MVC pattern
Simply pick the latest 4.6 QT and add good integration betwen the Pascal and the QT library.
They have done it before (in the Kylix times). The QT is such powerfull these days.
I believe that QT is even better then VCL and at least 10 times more frequently updated and fixed.
So the plan is simple:
make a cross-platform Pascal compiler
make a cross-platform RTL
put the QT on top
and you will have a first-class natively looking applications on all platforms.
My opinion:
Make cross platform compiler (OS x/Linux/ embedded solutions?/ symbian?). Maybe add ability to compile/convert pascal code into portable c/c++ code to build then on embedded platforms.
RTL have to be separated into cross-platform layer and native layer (as for JCL).
Add new core components for cross-platform compatibility and native components for each supported platform (QT for ex)
Add translation utilities to create/convert between platform's components, for ex: to convert pure windows form into mac os x cocoa's form.
All windows hierarchy of components have to be only upgraded to support x64 with maximum backward compatibility. All cross-platform component have to be in parallel hierarchy.
Next version of cross platform solution can be refactored and can include migration/convertion utility. Due to minimum codebase of cross-platform solutions, hierarchy and classes for cross platform can be heavily changed from version to version to achieve best architecture.
sorry for my English - not a native language (Russian is)!
Make C/C++/Delphi compilers that targets OSX/Linux
Make C/C++ compiler that can be Boosted
Write new VCL-Presentation Foundation (VGScene/WPF alike)
it should not be backward compatibile! Delphi IDE should be
written with such VCL-PF
Component Library should stay as it is (but with improved Data-Binding)
Only provide VCL 64-bit for Win64
Is this a problem?