• 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.

VanillaSnake21

Members
  • Content count

    797
  • Joined

  • Last visited

Community Reputation

174 Neutral

About VanillaSnake21

  • Rank
    Advanced Member

Personal Information

  • Location
    Brooklyn, New York
  1. I don't need real-time rendering, I should have mentioned it initially, I need smooth animations, real time rendering is obviously not happening with 120 ms cycle. I don't think this is something unusual. I need for example a graphic to play in the top right corner on game load, something like a snake eating it's tail. I don't have to render it out in realtime, just render it at game load and then playback at any fps when needed. What my mistake was is that I was in fact trying to render in real time by using time delta. 
  2.   The conceptual process looks like this  while(!done) { CurrentTime = GetTheCurrentTime(); ElapsedTime = CurrentTime - PreviousTime; PreviousTime = CurrentTime; Update(ElapsedTime); Render(ElapsedTime); } You get the current time at the top of the loop, subtract it from whatever the time was at the top of the last iteration of the loop. That's your elapsed time. You're measure the time it took to go from the top of the loop, through all the instructions in the body, and get back to the top. There's no need to concern yourself with trivial details like the cycle count of a jump instruction.       This sounds like a problem that you should fix. Updating animations (and game logic) via delta time is correct. But using a fixed timestep to do that is not going to solve the problem where it takes too long to render. What makes your game run like a slideshow is the fact that it takes 120ms to render stuff. That's like... 8 frames per second. If you subtract out the time spent rendering, your animations will make smaller adjustments between any two presented frames. But they will still only render at 8 FPS, and when you eventually fix the renderer or switch to a real one, all of your assumed times will be wrong.     I understand the loop, the way I had it didn't include the Update and Render functions on purpose because I thought that it wasn't what I needed. I was in a way right because in my case I don't really need Render and Update timing. What I was asking is why can't I see the delta of the jump instruction reflected by QPC. But in any case it's not important I suppose.     <But they will still only render at 8 FPS> No, they will render at whatever fps I instruct. 8 FPS would be realtime render, the buffered animation can be played at any fps (up to capture limit) after the fact.   Edit: I mean playback, playback at any fps I need.
  3. So in other words you're saying it may help but it's not an ideal way? So what do you suggest I do then if not this?
  4. My animations are based on delta time, akin to this <scalar*dir.x*delta_time, .scalar*dir.y*delta_time> so because my render function takes more time than acceptable refresh it completely destroys the look of the animation. What I think I have to do is to untie my anims from realtime (timedelta). But you're saying fixed timestep is not the way to go? So what should I do?   Edit: but is there really no way to avoid including my raster function in time loop? I don't even understand how a high rez timer timer does capture the time to get from bottom of loop to top, you're saying that the jmp instruction is taking less that one tick? And QPC can see 1 clock tick right?
  5. But this will completely destroy my animations then. By the time I finish rendering the elapsed time delta will be so huge that it's just going to be like watching bad stop motion anim. I guess I'm using the wrong approach to begin with. I need to cancel out the render time delta right, so just using a fixed time step would do it?
  6. No I'm doing software rasterizing, GPU is only involved in backbone. My code had the SetLastTIme at end of one of the branches of the loop, not at the end of the loop that is why I assumed that it won't always be circular. But again why am I timing my raster function and including that into delta time? The raster operations take about 120ms, so my delta time gets bloated out of control. I always though that the point was to only time the time between the calls to raster function, not raster call function timing in itself.
  7.   Wait a second I'm a bit confused, the code you have times the DoLotsOfWork function, not the elapsed time between the call of the function. I thought the point was to to see how much time has passed since last draw call, otherwise I'm just timing how long my raster operations take. And I am casting numerator to float first, I think the first sample code was incorrect. I reposted the right one later.   Edit: Also that's just one branch of the while loop there is another branch with message handling, so that's why I assumed that even though the call to SetLastTime was at the end of the while loop it's not a fact that it's going to hit the top of the loop right after, maybe windows will switch something internally or the window handles messages, that's what I was timing. But the code you have doesn't time any of that, why?
  8. That's worst case, you could also gain 1.8 seconds, or be lucky and have all the errors balance. The 0ms delta shows the worst case scenaro. If your game is running at 1000fps, your delta will always be 0ms, so no matter how much real world time passes, no in-game time will ever pass. The effect is similar at other fps rates. At one fps the errors will be more likely to be +0.5ms, and at a different fps they errors will be more likely to be -0.5ms. The chance of the errors cancelling out perfectly is slim (and based on chance). If you care about keeping real world time (many games don't have to!) then millisecond accurate timing is not a valid option.     Yep. This won't keep accurate time - it will likely be out by a few seconds after a while, but the bigger your 'limit' value, the more accurate it will be. Again though, QPC does work. Everyone uses it. Most people use it without any special threaded magic. If it's not working for you then there's probably a bug in your game loop.   I've got my loop posted here, I'm not really sure where there could be a bug. I get the delta before the Update and set the last time after the update.    Edit: OK so this is just out of curiosity, this is the structure of my framework WindowsMain->GameEngineUpdate()->ApplicationUpdate()->QueryPerformanceCounter(). So if I do this then the QPC is nonzero and everything is fine. But I don't want to have each app track it's own time and would like to have the the engine handle it. But when I do this WindowsMain->GameEngineUpdate()->QueryPerformanceCounter() then ApplicationUpdate() I again get QPC of zero. It seems like the QPC calls have to be in the same compiled code object, probably because of the issues mentioned earlier. If you still insist it works and I'm just doing it wrong perhaps a little example of the proper way that you use in your engine could help? 
  9. No, you don't need to do anything like that. QPC does just work without any need for dedicated threads, etc... You have a bug in your game loop somewhere. That would be expected if your game is running at 1000fps, or 60fps without you calling timeBeginPeriod(1). If you're measuing deltas and accumulating them, then think of 1ms resolution meaning that you can lose around 0.5ms worth of real time per frame. So a 60Hz game loop is potentially losing 1.8 seconds of real time per minute, or potentially losing over a minute of real time per hour. I would not buy an alarm clock with that kind of time-keeping ability.    But I can also gain 0.5ms, I'd lose 1.8 seconds if it just happens that on every call to timeGetTime I round down, but I think realistically it balances out to almost nill.   edit: so if that is correct then I can just use timeGetTime with a frame limit and should be ok right? Something like if(overflow > limit) then Update?
  10. What the hell, where'd everyone go?
  11. As for my multithreaded approach I would like to have this Logic -> 4 threads  Physics -> 0 (no physics in my apps) Rendering -> 4 threads (software rendering 3d/2d worlds)   Edit: so for these things I have to have inter-core timing right? 
  12. So I just want to be clear that we came to some conclusion here. I have to always give up one core no matter what I do to use QPC. So on my quad core machine I'm only left with 6 physical threads? How is this possible?   Edit: But how would that even work? If I'm timing a non active thread and my main code is on other core then the qpc will still return an invalid result.   Edit: OK after some more reading, I think Microsoft is saying QPC should not be used for inter-core timing. The examples they give is just timing within the thread, I'm guessing mostly for codebenching purposes. The proper way seems to be using timeGetTime. I'm not sure why you guys are saying that it's low resolution for game code. It could go down to 1ms, my update code must be at least 16ms that would give me 60hz refresh. For 30hz refresh I could need as much as 32ms.    Edit: I already mentioned this but the reason I'm not using timeGetTime is because it's returning zero for delta.
  13. What's the difference between when I convert to float before the division or after? The frequency is in the range of 2 million, the actual double double difference between times are about 6k usually so in most cases it's doing something like float(6k) / double double(freq), the result should be something like 0.00x way less than float capacity.
  14. I've never seen a thread be so divided, it seems like half are pro QPC and half are against. In any case this is my WinMain loop: resetEntry:       CreateEngineWindow();     GameEngineInitialization();   while (TRUE) { // test if there is a message in queue, if so get it and remove it from the queue if (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE)) {               if (msg.message == WM_QUIT)                 break;                 TranslateMessage(&msg); DispatchMessage(&msg);   } else { LARGE_INTEGER currentTime; QueryPerformanceCounter(&currentTime); Timer.deltaTime = float( (currentTime.QuadPart - Timer.lastTime.QuadPart) / Timer.frequency.QuadPart);   //for first run if (Timer.deltaTime > 3) Timer.deltaTime = 0;   int code = GameEngineUpdate();   if (code == APPUPDATE_RESET) { ApplicationSettings(); GameEngineShutdown(); goto resetEntry; }   QueryPerformanceCounter(&Timer.lastTime); }   }