• 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

140 Neutral

About slip

  • Rank
  1. @Hodgman. I do agree. Some patterns do emerge and are intuitive. I certainly don't consult a book to determine which patterns to use for a given problem. Which patterns to use is something you get a feel for over time. Not everyone "thinks of" or stumbles across all patterns though, especially if they develop habits that mean they never head down a path to learn potentially more useful patterns.
  2. [url="http://en.wikipedia.org/wiki/Tetrisphere"]Tetrisphere[/url] is a game that first springs to mind that actually use a torus. The game could not work on a sphere so instead they used a torus and did some perspective tricks to make it look like a sphere. taby shows how you can resolve what a position would be. Actually rendering the same scene wrapped around involves different techniques though. A [url="http://en.wikipedia.org/wiki/Portal_rendering"]portal rendering system[/url] is one that could be used to accomplish this. It depends on what kind of game world you have though.
  3. Something that is often overlooked by people learning to program is the importance of design patterns. Design patterns aren't about how to write code in a particular language but rather how to structure code and make it as flexible and robust as possible. [url="http://en.wikipedia.org/wiki/Design_Patterns"]Design Patterns: Elements of Reusable Object-Oriented Software[/url] is a great place to start. This one is quite advanced but something I would recommend C++ programmers to eventually work towards understanding - [url="http://en.wikipedia.org/wiki/Modern_C%2B%2B_Design"]Modern C++ Design[/url]. It makes heavy use of templates. These are just two examples of great books on the topic. I can't stress enough how important software design is for programmers. Simply learning how to write code might allow you to hack things together, but projects that have a high level of complexity (and games certainly fits in this category) are almost impossible to maintain if not designed properly. It was years before I was made aware of design patterns, after which my programming ability improved dramatically.
  4. I guess that's the MS compiler for you...
  5. For those interested I resolved this problem. mBuffer->Unlock(&block1, block1Bytes, &block2, dataSize); should have been mBuffer->Unlock(block1, block1Bytes, block2, dataSize); I was Passing in the address of the address of the locked region instead of just the address. heh.
  6. Hi Buckeye, The docs for Lock say the following dwBytes Size, in bytes, of the portion of the buffer to lock. The buffer is conceptually circular, so this number can exceed the number of bytes between dwOffset and the end of the buffer. http://msdn.microsoft.com/en-us/library/bb206055(VS.85).aspx which makes that code correct for determining length which includes the portion of the buffer from the start to play position. Sorry I forgot to mention that the buffer is looping with DSBPLAY_LOOPING.
  7. This is a long reach, but what OS are you running? I recently had problems with OpenGL on linux. All my textures were white - I never resolved the issue and came to the conclusion it was a driver problem. I could not get drivers working correctly to confirm this though.
  8. Check the include order. To ensure that you use the correct new/delete, typically my rule is that the source files should be the only ones including the new definitions but if they aren't then just make sure you include those last. For example newdelete.h -undefs and defines new and delete File1.cpp #include ... #include ... #include ... #include "newdelete.h" <- last include If you do need to use new and delete in a header (for inline functions), consider if its the best idea. It may enforce a strict usage of that file (i.e can't include from anywhere with fully known behaviour) because your newdelete.h file will override the previously defined one which may not be the desired behaviour following your include.
  9. If you still have the white texture problem, try making sure your texture size is a power (e.g. 128x128). Some (older) graphics cards don't support textures of an arbitrary size.
  10. Hello, I have been trying for days to figure this out and can't find any solutions online. I have created a class that represents and manages a DirectSound buffer. The member mWritePosition is used to track the write position. Originally I did not have as many checks before calling Lock but, since I could not figure out the problem, I added the extra checks to ensure my values are within (what I believe to be) the valid range. I am trying to stream into the buffer up to 'dataSize'. The function is intended to be called and if the available space to be written is less than the desired dataSize then dataSize is adjusted to the maximum. Filling the buffer seems to work as expected up until mWritePosition>=mBufferSize (which it is then changed to mWritePosition-=mBufferSize), at this point Lock constantly returns DSERR_INVALIDPARAM. My guess is that DSERR_INVALIDPARAM returned when the "dangerous" ( between Play Cursor and Write Cursor) is asked to be locked. However my extensive checks seem to ensure these values are correct. It is almost as though Lock has the condition if(requestedWritePosition < writeCursor) return DSERR_INVALIDPARAM; The Commented out section is a text visual representation of the buffer and the pointers within (numbers ticked by too quickly to properly analyse them). Any help is greatly appreciated :) Cheers Sean u32 Buffer::Append(void* data, u32 dataSize) { void* block1=0; DWORD block1Bytes=0; void* block2=0; DWORD block2Bytes=0; DWORD bytesWritten=0; DWORD playPos,writePos,writeLen; HRESULT hRes = mBuffer->GetCurrentPosition(&playPos,&writePos); if(playPos > writePos) if(mWritePosition < writePos || mWritePosition > playPos) { std::cout << "mWritePosition < writePos || mWritePosition > playPos" << std::endl; return 0; } if(mWritePosition < writePos && mWritePosition > playPos) { std::cout << "mWritePosition < writePos && mWritePosition > playPos" << std::endl; return 0; } if (mWritePosition < playPos) writeLen = playPos - mWritePosition; else writeLen = mBufferSize - mWritePosition + playPos; if(dataSize>writeLen) dataSize=writeLen; if(dataSize==0) return 0; //#define PERCENT_BAR_RANGE 65 // u32 playPosP=((playPos* PERCENT_BAR_RANGE)/mBufferSize); // u32 writePosP=((writePos* PERCENT_BAR_RANGE)/mBufferSize); // u32 mwritePosP=((mWritePosition* PERCENT_BAR_RANGE)/mBufferSize); // std::cout << /*mwritePosP << "|" << mWritePosition <<*/ "["; // // for(int p=0;p<PERCENT_BAR_RANGE; ++p) // { // u32 d=(((mWritePosition+writeLen)* PERCENT_BAR_RANGE)/mBufferSize); // u32 d2=0; // if(mWritePosition+writeLen > mBufferSize) // d2=playPosP; // if(p==writePosP && p==playPosP) // std::cout << "X"; // else // if(p==writePosP) // std::cout << "<"; // else // if(p==playPosP) // std::cout << ">"; // else // if(p==mwritePosP) // std::cout << "W"; // else // if((p<d && p>mwritePosP) || p<d2) // std::cout << "D"; // else // std::cout << " "; // } // std::cout << "]\r"; int r=mBuffer->Lock(mWritePosition,dataSize, &block1,&block1Bytes, &block2, &block2Bytes, 0);//DSBLOCK_FROMWRITECURSOR);//DSBLOCK_ENTIREBUFFER); if(r==DS_OK) { if(dataSize>block1Bytes) { memcpy(block1, data, block1Bytes); dataSize-=block1Bytes; bytesWritten+=block1Bytes; if(dataSize>block2Bytes) dataSize=block2Bytes; memcpy(block2, &(((u8*)data)[bytesWritten]), dataSize); bytesWritten+=dataSize; mBuffer->Unlock(&block1, block1Bytes, &block2, dataSize); }else { memcpy(block1, data, dataSize); bytesWritten+=dataSize; mBuffer->Unlock(&block1, dataSize, &block2, 0); } }else { switch(r) { case DSERR_BUFFERLOST: std::cout << "Buffer::Append() - DSERR_BUFFERLOST" << std::endl; break; case DSERR_INVALIDCALL: std::cout << "Buffer::Append() - DSERR_INVALIDCALL" << std::endl; break; case DSERR_INVALIDPARAM: std::cout << "Buffer::Append() - DSERR_INVALIDPARAM" << std::endl; break; case DSERR_PRIOLEVELNEEDED: std::cout << "Buffer::Append() - DSERR_BUFFERLOST" << std::endl; break; }; } mWritePosition+=bytesWritten; if(mWritePosition>=mBufferSize) { mWritePosition-=mBufferSize; } return bytesWritten; }
  11. Got to step three and said screw it. Typical American thing to do for a step. What ever happened to the concept of the internet where It didn't matter where you're from?
  12. Heya, Just checked out your Midi's, downloaded a couple of MP3's and now checkin out VibeCity. Have you tried making MOD's at all?