“Input.pressed & Input.released & Input.mousePressed & Input.mouseReleased”
anyone of this “one frame” control conditions are not working in “render():” function of entities?
No problem about “Input.check or mouseUp, mouseDown” stuff… they works… but one frame checks doesn’t working, probably that’s a framemissing issue or is that something made intentionally?
I’m not sure if its correct, but I suggest putting it in the update function instead.
Yeah, that’s not a big deal… I mean, if that’s something made intentionally, input.check, mouseUp, mouseDown too shouldn’t work in render function, but they are working… I’ve tried overriding it in world class’s render function just now, same result…
It’s probably to do with when the render() function is called. I wouldn’t class this a bug because it’s a very very poor design choice to have game logic in the render loop anyway (especially since rendering calls depend heavily on timestep logic - you might get 3-4 updates before there is a render call if your game is lagging in fixed timestep mode for example).
yeah, it’s lagging in fixed timestep mode.
so, actually, game logic aren’t in render loop, actually thats render logic, yeah 
i’ve a render logic, and if i have a required algorithm condition in render logic then why i should copy paste the same logic to update function only for checking a little key… (yeah, that’s only for a little key, no more…)
Checking for input is game logic 
The only things that should be done in render is stuff that directly pertains to drawing; a good example is this other post; in this case it’s ok to put the solution in render() because keeping the character’s gun in sync with the body position is just a cosmetic (rendering) thing.
Keeping rendering and game logic separate is good practice for a multitude of reasons but generally the most obvious is for the timing I mentioned above; most games split their game update and game render so that they can render as much as possible without lagging and still maintain a steady update cycle (for physics etc). If you mix up rendering and update logic then it becomes a lot harder to have consistent and stable timing.
Other reasons for keeping rendering logic separate include code readability (it’s easier to figure out where a particular piece of code might be happening if all your game logic is in update and all your drawing is in render, and not mixed up), code portability (consider that you might want to port your game to a different engine such as starling; if only your rendering code is in the render stuff then that’s all you need to replace. The game logic, update stuff, stays the same), and ‘separation of concerns’.
That last one covers a lot of ground but broadly speaking it’s useful for cases where, for example, you want to switch out the graphics of your game and have your player look different but behave the same. It’s way easier to do this if the drawing-related code is the only thing in your render loop. Of course, thanks to FlashPunk we can just switch the spritemaps around, but it’s good practice to get into a habit of learning good coding practices all the same. In general when programming, you want each and every class (and further, each and every function) to do a minimum of work. You want to ‘separate concerns’ across lots of classes and functions so that you can easily switch out and test individual classes or functions. Learning where to draw the line and stop is something that comes from experience, but keeping update and render logic is one of the most fundamental cases (and as such is even important when using a library such as FlashPunk!).
If you have a required algorithm condition in your render code (note that there shouldn’t be any ‘logic’ in there, only drawing) you should refactor to handle the logic in your update (eg check for key down), store the result in a variable an use the variable in your render to draw the appropriate representation. Never have logic in your render code!
If you want to learn more about good coding practice, separation of concerns and code architecture then have a google for stuff like ‘model view controller pattern’, ‘class encapsulation’, and ‘programming design patterns’.
That’s so enlightening ^,^
I’m trying to follow “class encapsulation” thing, and trying to learn design patterns…
But the main problem in here, i’ve started coding in real! with flashpunk, i wasn’t know anything about as3, and i was forgot everything(not so much thing) about as2…
I’ve started to this game and god damn i’ve remake it 3 times like FEZ because of i’ve learnt much things and i just wanted to make my code understandable according to things i’ve learnt.
So, after this time, i’m bored remaking the same game again and again i just wanna finish this then start a new project with my new knowledge
thank you very much for your long reply love you <3
Definitely know that feeling! My first major project was a shooter on the gameboy advance. I was working on it for around 5 years and it went through various iterations before it was eventually shelved!
This stuff takes a LONG time and many hours of work to learn, and the best way to do it is to accept what you have for each project and just improve a little bit at a time where you can, then in your next project try to take it a step up from before. Before you know it, it’ll be second nature to think that way!
Also! Trying to make your code understandable (actually not understandable, i mean, “controllable” or “improvable” or just watch this video)… is something really satisfacting…
This topic was automatically closed after 3 days. New replies are no longer allowed.