Windows version is half the speed then Mac version in terms of collision for me

[jnpickee]

Sorry to be back so soon, I actually wanted to drop this since I have a working game on windows, but people want a full speed windows version, this issue was somewhat addressed in the thread below, but believe it needs it’s own thread to focus on.

I cannot produce a working "bdist_apps" version of my game on windows

yes we are back on this topic again, I apologize, but I am currently in game jam, and people are reporting the game being broken on windows, today I finally had the chance to install bootcamp on a borrowed mac and check out the issues for myself, there are couple, I will focus on the missing modules issue, here is the terminal log. Building runtime for platform: win_amd64 There are some missing modules: [‘builtin’, ‘_bisect’, ‘_blake2’, ‘_codecs_cn’, ‘_codecs_hk’, ‘_codecs_iso2022’, ‘_codecs…

So as the title says my collisions are cutting my game’s speed in half when on windows, regardless if I am running the exe or sdk, it is the same mac machine just the platform is different (bootcamp enables me to run windows 10), and windows version runs at 14fps while mac runs at 30fps (my cap).

I manage to record the pstats in a image on the windows version (it’s below, I would get them for the mac, but I cannot get pstats working, though it should not matter much because mac is running at the full capped 30fps)

So in the previous thread, me and Thaumaturge concluded that the slow down in windows was the collisions (as you can see above) which would be fine, I mean I could try octree, or combining the collision nodes into less nodes or the like for speed ups.

But there would always be that problem that the mac version is faster and I can do more on it, which wouldn’t be problem if I developed on windows, but I develop on mac, having to check on the windows version often would be difficult for me (especially since I don’t have a windows machine in my possession, I had to barrow the macbook with bootcamp)

I am so thankful for you guys help, and I am sorry for bugging you so soon, and thank you to those willing to help.

[rdb]

Let’s first establish whether we are comparing apples to apples. Are you using the 64-bit version on Windows? Are you getting this performance in both cases in the build produced by build_apps, or with the development version of Panda? The build produced by build_apps is significantly more optimized than the “normal” installation of Panda.

You should optimize your collisions one way or the other, though; it is usually possible to get good performance benefits by octreefying or even just using something like world.subdivideCollisions(4).

[jnpickee]

yes, it is the same machine, I always use 64bit in my bootcamps, I don’t see any benefits to using x86 unless the machine requires so, and yes tested both bdist and sdk, the difference between the two is model loading is faster on the bdist, but the collision remains the same, even with other users complaining the same thing.

Thanks for the optimization tip, I will use if I see slowdown when I am developing.

Edit: I am going to try your subdivdeCollsion method on the windows version, give me a minute.
EDIT2: so I tried and kept getting “NameError: name ‘CollisionNode’ is not defined”, I am now going to attempt octreefy tomorrow with some code found on the forums.

[jnpickee]

I couldn’t get the octreefy code to work, though subdivdeCollision I decided to look into more, I went to py file responsible and added the collisionNode import to finally get it to work, but it turned out, it ended up breaking my game, I assume that it must have changed the collision nodes names and I cannot have it do that.

If octreefy does the same and touches the names, then it is also not the answer for me, I am appreciative for the tips though, thank you rbd.

EDIT: my brother toke back his pc, so I cannot test this for the time being, my apologies.

[jnpickee]

Hey, long time no see, I came back to this topic because it is issue that still persists, I made a sonic fangame recently and got a 1 star review because of this vary issue (laughs) but more importantly I finally got a windows device where I can start testing this issue again, so lets continue

---

I will say I only ever got the windows version to run full speed by using the SDK version with the directX graphics pipe in 2019, I wonder if the collision system is dependent on the graphics or GPU, if so, this may become a issue of getting directX to work with bdist_apps, something I have not done ever after all these years.

[rdb]

Hi there!

DirectX won’t run collisions any faster, I don’t think that that will make your collisions run faster. However, if you want to try it, make sure to add “pandadx9” to the plugins list in your setup.py and also make sure to have a line saying load-display pandadx9 set in Config.prc.

As an alternative to subdivideCollisions, you could check out this thread, which is a more sophisticated yet still very easy way to optimize the collisions of a scene using an octree structure:

Magical collision scene optimizer

Do you occasionally struggle with slow performance of collision detection routines? Do you sometimes wish there were a magical function you could call that would just… suddenly make everything fast, with no extra work needed? Well, no longer! I have written a function that will optimize any node graph containing “into” collision nodes in such a way that collision detection will become orders of magnitude more efficient. As an extra feature, it can also convert visible geometry into collision…

This function has a flag to preserve the names of the resulting structure, which should fix the issue you were running into with subdivideCollisions (assuming that was indeed the cause).

[jnpickee]

sorry for taking so long, I had to get some things setup, but I tried your first soution and got this…

this is the common problem I get when I try to build with directX there is always no gaphics pipe, I did what your said too with the config.prc loading only directX

---

I did notice it tried to load openGL, something I did not notcie before, why? is there a separate config.prc within the executable?

---

Edit: your second solution appears to work, but a bit of conflict with my systems, still I am still doing some more tests, I will get back with you with what I got in a while, thank you for the optimizer

Edit2: so it does work, when i build it from my windows device, my mac gives a error saying there is no rich command, but that could just be that I am using a older version of python on mac.

But like I said, there are some conflicts, like some of the button holding down no longer works, it also seems that collision handler event drops on some surfaces.

Edit3: Its not the button holding that’s the issue, the action where I thought had the issue which was jumping is tied to the fact that the character must be making contact with ground to work, the true issue is the collision event handler, the handler does not like when the character is at a certain angle

Edit4: It turns for the most part, your optimizer works, other then the conflict with the collision event handler, so I will give your post the solution tag in hopes that it will get fixed in a later update, thank you for solving this, you have been a huge help.