macOS Tools/libraries to convert DirectX to OpenGL (and help with libusb32)

[gumbyx84]

Hello all. I have a fairly odd question for you all. I am thinking of taking on a personal project now that I will be graduating and it is porting the Windows homebrew app RemoteJoyLite (app and plugin for PSP that allows you to output video from PSP to monitor) to OS X. I have looked over the source code and found that the orignal programmer used DirectX to display the video to the screen. I am new to graphics programming (DirectX or otherwise) and am not sure how to port this app. On the Open-Source front, are there any tools or libraries I can use to convert the DirectX calls to OpenGL? If I can get those calls converted, it should be easy to port it to OS X and *nix.

If any of you guys could help me out, I would greatly appreciate it.

EDIT: After WINE was mentioned in this thread (these three posts), I did a bit of research on WINE and windows drivers. From what I understand, if you have *nix drivers for the device (in this case "PSP B" drivers which are based on libusb32), it should interface properly with the Windows app running in WINE. Basically, I am trying to find out if this is true. If so, does anyone know how I would actually go about doing this (getting libusb32 to recognize the custom PSP drivers as a valid device).

 

[boast]

hmm, maybe you can try talking with the wine devs to see how they do their Directx -> OpenGL, or searching through its source code in hopes of finding something.

 

[gumbyx84]

hmm, maybe you can try talking with the wine devs to see how they do their Directx -> OpenGL, or searching through its source code in hopes of finding something.

The issue is I don't want to "wrap" the program like WINE does. I want it to run natively as a Coca app.

This also reminds me that I need to find a way to get the Windows PSP driver to work in OS X and *nix. That's gona be fun........

 

[Cromulent]

The issue is I don't want to "wrap" the program like WINE does. I want it to run natively as a Coca app.

This also reminds me that I need to find a way to get the Windows PSP driver to work in OS X and *nix. That's gona be fun........

Wine does run natively. In fact Wine stands for WINE is Not an Emulator precisely for that very reason.

It basically provides the headers and function calls that Windows applications require to run and then implements those methods using the operating systems native calls.

 

[gumbyx84]

Wine does run natively. In fact Wine stands for WINE is Not an Emulator precisely for that very reason.

It basically provides the headers and function calls that Windows applications require to run and then implements those methods using the operating systems native calls.

I mean a "native" Coca app. WINE does not run apps "natively" as in the app is not running without WINE.

If I wanted to (as I call it) wrap the app in something like WINE, I would just use WINE or Crossover.

Edit: Been doing a bit of research and it seems that I can run the app in WINE as long as there is a *nix version of the Windows "PSP B" driver, which uses libUSB32 as a base. I'm going to try and edit the thread title to ask for help with libusb32. Maybe that is a better way to make this work then reworking the entire app.

 

[Cromulent]

I mean a "native" Coca app. WINE does not run apps "natively" as in the app is not running without WINE.

That is a very odd definition of the word native in computing.

 

[gumbyx84]

Not here to argue about what is "native" to an OS really means

That is a very odd definition of the word native in computing.

Native (in this context) = Made/compiled for a specific OS.

While the discussion of WINE did help me come up with an alternative solution to re-coding the entire app, it was not the reason I created this thread. I am looking for a way to change/convert in the source code of the application DirectX calls to OpenGL and Coca calls so the app runs as a Coca app. Not a X11 app. Not a Windows app running through WINE.

 

[Cromulent]

I am looking for a way to change/convert in the source code of the application DirectX calls to OpenGL.

In that case your best bet is just to rewrite the application using OpenGL if you refuse to use a library such as WINE. Unless of course you want to duplicate the years of work the WINE developers have put in doing exactly the same thing.

 

[gumbyx84]

In that case your best bet is just to rewrite the application using OpenGL if you refuse to use a library such as WINE. Unless of course you want to duplicate the years of work the WINE developers have put in doing exactly the same thing.

1. Please stop arguing with me about me using WINE or not. Its a waste of both our time. Just drop it.

2. Please quote me completely. I want to change/convert the calls to OpenGL and Coca. I believe Coca apps still use OpenGL to draw the window to the screen. If they don't, then I made a mistake and don't need to convert to OpenGL but to Coca calls.

 

[Cromulent]

1. Please stop arguing with me about me using WINE or not. Its a waste of both our time. Just drop it.

Fair enough, although a decent reason is a better way of getting someone to drop an argument.

2. Please quote me completely. I want to change/convert the calls to OpenGL and Coca. I believe Coca apps still use OpenGL to draw the window to the screen. If they don't, then I made a mistake and don't need to convert to OpenGL but to Coca calls.

First of all it is Cocoa.

Second, Cocoa and OpenGL are two distinct entities. In just the same way as DirectX is separate from the Win32 APIs in Windows. Cocoa may use OpenGL underneath the hood but you should neither care nor worry about that as it is all encapsulated.

From the sounds of it, it now appears that you want to port a standard Windows application to Mac OS X. In that case you will need to rewrite the parts of the application that make direct calls to the Windows APIs and replace them with the correct Objective-C calls to Cocoa. If your Windows application is primarily C or C++ then this should be reasonably straightforward assuming of course you have separated the GUI elements properly from the application logic.

If it is in C#, Visual Basic or another language your job might be somewhat harder. Although if that were the case I would just recommend you use Mono.

 

[boast]

my post was to say that the wine devs have experience in knowing what opengl calls can be used when apps request them in directx.

I didn't mean to use wine, or create a wine-like program. Just see what they use for their Directx -> OpenGL, and in turn be able to edit your source code with it.

 

[gumbyx84]

my post was to say that the wine devs have experience in knowing what opengl calls can be used when apps request them in directx.

I didn't mean to use wine, or create a wine-like program. Just see what they use for their Directx -> OpenGL, and in turn be able to edit your source code with it.

My comments about WINE were not directed at you boast. I do get what you mean though, it is an idea, but as Cromulent stated, if I want to make it a Cocoa app, I need to recode the WinAPI calls to Cocoa calls. I haven't looked at the source code for a while, so I need to do that before I decided exactly how I'm going to attack this.

Also, if I can get libusb to work on my mac and recognize the PSP as a valid device, then the app (run through WINE) should be able to connect to the device (PSP) and display the video. That is the reason I changed the thread title, to see if that would work as well.