search

BoolClub / ProjectCrusade

First project of RHS Software Development Club
0 stars 0 forks source link

XNA Framework's limiting functions #20

Closed AnonymousNix closed 8 years ago

AnonymousNix commented 8 years ago

While the XNA framework is nice and fast, there are limits to what it can do for a game. In order to add certain core features to the game, the project needs to be converted to either WinForm or WPF with an embedded XNA view.

AnonymousNix commented 8 years ago

I'd do it myself, but the major change may cause temporary setbacks. It would be a "one step back, two steps forward" situation that would give the game a lot more capability in the long run.

christiancosgrove commented 8 years ago

Is there a WinForms alternative for MonoGame though? The project should be portable.

Also, what would we need forms functionality for? We haven't found a need for more complex GUI.

AnonymousNix commented 8 years ago

MonoGame is under the XNA framework. XNA can be used quite nicely under WinForms, so we could likely run a decent portion of MonoGame under it. The aforementioned setbacks would be caused by moving some portions of code up from MonoGame's XNA to the WinForm or WPF above it. As far as the functionality goes, it's not only the GUI. WinForms or WPF affect the graphics, input, etc. For example, OS X's native APIs do not allow XNA to have mouse support. Under WinForms, we could have full mouse support. It's common practice to put XNA under WinForms as it allows the speed of XNA and the functionality of WinForms. It also allows (a very tempting opportunity that I must mention,) much easier 3d or 2.5d graphics.

christiancosgrove commented 8 years ago

AIFAIK MonoGame is a self-contained cross-platform implementation of XNA, not a subset. With vanilla MonoGame we still have significant control over even the mouse--we can get and set its position within the window, detect button presses, scrolling, etc. I'm not sure of any other low-level features we would need in a game like this.

AnonymousNix commented 8 years ago

By under I meant written using. Sorry about that misunderstanding. As far as my knowledge goes, OS X will not allow some of those features without elevated privileges. Fully tracking the mouse movement and setting the cursor position should be restricted by the native APIs. Then again, if there was an update to the APIs that I was not aware of, I would love to know about it. But you must consider that Xamarin studio may be running the program under some form of elevated privileges.

EDIT: I did a look through of the cursor handling. While clunky, It seems to work well enough. However, Almost all graphics and animation would benefit from WinForms (or the newer WPF) instead of MonoGame, which is really just an improvement of XNA. As many devs have said, "XNA is dead." MonoGame does give good functionality, however I stress that WPF is a better option.

AnonymousNix commented 8 years ago

The project's organization is very poor, so rewriting a bunch of it is necessary anyway. I suggest we fix things and make important decisions early, before we get too dependent on certain bad code/features.

AnonymousNix commented 8 years ago

You know what, I've had a change of heart. I'll fix up and optimize the current code and see where we can go from there. I'll branch the master and work my magic. Expect a large pull request in the near future.