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

MortenB

Members
  • Content count

    45
  • Joined

  • Last visited

Community Reputation

993 Good

About MortenB

  • Rank
    Member

Personal Information

  • Location
    Porsgrunn, Norway
  1. There's a little problem with calling FloatSwap, at least on x86. It will only cause a problem with a few numbers but they can be a real pain to track down:   Not all floats are numbers, as some bit combinations are NaNs. The bit pattern for a NaN is: s1111111 1axxxxxx xxxxxxxx xxxxxxxx   It's the "a" bit that's causing problems. It tells the x86 if operations on this NaN can cause a float exception. If an operation on the NaN can cause an exception, it's a signalling NaN (sNaN), if not it's a quiet NaN (qNaN).   When the x86 encounters an sNaN it will trigger a float exception (if enabled), and then turn the sNaN into a qNaN.   This won't usually cause a problem because a NaN can't really be any other number. As long as it's treated as a float, all NaNs are NaNs, signalling or not.   The problem is that when FloatSwap is called, it will return the swapped value as a float. A valid float number can be returned as an sNaN, because the bits in the float that says if the float is an sNaN is loaded from the bottom end of the mantissa. If it is an sNaN, the x86 will flip the "a" bit to make it a qNaN.   Two FloatSwap's in a row won't always give you the same number back on x86. Since the flipped bit has a fairly low significance, it'll only be a small change in the value.   E.g. this : #include <stdio.h> #include <math.h> union floatintbyte { float f; unsigned char b[4]; unsigned int u; }; float FloatSwap(float f) { floatintbyte dat1, dat2; dat1.f = f; for(int i = 0; i < 4; ++i) dat2.b[i] = dat1.b[3 - i]; return dat2.f; } void main(int argc, char *argv[]) { floatintbyte start; start.u = 0x3f8080ff; // 1.0f + sNaN in the lower bits. float once = FloatSwap(start.f); float twice = FloatSwap(once); printf("start : %f\nonce  : %f\ntwice : %f\n", start.f, once, twice); } will output   start : 1.003937 once  : -1.#QNAN0 twice : 1.005890   -Morten-
  2. I've found that I get the "stiff" controls comment when I change my game objects velocity without considering the initial velocity of the object. To "fix" this I make sure that the object has a little time to change its velocity. When an object starts to move, there's a little bit of acceleration time before it's going at the right speed. Same when it slows down to stop.   It sounds like this will make the controls less precise, but the mind picks it up really quick and compensates.   If you overdo it, people will complain that the controls are sluggish. The mind adapts to it pretty quick so during testing, make sure you get some fresh hands to try it out.   -Morten-
  3. Any disk access is very slow. The hard drive is faster than DVD by maybe 5-10x, and RAM is ~100x faster than that again (I don't have the exact numbers, but 5MB/s, 50MB/s, and 5GB/s aren't unrealistic). These are ideal numbers, and you're not likely to get those without planning ahead. Also, obviously, the GPU and CPU can't use stuff that's not in RAM, so it's got to get there at some point. I think you should look at trying to get data that gets used a lot into RAM first and keep it there and, if you need to, stream in the unique bits. Streaming from hard drive will make your life a little easier because it's faster, but maybe not as much as you'd think. If you make sure your scene draw works with assets that aren't ready yet it'll be even easier. The general rule is if you plan for streaming up front, it'll be a lot easier than trying to add it later. There are a few good papers on streaming and disk IO on the xbox360 dev site. -Morten-
  4. OpenGL

    DXT works for 4x4 image blocks. When you have images with other resolutions you have to ignore the pixels outside the valid area. The problem with the code that it computes the workload by dividing width and height by 4, and so cuts off the pixels in the extra "unfilled" 4x4 blocks. In the 2x2 and 1x1 cases there are no pixels left to process. Most people only use textures with "sensible" resolutions, and so most end up not implementing the case where the texture resolution isn't a multiple of 4. The details are mentioned in the "[color=#000000]Implementation Note" of the spec.[/color]
  5. [left]Your display function is gonna crash. You've got NULL in your nodes array for leaf nodes, but still try call display(sprite) on them. This is probably what's causing the crash on 1st run through the loop.[/left] If you're getting a crash earlier than that, it's likely to be in code you're not showing. You're also not initializing nodeStatus in the constructor.
  6. Here's a description of what we used to do back in the old days. [url="http://freespace.virgin.net/hugo.elias/graphics/x_water.htm"]http://freespace.virgin.net/hugo.elias/graphics/x_water.htm[/url] When you've got it working you can just write some values into the current buffer for each position where you want objects to interact with the water. This method is still used for games today when you need to get the water to ripple around objects.
  7. This is only a problem if you need the textures to live in memory on the gfx card at the same time, like render targets or similar. This used to be a much bigger problem than it is now. The S3 Virge left ~250Kb for textures after a weak 640x480 screen. The driver keeps a copy of all textures in main memory and only uploads it when you bind it. If it runs out, it runs out. This will make your draw go slower. That would be about all it's doing, though. If your driver is returning an error there's something else going on, like not being able to map in more memory for the texture.
  8. You should take a look at Hugh Hoppe's research[url="http://research.microsoft.com/en-us/um/people/hoppe/"]http://research.microsoft.com/en-us/um/people/hoppe/[/url] His thesis is about reconstructing 3d surfaces from points.
  9. OpenGL

    It looks like the problem comes from the vertex normal generation . You are running something like this? for all vertex normals { Set to zero } for all triangles { Add the face normal to the vertex normals used by this triangle } for all vertex normals { Normalise normal } There are a few techniques that will get you a better result from just triangle data. Checking the angle between adjacent triangles, and only use the face normal across the edge if less than something will probably get you a better result. Best is of course to get an artist to create the model with normals for you. -Morten-
  10. [font="arial, verdana, tahoma, sans-serif"][size="2"]The lines are there because the vertices gets transformed to slightly different positions, most likely because of the float math in the transforms. If they where exactly the same the cracks wouldn't be there. Ideally I would solve it by drawing all the quads with the same transform (have loads of quads instead of loads of transforms).[/size][/font] [font="arial, verdana, tahoma, sans-serif"][size="2"]For quick and dirty solutions I'd try solve it by not clearing the screen. Sometimes that will make the cracks a lot less noticeable. Don't work if there's a skybox pass or something else that goes fullscreen. Another quick fix would be to make the quads all a little bit bigger. That'll work if there's no alpha on the quads themselves.[/size][/font] [font="arial, verdana, tahoma, sans-serif"][/font] -Morten-
  11. I use an animation compressor for handling animating sprites, rather than spritesheets. If video memory is an issue, that'll be a way to cut that side right down. There will be a runtime cost with decompress and upload, so you'll have to balance it out. -Morten-
  12. The whole graph was pre-made by the artists in 3DSMax as a way to say "you can go here". Some nodes were added that were marked as "when you get here jump" by the artists. It looks something like this : where the red rectangle is marked for jump, and the green/blue is the result from the pathfinder. When I get to the blue bit of the path, I make the AI execute a jump command. Design/art were responsible for making sure that the AI could reach across and not fall off the edge. -Morten-
  13. What I did was just A* as normal, with a "jump" flag on some node transitions (not the node itself but the edge between two nodes). When the path came back, some had the jump flag set. When those were traversed I made the AI execute a jump. I used a nav mesh and made the artists flag the jump nodes for me. They can be hard to detect with code. For a Mario type game I expect you use points for nodes, connected by lines for edges. All you'd need to do is to have a flag for every line, and mark all the lines going up, or over holes with the jump flag. -Morten-