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

zaphod2

Members
  • Content count

    32
  • Joined

  • Last visited

Community Reputation

1522 Excellent

About zaphod2

  • Rank
    Member
  1. SDL can be used for many simple things, but this is beyond its capabilities. You have to use directly DirectX or OpenGL. You can still use SDL for creating window, receiving input and such.   Even if you do that, that probably not solves all your problems. The slowest part of the computer is the hard drive, and those freezes may come from the reading of image files from drive. Even if another thread reads the textures, you have to wait for them to be available. One way to go around this to predict what textures will be needed in the future, and load them way before they are needed.
  2. You are using recursion here. Recursion is typically the wrong answer for a problem in an imperative language. It consumes variable amount of stack, and stack is a precious resource. In windows it is typically 1MB. You can use a recursion if you are sure that it doesn't consume too much stack and it decreases the complexity of the code, but that's not true here. You can use a loop here quite easily.   Other problem that I don't see a stopping condition for the recursion (even if you redesign your code to use loops this is important) if it runs too long. If you try to insert two object at the same place in an Octree it will generate infinite number of children. (Even two objects very near can result a huge amount of levels.) So you must stop at a certain cube size or when it reaches at a certain level.  
  3. Well, you can't do that. Unit tests are not for that. Unit tests have strict rules: they have to run fast (all of the project's unit tests must run in a few seconds altogether), they can't access hardware (so no graphics, no sounds, no file I/O, no network I/O, no DB access), they have to test the functionality of a single unit separated from the others. Unit tests are used after every changes or at least before every check-in to repository. So you can't play sounds shows UI for minutes, otherwise your developing speed will decrease drastically.   I know there are GUI tester programs which hooks into the OS, and records keyboard and mouse events, replays them, and checks for window creation. I think they don't graphically test for the windows, but they check if Window creation calls are sent to the OS.   You can also use automation libraries. This is a library, that you can write, accesses your code from outside to start a task, and it can also checks the result the same way. Though it can't really check if the sound is played correctly, but it can check if the correct sound data is sent to the sound engine.   I don't heard of any automatized graphic/sound tester softwares.  
  4. The original code was correct. OnClickListener is an interface, you can't pass values in its anonymous class's constructor. And your onCLick method has a capital L, that's why it can't override.  
  5. Since QuadTrees are used for collision detection (object-object, object-line, object-frustum, etc), the collision bounds should be used for placing the object in the tree. That means Collider component will give the position and size of the object that is used to place the object in the QuadTree.   Or do you want to use the tree for a different purpose?
  6. As I understand QuadTree, it contains object ids or references to game objects, and not components. For me putting a component into a QuadTree is like a grin without a cat. You can access any component through a game object and the appropriate container. This is an extra indirection comparing to your solution, but I don't think it's much slower, especially because it doesn't need to store so much extra data.   Of course you can put some convenience methods in the QuadTree which return components, but it should use the game object and the component containers to do that.   A small optimization is to store the AABB box besides the game object reference in the QuadTree, it might simplify code and makes it a bit faster.   For the layers it's a solution to create a QuadTree for every layer and a common QuadTree containing all the layers. But that sounds like an overkill. Here the best thing you can do is to check which is faster in your case using a single QuadTree or using separated QuadTrees.
  7. He just did that. a+b is a single identifier in Stanza. f(x) and f (x) are also different expressions.   I think this could lead to programmers hunting missing or extra spaces, but I could be wrong, and the language is protected from misspelling for an extent.
  8. On ARM processor the alignment of data is important. It can read/write much faster at aligned positions. So 2-byte long value should be on an even address, and a 4-byte long value should be on an address dividable by 4. There are codes for unaligned read/write but they are different, longer and slower. The compiler must find out which code has to be used, and generally it does a very good job finding it out, but a few times fails.   These failed cases always contain a reinterpret_cast. In your case this is the C-style (int*) casting. That kind of casting is typically used in loading/saving data, or receiving/sending data through network. In other places it is typically just bad design, and should be avoided.   So I recommend you to concentrate all your code that uses reinterpret_cast into one or few classes, and handle the problem there.   And you can create a function for this kind of reading/writing similar to your doLittleBigEndianConversion. Like this: float value = doLittleBigEndianConversion(doUnalignedReading(reinterpret_cast<int*>(ucharPtr + offset)); In that function just use the memcpy trick or read the data byte by byte and assemble it with |.
  9. On Windows (but preferably everywhere else too) always use binary mode file streams, because text mode file streams may replace end of line characters: std::wofstream OutputFileStream(L"C:\\Users\\Administrator\\Desktop\\Test\\Output.txt", std::ios_base::out | std::ios_base::trunc | std::ios_base::binary);
  10. No. When you press a key, a WM_KEYDOWN is sent, and when you release the key, a WM_KEYUP is sent. The WM_KEYPRESSED message repeats during the hold, but it is less useful for game input.
  11. As far as I know, DirectX is not compileable anything else than MSVC. This is a kind of vendor lock-in. I'm not really up-to-date, but I think it's improbable that anything changed in this question.  
  12. Virtual keys have the same physical position in every keyboard layout. So the WASD virtual keys will be on the upper left part on every keyboard. However the text on the actual keys will be different. This is ideal for game control keys, because their position is important, not the text on them. And virtual keys can handle special keys like shift, ctrl etc too.   Off course on the keyboard binding screen you have to translate the name of the virtual key based on the actual keyboard layout with the OS.   If you want to use a textual input, you shouldn't use virtual keys at all. There are many different input methods in different languages that you probably don't want handle. You should use the unicode character codes from the windows messages.  
  13. You need 4 vertices for a rectangular sprite. For 20000 you need 80000 vertices. The maximum value that can be represented by an GL_UNSIGNED_SHORT index is 65535. So you can't draw them with a single draw call.   This is only a guess since I don't see the code that creates the batches.  
  14. I think this is not compressed. It just stores the image as you asked every sample is 1 bit. So a byte contains 8 pixels. You wants every byte is a single pixel, but to that you have to convert it by yourself.   And the periodic letters are there because the lines are padded not to start them in the inside of a byte. (But it's possible it uses a different padding size. e.g. to start on an address dividable by 4.)
  15.   Because it needs the attribute index as input and not the VBO identifier.