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

trs79

Members
  • Content count

    60
  • Joined

  • Last visited

Community Reputation

126 Neutral

About trs79

  • Rank
    Member
  1. Txt rendering
  2. Oh, no worries! Too many api's and combinations of extensions to keep track of :)
  3. Thanks for the responses everyone.   @froop: Yeah, I think over-optimization is to blame here, I hate it when that happens.  A draw call for each album seems like the way to go   @Norman Barrows: Thanks for the tip about sprites, I had forgotten about those. So it sound sounds like you're also saying to use a draw call per album, but using point sprites instead of quads?   @marcClintDion: PBO's sound interesting, but unfortunately they don't seem to be supported in GLES 2 that I'm targeting. I wish they were though, sounds like that would be the best way to update the textures
  4. Hello,   I'm planning on creating a program whereby a list of album names is retrieved via http. Once the names are received, I plan to do the following: Create a static VBO, with one quad for each album name. Each quad shares part of a texture atlas, so I can use a single draw call There will be additional http requests for album art images Display a loading indicator until image arrives, then lock part of dynamic texture atlas and write image data There will be a scissor clipping rectangle that will hide the quads not yet shown User can scroll list up and down   Questions: I'm using GLES, is there a better way to handle the asynchronous incoming images then to use a dynamic texture with locking overhead? Instead of one VBO for a single draw call, I could issue a separate draw call for each quad, not sure if this would be much slower? I think it would be easier because I could simply draw each quad with either album art texture or progress texture until image comes in   Thanks for any help, please see image below     I
  5. [quote name='jameszhao00' timestamp='1333440496' post='4927815'] SH = (roughly/sometimes) Light probes = environment maps = cube maps - Storage - Maps a direction to a color (or any value) - Light probes can mean SH, which is an approximation and can store blurry stuff. It cannot store sharp (high frequency) details. - Light probes can also mean environment maps / cube maps. They can handle sharp details. PRT = Precomputed Global Illumination - Method - Need to read paper... - Can store its results in some format... (paper mentions SH) Irradiance map = filtered map of incoming radiance. - [url="http://codeflow.org/entries/2011/apr/18/advanced-webgl-part-3-irradiance-environment-map/#irradiance"]http://codeflow.org/...map/#irradiance[/url] - Time saver. - For diffuse stuff in image based lighting, you usually sum incoming light for a given direction, with each light 'beam' weighted by its angle. That's your irradiance. - The summation is expensive, so we precompute a direction -> irradiance map. - Usually looks like a blurred light probe. - Stored in environment map, SH, etc... Also I feel like that unless you're reading a paper, the terms 'SH', 'light probe', 'environment map', 'irradiance map' usually are used interchangeably. [/quote] Thanks for the information, I'm beginning to get a better grasp of the terminology. It sounds like I probably just need SH for now, and I'll use standard shadow mapping for my characters on top of that. [quote name='InvalidPointer' timestamp='1333484141' post='4927989'] Spherical harmonics refers solely to the math/concepts behind storage, PRT is just the idea of calculating how light bounces around ahead of time. Technically speaking, boring old Quake 2 lightmaps are just as much PRT as are the fancypants spherical harmonics stuff that's in vogue today. [/quote] Thank you, that clears up a lot for me. So, to summarize, it sounds like to get the basic ambient indirect lighting I just need to do the steps by MJP. Just to make sure I'm understanding things now, it seems like both Unity and UDK are doing this, i.e. see this link [url="http://udn.epicgames.com/Three/Lightmass.html#Character"]http://udn.epicgames....html#Character[/url] lighting there it looks like they are just doing an irradiance map as well? The DirectX SDK has an Irradiance volume sample from ATI that looks similar.
  6. [quote name='MJP' timestamp='1333430748' post='4927785'] They're not using PRT in Unity, nor is PRT particularly popular for light probes in general. If you're just starting out with light probes, then you can implement them like this: 1. Pick your probe locations throughout the scene. Easiest way is a 3D grid. 2. For each probe location render an cubemap by rendering in all 6 directions 3. Convert the cubemap to SH (you can use the D3DX utility functions for this if you'd like, but it's not too hard to do on your own) Then at runtime you just lookup and interpolate the probes, and look up the irradiance in the direction of the normal by performing an SH dot product (just make sure that you include the cosine kernel). This will give you indirect lighting, and you can add in direct lighting on top of this. [/quote] Thanks so much for the reply. As I suspected, I must be confusing PRT with SH in general. So are light probes with SH like in Unity known as an "irradiance map"? (sorry I'm trying to wrap my head around the terminology). If this is the case, then as far as I can tell the main difference between PRT and an irrandiance map is PRT computes self shadowing whereas an irradiance map does not? Thanks for any clarifications. Basically, I'm just try to set my game up such that I can have nice indirect lighting mixed with lightmaps and direct lighting. It seems like light probes are how the commercial engines do it (UDK, Source, Unity, etc.)
  7. Hey all, I'm trying to see if it's possible to use the PRT DirectX tools to setup light probes similar to this from Unity: http://blogs.unity3d.com/2011/03/09/light-probes/ I notice there is a spherical light, as well as functionality to convert cubemaps to spherical harmonics coefficients. Any tips on how to be able to place light probes and create spherical harmonics coefficients from them? Thanks
  8. Thanks for the info, I could use placement new to get contiguous memory for particles in the same uniform grid cell as the particle I'm testing, but getting the particles from the surrounding neighbor cells is where I'm stumped. I'm not even sure if this is possible, but I'm hoping
  9. Hello, I'm trying to use SSE to speed up neighbor finding for a particle fluid simulation. My main issue, however, is storing the neighbors of each particle in memory such that I can quickly load all candidate spacial neighbors into xmm registers to begin distance testing to see if the neighbors are within the cutoff radius. I've tried Z-order morton sorting, but that doesn't always ensure that the spacial neighbors of a particle are stored contiguously in memory. Anyone have any ideas? Thanks
  10. Thanks for the responses, to answer: [quote name='iMalc' timestamp='1325742149' post='4899862'] What type is the data (e.g. unsigned int, float, struct...) and what are typical and expected near maximum values on the number of items? Is it in an array rather than a linked-list? How often will the data actually be sorted already, and how often will it be nearly sorted? It might help if you explain where the data comes from. If I can get enough info from you then I can point you at the optimal sorting algorithm. I doubt there's much to be gained by trying to do it using SSE though. [/quote] Basically I'm looking to sort SPH fluid particles. Most of the time, they will be at rest inside of a small round container, with only occasional disturbances. I plan on sorting them with Morton Z-order according to what 3D spatial grid cell they are in, so they'll be spatially sorted inside of memory. I'm currently storing them in an array, and the min and max values should be somewhere around 9 and 25 respectively. Since the fluid will almost always be stable at rest, I'd say it's sorted probably 90% of the time. [quote name='Antheus' timestamp='1325772374' post='4899939'] Derive [url="http://en.wikipedia.org/wiki/Sorting_network"]sorting network[/url] for insertion sort and implement it as SSE. Sorting networks get around the lack of branching, but tend to be less efficient. For general parallelization, something like [url="http://en.wikipedia.org/wiki/Bitonic_sorter"]bitonic sort[/url] might be a better fit. All of these work best on 2^n-sized sub-sections, other sizes may either require padding or differently sized subdivisions, if possible. For SSE specifically, such methods tend to be best suited for sorting register-sized data (4xint SSE register, for example). Rather than general sorting, they tend to be used for selection or filtering, such as selecting smallest component of a vector, or as preparation pass for next stage. Biggest gain is ability to keep data in SSE registers instead of moving them back and forth for regular processing. [quote]would give as good performance for mostly sorted data sets[/quote] Heap sort, merge sort or tim sort. Insertion sort has that painful n^2 common case. Quicksort found in various standard libraries may be implemented as introsort, which should avoid typical qsort problems. [/quote] Thanks for the info, the Sorting network sounds interesting. Since the fluids will be 90% sorted I'm trying to optimize for the mostly sorted case, would the sorting network slow things down for that?
  11. Thanks, I was afraid of that. My data sets is almost always going to be mostly sorted so it seems like the insertion sort would be ideal, even vs another algorithm that is SIMD capable. I'm not sure of any other algorithms that would give as good performance for mostly sorted data sets as the insertion sort.
  12. Hey all, I've looked all over the Internet but can't seem to find any examples of an SSE insertion sort. Maybe it doesn't lend itself well to SIMD? Anyone know of any good resources? Thanks
  13. [quote name='luca-deltodesco' timestamp='1323966858' post='4894202'] do you understand what the normal to a surface means? [/quote] I do, but this is my first attempt at coding collision detection, probably why I got confused on the implementation Thanks for the help, it was the z component that was causing problems, I finally ended up using this based on your code: [code] norm.Set ( -p->pos.x/diff, -p->pos.y/diff, 1.0-(p->pos.z/diff) );[/code] along with the initial boundary slope code: [code]float boundary = abs((-.4 * p->pos.z) + 9.8);[/code] Thanks again!
  14. [quote name='RulerOfNothing' timestamp='1323929951' post='4894094'] Here I am assuming the norm variable holds the normal vector of the container, which would indicate to me that it needs to have a non-zero z value if the container is a frustrum instead of a cylinder. [/quote] Thanks for the reply, you are correct the norm variable holds the normal vector of the container. Unfortunately when I change it to have a non-zero z value I still get the erratic particle movement, i.e : [code] norm.Set ( -p->pos.x, -p->pos.y, p->pos.z ); norm.Normalize(); [/code] Maybe I need something different for the z value?
  15. Hey all, I'm seeing some strange behavior from some SPH fluid code I'm working on. I modified it to have a cylinder as a container/collision shape and that works fine. However, I then change it so that it slopes inward as it gets taller, and the particles start to move around constantly like the fluid is boiling and they never settle down. Also, the fluid level doesn't get higher as the container slopes inward as I'd expect. See image: [attachment=6419:fluid.gif] Here is the code I'm using to calculate positions (it's a modified form of the code at [url="http://www.rchoetzlein.com/eng/graphics/fluids.htm"]http://www.rchoetzle...hics/fluids.htm[/url]) [code] accel = p->sph_force; accel *= m_Param[SPH_PMASS]; ..... // p is the particle structure, with z being up // radius is the particle radius // norm is a 3-vector float boundary = abs((-.4 * p->pos.z) + 9.8); diff = 2.0f * radius - (boundary - (float)fastSqrt_2(p->pos.x*p->pos.x + p->pos.y*p->pos.y)) * ss; if (((diff < 8 *radius) && (diff > EPSILON))) { norm.Set ( -p->pos.x, -p->pos.y, 0 ); norm.Normalize(); adj = stiff * diff - damp * norm.Dot ( p->vel_eval ); accel.x += adj * norm.x; accel.y += adj * norm.y; accel.z += adj * norm.z; } .... // Leapfrog Integration ---------------------------- vnext = accel; vnext *= m_DT; vnext += p->vel; // v(t+1/2) = v(t-1/2) + a(t) dt p->vel_eval = p->vel; p->vel_eval += vnext; p->vel_eval *= 0.5; // v(t+1) = [v(t-1/2) + v(t+1/2)] * 0.5 used to compute forces later p->vel = vnext; vnext *= m_DT/ss; p->pos += vnext; // p(t+1) = p(t) + v(t+1/2) dt [/code] I'm pretty sure the way the normal is being added to the acceleration is causing the "boiling" of the particles, but I'm not sure. Thanks for any help