Jump to content
  • Advertisement

chronos

Member
  • Content count

    428
  • Joined

  • Last visited

Community Reputation

100 Neutral

About chronos

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Do the limits on texture coordinates imposed by MaxTextureRepeat only become an issue during calls to texture lookup functions such as Tex2D, or do the limits come into play even before the sampling instruction is executed? I wish to know whether it's possible to avoid the MaxTextureRepeat limitation by calling frac() on the texture coordinates before passing them on to the texture lookup function.
  2. chronos

    why is C++ still being over-used?

    Quote:Original post by johdex I could also use a programming language whose specification tells me what the basic types are able to contain. I don't know whether C++0x will implement this, but C99 has standard types that call for specific widths: Quote:7.18.1.1 Exact-width integer types 1. The typedef name intN_t designates a signed integer type with width N. Thus, int8_t denotes a signed integer type with a width of exactly 8 bits. 2. The typedef name uintN_t designates an unsigned integer type with width N. Thus, uint24_t denotes an unsigned integer type with a width of exactly 24 bits. 3. These types are optional. However, if an implementation provides integer types with widths of 8, 16, 32, or 64 bits, it shall define the corresponding typedef names.
  3. A MySQL database is probably fine. From a 2002 postmortem of Dark Age of Camelot: Quote:Because running Camelot would require a considerable amount of data management, we initially planned on using Oracle to store account and character information. However, Oracle's quoted license fee of more than $900,000 quickly removed them from contention. Once we got over our shock and amusement at Oracle's pricing, we turned to a Linux-based freeware solution, MySQL, to manage Camelot's data storage, which so far has worked admirably. Everyone developing games should at least investigate open source solutions for their servers. It's saved us a pile of money and has been stable and reliable.
  4. chronos

    why is C++ still being over-used?

    Quote:Original post by Daaark Heaven forbid that someone should try to objectively point out a flaw in something that they have put on a pedestal. If you had done so objectively I wouldn't have complained. PS - Thanks for the vote of "confidence". Very mature.
  5. chronos

    why is C++ still being over-used?

    Quote:Original post by Daaark And there is always that 10% who think themselves above everyone, and need something to separate themselves from the pack ... Yeah. I guess I can see that. Quote:Original post by Daaark You are just ignorant, and really don't know what the hell you are talking about in general. ... Lots of programmers are not as good as they like to pretend they are. ... Every random jackass is hacking up all kinds of over engineered solutions that are no good for anything but crashing, or causing all kinds of other problems. ... C++ has a fundamental design flaw in that it gives so much power to so many incompetent people. ... How many 'pros' are still doing this and have no clue? ... Most programmers in general are incompetent and irresponsible to begin with. ... These languages have a strange culture of people who obsess about over-engineering, over-optimization, and speed no matter what the cost. ... Once upon a time, people were too good to use C, because they were clinging to the tit of their own language of choice. ... Maybe one day people can have an objective discussion on C++ without a brigade of threatened apologists rushing to it's un-needed rescue. These kinds of threads would be a lot less annoying if they weren't always so full of net-tosterone.
  6. You're wasting your time. Besides, why would you want to do that to your customers? Designing your game so it doesn't work with your customer's hardware is a great way to drive them away.
  7. For terrain meshes I've decided to use skirts instead of stitching the edges together because otherwise the blending between LOD levels becomes too difficult for me to understand and implement. Skirts are conceptually ugly, but they make blending between LOD levels a trivial matter. With regard to my original post, when I speak of stitching I am talking about stitching together pregenerated textures that together make up the terrain's surface, similar to megatextures. Also, when I speak of sharing edges I am referring to duplicating texture edges rather than mesh edges, in order to avoid artifacts from texture filtering. I wish to minimize storage space requirements through texture blending, but I can't think of a way to do so that isn't significantly complicated by the quadtree structure of Chunked LOD.
  8. I'm trying to decide how best to texture a Chunked LOD terrain. I could either blend between various tiled terrain textures whenever a chunk is loaded into memory, or I could load an image from disk and use it directly as the texture for that chunk. I find myself unable to decide between the two options. Consider: With blending, the closer you get to the root of the quadtree the more distinct terrain types are likely to be present within each chunk. Whereas rendering a leaf chunk may require blending between four distinct terrain types, that chunk's parent may require blending between sixteen (four per child). This means multiple passes and just as many more blend maps, thus increasing processing and storage space requirements. To make things worse, the need to share borders with neighboring tiles (to avoid artifacts due to texture filtering) means that even a leaf chunk may require blending between more than four different terrain types. An alternative to the above is to load an image directly from disk and use that as the chunk's texture. Unfortunately, storing a unique image for each terrain chunk may require greater storage space than storing only tiles along with the information necessary to blend between them. Although it's possible to significantly reduce memory requirements by creating a compressed texture pyramid (as for Geoclipmaps), I'm still concerned that it may require too much memory. Of course, it's possible to combine both techniques, with blending for the finer levels and unique images for the coarser levels. Even so, unless blending is restricted to the leaves of the quadtree (which might not provide a sufficient storage-space advantage), blending between tiles at anything other than the leaves is still more complicated than I'd like it to be. What do you think?
  9. chronos

    Something to consider....

    Why wouldn't AMD and NVidia want to have their most expensive cards supported by what's still the most popular operating system? Unless there are technical reasons for why DX10 can't be implemented under Windows XP, it seems to me the only party that benefits from making DX10 Vista only is Microsoft. Take a look at Microsoft's DirectX website and tell me pushing Vista is not their main agenda.
  10. chronos

    Shaders and multiple textures

    Thanks for the replies. I'll implement it as several shaders (e.g. Name_1T, Name_2T, etc). Just wanted to make sure I wasn't doing something utterly stupid.
  11. I wish to have a pixel shader that will take a variable number of textures as input, up to a maximum equal to the number of samplers available to the shader. Is it possible to do this with a single shader, or do I actually have to write N different versions of the same shader (for 1 texture, for 2 textures, ..., for N textures)?
  12. chronos

    integration

    Ah... I misunderstood the question. Tabby, What is your source for the claim that one should obtain the new velocity before the new position? According to the book "Numerical Methods" by Fausett, the way to solve higher order ODE's is as follows: If y'''' = g(x,y,y') is your second-order ODE, then v = y' u = y v' = g(x,u,v) u' = v = f(x,u,v). By Euler's method: a = initial value of x; b = final value of x; n = number of steps; h = (b - a) / n; // step size u[0] = u0; // initial condition for u at a v[0] = v0; // initial condition for v at a for i = 0 to n-1 x = a + h * i; u[i+1] = u + h * f(x, u, v); v[i+1] = v + h * g(x, u, v); next i return u, v; // arrays of approximate values So, both the new position and the new velocity are obtained at the same time. [Edited by - chronos on February 24, 2008 2:46:46 AM]
  13. chronos

    integration

    You integrate velocity to obtain position.
  14. chronos

    Terrain (for a city), texturing

    From vterrain.org, Generating 3D Roads the idea is to go automatically from a 2D road description to a completely 3D polygonal road two main approaches: draped vs. merged thin geometry draped on top of the terrain pro: simpler and faster, easily changed at runtime, allows the terrain to be a regular grid con: "Z-buffer fighting" due to overdraw there are ways to reduce the Z-buffer problem roads merged into the terrain ("stitched", embedded) pro: flawless road boundaries, no overdraw issues con: requires computationally complicated and slow preprocessing all known commercial programs (see below) prefer this approach with either approach, an algorithm is needed to convert road centerlines (raw vector data) to a full 2D/3D representation there are no known published algorithms for doing this!
  15. chronos

    Terrain Vertex Tweening, etc.

    Nine tweening factors: one for the inner vertices, one for each neighbor's edge vertices, and one for each of the vertex rows in between. How does taking that into account solve the problem?
  • Advertisement
×

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!