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

anonuser

Members
  • Content count

    152
  • Joined

  • Last visited

Community Reputation

148 Neutral

About anonuser

  • Rank
    Member
  1. Actually IBM has done quite a lot of work on easing this process. Octopiler! The idea is you write your program sequentially it does magic and generates you PPE and SPE programs. Complete with a caching mechinism to ease the pain of SPE DMA fetching (they can't use anything but their local store). It tries to optimize just about everything. It's damn impressive. Give it a look. http://domino.research.ibm.com/comm/research_projects.nsf/pages/cellcompiler.index.html
  2. Okay OpenGL isn't really responsible for this. OpenGL should just be drawing a graphical representation of the internal state of your game. With that said if you use the standard mouse and don't turn in off you can translate the coordinates from world to local coordinates and then perform intersection test. Google will show you the way to do this. If you're using windows there are specific messages for obtaining the coordinates of the mouse.
  3. It is possible. With a little magic. friend a method, that'll help. Or have a static method and make sure a pointer to this is passed in as an argument and call the regular method. A great example of this is done at stromcode's Win32 tutorial. It completely encapsulates Win32 windows. Including the WinProc. Which is a callback method. Stromcode's C++ Win32
  4. I'm going to be a bit different here. I'd say learn C. Get a very solid grasp of C because C is a simple language and very basic. C++ is a very complex language and I'd feel bad if someone learns the language as C with classes when there's so much more to it. And all of C++ is hard to take in all at once. After you're done with C I'd take what you know about procedural programming and keep it close to heart but then forget everything. Learn threaded design and programming. It'll be more useful than you know. After you have your threaded fun done. Then go for an advanced language cause then you'll begin to appreciate the abstractions and the wonderufl things you can do to automate a lot of things. To me it cleans up a lot of things. Wanting to head to game programming is a dangerous thing. It's not easy. Writing a game takes a lot of skill and effort. Especially if you want to do ground breaking work. The problem lies in the fact a game must be an entire system. You have a lot more to deal with than most programs. I mean most business applications I write are simple. You have data, process data, spit result. A game well is a game! There's so much too it! I'd start off writing simple programs to test your skills. Then maybe fun little things like a sprite animator. Work your way to it. Don't dive in, you'll drown. Good luck!
  5. Give it the WM_CHILD attribute, which should be accessable in the dialog editor. Then when creating it give it a parent window, it'll be embedded as such. Remember coordinates follow the parent. Hope this helps. You may wanna look into Win32 a bit more. If you're going to be doing a control the best way would probably be active x. just because that's the norm. Me I don't do it because I'm lazy, but hell the proper way to create new controls and such is with active x. That way you can take it to and from different languages.
  6. Quote:Original post by Leadorn Conclusion: go with the crowd I officially give up the fight. I will start to use STL. I belive in the STL. Lets wrap this up by posting good books or urls about STL. First The Official Place: http://www.sgi.com/tech/stl/ Effective STL is a great book. I've skimmed through it, but never bought it. Most of it makes sense.
  7. Maybe no matter what you do you're going to face challenges eithe way. Me personally I thread my games. Render is on its on thread while an input layer is in its own thread. Sounds are either fire and forget, or synced with the enviornment. This has is ups and downs. The major down is obviously thread synchronization. Which can be a pain but synchronization quickly becomes second nature. I like doing things this way. In code you can create really obvious layers and keep things really abstract and easy to work with. I hope this helps. I am a multithreaded game programmer ;D Actually I'm just not scared of threads and have been using them for a good while. A lot of people get scared and think its unneeded complexity. And that may be true for some people. The hardest part is learning to design things with threads in mind. Procedural designs just don't cut it as they have in the past. And C# is an amazing language for concurrent programming! It comes with a pre-allocated thread pool waiting for a task. In essecence all C# programs are multithreaded even the single threaded programs. Its incredibly easy to create and manage thread in C#. And if you ever go to Win32 its not that bad either. Win32 gives a really great threading model.
  8. Okay the title is a bit confusing? All of the std namespace (which includes the stl) is the root of all evil? C++ streams are evil? That's odd. I mean lets be honest here. You just hate C++. There's nothing wrong with that, a lot of people don't like the language. To ask others to step forth and hate C++ is a bit of a bold step? The worst hole in your argument is that you admit to not knowing what you're talking about. And that is a big problem. I like C++, the STL and all it has to offer. I see usefulness that the STL has brought to us C++ programmers. I didn't learn this over night, and it took some time for my mind to fully wrap around all the concepts presented in the STL. There was a time when I was learning C++ and I was basically writing C with classes. Which C++ is a lot more than just that. It might be wise to sit down and evaluate your stance on C++. You may want to move on to a different language. This is to mean no offense to you in any way, its just simply meant to make you think. It's nice you post a picture with numbers. I too can post pictures with numbers. There's not much validity in your statements without allowing us to examine what you've already done.
  9. A dirty way maybe to set a timer to send a redraw message to the window This might work. I've not tried it but I'd imagine it'd work. So InvalidateRect(hwnd, NULL, TRUE); //redraw entire client area, and erase the background
  10. Goto's make sense for bailing out. C++ has exceptions for that, but still useful none the less. cause you can test all your cases have a goto to throw an exception if you don't want to be descript about it. Apple uses then in Carbon for skipping code on error. It makes a lot of sense too, becasue they have clean up code they wanna execute before quitting.
  11. Well I was starting a new project and its just a typical win32 project. I always go empty on settings with no links to MFC or ATL, I set those up by hand if I need them. Well out of laziness I was going to use a Dialog as my window and I had it all designed out and I do the wrap my win32 stuff inside the class thing. so it look something like this // note static is only in the prototype its just her to let you know NOTE: lParam should be a pointer to this. and DlgProc is the internal proc that has full access to a class. I like this method it gives me the entire class inside of all the win32 stuff. Which is great. static BOOL CALLBACK CWindow::stDlgProc(...) { //assume msg is the proper variable //assume lParam is the proper variable //assume hwnd is the proper variable CWindow* pwinThis = NULL; if(msg == WM_INITDIALOG) { SetWindowLongPtr(hwnd, GWLP_USERDATA, (LONG)lParam); return TRUE; } pwinThis = GetWindowLongPtr(hwnd, GWLP_USERDATA); return pwinThis->DlgProc(); } Now I didn't think much of this at first cause it did call DlgProc but only out of coincidence. pwinThis is actually NULL, visual studio can dereference it somehow, honestly I have no idea how. It should be throwing unhandled exceptions on dereferencing null but it doesn't until I try to acess this inside of DlgProc which is a private method in the class. The Debugger proved this was null but somehow I was inside of the right method. This was done from memory and should be accurate, but the problem is that the first message is not WM_INITDIALOG, or at least its not being passed to me. It's 48 in decimal but no idea which message that is in hex. Any ideas why or how I wouldn't be getting the WM_INITDIALOG message. My plan is to go back and just do a sandbox child window of my layout and place as a control on a regular window.
  12. Personally I avoid this like the plauge. Its not particularly harmful to keep them open during the duration of your program because the OS takes care of closing open file handles anyway. This is however bad practice. And I'd actually use the system for File IO.
  13. Quote:Original post by Fruny Quote:Original post by anonuser So if you have a large set of data, thread it. Not going to help unless you have multiple CPUs. Even then, the loop is memory-bound. The only way I can think to make that might make that code faster would be to interleave the arrays in memory ( [A,B,C,A,B,C,...] rather than [A,A,A...] [B,B,B...] [C,C,C...] ) to better exploit locality of reference (and CPU cache). I did forget to mention the CPU part, thanks for the correction.
  14. Fast math routines, that's about all I can think of. The only other thing is not doing it in series since you have a finite set of data it shouldn't be that hard. But this is C and the overhead of creating threads would probably make all potential performance nil for all but large data sets. So if you have a large set of data, thread it.
  15. Question 1: NO, you allocated it on the heap so you need to get rid of it yourself. Destructors destroy the class, just because the variable pointing the area of allocated memory doesn't exist any more doesn't mean something else could now be pointing to it and using it. Question 2: Yes the loop will be skipped if the initial value is 0 and will stop on 0. Hope this helps. (edit: Sorry misread my answer was correct except for a misleading yes)