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.
jwezorekMember Since 10 Nov 2009
Offline Last Active Yesterday, 06:03 PM
- Group Crossbones+
- Active Posts 929
- Profile Views 16,228
- Submitted Links 0
- Member Title Crossbones
- Age 44 years old
- Birthday July 21, 1972
- Website URL http://www.jwezorek.com
Posted by jwezorek on 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().
Posted by jwezorek on 05 August 2016 - 09:22 AM
Posted by jwezorek on 17 July 2015 - 09:39 AM
Dude, I am going to give you some very general advice that is nonetheless true: Shit like this never leads to you making money. Don't even start in on it. It is a waste of everyone's time, especially yours.
Just tell the guy or your brother or whoever that if they want custom software on an iPad then you need a Mac mini, an iPad Mini, and an Apple developer account, period. Don't screw around with web apps; everyone is just throwing that around because it sounds cheaper than a real custom application but it is the same amount of work and is not what they actually want.
They need to pay for this stuff for you, if they are not willing to invest even that little bit into this project then they are not serious about it.
Posted by jwezorek on 01 June 2015 - 06:02 PM
To the extent that design patterns are ever useful at all, they are useful when talking about code. They give you a common vocabulary that you can expect other programmers to know covering many technical abstractions that had no official names before patterns came to prominence. In other words, when used correctly the notion of design patterns is about terminology.
But terminology is only useful if it is providing greater specificity than ordinary language more succinctly. Design patterns often don't do this. It's succinct to call some class X an adaptor, say, but you are not really saying anything. It is less succinct to say that "Class X wraps the old library and exposes the interface that the new version of the software expects" but at least that is actually saying something about class X. In other words, if you say, "Class X is an adaptor that wraps ... blah blah blah" what exactly is the word "adaptor" actually adding?
Also the whole subject seems a little confused in that in some cases patterns are sort of common themes in how algorithms interact with data structures (e.g. the visitor); in other cases they seem to be the data structures themselves (e.g. the composite), and in other cases they seem to be styles of programming (e.g. wikipedia lists RAII as a design pattern. Is RAII even meaningful in languages besides C++?)
Posted by jwezorek on 01 June 2015 - 12:26 PM
Don't worry about design patterns and certainly don't worry about whether you are using one "correctly". Design patterns are an ill-defined topic that don't add much beyond some terminology that is occasionally useful when talking about code.
If having a class do conversion between units polymorphically helps you then do it. If it adds too much complexity then don't do it. Call it an "adapter" if you want to, or don't -- that is all "patterns" are adding.
Honestly I don't understand why "design patterns" haven't gone away already as a thing. Why are young people so interested in them?
Posted by jwezorek on 19 May 2015 - 11:53 AM
I like QtCreator and it is what I would recommend for general cross-platform if you want to use an IDE or if you are developing to Qt specifically, of course. Beyond that I still see no reason to not use Visual Studio Community Edition unless maybe you are already familiar with QtCreator for some reason but are not familiar with VS.
Posted by jwezorek on 25 November 2014 - 04:35 PM
I used it in cocos (long ago) because I didnt find any other means to control the stuff (like animations) tightly.
I hated it, it requires a bunch of loading code to prepare the actions, and when you need to interrupt it, cancel in the middle or something, it gets even more ugly. ( I dont remember very well thou)
Yeah the trouble with the actions thing that I see is the following:
- You often need something to happen that is "an action" in a general sense but that doesn't map cleanly to a particular sprite. It needs to happen to a bunch of sprites. It needs some state to be preserved across modifications to the sprites but not across iterations of the game loop. It is something that just naturally wants to be applied to some sprites in a loop rather than to be called by each sprite.
- You need to perform an action on a sprite that will take a long time (in game programming terms) to complete and probably will be cancelled, interrupted, or otherwise transformed before it completes.
Now obviously both 1. and 2. can be done with actions but would you choose to do either this way, all things be equal, if a framework wasn't demanding that you have to? And further, I would say that most "actions" in the games that I write are like 1. or 2. The exceptions would be very simple cosmetic things such as this guy is taking damage so make him glow red or whatever, but very simple cosmetic things are the exception not the rule...
In cocos2d-x I was able to get out of the whole action thing by just scheduling an update event on the layer and then treating that like the update in a game loop. I wrote an entire game to cocos2d-x and didn't use actions at all. Basically I used cocos2d-x for the node tree, input, and sound and that was the extent to which I used the framework. I believe it will be possible to do the same thing with Sprite Kit ... I am just posting here to see if I am being stupid. I don't want to be some dude who insists on doing everything the way I have always done it, but it just looks like to me that using the actions system is going to make my code worse.
Posted by jwezorek on 25 November 2014 - 11:21 AM
When implementing 2D games to somewhat heavy-weight 2D frameworks like Sprite Kit or Cocos2D, do you use the action system for everything or do you prefer a traditional game loop?
I'm currently working in Swift + Sprite Kit which is new for me. I find myself searching for documentation or sample code that implements a standard
style game loop, but then I think maybe I am just being old-fashioned and instead I should try to embrace the actions system. My problem is that the game I am working on doesn't seem like it wants to be implemented in terms of actions, but it could just be me.
As a little background, basically these frameworks are kind of new in the grand scheme of things, meaning before the mobile era the only "framework" most people would consider for a 2D game would be something like SDL. SDL isnt so much a framework as a hardware abstraction layer so this question wasn't really an issue. I'm just wondering what other people do besides me -- particularly people who didn't grow up writing 2D games without any kind of framework.
Posted by jwezorek on 20 August 2014 - 10:38 AM
Am I the only one that thinks that all those new features makes C++11 look and feel completely different than C++?
Seriously, that's practicality a different language, why keep calling it C++?
I actually feel the opposite.
Before C++11 there was all this cool stuff you could get by #including <algorithm> that was impossible to use without
- sprinkling, often one line, free or static functions, all over the place that either use global state or use no state.
- use std algorithms with state using boost::function and boost::bind
- sprinkling weird little functor classes all over the place.
- use std algorithms with state using a local anonymous struct as a functor (even though this wasn't strictly speaking legal C++ VS would let you do it)
Now you just use lambdas and std::functions. What I am saying is that once <algorithm> was part of the standard library then you pretty much had to have lambdas or an equivalent., so if you are saying the lambdas don't feel like C++ then a lot of the standard library must not feel like C++ either.
Posted by jwezorek on 19 August 2014 - 11:39 AM
Take 'auto' for example - it's great when used with caution (and very very sparsely). But I saw some programmers who just decided that it would be great to use it as much as possible (even a very experienced one), regardless of minor things like code readability and type safety.
Using "auto" may or may not lead to less readable code (I actually don't think this is true but whatever) but it does not lead to type unsafe code, at least for any reasonable definition of "type safety". The whole point of "auto" is that it is type safe.
C++ is a statically typed language. It doesn't suddenly stop being statically typed because they added a mechanism to make the compiler deduce types for you.
Posted by jwezorek on 11 August 2014 - 05:19 PM
Neither is really correct but 2 is closer to correct; 1 sounds more like a C-style macro.
Basically you can think of templates as type-safe macros. This is not altogether accurate but is a good first approximation.
In other words both macros and templates cause code to get generated. The compiler will do some work for you filling in what you mean. However, in the case macros the way that the preprocessor does this code generation is completely braindead: it doesn't know anything about the types involved it just pastes the arguments into the macro and if what comes out is garbage then so be it.
In the case of templates the compiler is checking types while it is doing the code generation.
Posted by jwezorek on 07 August 2014 - 03:08 PM
Some thoughts... (and a description of the Infocom interface for younger readers)
I've been thinking about this for a couple of days and I think the key thing that you would have to do to make a graphical game like this would be get rid of all the guessing. In a graphical game what can be done needs to be explicit.
When you strip away the hype of natural language processing, the Infocom interface was basically the following:
- Nouns were marked by the game. (You enter a room once and get the elaborate description, you then start getting the abbreviated description which was a list of the nouns in the room, some of which you could take and some of which were fixed to the room, but all could serve as objects in commands while in the room)
- There was a list of common verbs that you knew you could use: get, move, pull, push, insert, give, tie, untie, open, close, cut, destroy, burn and a few more. This list was augmented by a few unknown verbs that were game dependent.
- The verbs in 2. could take direct objects as well as indirect objects where applicable. Indirect objects could be entered either as proper indirect objects or via a prepositional phrase e.g. "Give the Chistmas tree monster the coconut" or "Give the coconut to the Christmas tree monster" respectively.
- Prepositional phrases worked for modifying some objects if, I think, the object exposed a property for a slot associated with the preposition -- I'm guessing this is how it worked internally anyway; for example in The Hitchhiker's Guide to Galaxy pretty much the whole solution to the Babel Fish puzzle involved prepositional phrases and the object model they induced "Hang dressing gown on hook (so the "hook" has an "on" slot). Cover grating with towel (the grating also has an "on" slot which <cover> <with> knows to map to). Place satchel near door. Place junk mail on satchel.
- There were places in which you could issue commands in the same form to other agents e.g. "Robot, give the coconut to the Christmas tree monster"
On 1. and 2, I would definitely consider any guessing of words required to be a negative thing. It was mitigated by the fact that after you played a few of these games you pretty much knew which verbs you could expect and relying on the need for a magical verb to solve a puzzle was considered bad form (although it happened. the life raft in Zork I was like this: you had to guess that a pile of plastic was "inflate"-able)
so 1. you could do in graphics in some way. 2. you could also do by way of limiting the list to very few and having some kind of uniform mechanism for engaging one of them -- something that isn't a menu though, I find the menus I've seen ugly, but also more that just an "action" button. Don't know exactly how I will do it but this seems solvable.
It's 3. and 4. where there really seems to be room for innovation. I think that there would need to be a visual language for the slots bound to objects that I am assuming exist invisibly to the user in infocom games. In infocom games you had to guess what you could do to and with an object. In the interface I am envisioning I think you would need to make what you can do to an object explicite via some mechanism.
(and 5. couldn't be done without text ... although in a 3rd person game essentially your avatar is just a special object you are interacting with that follows the commands you are entering in some way so in theory you could have more than one)
Posted by jwezorek on 07 August 2014 - 10:49 AM
Posted by jwezorek on 04 August 2014 - 09:39 AM
It's a little hard to answer without you being more specific about which computational geometry algorithms you need to use. It is a big subject.
Saying that you need to "tackle computational geometry" is a bit like saying you need to tackle graphics, or tackle game design, or something equally broad. I mean, it can be as easy or as hard as you want it to be depending on the requirements of what you want to do i.e. tackling graphics for a Tetris clone is different than tackling graphics for a AAA console game.
But even the above is not really a good analogy because videogames need graphics by definition, videogames do not need computational geometry by definition -- even procedurally generated space shooters. So what computational geometry do you need and why do you need it? Because basically you want to not to have to use a heavy-weight library like CGAL; something like that should be a last resort.
Anyway, yeah, I've used CGAL in the past. I did some work with the triangulation routines. It is a solid library. One thing to note is that it is not permissively licensed. CGAL is GPLed I believe with a dual proprietary license for commercial use. I don't know anything about Wykobi... (thanks for mentioning it actually...)
Posted by jwezorek on 01 August 2014 - 10:58 AM
Hi Chris, can't do that since I need to compile on XCode too...
Xcode has supported lambdas since about version 4.5, see here. However, I believe these and other C++11 features are still not enabled by default -- at least they didn't used to be.
Go to build settings and look for an item called "C++ Language Dialect". You need to select C++11 or greater.