Site navigation

D3D Component progress

General JUCE discussion
#1

Hi,

I’ve made my initial implementation of the Direct3D component based on the 1.9 code base and the OGL component. The only problem I have at the moment is that, once the component is working, the rest of the window is black. There are a couple of things I dun’t fully understand in the OGL component, suchs as what the componentParentHierarchyChanged does exactly. Also noticed the QuickTime masking is different than the OGL, but I dont fully understand why.

Now I have to change quite a few files to incorporate the D3D component. Eventually requireing tinkering when ever I change to newer code base. Could it be possible to have some kind of base class for this kind of components which need masking?

I noticed one rather interesting thing as well, if I copy (ctrl+C) text from the demoapp source window and paste it in visual studio, it will not compile. The editor displays it correctly, but the compiler does no understand it.

I think this is the problem I mentioned earlier in the Windows forum too. At least the end of line seems to be non standard (paste the text into Notepad for example).

Correcting the EOLs and reformatting the code in VS helps a little, but sometimes I still get very strange errors, like commenting one line of code will result error complaining missing ‘}’, the original line being:

canvas->setBounds (10, 200, getWidth() - 20, getHeight() - 230);

Any ideas?

#2

Hi,

I don’t want to be pessimistic, but I don’t see the interest of a Direct3D component. You have OpenGL, it is cross platform, is at least as powerful as Direct3D, and it is very well documented.

What would be the interest of a Direct3D component ?

  • It will work (if it works) only under Win32 platforms.
  • It is not supposed to be integrated in windowed environnement (you can see MFC support for D3D, made by MS, you’ll see it’s very, very limited)
  • You will have to change the code, each time a new DirectX SDK is out, and developper will have to have the same SDK as you have.
  • You will waste more time trying to create that component than learning to use a standard, cross platform code.

Concerning the copy & paste problem, you should save the file with a default encoding (if you have visual express 2005) in the save as menu, and reopen it. Else, you will have to use wordpad to paste the code, than save it as a MSDOS file, reopen it with notepad, copy and paste from here.
The simpliest solution is to download the source from the website, and use them directly.

#3

hmm - yes, I have to admit that I wouldn’t really be tempted to actually add D3D support to the library as an official thing. I’m not a big microsoft fan, and D3D people (mostly game writers, I guess) aren’t really my target audience…

I’ll check out the line-break thing. Odd, really - as you’d kind of expect compilers just to ignore all the whitespace.

#4

I’m well aware of the limitations of the D3D and OpenGL, I have used both. The main reason not to use OGL at the moment is that it does not support the functionality I need (the immaturity of FBO extension is a huge problem for me, and no, I will not use p-buffers). My application is very 3D graphics heavy, using the same algorithms as the current games to create realtime animations. There is no reason to go to the D3D vs. OGL war, I’ve chosen my path… :wink:

So I’m mainly doing this for myself, but I don’t mind to share the stuff with other users too. As for the masking part, it would be nice to have some common way to do that, so that my code could live outside the main JUCE codebase. At the moment I need to change few files to get my stuff integrated (related to the masking).

I’m using the old Visual studio 2002, have to check out that save option once I get home. Maybe the reason is that the editor supports some encoding the compiler cannot understand.

#5

yeah, I should really try to come up with a generic way of doing the masking, and use the same thing for opengl, quicktime, etc. I’ll have a think about that.

#6

Got a little further figuring this out. The problem with my D3D plugin seems to be somehow related to the window updating.

If I create a D3D component, the parent window will not update. Not sure what excatly is the problem, but it seems that if I force the window to update (like move other window on top of it, and move it away) I can see everything else drawn into the window (the invalidated area), except font rendering.

I’m using pretty much the same code as the OGL component, and the problem seems to be somehow related to parenting the windows. That is if I comment out the line

SetParent (hwnd, (HWND) topNW->getNativeHandle());

The D3D window will of course be floating, but no update problems. The handlePaintMessage() is called twice per frame (render is printed out in the render method, called similarly as the rendergl)):

wnd=1312884 x=0 y=0 w=0 h=0
wnd=1509618 x=0 y=0 w=580 h=570
render

When I break the parenting, the handlePaintMessage() is called twice too and for some reason the render method gets called twice too. But the parent window gets rendered correctly.

wnd=1116414 x=0 y=0 w=580 h=570
render
wnd=1443950 x=10 y=200 w=580 h=570
render

I’m posting this in the hope that there would be something that could ring a bell to someone :slight_smile: Back to debugging…

#7

I realize that Juice is all about cross platform, but as an aside I want to throw another voice in the mix on behalf of DirectX, although I am somewhat biased as I worked for Microsoft for 5 years.

There are good reasons why people chose it over OGL, and there are good reasons why the opposite also happens. There is no clear choice for all uses and memon already mentioned one good reason.

On Windows and when working with game related technology, or in some cases when working with general purpose GPU programming, DirectX can have an advantage in terms of its API features. Another issue is that there is better optimized driver support for DirectX on Windows across the board for all vendors. OGL on Windows is always the ugly stepchild.

It should be easy to offer an abstraction to enable DirectX on Windows and OGL everywhere else. Of course I agree this DirectX portion shouldn’t be part of Juice, just that it should be possible and no harder to implement such a feature for Juice than it is for OGL, at least in my opinion.

I am new to Juice, how can I get a hold of the D3D plugin? And also, where can I get the latest source? Is it just the compressed file offered on the Juice page? Or is there anything newer or cvs access?

#8

Can anyone tell me where I can get the D3D component for JUICE? Is it publicly available?

#9

There is no official d3d component, but I’ve been working on add-on, but it’s not distributed yet, as there are this issua which prevents from working at the moment (for the description of the problem see this thread :)).

#10

I understand, but I may be able to help you if you release the code.

#11