• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

ElyasMachera

Members
  • Content count

    40
  • Joined

  • Last visited

Community Reputation

102 Neutral

About ElyasMachera

  • Rank
    Member
  1. if(timeElapsed > 16) draw() That is limiting the draw rate isn't it? But what you want is to draw as fast as possible.... You are right it may jump....that's one of the drawbacks..but I can't even get it working..well I can but there is something I don't understand about it.. From what I was told and understand I calculate elapsedTime after update and draw... But the thing is initially when I pass the timeDelta the elapsedTime would be 0.0f which is wrong So I am confused... I am reading that dewitters page again, to see if I can understand it. And btw, as a fellow beginner I am impressed how quickly you've grasped it
  2. It got too long so I will continue from here... [code] while(true) { start_time = clock() ; player->update(timeDelta) player->draw(backBuffer) ; end_time = clock() ; elapsedTime = end_time - start_time [/code] So, to calculate how much time elapsed for the next frame..the timeDelta will be position = velocity * timeDelta where timeDelta = elapsedTime/16 * 100. So If the duration was 10ms instead of 16ms it would be 10/16 * 100 ..62.5 instead of the original 100px. if the elapsed time was 16ms then 16/16 * 100...exactly 100 units...But there is a bug in the code..which I am trying to solve
  3. [quote name='arthurviolence' timestamp='1315589236' post='4859646'] (Wish I was more used with english, my brain gets a little confused trying to read and explain some things in english) [quote][color="#1C2837"][size="2"]But if [/size][/color][color="#1C2837"][size="2"]startTime = 160ms, endTime = 170ms then elapsedTime = 10ms! [/size][/color] [color="#1C2837"][size="2"]The update and draw finished quickly, and if there was no code to say sleep(6ms) the next draw will be called, and it will be [i]fast![/i][/size][/color][/quote] No, because what you will define a minimum time step in the beginning, and if the process if too fast, you will your time counter is AT LEAST higher than that minimum time step before drawing the next frame. So it will never be too fast. And if it goes too slow, you might have a problem in your logic that should be improved, or you will have todivide your update in multiple steps (think about this later, first try to implement these fixed time steps based on the actual elapsed time) I will give you a real example. In my game, I usually have 60 fps. But I dont have enough animation frames on my sprites to change them 60 times a second! So what do I do then? Well, its simple. use the same example given above. [code] float updateTime = 100f; float animationTimer = 0f; void Update() { animationTimer += TimeElapsed(); if(animationTimer >= updateTime) { Animate(); } } [/code] This will never be too fast. Its pretty simple actually, just clear your thoughts, and go over it from the beginning, because it seems like you already have your mind set into a way you think things are supposed to work (like defining how much time things are going to take, instead of defining WHEN are YOU going to do something) and thats confusing you a bit. [/quote] No problem, I also find it hard to understand people's explanation, and I [i]know [/i]English lol. But I don't understand why you say it is wrong... Using a fixed fps of 60fps so the frame [i]may[/i] draw at 16ms But it could happen that the frame finished updating the logic and drawing at just 4ms. which means the remaining time of the time slice is 12ms... So I start to update the next logic and then draw ahead of time....Which is fast? It makes sense to me.. but I don't know why you say it is wrong Since we want each frame to have a duration of 16ms the way I can control it is to spend the remaining 12ms doing something else, and when it is up continuing update and draw... So the update or game speed is [i]dependent[/i] on the fps. I thought I was making progress But this is highly efficient because I am limiting at a constant fps and I have to use sleep, better to use a dynamic fps....which I am having a bit of trouble understand. You are right.. I need to clear my head and think about it. To calculate the amount of frames to move..let me imagine a scenario where every 16ms I move the position by 100px So, position+=100 ; So I am moving 100px/16ms... I believe that is 6000px per second? Using sleep. But to get rid of it, I will have to calculate the elapsed time between update() and draw().
  4. Guys, I believe I understand...sorry for being so slow.. When we say a the game runs 60fps, it means we must draw the frame 60 times in a second. So a frame drawn to the screen - this is the part I didn't fully get - [i]has a time slice of 16ms[/i]... In other words a frame must be drawn in the time allocated which is 16ms, right? But the problem is maybe the update and draw takes too long so the the greedy frame uses more than 16ms.. So: StartTime = 160ms, endTime = 200ms, duration of update and draw is elapsedTime = 40ms. But a frame should have taken 16ms So it was 24ms overtime, which means there is now a lag yeah? And that sucks..big time....the only thing I may do is allocate a bigger frame rate, so that each frame may have sufficient time to finish update and drawing without stealing precious time from the next frame draw. But if startTime = 160ms, endTime = 170ms then elapsedTime = 10ms! The update and draw finished quickly, and if there was no code to say sleep(6ms) the next draw will be called, and it will be [i]fast![/i] The best thing then is to use a variable time step. We calculate the elapsed time the draw and update takes and use that as our speed. so if it took more time: 10/16 * 2px that is elapsedTime/frameDuration * velocity will give me the amount of units I should move the player by instead of using the speed of 2px. I think that is pretty much the idea of timing the game loop. My brain is still trying to cope with the concept, but I believe I am getting there! Please correct me if I am wrong.
  5. Hello again, I decided that the only way to understand this timing stuff..it is to try and do a simple timing implementation myself, and try to understand it. I can't grasp the logic just by reading the examples So this is what I have, and I need help understanding what is happening even if I wrote it [code] float startTimer = 0.0f ; float frameTimer = 1.0f/60 ;// 60 frames per second. while(gamerunning()) { while(startTimer < 1000) { player->update() ; startTimer+=frameTimer ; // so for every 0.016ms update the game logic.... } startTimer = 0.0f ; player->draw(backBuffer) ; //draw the new endpoint? } [/code] I recognize that even though I did startTimer < 1000, it doesn't necessarily mean that the update logic ran for 1 sec. It might run exactly second, on a higher processor finish in the 0.5secs ,or take 2 seconds on a slow processor. But in theory and for my sake, let's assume it [b]did [/b]run for 1sec. When I ran it, it actually drew reasonably well...I thought it was going to be choppy, since I was calling update 60 times and drawing once. I don't know why it drew reasonably well. if the initial position X is at 0 and I kept pressing right..until the loop ended, it didn't end up at the other end of the screen or outside the screen window..can someone please explain why?
  6. [quote name='Infernal-rk' timestamp='1315520974' post='4859252'] Your understanding is that the game logic updates and screen renderings are done together at the same rate. Correct? This is where you are getting mixed up. At one time this may have been the norm, but now, people usually decouple the game updating from the game rendering. Why? because your game will render at different speeds at different resolutions and on different hardware. You do not want this render time difference affecting the game updates. This goes back to using a fixed timestep vs realtime timestep. With a fixed timestep, objects will move slower on a slower rendering machine, on a faster rendering machine, they will move way too fast because in the fixed timestep situation you assume a given amount of time will pass to render and calculate and you specify this value. If in reality it takes less time, it renders and calculates too fast and the whole game speeds up. You can witness this in very old DOS games run on any newer processor. They run way too fast because of the fixed timesteps they use which were tuned to run on 66MHz machines. today, we use realtime timesteps. Now you have to balance simulation accuracy (HIGH Game update FPS required) vs rendering detail/quality (HIGH render/display FPS required) the typical balance is to minimize the complex physics math in the game update to 30-60fps and use the rest of the time to render the scene as fast as possible (older games like quake3 now render at 200+fps, but only update game logic at the most at 60fps) That's why the game_update() and game_display() in newer games are decoupled in their calling times. Your realtime timestep is counted.. when enough milliseconds have elapsed since the last game_update() you call game_update(). in some situations where you can spend too much time rendering frames at maximum speed, you may throttle the rendering with an accumulator to call the rendering less often. Hope this helps. [/quote] Thanks, that was somewhat helpful, that was my thought. I will try and reread some of the logic and see if I can make sense of it. If not, I will repost on this, maybe you guys can walk me through it. Thanks a lot guys.
  7. Lol, I know I can add a if man, but I don't want it now..not yet. I just want to understand the basics, before I can grasp the timing logic. Let's imagine, theoretically 2 computers a dell dimension 2400 and Sony Vaio the 2400 can compute a pathfinding algorithm in 6secs, while the Vaio half the time. The 2400 runs the while loop, that contains the update(exec pathFinding) 400times per sec, but Vaio can do it 1000times per sec. So for the 2400 doesn't it mean, that the update() and draw() is called 400times? Which means the fps and game speed is 400? FPS is definitely 400! But why is the update not 400? But the Vaio runs the loop 1000, so 1000fps and game speed is also 1000? If this logic is flawed can you please correct me, if possible not with code. Remember 2yr old
  8. Hello again, I still don't understand it..I actually when to sleep in depression. The deWitter one, [url="http://www.koonsolo.com/news/dewitters-gameloop/"]http://www.koonsolo....tters-gameloop/[/url], was kind of OK to follow but he lost me here: I quote [font="Verdana,"][b]"FPS [/b][b]FPS is an abbreviation for Frames Per Second. In the context of the above implementation, it is the number of times display_game() is called per second. [/b][b]Game Speed [/b][b]Game Speed is the number of times the game state gets updated per second, or in other words, the number of times update_game() is called per second."[/b] How is it that game speed, the number of times updage_game() is not the same as the amount of times display_game() is called? It doesn't make sense to me. If draw() or display_game() is called 60times per second (60fps) It should mean the calculations (the logic?) is also called 60 times per second? You can't skip one and call the other right? Can someone explain this, before I post my other questions. Thanks[/font]
  9. Thanks guys, I will read the stuff on the links provided, if I am still confounded I will be back. Thanks again .
  10. Can someone please explain the concept of a game loop to me? I am really slow on this kind of stuff. I am really trying to understand the concepts of game update and draw. And frames per second. A frame is like a picture yeah? So if I flip through many frames I can get something like an animation. I think the recommended is 60fps? Right now, all I have is [code] while(!keypressed) { input draw clearsprite } [/code] So anytime the loop is run input is required, then the changes - if any - are applied to the game objects, maybe they changed position screen. The backbuffer is cleared to reflect later change of positions or whatever. But the thing is..what is the number of frames in this case? I haven't set any number..so I assume the number of frames is how fast the while loop can run depending on the computer? If I was to introduce the concept of frames per second how would I do it? I can't find tutorials on this. I am using C++ thanks. NB: Can you please make explanations simple. Think of it like explaining to a 2 year old .
  11. New as well..found as a way to solve it: [url="http://pastebin.com/wMSHxpxW"]http://pastebin.com/wMSHxpxW[/url] position relative was the trick Your code works well nice
  12. I have an idea how to solve problem It IS because the animation hasn't completed..hence I am moving the div too early. I just don't know how to tell the jquery to finish the animation before doing the what mouseover wants. so maybe something [code] if(animationready) do reshrink [/code]
  13. Hello, I just started learning jquery and this problem baffles me I have divs in a container and when the mouse is over them it resizes the div and shifts the divs in front by a certain offset. on mouseout it shifts the div by subtracting from that offset. This is the code if you are kind enough to look at it: [code] <html> <head> <script src="http://code.jquery.com/jquery-latest.js"></script> <script language="JavaScript1.2"> function resize(obj) { shift(parseInt(obj.id[obj.id.length-1])); $("#"+obj.id).height("100px").width("100px") ; } function shift(id) { for(var i=id+1;i<=4;i++) { $("#hello"+i).stop().animate({"left":"+=60px"},1000) ; } } function shrink(obj) { $("#"+obj.id).height("64px").width("48px") ; reshrink(parseInt(obj.id[obj.id.length-1])); } function reshrink(id) { document.getElementById('testvalue').innerHTML+=document.getElementById("hello2").style.left ; for(var i=id+1;i<=4;i++) { $("#hello"+i).stop().animate({"left":"-=60px"},1000) ; } document.getElementById('testvalue').innerHTML+=document.getElementById("hello2").style.left ; } </script> </head> <body> <h1>Hello World!</h1> <div id="formWrapper" style="height:180;width:530;"> <div id="wrapper" style="position:relative;bottom:20px;width:460px;left:40px;height:160px;background-color:green;overflow:auto;" "> <div id="hello1" style="position:absolute;left:0px;height:64px;bottom:0px;width:48px; background-color:black;color:white;" onmouseover="resize(this);" onmouseout="shrink(this)"></div> <div id="hello2" style="position:absolute;left:49px;bottom:0px;height:64px;width:48px; background-color:maroon;color:white;" onmouseover="resize(this);" onmouseout="shrink(this)"></div> <div id="hello3" style="position:absolute;left:98px;bottom:0px;height:64px;width:48px; background-color:brown;color:white;" onmouseover="resize(this);" onmouseout="shrink(this)"></div> <div id="hello4" style="position:absolute;left:147px;bottom:0px;height:64px;width:48px; background-color:white;color:white;" onmouseover="resize(this);" onmouseout="shrink(this)"></div> </div> </div> <div id="testvalue" style="position:absolute;top:390px;background-color:yellow;height:100px;width:400px;"> </div> </body> </html> [/code] It is quite simple really, nothing too complicated in it.. What I found is that when the mouseover and out is rapid or maybe the animation isn't complete..the divs change more than the offset and eventually it overlaps! :'( Can someone please suggest how to solve this problem? And thanks . EDIT: To test rapidly move mouse over the first div..
  14. [quote name='jbadams' timestamp='1310805023' post='4835923']Perhaps you could link what you found in case others have the same question and stumble on to your topic in future? If you've managed to answer your own question, it's good etiquette to reply letting others know what the answer is rather than simply editing away the original question to say you've found an answer. Out of interest, the IMDB API you managed to find wasn't [url="http://www.deanclatworthy.com/imdb/"]this one[/url] -- the first result of a [url="http://www.google.com.au/search?q=imdb+api"]Google search for "IMDB API[/url]" by any chance? [/quote] mmn..sorry. I did find that one..but its request is limited. [url="http://imdbapi.com/"]http://imdbapi.com/[/url] I found that but the result is always an Uncaught exception, I think it is because of same origin policy - maybe someone else can make it work. So I ended up using open graph, [url="http://ogp.me/"]http://ogp.me/[/url] I used one of the libraries in the Implementation section.
  15. 24 views..never mind found an api