Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[bloop_bleep]

I haven't touched Unity, but given that all coordinate systems I've heard of have the XY plane be parallel to the screen, I think they mean that positive Y direction is physically upwards on the screen (origin is bottom-left), which is different from usual (origin is top-left).

[Reelya]

Y is upwards for all raster/pixel based display systems. They're based on Cartesian coordinates with (0,0) at the bottom-left.

Top-left is reserved for text-based displays, since they are in the form column/row, and the general consensus is that rows of text on a page are counted from the top down.

[bloop_bleep]

https://stackoverflow.com/questions/33805481/why-pygame-coordinate-system-has-its-origin-at-the-top-left-corner

Other engines have this system, too, though I can't quite remember their names. I was under the impression almost all of them were like this.

[EnigmaticHat]

I don't think there is a standard for whether Y-up or Z-up is correct.  The question is, if you reverted to 2D, which axis would disappear?  So if you think birds eye then Z-up makes sense, if you think antfarm then Y-up makes sense.  To me Z-up is more intuitive because to me every 3D level is going to start with the terrain, and you edit terrain in birds eye view.

I'm pretty sure the reason Unity chose Y-up is because if they didn't it would make their 2D games use an XZ coordinate system which is obviously terrible.  However that's kind of arbitrary thinking, there's no reason the camera couldn't be looking down for 2D games.  It would introduce the problem that gravity would have to change axis between 2D and 3D games.  Personally I don't think its a particularly insurmountable problem.

[Reelya]

https://stackoverflow.com/questions/33805481/why-pygame-coordinate-system-has-its-origin-at-the-top-left-corner

Other engines have this system, too, though I can't quite remember their names. I was under the impression almost all of them were like this.

Quite the opposite. Systems with positive Y up the screen include OpenGL, Unity and Unreal Engine, and Direct3D.

One quirk however is that Direct3D's "2D" pixel coordinate system starts in the top-left, since it's inherited from Windows screen coordinates, whereas most other 3D systems count pixel locations going up the screen, so are aligned with positive X and positive Y. So Direct3D's 3D origin is in the bottom left, but the 2D origin is in the top-left.

https://docs.microsoft.com/en-us/windows/desktop/direct3d9/coordinate-systems

Also note, that MacOS doesn't suffer from this quirk. The origin on Mac's is on the bottom left:
https://developer.apple.com/library/archive/documentation/General/Conceptual/Devpedia-CocoaApp/CoordinateSystem.html

I'm pretty sure the reason Unity chose Y-up is because if they didn't it would make their 2D games use an XZ coordinate system which is obviously terrible.  However that's kind of arbitrary thinking, there's no reason the camera couldn't be looking down for 2D games.

this isn't right. If you have an overhead view then X is "east/west" and Y is "north/south" which is the perfect way to do things. For side-scroller views, X is left/right and Y is up/down. These situations both work really well when you stick with X/Y being screen coordinates.

[MagmaMcFry]

Technically OpenGL and Direct3D don't enforce Y up, since you can always just switch to Z up by composing your camera matrix with a 90° rotation matrix.

[Reelya]

Well, more accurately, each piece of geometry can have it's own personal model-space where all the axes are defined however you like, but the default coordinate system for the raw camera view has Y-Up.

[MorleyDev]

Don't both DirectX and OpenGL both basically shrug and say "build your own god damn projection matrix, scrub" nowadays, anyway? I know modern OpenGL is driven by the shaders and deprecated the whole "state machine pipeline".

Been playing around with SFML again recently, since it's .NET bindings got ported to .NET Core. Playing around with building a game in F#, is interesting. Based how I handled the game state on the Redux/Elm model.

Figuring out a way to do game audio was a bit of a challenge, but I wound up building it as 'event driven' which actually I think works out pretty nice. I was able to build a 'soundtrack' system on top of it very quickly which just emits events to start songs and listens for the event emitted when the song finishes to automatically start the next song.

All in all the approach of chaining reducers and 'epics' seems like an interesting way to tackle a game. That approach is all about state management in a functional manner, and games are all about state. Whole thing is very multithreadable by 'default' too, since epics can be self-contained and run in the task pool and the state changes are just application of a sequential queue of actions to the state which produce a new state for the next action, so again can run on it's own thread.

Rendering can then be done by taking the snapshot of the state at the moment of render, and turning it into a tree of commands which is processed recursively by the rendering 'driver'. So it kicks into the renderer a data model that looks something like

Code: [Select]

[Viewport(rect 0.0 0.0 1.0 1.0, [
   Projection(rect 0.0 0.0 320.0 240.0, [
      Origin(vec2 160.0, 120.0, [
          Shader(noirify, [("colourDrain", ShaderParam.Float 0.5)], [
              BlitAt(vec2 0.0 0.0, texture)
          ])
      ])
   ])
])]


[Gentlefish]

For a real challenge, have the music crossfade when entering a new area!

[Reelya]

If doing that on Unity and you use multiple scenes, you make a music object that has "don't destroy on load" set, which is also handy for persistent data across scenes.

[MorleyDev]

For a real challenge, have the music crossfade when entering a new area!

Hmm, may try this. So to ignore some safety checks to handle something else stopping the playing song, and to assume a single playing song on a loop for simplicity, you'd probably wind up with epics structured like (pseudocode to hell):

Code: [Select]

let ModVolume musicId A =
    Interval (I)
    |> TakeFor(N<sec>)
    |> ModMusicVolume (musicId, A)

actions
|> on (FadeOutMusic musicId)
     |> ModVolume (musicId, -A)
          |> Concat(StopMusic musicId)

|> on (FadeInMusic musicId)
     |> StartMusic (musicId, Volume = 0)
     |> Concat(ModVolume +A)

on (ChangeCellMusic nextId, playingId = state..playingMusicId)
|> [FadeOutMusic playingId; FadeInMusic nextId]

Yeah, a FadeIn and FadeOut epic would be neat to see by itself. May try this for reals.

[Reelya]

Make sure the system can handle unexpectedly needing to cross-fade to a third piece of music during an existing transition. For example, if you die during a music cross-fade and it's supposed to play some death music, then if you only build a system that knows "fade old_music to new_music" then you'd have to boot out one of the currently-playing tracks, which could lead to some piece of music being noticeably cut short.

So, instead, have a stack or array of playing tracks, and you fade one in, while fading out all other things in the stack.

[MorleyDev]

Actually think that would almost just work, so long as you modify the epic to contain clauses like TakeUntil (oneof [(StopMusic musicId); (FadeOutMusic musicId)]). I left those out of the pseudocode for simplicity but they'd be pretty easy to add.

So you aren't fading from A to B, you're fading A out and fading B in at the same time. Then if you start fading B out for some reason, you just need to make sure to also stop fading B in or they'll fight.

[Kagus]

Or just play all tracks simultaneously to account for every possible situation. No fooling me!

[itisnotlogical]

In case anybody here is using Unity and didn't get the email, there's been a security issue revealed in all the latest versions of the editor. Patch available from the link. Only affects the editor, not built games.