LÖVE

bartbes wrote:

T-Bone wrote: 2. SDL on Windows Phone is compiled without SDL_Joystick, so games crash unless you remove the joystick module in conf.lua on Windows Phone. I'm not sure how I'll solve this, I've written a "null" joystick implementation but I'm not sure how to swap the SDL one for it only on Windows Phone (I really want to keep joystick support on PC/tablets, and there's no easy compile-time or run-time checks to differentiate between the PC/tablet and Phone).

Can't you check the return value of SDL_InitSubsystem?

Hadn't thought of that, I'll look into it. Thanks

EDIT: Yup, that worked just fine! I was always thinking of ways to identify Windows Phone itself, rather than looking at the more important issue of wether or not SDL had Joystick support. Now this code could be useful for other ports as well.

would this increase performance on windows platforms ?

jjmafiae wrote:would this increase performance on windows platforms ?

No definitely not. http://superuser.com/questions/571278/w ... assic-apps

T-Bone wrote: 1. When running in landscape on Windows Phone, the graphics get messed up. It looks like this is SDL's ANGLE's fault, I'll see what I can do.

Implement landscape in lua/love with some transformations (rotate, translate) and some math, should be pretty simple

jjmafiae wrote:would this increase performance on windows platforms ?

On most systems, no. Memory access is for example more limited. On some systems with terrible OpenGL drivers, it might be faster though because it uses DirectX (through ANGLE) rather than native OpenGL. For systems with good OpenGL drivers, this decreases performance somewhat. Also, LöveFTW uses "normal" Lua and not LuaJIT, so Lua performance is naturally worse.

Either way, for most systems any increase/decrease in performance is probably not something you're going to notice that much. In my experience, LöveFTW runs extremely smoothly on everything I've tested it on.

Positive07 wrote:

T-Bone wrote: 1. When running in landscape on Windows Phone, the graphics get messed up. It looks like this is SDL's ANGLE's fault, I'll see what I can do.

Implement landscape in lua/love with some transformations (rotate, translate) and some math, should be pretty simple

That would be quite easy to do, but detecting when it should rotate from within Löve isn't trivial. It's probably easier to solve from within SDL's bindings to ANGLE.

The issue seems to be this https://github.com/MSOpenTech/angle/issues/25 and they have a (possibly slow) workaround proposed that I will try to implement.

I~=Spam wrote:

jjmafiae wrote:would this increase performance on windows platforms ?

No definitely not. http://superuser.com/questions/571278/w ... assic-apps

Hmm I was in a rush and didn't check if the link had the info I wanted.... oh well. Well this link is someone complaining about startup time. But windows 8 apps actually run slower not just starting up. This is because microsoft couldn't find a team to have metro apps use COM: https://msdn.microsoft.com/en-us/librar ... 85%29.aspx

Small history lesson:

COM came out maybe about 15 years ago. It set out to solve the problem that because Windows now supports x86 processors (private application memory space). Embedding/Using feign code was close to impossible. That is until COM came out. COM, at the time, was a super powerful tool but was awful to use. Few learned how to use it.

Now back to present:

So no one knows/remembers/wants to use COM. It, again, is a huge pain in the *ss and is in a way rocket science to use. So one thing that Microsoft needed badly when making metro was COM programmers to be able to interface directly with the OS and with graphics, etc. This same work has already been done for Win32 target but it needed to be done again for Metro. Well, ironically, Microsoft couldn't find a team who knew how to use Microsoft's own technology. So how did Microsoft even make the Metro development target? Essentially, the Metro interface is analogous to a web browser. It functions in just the same way. NOTHING is direct. What about DirectX11? Nope. You actually don't interface directly with the graphics card.

That is why it is slower. Microsoft couldn't find people who knew how to interface directly with their own OS. It isn't their fault exactly. They just are pretty stubborn about supporting old technologies...

This is why I use Arch Linux.

EDIT: Unfortunately, I cannot find where I read about this :\

Oh dear, if this is slower than standard löve then I will definitely not port my game with this, I'm already struggling with performance for my game even though I optimized the hell out of it.

You are really complaining about that it is a bit slower? Imagine more than 2 times increased target devices and even more users what can download your game. Maximum performance isn't that much important aspect in game development. And Windows devices are very well optimized.

jjmafiae wrote:Oh dear, if this is slower than standard löve then I will definitely not port my game with this, I'm already struggling with performance for my game even though I optimized the hell out of it.

If performance is important, this port is probably not for you. This port is primarily for targeting phones and tablets, where performance is typically limited anyway. If you're doing heavy calculations and heavy graphics, targeting only desktop makes the most sense.

If you weren't planning on supporting the Android and iOS ports, you probably shouldn't plan on supporting LöveFTW either.

deathbeam wrote:And Windows devices are very well optimized.

.... Ummm from what I just said... no they are not. The windows desktop is nice and optimized because of its direct use of COM but not the metro apps. It is too bad... I would definitely like to see a performance comparison though. Maybe, just maybe microsoft has fixed the issue now... that would be nice. Someone else will have to do it though because I don't have windows 8 or any windows 8 powered device. :\

T-Bone wrote:If performance is important, this port is probably not for you. This port is primarily for targeting phones and tablets, where performance is typically limited anyway. If you're doing heavy calculations and heavy graphics, targeting only desktop makes the most sense.

If you weren't planning on supporting the Android and iOS ports, you probably shouldn't plan on supporting LöveFTW either.

My thoughts exactly.