Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 10 Nov 2009
Offline Last Active Yesterday, 05:15 AM

Posts I've Made

In Topic: Why C# all of a sudden?

21 September 2016 - 12:05 AM

Java was popular -- its popularity is for example why Javascript is called "Javascript" even though the two have absolutely nothing to do with each other. Get in a time machine and go back to the late 1990s and see for yourself. People couldn't shut up about Java. Mainly what  happened with Java is that client side Java failed. Client side Java failed because 

  1. applets failed. Poor design plus HTML/CSS + browsers werent where they needed to be. Java applets should've had access to the DOM which would have allowed Java to be what Javascript ended up being.
  2. AWT sucked.
  3. Swing sucked.

Thus Java for desktop applications and Java in browsers both failed despite Java's enormous popularity. This opened a door for C# which was a better language and WinForms and later WPF were both much better than the early Java gui frameworks. Given the defacto death of MFC with Microsoft not introducing a new native framework they were the only option for writing Windows applications besides 3rd party cross-platform C++ frameworks like Qt, but were also considerably simpler and easier to learn than Qt and in the case of WinForms, were both simpler than Qt and leveraged one's knowledge of Win32 C programming i.e. if you cant do something in WinForms you can always invoke native calls if it comes down to it. This all led to tools for games, which are GUi applications, getting written in C#. And tools probably led to Unity and other engines being written in C# -- which was possible given C#'s speed.


C# really is a better language than Java by the way. It isn't just little things. It's implementation of generics is better in a major way and LinQ is great. LinQ is a great achievement across software engineering, period.

In Topic: Game Timer / Game Clock

05 August 2016 - 09:48 AM

In the code you pasted I can't see where you calculate the floating point value for elapsed time that you pass to setPlayerTimeBasedVelocity().

I think you might be doing too much integer math, like not converting to floats early enough. For example, in your routine CalculateElapsedTimeMS() you are using a high precision timer but then convert to milliseconds at the end with an integer divide by a million, which will throw away any extra precision you were getting from System.nanoTime. Try making that routine return a double and do all your time and velocity math as floating point values everywhere.

In Topic: A Lightweight 2D Game Framework Doesn't Seem To Exist

05 August 2016 - 09:22 AM

Re: Corona, Godot, GameMaker
I think there is some confusion on what "lightweight" means in this context. It means that when you use the engine there isn't a lot of 3rd party code between you and just painting on the screen. It means that the "game framework" is close to just being a library. It is not a synonym for "simple" or "easy".
GameMaker, Love, Corona, and Godot(*) are not lightweight. They are ultra heavyweight. In each of these you are far away from the actual game loop. The actual game loop was written by the framework makers in C++ and compiled into an executable. Your game is a script plus your assets that is bundled with that exectuable, and loaded and run by that executable. In Love and Corona the script is in Lua, I believe. GameMaker and Godot use there own scripting languages.
There is a lot to be said for this approach. For example, you get the most painless cross-platform experience imaginable because the onus was mostly on the framework vendor to get cross-platform right when they wrote their executable and presumably they did a good job or you wouldnt be using their framework. Another plus is that it makes GUI game editors not only possible but easier for the framework vendors to implement than an equivalent editor would be for a lighter weight framework. So you get good GUI editors and the game making workflow becomes more visual in nature if you want it to be, which opens up the creation of simple games to people from non-programming backgrounds e.g. artists. 
The down side to this approach is that the you lose the freedom you get from a C++ compiler. A library gets to be heavyweight by guessing what it is you are going to want to do and implementing it for you. In the case of game engines a common thing to assume is the genre of games you will want to create -- for 2D games these frameworks are designed to create scrolling platformers. If you want to create a game that is unusual that doesn't conform to genre conventions it may be difficult or impossible. This is often the case with the little games I like to make. 
My current game for example involves translating tesselated shapes along the curves of a double logarithmic spiral. Could I do this in Corona? Probably, as long as Lua has all the standard higher mathematics functions, but doing so will be a pain in the ass because Corona's makers probably didn't think that users would want to interpolate affine transformations that are going to be applied to game sprites so there isn't going to be an interpolate affine transformation call in Corona Lua and there isn't going to be a "create double logarithmic spiral" call and so on. 
(*) - Godot actually looks like it also exposes a C++ version of the framework. Did not know this. I will have to look into Godot C++.

In Topic: A Lightweight 2D Game Framework Doesn't Seem To Exist

04 August 2016 - 12:15 PM

RE: The question is though, since this would seem to be more of your target audience for such a library, why would we rather use your lib than something like sdl or sfml?


I would write my thing on top of SFML if I did it.


SDL and SFML are hardware abstraction layers which is one part of what I want. The other part is basically an implementation of sprites:

  • a sprite can be created from a sprite atlas texture or a standlone texture/image
  • it can be displayed or not displayed by inserting or removing it from a hierarchical tree of nodes that the game loop knows about
  • it can contain other sprites as chidlren
  • it has an alpha value, a rotation, a position and a scale
  • its properites are relative to its parent's properties in the sprite tree stage thingy.

SDL/SFML/Allegro do not implement (all of) the above and SDL doesnt support subpixel placement of images without doing it yourself via OpenGL calls. An implementation of the above is a minimal 2D game framework ( along with background images, some kind of game scene or game phase abstraction and hardware abstraction of sound, music, and user input.)

In Topic: A Lightweight 2D Game Framework Doesn't Seem To Exist

04 August 2016 - 11:40 AM

My problem with Cocos2d-x is philoshophical and religious. I don't want to support it again because it makes my eyes bleed.


I actually think I'm just going to take Kylotan's advice and try Unity. Basically I never considered Unity because (1) I like C++ and (2) didnt realize Unity was totally free if you make less than $100k. I thought you had to pay $500 for some reason. The nice thing is my prototype is already written to monogame so I'll be able to reuse a lot of that code. I mean, to be honest, I  don't like the the idea of having to have a "powered by Unity" splash screen or whatever but it isnt the end of the world.