Advertisement Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

1562 Excellent

About bwhiting

  • Rank

Personal Information

  • Interests
  1. Adobe air. Pros: Free Easy Deploy to desktop or android or ios device in one click. Debug desktop or android or ios line by line no probs. Great perfomance profiling tool called Scout. Great free ide for Windows called flashdevelop that included some nice boilerplate for you. Can use starling for easy gpu accelerated rendering. Plus various other things... Cons: Not the fastest language in the world but plenty fast enough for 2d games. Limited access to device capabilities. Although you can use native extensions should you need it. There can be some quirks to get things running but the correct choice of ide can negate some of that. This applies to most other platforms too mind.
  2. Flash runs fine on ios devices when deployed with air as an app and also works on android devices, they have just released support for apple tv too. Thousands of successful games are built this way.   A game I saw recently that looked similar to the first title you posted is made with flash/air.   I personally still think flash/air is a great way to make games: One code base and it runs on web (desktop only), desktop, ios and android. It is easy to learn and free if you don't need adobe's ide. You can test on android and ios devices from a pc! There is a great profiling tool called scout that help get the most out performance wise.   Sure it doesn't have every feature under the sun built in but a great set all the same and has most things covered. Also pretty sure flash ships with Microsoft... never seen a pc it doesn't run on yet?   Still js is arguably easier to learn/pickup and also no compile times is great!   I would recommend just going with what you are most comfortable with. I have made games with unity,javascript and flash/air and each has pros and cons, but the point being they were all able to make what I needed them to.
  3. bwhiting

    Data throughput

    Wow Matias very thorough reply! Yes 60fps was indeed the target and the fact that you think any of those things could be a problem makes me think more could be achieved. Some limitations could be out of my control but you gave me a great idea to test the theoretical limits by taking out all the variables I can. So I will do 2 tests. One with all the data staying on the gpu as a baseline. And a second one uploading all the data each frame but do no calculations on the cpu. I.e. not changing any of the data but just reupload it. That should give me some good indicators. I will also use some gou profile to see what commands got issues to help give me a better indication. Thanks for great reply!
  4. bwhiting

    Data throughput

    Thanks Silence! Yes there are many factors at play here but I was just hoping for a "sounds about right" or "sounds a bit low" kind of replies.   That said. api: DirectX gpu: Nvidia Quatro k2200 cpu: Intel Xeon E5-2630 @2.5GHz ram: 32GB   extra info: assume not much else is going on as I am pretty much just trying to find limits of different aspects of the renderer   really only looking for rough, ballpack, anecdotal kind of answers though, just curious and nothing major is resting on any answer either.
  5. Hey all, Just looking for some guestimates with regards to how many vertices one could update safely per frame in a dynamic buffer.   I have done some testing and the limit seems lower than I thought it would be.   For reference I am uploading 5mb ish worth of data roughly at 20 bytes per vertex. So about 250,000 vertices I can push though per frame and that seems to be the limit on my machine.   To be honest that should probably be enough for what I need I just wondered if that number seemed on the low to anyone else? I thought double that should have been easily achievable.    Cheers   (on a low-middish range gpu if that helps)
  6. bwhiting

    render huge amount of objects

    @hodgman thinking about this further, are you suggesting that you only add nodes into that array in reaction to something changing? Infact scratch that. you would also have to add any child nodes too in that case and it wouldn't work if a transform was changed multiple times.   There will always need to be a complete hierarchy pass then I think, I can't see how to avoid it. In which case it still makes sense to just update all transforms    Some odd cases to think about. Leaf node modified followed by parent followed by its parent... all the way up to the root in that order.  Root node modified (all children will need updating) Leaf node modified followed by its parent's parent alternating all the way to the root. There are 2 things at play with transforms the way I see it, the local update of a matrix when it is changed... then the re-combining of all the child matrices - this is where I am struggling to see the optimal solution.   Rebuild from scratch? Update and recombine using a 3rd snapshot matrix that represents the hierarchy above? Some other genius idea of justice?   EDIT:: If I get time I might make a 2d test bed to test this, a simple visual 2d tree that is update-able via mouse drags. I can then try various approaches and rather than benchmark I can compare how much work is done/or saved.
  7. bwhiting

    render huge amount of objects

    aaaaa I clicked on something and lost my essay of a message, I should really install a form saver plugin!!!   @hodgman, interesting and tidy approach but does it end up being more efficient that a normal tree traversal? I guess it depends how much changes from frame to frame, it nothing does then a full tree traversal for transform updating only is pointless. But sorting arrays sounds slow also.   I was aiming for a solution that only touches the minimal set of nodes to respond to a change but also scales well from zero changes to changes in every object in the scene. Me wants cake and eating it!   @poigwym, flags like that should work well I think.
  8. bwhiting

    render huge amount of objects

    I do it slightly different than some. Each 3d object has a transform. This has getters/setters for scale/position/rotation. There is a 32bit dirty flag that is updated through the setters. So any any given time you can know if the scale, rotation or position has been change and in detail too, i.e. which component. When a matrix is required, the transform is requested to build it, if the dirty flag is non-zero the matrix needs rebuilding. Depending on different flags set it will do it differently. Scales and transforms are very fast, just directly set the values. But If rotations are included then a more complex recompose is done (sin/cos etc..) you can do this a number of ways and look on line for various approaches. A common one is to build each rotation matrix required and combine it. Then if the transform has a parent it needs to be concatenated with it's transform too, managing these relationship updates can be tricky and I am still not sold on the best way to do it.   You don't have to do it this way of course you can just operate directly on a matrix appending transformations to it as you wish (would probably be faster).     The view/projection matrix is calculated once per frame and shared across each draw call, only the world matrix is updated in the buffer between calls, so that is just copying 16 floats into the buffer and nothing else - should be pretty quick.   Hope that helps.
  9. bwhiting

    render huge amount of objects

    If you are on a desktop you can see and old flash demo I did here to test what your gpu can handle. this is in flash by the way so native you should be able to beat what you see here (it is not massively optimised either)   There is no instancing and each object has a unique transform, the only thing constant between draws is the material.   Lower end gpus should be 500-1000 no problems, mid range 1500-3000, high end can hit 8,000+ 
  10. I have used object pools combined with linked lists for this kind of thing in the past. Provided you don't need random access to a projectile it should work just fine. Pool allocates and stores references to the objects, it can create a bunch upfront based on and educated guess and expanded if needed at runtime, uses a vector behind the scenes and a pointer to the last unused item. Then you just run though your linked list in the update function advancing and collision testing. It is then extremely fast to add/remove projectiles from the linked list and return/retrieve them from the pool. Most of the time there will be 0 allocations and 0 vector resizing/copying. It is not as cache friendly as blasting though a flat vector but plenty fast enough and the ease of implementation is a real plus. There are no doubt other ways, this is just something I have used successfully many times and is both easy on the GPU and minimises memory allocation/GC. b
  11. Another option might be to disable the collision physics for the first few frames of the bullets life to given them a chance to not all be on top of eachother which is a worst case scenario for phyisics. Do look into the collision masking though as that could well be the fix you need and should be very easy to turn on.
  12. I really like this question (or set of questions) as it presents a large number of the issues developers in your position face. From my experience if you are already on the right track, you identified a large bottleneck and improved it.   What you need to avoid it trying to catch/handle every situation in the most efficient way - this can often end up worse! I recommend an approach that doesn't try to solve all of the issues but just the main ones. Often enough the performance of such a solution is plenty good enough for most applications.   If you are optimising your engine for this game and this game alone things might be different, but suppose you want to use the engine for a future game one that has more transparent objects, or transparent objects completely mixed in with opaque ones all over the place? Then a seemingly good solution might end up being a bad one.   In terms of over complexity avoiding you could start with very simple dirty flags for things like children changed or not, rather that trying to work out which exact child was removed or added it might be easier just to know IF one was added or removed and respond accordingly, hope that makes some kind of sense.   You will have to make those calls though based on your needs.   That said some kind of double buffer might work for handling changes (or lack thereof) well i.e. for each frame swap buffers and copy large chunks from the last one where possible when no changes occur otherwise just write in the new data. Just remember that blasting through more linear data can often be faster than jumping around all over the place trying to avoid unnecessary work due to cache misses anyway.   Look forward to seeing other replies in here :) b
  13. bwhiting

    Directional lighting trouble.

    Use vertex normal and pass it to fragment shader, renormalise it, then use that. If you use normal mapping you can use the normals from that. So essentially just dot the normal against the transformed light direction (which should now be in the same space as the normal)
  14. bwhiting

    Directional lighting trouble.

    don't "translate" the direction to model view, if the model has any position other than 0,0,0 then it will break the normalized direction.   use a m33 rather than an m44 to "transform" the light direction into the models space without taking any translations into account, i.e. only scales and rotations as they are the only things that matter for a directional light.   :D
  15. Some kind of bloom effect would probably help get nearer what you want. I think if you did that coupled with a fractal noise you could be well on the way.   So use a down-sampled version of the image to blur it based on light intensity, then overlay that onto the original image. I would also use that blur texture as a alpha map for some kind of noise (such as fractal) to get that "cloudy" look. Depending on how you built the initial image you may need to think about how a noise texture might swim as the camera moves and you will need to fix that, i.e. maybe sample a cube map there, just guessing at this point :D
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. 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!