Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 02 2019 01:00
    uoitalia commented #466
  • Jan 01 2019 18:58
    ZaneDubya commented #466
  • Jan 01 2019 17:47
    uoitalia closed #466
  • Dec 10 2018 23:09
    nydehi commented #472
  • Dec 10 2018 23:08
    andreakarasho commented #472
  • Sep 24 2018 15:21
    AzRieil opened #473
  • Sep 23 2018 21:02
    AzRieil commented #472
  • Sep 23 2018 15:48
    AzRieil commented #472
  • Sep 23 2018 14:45
    AzRieil commented #472
  • Aug 31 2018 06:59
    PatrikSamuelTauchim commented #472
  • Aug 29 2018 13:18
    AzRieil opened #472
  • Jan 05 2018 09:20
    arthurasrossi commented #471
  • Jan 05 2018 08:47
    msx752 commented #471
  • Jan 05 2018 08:07
    naggie commented #471
  • Jan 04 2018 23:19
    yazeed opened #471
  • Sep 06 2017 00:24
    jorsi commented #376
  • Sep 05 2017 03:01
    jorsi commented #470
  • Sep 05 2017 03:00
    jorsi opened #470
  • Aug 29 2017 01:30
    jorsi opened #469
  • Jul 18 2017 22:58
    msx752 commented #317
Zane Wagner
@ZaneDubya
Thanks @alerdenisov !
Jonathon Orsi
@orsi
Nice! I'll play around with it this weekend
Zane Wagner
@ZaneDubya
I'm replacing the mouse picking - because @hifi is right, we shouldn't be calling texture.GetData 10s of times per frame.
Toni Spets
@hifi
my approach was to generate a boolean array for hit testing
that particular implementation wasn't pretty but it was fast and worked well enough
Zane Wagner
@ZaneDubya
That was my first solution! Then I got a little over ambitious :P
Zane Wagner
@ZaneDubya
It now stores non-transparent pixels as spans. The performance hit from the extra math is tiny.
Zane Wagner
@ZaneDubya
And the benefit from having all the mouse picking data in one small location is - I assume - a huge improvement ;)
Toni Spets
@hifi
well, the kittens will thank you for not killing them for one
I still probably need to keep the texture conversion hack in place until MG is fixed
will look into syncing UltimaMono again soon
and I find it a bit funny people were like 'fuck yes, let's make UXNA portable!11' in the original issue and not a single person has contributed anything to UltimaMono ;)
Zane Wagner
@ZaneDubya
Lol
It's hard and people are busy!
I was looking at FNA this week. Just a brief overview - not as deep as my dive into MG last year (which was itself only surface level) - but my feeling is that FNA would be easier to move to.
I know FNA is cross compatible with nix and mac. Idk about mobile. One of the huge benefits of MG is iphone/android compatibility.
Not that uxna would take advantage of that.
Valentyn Andrushko
@AimedNuu
You sound u're being active again
Toni Spets
@hifi
@ZaneDubya though FNA isn't supposed to extend XNA but MG is so MG would be the more "modern" target than FNA
Zane Wagner
@ZaneDubya
As I'm reacquainting myself with the codebase after my absence since earlier this year, I'm finding that the code is in need of cleanup in a big way.
#463 is another step in the direction of making the code a lot cleaner.
https://github.com/ZaneDubya/UltimaXNA/blob/master/dev/UltimaGame.cs is now much easier to read - all the cruft has been eliminated or moved to support classes.
I'll continue cleaning up as I have time.
After all the Milestone 0.8 issues are complete, I'll probably do a batch fix of all capitalization, organization, and style issues.
Four big style changes I'm considering:
  • Egyptian brackets throughout
  • Change prefix of private member variables from m_ to simply _
  • Require brackets on single line statements.
  • Soft limit of 120 characters in a single line for 99.9% of statements.
Zane Wagner
@ZaneDubya
And I have some ideas that will hopefully reduce the time spent drawing by a good amount.
Optimizations.
Toni Spets
@hifi
+1 for _members
makes auto-completion also easier
Zane Wagner
@ZaneDubya
@hifi merged your portable TileMatrixData reading PR. Do we need to replace all the methods in NativeMethods?
Or - not replace - I'd rather just make portable versions. But same question.
Toni Spets
@hifi
It was the only method used after I replaced all input handling
Zane Wagner
@ZaneDubya
Ah, ok
My changes SHOULD work on your end. I can't see why they wouldn't. MG should not define WINDOWS on the linux / mac platforms.
Toni Spets
@hifi
I don't know what to do with the input handling just yet
ideally it would have a portable implementation and native implementation(s)
Zane Wagner
@ZaneDubya
Yeah, it's a beast. I spent many days trying to figure out how to handle different culture inputs.
I have no idea how nix handles keyboard<->text input.
Toni Spets
@hifi
where native implementations would be on-par with the windows one and portable some weird keyboard mapping thingy
because I would be just fine with the "portable" one I'm not too eager to go that route yet (native on Linux or Mac)
Zane Wagner
@ZaneDubya
I hear ya. Maybe just use the built in xna keyboard routines? I think we've talked previously how xna keyboard input is not optimal for typing text because the rate of input is not granular enough, but it's good enough for everything else.
But then again, it's been so long since I tried to use xna for that purpose. I might have been doing it wrong.
Toni Spets
@hifi
xna input has no notion of keyboard layout
or any text input at all, you either need to emulate it or use the MG add-on for text input events
Zane Wagner
@ZaneDubya
gotcha
Toni Spets
@hifi
the problem with UXNA is all input handling is so tied to win32 way of doing things
it would be much better if it was abstracted away and the input system be pluggable for this kind of thing
there were also quite a lot of code in the event system of uxna I didn't really understand why it was there in the first place
Zane Wagner
@ZaneDubya
Which event system? You mean the KeyboardEvent, etc code?
Toni Spets
@hifi
it seemed overly complex