A Update: so I could not get a hold of a windows machine, but I did the next best thing, Bootcamp! yes, I had forgot that I had a legit copy of windows 8 from my previous windows machine I decided to utilize it with my macbook air.
And with much trouble I finally got windows installed, so I got the game to run, but it is much slower! so I tried to use direct3d but it reported that it had no graphics pipeline, I,m guessing that a mac sdk has trouble creating a windows runtime(exe).
For the record, Panda should support Windows XP, but Python 3.5+ don’t. You need to use Python 2.7 or 3.4 if you wish to target Windows XP. If you were using either of those when you encountered the problem, let me know as there may be an issue with Panda.
I think the issue is, that my windows XP virtual machine was 32 Bit, it does not matter, because it ran like a slug natively trough bootcamp, so I don’t want even see how it runs under virtualization. but thanks for the tip rdb.
Before you conclude that the problem with your Windows build lies in building a Windows executable on Mac, have you successfully run a hardware-accelerated game in that installation of Windows under Bootcamp? If not, I’d suggest trying the build on a machine natively running Windows, if feasible. (And ideally one that has successfully run hardware-accelerated games in the past.)
In all fairness, I’m not familiar with the use of Bootcamp, so I may well be off in this. That said, it seems plausible to me that the problem lies in the graphics drivers on that Windows installation.
bootcamp is just fancy apple talk for having multiple OSes on 1 computer or dual-booting, so my windows installation has all the hardware capabilities as the Mac OS X, I don’t know about hardware acceleration but I tired graphics acceleration using the intel HD graphics control panel.
apple themselves provides all the drivers for windows through their bootcamp support software package, they would have to know anyway since it’s their machine model, anyway I still open to suggestions for 1 more day as I’m going to probably put out the demo tomorrow.
It seems if I had a windows panda3d sdk installed I can try the more optimized direct3d pipeline since the mac sdk for some reason won’t output it or the fmod audio plugin, but it is too late in the game to install sdk again on windows as it will take more work and time.
Update: so I finally toke the time to install the panda3d sdk on my windows installation, and so I built my windows runtime off of it and still the same, why? I thought direct3d was microsoft’s?
So I once again tried OpenGL, and yeah, still the same speed, so I will output a windows build of my game, but I will add a warning to those not to try it under a graphics card that under a card that is at least twice as powerful as the Intel HD Graphics 4000 Integrated (whatever that is).
Moguri, your suggestion just fixed the mac version! I did not get what you where saying until now when I kept on going over it, the “base.mainDir” command reveals the directory panda is using (even in the app environment!).
So looking the page you gave me a couple of times I came up with this code that fixed the mac runtime.
txt = open(str(os.path.join(str(base.mainDir),‘room’, “room”+str(room)+‘.txt’)))
This should also work for the windows version as well (even if the windows version already works fine) from the research I gathered
Ah, fair enough–as I said, I’m not terribly familiar with the Mac side of things.
(By the way, I was thinking of “graphics acceleration” when I said “hardware acceleration”, I believe–that is, the use of hardware (the GPU) to accelerate graphics operations. I suppose that, for whatever reason, the more-indicative term “graphics acceleration” didn’t come to mind at the time. Sorry about that! ^^; )
I honestly don’t know the state of the Windows graphics drivers provided by Apple, let alone for an Intel integrated device.
That said, if it is a driver issue, then I wouldn’t expect building with the Windows SDK to help, I believe–in that case, the problem isn’t on Panda’s side.
I am glad that you got your file-path issue solved! 
Thanks for your help in assisting with the file path issue, anyway, yes the openGL plugin seems to need more power when running on windows (for some reason), however the problem lies with the other graphics plugins.
I tried every one that was listed in the article wezu posted, and each one but the openGL gave me the same error, “there is no graphics pipeline” from that message I.m getting the implication that the plugins were not included.
Even though I commanded it in the setup.py file, I don’t know why it is doing this, but I bet if I can get the direct3d plugin to pack with the runtime it will probably run at full speed as it is windows native, but so far it does not work, so I,m working with what I have.
So sadly it might be that windows users are going to need twice the stronger hardware than what is afforded in a macbook air mid 2012.
I may be mistaken–and I stand to be corrected, if so–but I don’t think that this necessarily follows. It may just be that Apple have good driver support for OpenGL, but not for DirectX. (Which makes some sense, as DirectX is a Microsoft product, while OpenGL is an independent project, if I’m not much mistaken.)
Yeah maybe, another thing I forgot to mention is each sdk (on both windows and mac) are pip installations, I heard from rdb somewhere that these installations are bare-bones maybe my sdks are missing those plugins and that is why I cannot pack-in those plugins but I need conformation on this.
I don’t know. But I’m pretty sure that I’ve made Windows builds using a pip installation, albeit doing this under Linux, and had no such trouble that I recall noticing.
On top of that, from what I recall the build system doesn’t package your build using the SDK; instead, it downloads non-debug version from the Panda archive and packages the build with that. So I imagine that any plugins that you’ve specified would likely be included.
To be clear: I’m not saying that it’s definitely not an issue with the plugins. I’m primarily cautioning against concluding that it is an issue with the plugins, and not considering other possibilities.
hmm. well, I don’t have a clue why the openGL-es/2 plugins display that error message (maybe missing all together/not installed) but I might have a idea why direct3d may not be working.
The direct3d plugin seems to be direct3d 9.0 from the code name, I have checked my windows installation and it is using directX 11, maybe the plugin is simply not compatible?
Well, OpenGL-ES is intended for embedded systems (smartphones, tablets, etc.) rather than laptops, I think, so that may well not be supported on such a device.
As to DirectX, I’m afraid that I don’t know. I would expect it to be backwards compatible, but perhaps it’s not. I’ll let someone more knowledgeable on such things weigh in there, I think!
Oh? okay, thanks, I did not know OpenGL-ES was for that, well that explains that, I wonder if this is the method for one to port panda3d to game consoles, I actually think that is pretty cool, anyway, I think it is weird that direct3d is not working, but I guess you are right for us to wait for someone more knowledgeable.
Intel’s OpenGL drivers on Windows are terrible, so it doesn’t surprise me that performance is pretty lackluster using them. However, you should be able to get d3d9 running with your application (assuming you’re not doing anything OpenGL specific like custom GLSL shaders). Just to be clear, did you add pandadx9 to the list of plugins in your setup.py? Also, does the game run using d3d9 when not in a distributable (e.g., just running your game via python)?
Does roaming ralph use anything fancy? because my game utilizes the graphics properties of roaming ralph, and yes I did apply pandadx9 in the setup.py, the runtime always closes the program window immediately.
However when I switch to console apps, I get the error message “There are no graphics pipeline” talking with Thaumaturge has given me a idea, doesn’t windows have a “compatibility mode”?
Yeah, I remember a long time ago be able to emulate other versions of Direct X as as well as windows. I’ll maybe try that out.
Edit: I have not run my python script in windows through the sdk yet, I have to think about it.
Edit2: I have tried the sdk on windows, and it is still the same with openGL (slow), I used the config,prc to change it to direct3d and still the same error missing the graphics pipeline, I did notice something strange when checking the windows sdk.
And that was the pandadx9.dll was missing, so I supplied the one from the runtime and still the same missing pipeline error, so I do not know what to do.
Update: I’m now convinced it is the pip installation (and by it’s extension, the pip wheel), if you want to know why, listen to this long story below.
So while I was testing, I hatched the idea to use the official sdks (both 32bit and 64bit) and extract the direct3d plugin from them.
At first I installed the 32bit sdk to my VMware virtual machine (windows xp), and I obtained the pandadx9.dll from it, then vary hesitantly I installed the 64bit sdk to my bootcamp windows 8 installation.
And I obtained the dll file from it, of course both did not work, now I heard something bad would happen if one were the install the official sdk when the pip install already exist, so I had feared the worst about my sdk installed to my windows 8.
So I went ahead and tried it out, and if you read the previous post, I had last left it where the config only attempts to load direct3d, so I was expecting a error message of no graphics pipeline if the sdk still worked.
The script booted up, and the game ran slowly, what? this had to be the openGL plugin loaded, so did the config just reset? so typed up a search from the C drive for the config.prc (since I do not know where it is located) and I get two entries.
This makes since because of the newly install from the official sdk, so as joke, I thought let me match up the config files where both only load direct3d, when I loaded up the script, the game ran at full speed and at this point I know the direct3d kicked in.
Perplexed, I made a guess that panda3d must have now loaded from the official install instead of the pip installation, and to confirm this I decided to do a windows search on the directory of the official install and yup did I find it’s own “pandadx9.dll” file.
So I decided to copy that pandadx9.dll file to inject into the runtime, so I ran the setup.py to begin building the runtime once again, there was something I did not notice before, and that was it grabbed a 32bit wheel.
Then it dawned on me that “win32” from the setup.py is 32bit windows! so what was 64bit windows? I needed to know as I my windows 8 installation was 64bit, doing a bit of research I found only one entry that was both windows and 64bit.
And that was “win_amd64”, now I knew of this entry from the article Thaumaturge showed me, but did not use it because the word “AMD”, you see I use intel processors and I know AMD has there own x86 based processors, so I assumed this wouldn’t work.
But doing research on the internet, I found out it has that name because AMD supposedly invented the x64 instruction set for x86 processors, not because of a compatibility issue, so I went ahead and build the win_amd64 runtime.
And, no, it did not work, so doing a bit more research on these forums, I read in a post that the developers of Panda3d were aiming to make the least license burden copies of Panda3d when composing the wheels, that is probably why the direct3d plugin is missing and not functional, so there you go.
I would have to make a wheel myself that includes direct3d in it’s makeup, but sadly that is way too advanced for me, so I guess windows users are going to have deal with needing more powerful hardware (I,m vary sorry about this).
Ah, very interesting, and a nice bit of investigation on your part, I think! I’ll wait for the devs to weigh in, but it now sounds like you may well be right!
it’s just I don’t want to leave windows users out due to the fact I use to be one for many years, I also do not want to exclude linux users, though I have never used linux, but from I heard, linux is so similar to mac OS X, it is hard to think any issues would rise up.
Because I don’t think linux does would have have a bias towards such a exclusive format like directX.