Jump to content
  • 0

3D Models Mac


HuckChorris

Question

Hey, strange problem that no one else seems to have except maybe Linux users.(?)

 

I have a MacBook Pro late 2013, OS X 10.10.2, NVIDIA GeForce GT 750M, Intel Iris Pro (switchable).  And no matter what settings I've tried tweaking, turning things on and off restarting deleting .ini 's, running on battery or no battery etc., my characters and zombies do not have faces textures or feet textures.  Now I know I can simply turn off 3D models, but damned if I just don't love me some 3D models!  You feel me right?  Right.  Because I'm 3D.

 

Thanks for any help or information.

 

-huck

post-13039-0-70592500-1427942571_thumb.p

Link to comment
Share on other sites

Recommended Posts

To be fair, the first link you put up is a problem with line breaks not anything to do with OpenGL...

 

The second link could literally be anything, not enough information provided.

 

Most of the info in the third source is massively outdated. OS X was really bad about OpenGL updates for a couple years, but when they released 10.9 they brought everything up to date and beyond what most PCs have, if I recall correctly (and patched their older OS's for the same). That bug is pretty heavily undefined and unverified; if it was a bug at all it was likely fixed years ago since that post was in 2012.

 

I'm not sure how either of these links correlate with the current issue. We're keeping an eye on it, and if time allows we'll look into it further. Unfortunately just guessing probably isn't going to get us anywhere at this point =\

Link to comment
Share on other sites

The game uses the Slick PNGDecoder.

It doesn't use bilinear filtering, so that's not it either.

This is perhaps the rarest issue PZ 

 

You're right. If you guys get your hands on a case with OS specs and what not, that will probably be when you are able to test-case this issue to find the real problem.

 

 

To be fair, the first link you put up is a problem with line breaks not anything to do with OpenGL...

 

The second link could literally be anything, not enough information provided.

 

I'm not sure how either of these links correlate with the current issue. We're keeping an eye on it, and if time allows we'll look into it further. Unfortunately just guessing probably isn't going to get us anywhere at this point =\

 

You're looking at the references too directly. The point is, on MacOS's, OpenGL is a nightmare for various bugs surrounding the components being affected in this case. No there were no specific drivers / cards mentioned, because it is a deeper problem. 

Link to comment
Share on other sites

You'll have to forgive me here, but I keep up with Mac stuff being TIS's primary Mac user and a pretty heavy power user. Your information is massively out of date. OS X drivers haven't been bad for several years now. They had a bad period. They aren't anymore.


But even if you're right, subjective complaints about "bad" drivers doesn't help us solve this issue. I appreciate you trying to help, but we'll need to look into the actual issue to fix it rather than just blame "bad" OpenGL implementation.

Link to comment
Share on other sites

You'll have to forgive me here, but I keep up with Mac stuff being TIS's primary Mac user and a pretty heavy power user. Your information is massively out of date. OS X drivers haven't been bad for several years now. They had a bad period. They aren't anymore.

 

Well that removes one possibility (mostly. Being in-house in development doesn't necessarily mean it's perfect. Emulation is never perfect.). It can be a result of the emulation acting differently to a set of opengl commands / code. The problem still lies with how MacOSX, or how LWJGL and it's natives are reacting in coordination with the code. 

Link to comment
Share on other sites

We'll keep that in mind. I'll certainly keep everyone up to date as and when we have any more concrete info. Again, posting specs would be extremely helpful.

 

Definitely.

 

Another thing to note that may be useful to this situation is considering that Java's default endian and native endian usually are different from my experiences, and can lead to issues if the natives for certain libraries don't handle things like this properly. This is where hardware specs can effect the way data is stored / manipulated in various ways.

 

The rarity of this only means it could more-likely be an issue with LWJGL. In that case, if you can get your hands on the specs of a test-case client, then I would suggest possibly sending LWJGL a support ticket with this in mind. This may fix this issue quicker. 

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...