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

adder_noir

Members
  • Content count

    507
  • Joined

  • Last visited

Community Reputation

275 Neutral

About adder_noir

  • Rank
    GDNet+
  1. Ok thanks for the information. I voted you guys all up I've found a way if anyone is interested? It uses some standard functions and a small one I wrote too.
  2. Hi, is there a way to find a specific char string in a file using the fread and all those f functions without going into large comparison iteration loops? I've looked through all these f functions that I know of and I can't find anything? Any ideas? Cheers
  3. That's a really good reply which has given me more idea what's going on and how much of it I really need to know about. Thanks so much I voted you up
  4. Thanks for the reply. That's a very detailed and technically accomplished post which I have to read quite a few times to understand. Some of it to be honest I don't understand neither am I ever likely to in truth. I'm afraid my knowledge is limited only to that which I have read from the author of my book. In it he describes dynamic buffers as: 1) Being created and stored somewhere between the CPU and the GPU on the bus. 2) Somehow being connected to the concept of AGP but this now appears doubtful. 3) Something that has to be copied over the bus from their location to the GPU every frame even if the vertex positions haven't changed. That's as much as I know. Reading your writings it appears they are still valid and still in use and I think that is as much as I would ever need to know, therefore I will keep them as part of the engine. Thanks
  5. Hi! The engine I'm working on - which I'm almost getting to enjoy - has a part of it that uses a dynamic vertex buffer. It stems from the days of AGP graphics cards. As far as I know that has now been surpassed long since by PCI-Express cards. A dynamic vertex buffer is a kind of temporary buffer which is created in the AGP ram between the CPU and the GPU. It has the advantage of being fast, yet has the drawback of having to be rendered every frame whether the vertices have changed positions or not. You can, for example use them for models where the vertices deform. You could I suppose use one to deform a vehicle that was crashing or maybe make a nice waterfall with one. They are also used for animations which again has now been surpassed by using shaders to do the animations. Why am I asking? Well the engine I'm working on is old, but my word it's teaching me alot. I've successfully updated it to use effect files over the old assembly method it once used. Not an easy task for an intermediate programmer but anyways it's done now and touch wood is all nice and clean too with no memory leaks or problems. When running in debug mode the program exits normally which I hope is a good sign all memory has been properly taken care of which I've tried to ensure with the constructor and destructor. Learned a few things about variable initialisation I can tell you! Anyways, dynamic vertex buffers are a huge part of the vertex manager class in the engine. The original author even used a method of catching render calls and delaying them so they could be sorted into little mini caches based on the texture (or was it the material? - can't remember) they were using. This meant instead of rendering a few triangles you rendered maybe a couple of thousand per render call, even if the render calls in the application weren't all made at the same time. What I want to know is: 1) Can I completely do away with dynamic vertex buffers given the presence of PCI-E in the modern age or should I keep them in case they are needed? 2) Are they even still supported by modern releases of DirectX 9.0 and onwards? Would be most helpful to know cheers
  6. That might just be it! Let me go have a look
  7. That's a very clear and helpful reply thanks I'm using the effects framework. I find it nice and easy for someone like me The engine is a very old engine from the late 90's called the ZFX engine. I'm learning it totally from scratch so I can be familiar with absolutely all parts of it. I'm also upgrading alot of stuff in it too. So much so infact that the only reason I'm not writing my own engine is because so many of the required protocol procedures are already written and working in this engine I've acquired. It gives me a great chance to really understand an engine, even if I switch to a newer one before making anything. It also means if I can get good frame rates out of it after doing all the upgrades and plugging a new SIMD math library and physics engine into it I've got like total entire control of what's going on of something I know intimately. Hard but enjoyable too in some ways. Cheers
  8. Hi, I would like some advice on how to set-up a texture ready for being processed by a vertex and pixel shader. I've had a look at my engine and I'm aware of the following function as I was before (this is DirectX by the way): [code]HRESULT SetTexture( [in] DWORD Sampler, [in] IDirect3DBaseTexture9 *pTexture );[/code] I always thought the first argument was just an index from 0 - 7 to access one of the available 8 textures. I've run DX stuff before without shaders and this was the only function I had to call. However in the vertex manager of my engine I've found alot more function calls as well as the one mentioned above: [code]m_pDevice->SetTextureStageState(iT, D3DTSS_TEXCOORDINDEX, 0); m_pDevice->SetTextureStageState(iT, D3DTSS_COLORARG1, D3DTA_TEXTURE); m_pDevice->SetTextureStageState(iT, D3DTSS_COLORARG2, D3DTA_CURRENT); m_pDevice->SetTextureStageState(iT, D3DTSS_COLOROP, m_pZFXD3D->GetTOP(iT));[/code] iT is just an integer which corresponds to a texture index (i.e. 1 of 8 available). As for the DWORD flags involved the potential combinations are enormous after a quick look at MS's website. So: 1) Do I need all these extra SetTextureStage functions? 2) If so is there a kind of safe default flag set-up which avoids over-complicating things? I just want to load a texture into a shader file (effect file) that's all. Access it's texel and add it to the ambient light for now. Any ideas? Thanks
  9. Great! I love straightforward replies!!! That's so good it means I can simplify the way light and materials are handled in the application now Thanks so much - now back to learning for me
  10. Hi! I'm ok getting a vertex shader to work using the effect file format. I just use the handy DX functions to load the effect file. BUT! I'm told a pixel shader can also be used with the effect file format! Now as far as I know you can have or have to have a vertex shader and a pixel shader active simultaneously. That sounds ok. I'm getting confused though. 1)If you're using an effect file is the vertex shader and pixel shader combined into one .fx file? 2)If 1) is not the case do you need to call the Effect->BeginPass(int) for both the vertex shader and pixel shaders or can you combine both into one BeginPass call? Pretty sorry state of affairs but I really need with this one Thanks so much for any clarity anyone can offer
  11. Hi this problem has now been solved. It was being caused by the argument list to the DLL function. Because I was passing a pointer into the function, not a pointer-to-a-pointer, the function was making a copy of the effect pointer which got deleted when it went out of scope in the DLL function. A real schoolboy error (apparently) Here is a working version (although perhaps still not perfect but it shows the fix anyhow): [code]void CreateEffectFromFile(LPDIRECT3DDEVICE9 d3ddev, LPCTSTR shaderFile, LPD3DXEFFECT* ppEffect, LPD3DXBUFFER errorLog, D3DXHANDLE* technique) { HRESULT hr = D3DXCreateEffectFromFile(d3ddev, shaderFile, 0, 0, 0, 0, ppEffect, &errorLog); (*ppEffect)->FindNextValidTechnique(NULL, technique); return; }[/code] And that's it. I thought that the function would preserve the pointer but it didn't it copied it. A pointer to a pointer fixed it
  12. That's good enough for me Andy. Thanks so much for the reply. Voted up
  13. Hi, I'm making an upgrade to my engine and I'm wondering what to do! In short is it possible to use the DirectX SetMaterial() method and use a shader too, or do you have to handle everything inside the shader including the effects of the material combined with the ambient light? it's no really big deal if this is so, I just have to send a few more matrices over I guess I'd appreciate some insight if possible cheers.
  14. Oh and be careful you don't get too mad whens tuff goes wrong. I'm sure I read somewhere that it angers God or something.
  15. [quote]A Newbie, A Vision, No budget. Absolutely no experience.[/quote] Perfect! The more sh*t you are in at the start the better your chances of survival once/if you have or learn or display the incredible patience required to emerge from the first few years of appalling confusion. Projects like this are without doubt the most interesting of all if they succeed. Just be prepared for how long it will take. Forget deadlines, let it take as long as it wants to take is the only advice I feel just about comfortable enough to give