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

cshowe

Members
  • Content count

    248
  • Joined

  • Last visited

Community Reputation

360 Neutral

About cshowe

  • Rank
    Member
  1. Go to https://mail.google.com and log in from there.
  2. Quote:Original post by Crypter Quote:Original post by boolean If ever I'm typing up a long post but I can't be assed opening a text editor, every couple of minutes just select all the text and copy it to the clipboard. It’s not a perfect solution, but it’s saved my ass a few times. I do that alot myself. Not just with this forum, either. ...You never know when something like this might happen. I use It's All Text - great little firefox addon to automate the text editor process.
  3. iterator/pointers into a vector are invalidated whenever it is resized. Therefore any operation which might potentially cause a vector to resize itself should be assumed to invalidate all iterators (or pointers) to the contents of the vector. If you don't want this behavior you'll need to use another container like a std::list. List never invalidates iterators to any of it's elements (except obviously iterators to deleted elements are invalid). Alternatively you could maintain a vector of pointers (or better yet smart pointers, or even better boost::ptr_vector)
  4. Have you looked at RTAudio? http://www.music.mcgill.ca/~gary/rtaudio/ It's a pain to compile under visual studio - but it works great.
  5. Quote:Original post by gemin ta Really, you should get into the habit of using buffers instead of the "string" type. e.g: char name[32]; When working with those, though, you need to watch out for the potential for buffer overflows... but that may be too much to worry about if you're just starting. What!?!? Why on earth would you suggest something like that? Using character arrays as strings is an unfortunate throwback to C that should NEVER be used in C++. They are less intuitive, prone to security errors, and lead into the whole arrays/pointers syntax nonsense. To the OP: Stick with std::string. It's a core part of the C++ language and using it correctly will save you hours of debugging and frustration.
  6. http://www.music.mcgill.ca/~gary/rtaudio/ Mildly annoying to compile under visual studio, but it's cross platform realtime audio
  7. Quote:Original post by spyridonz But I was drawn to C++ because of the superior power. What do you think that means?
  8. Would rtaudio work for you? http://www.music.mcgill.ca/~gary/rtaudio/
  9. Quote:Original post by HappyCoder I was wondering, because the limiting factor to how close an object can orbit earth is the atmosphere, how close could something orbit the moon? The limiting factor isn't the atmosphere - it's the velocity at which you would have to be traveling. As your orbit gets smaller you have to go faster to overcome gravity (you could work out the exact equation with the virial theorem). If you could travel sufficiently fast you could orbit the earth at 1 foot - assuming you ignored all the stuff in the way. Admittedly the presence of an atmosphere adds drag which makes it harder to maintain a particular orbital velocity.
  10. Don't do that. Seriously visual studio 6 is an utterly pathetic excuse for a compiler (it's 10+ years old - and was released before C++ was standardized). The express editions of visual studio are free - download Visual C++ Express 2008 - it's a MUCH MUCH better program.
  11. Just use ShellExecute - running an executable is ALOT more complicated than just dumping it into memory and jumping to the entry point. In particular you need to patch up any relocated sections, load DLLs, set up the import address table. All of these things are handled by the windows loader. Furthermore you would probably want to run your other executable in its own address space - which I doubt you can even set up from user mode. There isn't a simple ShellExecuteFromMemory function.
  12. Quote:Original post by thedustbustr A common professional debugger is IDA, I've never used it. IDA isn't a debugger - it's a disassembler. You can run it as a debugger, but it's not designed to be used for debugging nor is it particularly effective as a debugger. My vote goes to Olly.
  13. Whatever you do DON'T USE STRTOK. The function creates far more problems that it solves. It has a weird syntax (passing a buffer once and NULL subsequently) It is often implemented with a static buffer and thus cannot be used with threading or multiple buffer simultaneously It encourages the use of C-strings in C++ which is never a good idea
  14. Not exactly. When your dealing with objects and lighting color becomes ambiguous. Every vertex has 4 "colors" that are used by the lighting equations. These can be set using glMaterial and are: Ambient Diffuse Specular Emissive Note that none of them has anything to do with the Color of the vertex which is set by glColor. Ambient light is general illumination. Everything gets the same amount of ambient light regardless of it's position. This is an approximation of the light that bounces off of walls and everything else in a room. Generally ambient color of an object is the same as it's color. Diffuse light is what you think of when you think of light. It comes from a particular direction and is affected by the position (and distance if you're using attenuation) between the object and light. It also is usually the same as the color of the object. Specular light is related to shiny things. If you look at a shiny object you can see reflections of the light source - these are specular highlights. Generally no matter what the color of the object the specular highlights are the same color as the light - so the specular material property is almost always white. Emissive light is meant to model objects that create their own light. It is unaffected by any light in the scene. I have never used it - but apparently it can be useful. Note also that in addition to materials haveing these 4 properties, lights have ambient, diffuse, and specular properties. The properties of the light and of the material are combined to determine the final color you see on screen. Ok, with all that said. glMaterial calls are a pain in the ass. Furthermore you're generally safe letting specular = white and ambient = diffuse = color. So to make this easier there is GL_COLOR_MATERIAL. If GL_COLOR_MATERIAL is enabled then glColor calls also change the appropriate material property. In particular you can use glColorMaterial to specify what material properties are affected by glColor calls. This means that usually you can just call glEnable(GL_COLOR_MATERIAL) and everything will work just fine - but it's good to understand. This has been sort of a rough overview - read this article http://www.delphi3d.net/articles/viewarticle.php?article=phong.htm or the red book to get an idea of the equations that actually underly all of these things
  15. If you have lighting enabled then vertices are not affected by glColor. You have two options: 1.) Use glMaterial calls to set the diffuse, ambient, and specular properties of the vertices you are drawing. Generally speaking the specular color should be white and the other two should be the same as what you would ordinarily think of as color. Reading up on glMaterial should be enought to give you the idea. 2.) Use color material. glEnable(GL_COLOR_MATERIAL) is an easy fix. It associates the color (as set by glColor) with the material properties. You'll need to read about glColorMaterial and this: http://www.opengl.org/resources/features/KilgardTechniques/oglpitfall/ number 14. Which should good you a feel for this technique. The quick fix is just to use glEnable(GL_COLOR_MATERIAL). However I STRONGLY recommend you read about the functions I mentioned and understand what is going on rather than just pasting that line into your code.