Jump to content

  • Log In with Google      Sign In   
  • Create Account

jwezorek

Member Since 10 Nov 2009
Offline Last Active Today, 09:24 AM

Posts I've Made

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.


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

04 August 2016 - 10:41 AM

RE: Unity, maybe you are rigth.

 

For me it's basically just a matter of preference.I write C# all day at work so like to do C++ on the side, but to be honest I don't know a lot about Unity,

 

Is Unity totally free?


PARTNERS