Jump to content

  • Log In with Google      Sign In   
  • Create Account

jwezorek

Member Since 10 Nov 2009
Offline Last Active Dec 19 2014 11:46 AM

Posts I've Made

In Topic: Which parameter of CreateWindowEx() is incorrect in my code?

02 December 2014 - 12:20 PM

HWND_DESKTOP.

 

You are probably msitakenly making what is called an "owned window" but passing garbage as the parent window's  HWND. Set that parameter to NULL to make an unowned toplevel window otherwise set it to a valid window handle. 

 

Oh, yeah, SmkViper is right...


In Topic: The "action" systems that 2D game frameworks all now have...

26 November 2014 - 10:27 AM


Apple actually mentions in some of the documentation that this is the recomended way of doing things and that Actions should only be used for one time canned effects or UI animation

 

This answers my question. 

 

I know that it must be possible to not use actions to drive a game codebase's architecture in Sprite Kit because, as I said upthread, I have done exactly this in cocos2d-x and Sprite Kit seems to borrow a lot from cocos2d. Actually that is an understaement: Sprite Kit seems to be basically a version of cocos2d, Apple's version.

 

My question was, do other people who have written nontrivial games to Sprite Kit or cocos2d-iPhone or cocos2d-x and have them in the App Store etc. do this too? Or do people use actions extensively? -- unlike the way that I do it.

 

If Apple really mentions in the documentation that you should use a scene object's update method for most game logic then that answers my question. Do you have a link to this?


In Topic: The "action" systems that 2D game frameworks all now have...

25 November 2014 - 05:45 PM


That's an inefficient and inflexible way to handle game updates. Even back in the simpler days, that kind of update loop only took you so far before you started needing piles of hacks to get all the different things to update in the right order.

 

I don't know anything about fancy 3D engines but 2D games indeed commonly have a method that gets called with a time delta on some game stage object or whatever that then updates the state of in-play sprites and what-nots with the time delta and then draws them. Are you seriously saying that that is not common? 

 

Don't know if mobile frameworks are not calling the update method in a simple loop in their implementations but whatever they are doing amounts to a loop.


In Topic: The "action" systems that 2D game frameworks all now have...

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:

  1. 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.
  2. 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.


In Topic: How stable is Swift + Sprite Kit as a framework for building a 2D iOS game?

22 October 2014 - 03:59 PM

Serapth, do you know how much Swift has changed since you wrote your tutorial? (I'm looking for a Swift + Sprite Kit tutorial...)


PARTNERS