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


  • Content count

  • Joined

  • Last visited

Community Reputation

164 Neutral

About Fidelio66

  • Rank
    Advanced Member
  1. Quote:Original post by MichaelT My understanding is that Dx9 translates the fixed pipeline to shaders internally. I'd imagine that comes with a cost. DX9 doesn't, the card driver does for the newer generation of cards (ATI x-series, nVidia 6x00 and 7x00). With every renderstate, sampler (texturestagestate) or vertexdecl (fvf) you set the driver changes the current shaders to match what you have specified. I think using your own shaders combined with the Effect class will be faster and cleaner than setting renderstates everywhere in code.
  2. Quote:Original post by haegarr Quote:Original post by Valor Knight How would you be doing your terrain? I am using geomorphing in each of my terrain patches. Loding 8x8 large terrains would be a lot of information loaded up (I think one of my 513x513 terrains has a ~7meg vertex buffer). How is your terrain handled? As said, I'm still in a planning phase ... so I'm quite not sure whether it will work well. My patches are thought to be 129 by 129 vertices only (there is also a reason besides memory consumption, namely texturing, that lets me think of 65 by 65 vertices, see below; but that may be bad for vertex buffer efficiency). With 8 by 8 patches this means ~1k by ~1k vertices for the total terrain in full LoD. The entire thing is of corse a question of terrain resolution, how far the player could see, and how fast the player could move. This must be balanced well. My first attempt was to let the player look 500 meters ahead. Meanwhile that seems me too much if the terrain should have a resolution of 1 meter from vertex to vertex. Currently I think of 200 to 250 meters (do you have any experience how far a player should see?). Then most of the measures given above have to be halfed/quatered. It depends on what kind of game you are making. In most games players rarely see that far. In Dungeon Siege II I sometimes notice fog or fading at the top of the screen, and that's maybe 20-30 meter away. I think you see maybe up to 100 meters in Battlefield 2, even though the terrains are big. If your players keep their feet on the terrain and don't have the ability to fly or to mount giant eagles and see the world from above, 129x129 meter patches may be overkill. I've been thinking about my own heightmap system as well, and I think it may be better to use meshes that are 32x32. The heightmap itself might be stored in 256x256 or 512x512 files, but it doesn't have to be so that the mesh size is the same as the file dimensions.
  3. Typically you enable the stencil buffer when rendering the wall/floor/terrain where your blood stain/explosion mark will be rendered on, then you render a quad with the decal texture applied using the appropriate stencil operation. The stencil buffer is used so you don't get blood floating in the air when you shoot someone near a corner and the decal is only partially to be applied. These are simple flat decals, if you use more complex geometry then you'll need to think of something else. Try googling for it or the article section here.
  4. If you need normals (and he said he does) then you cannot just use 8 vertices, you'll have to use 24.
  5. Just put the game and engine in different namespaces, that's a start. Make your own class, eg. Engine.DXDevice and pass the control in the constructor of the class, to separate the device from the form. You will probably have some event handlers, like device = new Device(0, DeviceType.Hardware, control, flags, presentParams); device.DeviceLost += new EventHandler(this.OnLostDevice); device.DeviceReset += new EventHandler(this.OnResetDevice); device.DeviceResizing += new CancelEventHandler(this.OnDeviceResizing); OnResetDevice(device, null); You can have those handlers raise your own event and have the game subscribe to this event. This way whenever the device is lost or the resources should be recreated the engine will call the method the game provided.
  6. Try the following in the method where you create the device (partial code): device = new Device(0, DeviceType.Hardware, control, flags, presentParams); device.DeviceLost += new EventHandler(this.OnLostDevice); device.DeviceReset += new EventHandler(this.OnResetDevice); device.DeviceResizing += new CancelEventHandler(this.OnDeviceResizing); OnResetDevice(device, null); and private void OnDeviceResizing(object sender, CancelEventArgs e) { if (presentParams.Windowed == false) e.Cancel = true; }
  7. I assure you don't have textures on your objects right now ? If you run with lighting=off then the color is taken from the vertex color definition. If you turn on lighting and define a light, then it will ignore vertex colors and use the currently set material instead. This might be a bit confusing.
  8. I think it's a good idea, in fact I am planning to do the same. A lot of people learned DirectX with DX7 or 8.0, and ignored new functionality and recommendations and just continued to do what they have always done. Many tutorial sites and webpages with examples just translate DX7 thinking into managed directx, and although it works, it's just not the best way. There are a lot of people that think 'oh a mesh is just for loading an .x file, it's probably slow' while in fact it's just a class that encapsulates a vertex buffer and an index buffer, and a lot of helper methods and properties. So a lot of tutorials show you how to create a separate vertex buffer and index buffer, and then manipulate it. Yet it's easier to just create a mesh, access the VB and IB within and then use mymesh.DrawSubset(); Working with the effect class is just easier than setting a lot of states manually. You can specify different implementations of an effect, for example one with and one without a pixelshader. It makes your code a lot simpler, because all those states are not in code but maintained somewhere else. Everyone has experiences with setting states, that if you add something like an extra alpha stage somewhere that totally different things start to fail, because something is not reset. The way newer cards like the ATI 9800, x800, etc and nvidia 6- and 7-series work is that they use shaders only. Whenever you set a renderstate or texturestagestate the driver dynamically builds a vertex and pixel shader that does what you specify, then uses it. Vertex shaders can be run on the CPU anyway. I've seen a sample that uses a 3.0 vertex shader for heightmapped terrain using the new functionality that a 3.0 vertex shader can access a texture directly (the heightmap). On older cards it runs on the CPU, yet it's very fast.
  9. A general hint: don't clear your screen to black, use dark blue as background. As you noticed there are many things that can cause things to render as all-black, with a black background you can't see it. With a blue background you can see if you have a lighting problem (triangle is there but it's black) or a coordinate problem (nothing is drawn).
  10. Definitely just get Visual C# 2005 express, it's free and it's a full professional development environment. The pro and enterprice versions have some extra stuff that you probably won't need. Although sdl.net and other frameworks might be nice, I'd suggest starting with just standard C#, there's so much you can do with it already. Just google around for tutorials and sample source, you first need to get a feel for how it works, the object oriented approach. C# is a great productive language, it's easier than others to work with, so you make less mistakes and get things done more quickly.
  11. Quote:Original post by Toji As the above poster said, it was a big deal in Q3, because at that point triangles were still precious resources. You skimped wherever you could. Any more, though, the number of triangles are not a big deal. It more a matter of how many passes you can render, and keeping everything grouped in big batches. As such. most modern curved surfaces in games (Doom 3, for example) are pre-calculated and stuck in as static geometry. Dynamic curves still have their place, but it's become impractical and unnessicary in games. The way the Q3 engine was designed didn't allow for a shape to have shared normals and smoothed lighting. If you made a rounded wall or a cylinger out of rectangles you would always see the edges. The curved surfaces of Q3 provided a way to do that. If you design your engine a different way, or if you use meshes with shared normals you can make perfectly smooth looking structures, the Q3 way is no longer neccesary. Cards like the ATI radeon 8500 added hardware support for splines and surfaces, but I don't know if games ever used those, or if they are still supported on modern hardware.
  12. Quote:Original post by AndreTheGiant Ive just done all the necessary research, and consequently just bought a computer 3 days ago: AMD64 X2 3800+ Basically, never buy a 32 bit processor. Both AMD and INTEL are/have switched to 64 bit and its the new thing. Your conclusion might be taking it one step too far. You bought an AMD, while AMD has switched to 64-bits, Intel offers it as an option, you can buy with and without. 64-bits isn't a totally different thing, both a 32-bit and 64-bit P4 are basically the same chip. 64 bits is more of an extension, a few more instructions, a few registers more. But since almost everyone will be running a standard Windows XP with standard software it doesn't even benefit you. Sure, it's nice to buy a newer and faster PC, but you conclude that it has something to do with 64 bits, and it probably doesn't. You are probably not even using the 64-bit options. Basically this is like owning an older beige PC and buying a new black one that's 3x faster and then advising people never to buy a beige PC and always get a black case since it's the new thing.
  13. Quote:Original post by Wixner First of all: This is not a "how-do-i-create-a-mmorpg" topic so holster your flamethrower. Second of all: I am no MMORPG expert - in fact, the only MMORGP I've played seriously so far is World of Warcraft. Until today, every MMORPG game has had the exactly same basic design: slaying monsters in the world is a very cheap way to gain new equipment and items. As in this World of Warcraft comic: http://www.worldofwar.net/comics/heroesofwow/chapter8/index.php, some monsters even got a very powerful weapon. This fact popped two questions in my head: why didn't the monster use that item in it's fight against you and how did the monster aquire such an item? This is just a question of game design. Some games generate random loot when a monster is killed, this can lead to the situation you describe. Other games have both monsters and players have an inventory, and depending on what armor/weapon the monster possesses calculate its attack and defense strength. The latter is much more attractive, and makes the orc with the rusted shortsword a lot easier to kill than the same orc with the steel +3 broadsword of lightning. In Morrowind, when you sell items to a merchant and they are better than what they are wearing, they will often wear that item. And when you kill someone, what you loot is what they were wearing earlier. In games like Diablo, random loot falls to the ground on every kill. Personally I think it's silly to think of eg. wolves walking around the forest with coins, potions, a helmet and a sword, when you can see they are obviously not equipping those items, nor do they have room to store them. You could just make your game such that animals can be looted for hides, meat, bones, etc. and that you only get weapons, armor, coins, etc. from humanoids.
  14. Try Managed DirectX with C#. The visual studio C# express 2005 compiler environment is a free download from the Microsoft site (just like C++ express), and it's very easy. Once you get comfortable with C# programming you could learn how C++ is different and start with that. C# concentrates on getting work done and is still almost as fast, yet it's more difficult to make mistakes in C#. This way you concentrate on actual programming instead of nasty implementation details like header files, pointers to pointers, etc. Search google for eg. 'managed directx tutorial'. Ignore that one about DirectDraw, focus on Direct3D instead.
  15. Quote:Original post by sirob You can check the device caps to see how many stages are supported. MaxTextureBlendStages is the one you're looking for. That defines the maximum number of stages. There is another caps, I believe MaxSimultaneousTextures that defines how many textures can be used in one draw call. Sometimes a card can handle 6 textures and 8 stages, like the Radeon 8500. Not every stage needs a separate texture, for example alpha blending can use one texture, in stage 1 apply it to the mesh for coloring and in stage 2 use it for alpha blending.