Jump to content
  • Advertisement

zokeefe

Member
  • Content Count

    13
  • Joined

  • Last visited

Community Reputation

132 Neutral

About zokeefe

  • Rank
    Member

Personal Information

  • Interests
    Programming
  1. @Olof Thanks for the response! Ya, this is pretty much what I was thinking of doing. Does your small server sit on a central machine, or is it part of the toolchain on the dev/content creator's workstation? Do your artists/level designers like this setup? 
  2. @Sean - Thank you for your response. I swear I've seen youYes, this was precisely the other option I was thinking about. Transferring data over USB would be ideal - though I can't find any (official) way to do that for say, iOS. Going the route of setting up a simple file server would mean developing PC/Mac-side tools anyways :) At the moment, we hire contractors for assets - so the second we rely on a desktop approach, may have to support both Mac and Windows. Also, given mobile's available RAM, there is a chance there is frequent access over the network for assets. Would need to do some back-of-the-envelope calculations to see if I can dl the assets in a reasonable amount of time! Do you have experience with either method?   @Hodgman - Thanks for the response! Ya, that's what I've seen in my experience too. See my response to Sean for thoughts. Any experience on what works/doesn't work for mobile?   @Columbo - Part of me thinks this may just be safest - albeit, the most time-consuming. Eventually, we'll need to build actual tools and a Desktop-based editor. All C, don't use MSVC, but have a self-implemented edit-and-continue ;)
  3. 2-person indie studio, in-house mobile engine.   The goal is to be able to create an environment that allows content creators to iterate on their assets.   For example, I would imagine an artist who creates some texture, UI, sound, model, ect. in some content creation tool, would want to see, in real time, how this asset looks in the game world.   However, working on mobile, the engine doesn't have direct access to the filesystem where the content is being altered.   I suppose the simplest solution is to have the engine support PC and/or Mac; however, I was wondering if any other small studios / hobbyists came up with other solutions? With 1 programmer, want to keep development to a minimum.   Thanks, Zach
  4. zokeefe

    Resolving and Remembering Collisions

    @Dirk Gregorius   Very cool to hear from you! I just watched your 2013 GDC presentation: The SAT between Convex Polyhedra last week.   Thank you for linking your 2015 GDC presentation - seems to answer many questions I had. Hopefully I can respond intelligently after reading it :)   That being said, my initial question would be why not generate contacts at the same time as computing TOI (particularly if you are using SAT for TOI) ?   Thanks Dirk, Zach
  5. zokeefe

    Resolving and Remembering Collisions

    @Randy Gaul   Are you applying this epsilon in space (not time)?    If so, if you only apply the epsilon to the colliding bodies (regardless if it's applied along trajectory, or along contact normal), you run the risk of producing a state where either body could be in contact with a third body.   Only if you apply the epsilon in time can you guarantee you won't produce any other contacts; however, choice of epsilon needs to account for speed of colliding objects (or cap max speed). Regardless, trying to maintain a consistent, separated world in this manner seems to be vulnerable to floating point inaccuracies.
  6. Assume continuous collision detection When we find the time of impact, t, between any two objects, A, B, about to collide, there is a lot of rounding error built into t As such, if we advance physics simulation (which will have rounding error) by t, A and B may now be (1) Slightly overlapping (2) Exactly touching (3) Slightly separated. Do we: Advance physics by t - e for some small e (potentially will have issues for things like friction) Remember what objects are in contact
  7. zokeefe

    What's Your Ios Game Loop?

    @Hodgeman       I have a hard time following this. Don't know how realistic it is without VSYNC. And sure, you can get extra "render frames" from just doing the interpolation with different interpolation factors. I think this is the only way to be able to handle these new 144fps displays. But, I mean, there's nothing stopping us from doing the same thing with variable time step...     I'm scared of this. I'm scared of missing a frame, having to do 2 updates, which cause me to miss another frame, which causes me to do 2 updates, ...   Also, it totally depends on your physics whether or not that is true. If you have forces that depend on object's velocity or position (like drag, springs), then yes. If you only use constant forces (like gravity), and impulses, with continuous collision detection and a global collision-stepped physics solver - then any amount of time can pass and you're fine :) (Though that physics simulation step may take a long time... which will arguably cause you to miss your next frame, ect). No good solution!
  8. zokeefe

    What's Your Ios Game Loop?

    @L. Spiro   Thanks again for the reply!       Ya - don't know how I feel about slowmo - seems almost as "physics-breaking" as object behaving unpredictably in variable-step under large dt.     You'll have to forgive me - first time writing such a system from this level! Just trying to get it "right".   If (part) of the objective of using fixed-time is to have your game-update rate be independent of display refresh rate - why not go all the way and not have your game update thread wait for CADisplayLink? I.e. Just setup a normal system timer to wake up your game update thread at your desired rate? You could still do interpolation of game object states when you go to render in your CADisplayLink callback.
  9. zokeefe

    What's Your Ios Game Loop?

    @Hodgman   Thanks for the reply!     What argument are you using? :)       This is where I am at now :) It's a 2D engine, my game update loop is very tight. The physics is entirely continuous. The only vulnerable aspect are objects undergoing acceleration dependent on velocity & position (using Verlet).   I wish I could find that object argument you were looking for - then I could stop worrying about this :)
  10. zokeefe

    What's Your Ios Game Loop?

    @mgubisch   Interesting. Do you know what the original paper was called?
  11. zokeefe

    What's Your Ios Game Loop?

    @mgubisch   Thanks for commenting! Interesting. Out of curiosity, how does one maintain separate threads for game logic & physics effectively? I would assume both want to be touching the same bits of data - to a large extent.
  12. zokeefe

    What's Your Ios Game Loop?

    @L.Spiro   Thanks for commenting :) I've read your blog - and as such am not surprised by I don't know if it's "trivial" (at least for me :P). Variable-step allows you to sim right up to start of frame easily, while to do this with fixed-step requires you to fudge all the renderable object transforms (at least just for rendering) No?   The other drawback of fixed-step is you don't know how many update steps you may take - which scares me since doing 1 game loop vs 2 game loops could blow my CPU budget for a frame out of the water and cause us to miss a rendered frame? (Included just for discussion :P).   OK :)
  13. Just looking at what other people have done, what's been successful, and what pitfalls to avoid.   Current Prototype: Game update is variable update time Game update and rendering done in CADisplayLink callback running on main thread. Audio update occurs on separate thread controlled by AudioUnit. (Game-specific context): Game update takes ~5ms to complete   Thoughts: I feel like variable-time game update might be OK on mobile given we don't have to worry about being preempted as much. Don't know if this is how CADisplayLink is designed to work - perhaps should run game logic on background thread and only render in CADisplayLink callback? Not sure what synchronization issues arise here. Game logic could be allowed to update as fast as possible - or could cap to screen refresh rate. Similarly, could push rendering into same background thread as game update. Again, not sure what synchronization issues arise here. Goals (The same as everyone else?): Minimize input -> display latency Every screen refresh, the device should have an new/updated frame buffer to display. (Placed in Graphics Programming and Theory because of CPU/GPU synchronization issues - of which I am most uninformed)
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!