• 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

667 Good

About zacaj

  • Rank

Personal Information

  1. If you insist on doing it that way, then malloc is indeed what you want to use if you want to allocate the memory for them without calling the constructors.  You just have to be careful that the first bit of memory in each object doesn't ever end up being zero, otherwise your check wouldn't work.     Alternately, just have an empty constructor.  
  2. Since you didn't allocate them using new there won't be a memory leak
  3. If you want to use any inheritance then you need to story individual pointers to objects, so the 4 bytes are required anyway (and it's not like 4 bytes per object will actually make an impact).  If you only have one object then I'd suggest just giving them a bool active variable and then just setting it to zero to show that they're 'dead' or whatever.  As to the unbearableness, it only affects maybe three lines of your code, and besides, you *are* using C++.  What did you expect?     really though, unless there's some big reason why you're using an array like this, I'd recommend you switch to using a std::vector<SomeObject*>
  4. Off the top of my head, try SomeObject **so; so = new SomeObject*[max_objects]; An array is a pointer to a block of memory, so in your case you want a pointer to a block of pointers that you can then individually allocate
  5. I'm working on a DOOM-esque game in opengl for 7dfps and I need to make the billboarded pickups and enemies.  Is there somewhere which documents the 'correct' way to rotate the quads and to choose which sprite of the enemy to show?  If not, can someone tell me if there's anything wrong with the algorithms I've come up with?   For billboards: I have made the billboard perpendicular to the player's view angle.  I also tried making it perpendicular to a line pointing at the player's position, but it looked worse.     For enemies: radiansToSide=PI*2/8  (8 is the number of sprites I have for enemy) angle=atan2(enemy.y-player.y,enemy.x-player.x) angle+=radiansToside/2    angle/=PI*2 angle*=8 angle=floor(angle) //angle is now an int 0-7
  6. Try using a union union FloatInt { int i; float f; } FloatInt fi; fread(&fi.i,sizeof(FloatInt),1,fp); Are you sure blender wrote a float and not a double?
  7. class Foo; Foo *foo_pointer; //valid. It's just a pointer, so it only needs to know that Foo is a type (which it does from the forward declaration), it doesn't need to know anything about Foo itself Foo foo; //error. Actually making a variable of type Foo (foo_pointer is of type Foo*, not Foo) can't be done, because we don't know how big Foo is. void accessFoo(Foo *foo) { foo->x=4;//also an error. We don't know what variables Foo contains, so there's no way we could access them } class Foo { public: int x; }; //declaring the type Foo down here doesn't affect the code above it Foo foo2; //this is now valid, because Foo is a fully defined type void main() { foo_pointer=new Foo();//although foo_pointer was declared above the Foo class, since *this* code is below the Foo class, it can access foo_pointer's members foo_pointer->x=8; accessFoo(foo_pointer); }
  8. A.h: class B; //forward declaration class A { //contents } B.h: class A; class B { //contents } A.cpp: #include "A.h" #include "B.h" //code  B.cpp: #include "B.h" #include "A.h" //code This is the safest way.  Basically you can't include a file that includes the first file.     Forward declaring a class allows you to define pointers using that type, but not access them.     So in class A you can have   B* b;   but you can't have an inline constructor that calls a function in b or accesses its variables.   Since you don't usually #include a .cpp file directly, it's safe to just include all the classes .h files in your .cpp files
  9. Ah!  When he was saying "the distance from the projected pixel to the floor" I thought he meant vertical distance!  That makes all of his code make sense, even if I still can't get the floor to render right when I change the camera height.  (I've got it working fine for z=0)   In his tutorial, he renders the floor in vertical spans above and below the wall sections, computing for every pixel.  You seem to be suggesting that I do floor spans horizontally?  Wouldn't that mean I'm going to need some kind of complicated algorithm to figure out the horizontal spans, since the walls are all drawn vertically?
  10. Been trying to make a little textured raycaster for fun the past few days.  Walls went fine, but I hit a wall when it came to floor texturing.  No idea how to do it.  So I found http://lodev.org/cgtutor/raycasting2.html , and I was able to adapt their floorcasting code quite easily.  It worked, except that it couldn't handle it when I changed the camera height.  Looking at their section on computing the 'currentDist' (from current pixel to floor, I'm assuming vertically), none of what they say makes any sense. "the distance from a pixel in the center of the screen to the floor is infinite"  What? "for the bottom of the screen, you can choose a distance" I'm assuming this would be where my camera elevation goes in "for example, 1" oh, thank god they chose 1 as their magic number.  It's not like that ever comes up anywhere else "the distance the pixel represents in function of it's height in the bottom half of the screen is inversely related as 1 / height."  that wasn't even proper english.  Plus, when they say 'inversely' and then use 1/x I assume the 1 is from standard math, but it's the only place on the page where they make any reference to the camera height which they so helpfully chose as 1 earlier. "you can use this formula" no explanation on how they got that, or anything.   Is it even possible to have different camera elevations with this technique?  
  11. How am I supposed to get a BMP of every character? And by array you mean a BITMAP array?     Oh look what I found on Google:   http://www.dafont.com/perfect-dos-vga-437.font     How am I supposed to use a TTF in SDL? (I know about SDL_ttf() and such.) I'm assuming I make a black BG that takes up the whole screen, then assign a letter in the TTF to each keystroke? That should work, correct?   If you know about SDL_ttf then what's the problem?
  12. Make a console program that prints out each character and then take a screenshot?  
  13. SDL should be enough.  Just get a BMP of all the characters you can print and make an array you can "print" into.
  14. Go over the points in your grid, calculate distance from center point of circle to that point.  If it's less than the radius of the circle, then do point.z+=(1-distance_away/radius)*height_change to get a gradient
  15. tank movement/control?