Experimental v80c now up!

20 replies to this topic
Posted 1+ years ago #1
marksibly

Hi,

Just in the process of uploading v80c....

This includes a reasonably important fix for a c++ gc bug, and an attempt at making the glfw joystick functions return hopefully saner results on pc/mac.

Fixed a nasty GC bug.

Fixed misspelling of CFG_GLFW_APP_LABEL in glfw target.

Had another hack at the glfw joystick code. Both pc/mac versions now attempt to detect xbox360 controllers (mac also tries to detect ps3) defaulting to 'logitech dual action' layout if device not recognized. FAR from foolproof, but should/may be an improvement on current setup.

Added RealPath to brl.filesystem.

 
Posted 1+ years ago #2
Playniax

Thank you Mark!

 
Posted 1+ years ago #3
Snader

Thanks Mark!

 
Posted 1+ years ago #4
ElectricBoogaloo

Kewlykewly!!
..Although, knowing how often I bother to update my Devkit. I probably won't notice this change until about mid 2015, and then freak out on the forum, as to why the controller code's suddenly changed!!

 
Posted 1+ years ago #5
Nobuyuki

thanks a bunch!!! I'll be sure to test it soon.

 
Posted 1+ years ago #6
Skn3

Hurrah for RealPath :D 1 less thing to hack in, each build!

 
Posted 1+ years ago #7
ImmutableOctet(SKNG)

Hey Mark, apparently MSVC hates C99, so your 'j' local variable (On line 237 of "win32_joystick.c") needs to be moved up, otherwise it'll complain. Don't ask me why Microsoft thinks C99's the devil, but it's still a compilation error with MSVC.

 
Posted 1+ years ago #8
marksibly

> Hey Mark, apparently MSVC hates C99,

Thanks, will fix.

Any particular reason you're still use msvc? It'd kind of make things easier if I could go gcc only for the desktop target, esp. WRT linking with external libs, include paths etc.

 
Posted 1+ years ago #9
ziggy

Any particular reason you're still use msvc?

In my case, gcc takes about 10 times more to compile. From less that one minute to abou 6 on big projects with lots of reflection. The difference is very notorious.

 
Posted 1+ years ago #10
Samah

Mark: Any thought toward accepting my GLFW3 target pull request?

 
Posted 1+ years ago #11
skape

Cool! Thanks Mark!

 
Posted 1+ years ago #12
Nobuyuki

gcc is indeed slow as a butt to compile large projects with; the last commercial proj I was workin' with using Monkey had the same huge amounts of lag Ziggy was dealing with, so I was using msbuild for debugging too. However I respect how much of a PITA that msbuild can present with some C code. Perhaps a compromise would be able to optionally tell trans to run gcc with -o0 or whatever optimization level the user wants? I think debug builds were already hardcoded to -o1 or something, but it's still too slow for really big projects compared to msbuild.

P.S. Mark, I'm sorry to report but it seems I'm still having the axis issue on analog stick 0 on v80c. If I can get my hands on a "real" x360 controller and not just this MadKatz fightpad, I'll let you know if it also has the same issues. I'm almost certain this is related to the drivers being different between XP and 8.1 x64, since no analog use is reported on 8.1. It's using the standard Microsoft drivers, however, so this problem doesn't seem to be end-user fixable. My update here has more: http://www.monkey-x.com/Community/posts.php?topic=8846#93486

 
Posted 1+ years ago #13
Neuro

Anyone getting Error : Type 'App' not found issues on OSX with this one besides me?

EDIT : nevermind, textedit was adding a weird looking quote thingy at the end of config.macos.txt

 
Posted 1+ years ago #14
golomp

Thank you Mark!

 
Posted 1+ years ago #15
skape

Xbox controller on Mac now seems to map 100% correctly. Thanks. :)

 
Posted 1+ years ago #16
Arjailer

Yeah, I found switching from GCC to Visual Studio 2010 cut my builds from almost 3 minutes to just over 10 seconds.

Plus I use Visual Studio every day in my day job, so I know it well - whereas GCC is a mystery to me :-)

 
Posted 1+ years ago #17
marksibly

> Mark: Any thought toward accepting my GLFW3 target pull request?

I've actually got a glfw3 target pretty much ready to go, however there are still a few bugs/issues in glfw3 that make me a bit nervous about releasing it right now.

I was thinking of waiting for their next public release, but maybe sooner...? Dunno right now.

 
Posted 1+ years ago #18
ImmutableOctet(SKNG)

You could always just have it as an experimental target, like what you did for Android. Also, as several users have pointed out, GCC is slower at times (But damn does it produce optimized code). Mainly for debug-builds, though. When it comes to release builds, it's pretty close for me. To tell you the truth, I prefer GCC, but MinGW has always been a half-assed port (Even if it is pretty good realistically). For Windows, MSVC's an okay choice, it's just horribly managed (Hey look it's, 2010, 2010 again, 2012 (Which barely supports C++11), 2012 again, 2013, and 2013 again, and then 2014/2015 (Which will supposedly support C++14), etc).

Then there's Intel's compiler, which doesn't check specific hardware features very well on non-Intel CPUs, so everyone thinks it's biased. Which in a sense, it is, it's just Intel's laziness. That being said, I've heard it's gotten better about that.

But to begin with, I think having the option to just output standard C and C++ is overall the best option. The compiler should be irrelevant. However, since we can't always have everything we want, I'd say supporting two compilers is the way to go. If you start only supporting one compiler, it's likely you'll run into a compatibility issue, a typo, or another anomaly which breaks another compiler. And you might be thinking "Well, as long as this works, I'll be okay.", but when you get to the STDCPP/C++ Tool target, all hell breaks loose.

My thoughts are that you should stick with GCC, and support a stable Visual Studio version until it gets too old, and starts hindering development. From there, simply move to the next Visual Studio version that everyone's willing to install. (Maybe when C++14 gets added?)

By the way, does this new GLFW3 target of yours support the usual resolution management? (Well, at least the Mojo stuff?)

 
Posted 1+ years ago #19
Koradin

Thanks Mark. I've been trying different libraries / engines for several months and am grateful for Monkey and its ease. I appreciate the time and effort you have spent putting the product together.

 
Posted 1+ years ago #20
MonkeyPlotter

Thanks Mark, giving v80c a whirl now ;)