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

EpicCupcakes

Members
  • Content count

    19
  • Joined

  • Last visited

Community Reputation

130 Neutral

About EpicCupcakes

  • Rank
    Member
  1. Right now I am trying to rotate a grid of individual points on the grid's center, to make it spin around its center like a top. However, all I've managed to do is make the grid orbit that point in a circle. How would I go about actually making an entire grid of points rotate around a central axis?
  2. Good news, I've solved the problem. Just wanted to post the solution in case other beginners found themselves having the same troubles. One mistake that may lead to the symptoms I described above is to make your backbuffer the same size as your window. Since the window is actually larger than the screen that it draws (due to the menu bar, borders, etc), your drawn content will be stretched, leading to inaccuracies in the drawing. Increase the size of your backbuffer by the size of the window's edges, borders, etc that you will be drawing it in, and the problem disappears. For example, I used the code:   int gnBackBufferWidth = gnWindowWidth + 16; int gnBackBufferHeight = gnWindowHeight + 40;   to solve the problem. I assume that, depending on your chosen window style (with/out borders, with/out system menu, etc) your values will differ. If that doesn't work, try some of the suggestions above.   Thanks for everyone who responded, I appreciate it.
  3.   Could you give an example of how to do this correction?   Okay, that was a silly question of me. I simply manually added 3 to the x position and 10 to the y position of the clicks I got and the return is more or less accurate enough. But is that really the ideal solution? I've searched the forums and found many people who have encountered the same problem, but they never seem to actually post an official solution that uses the Win API. Does an official solution even exist?
  4.   Could you give an example of how to do this correction?
  5. Edit: I apologize for the misleading post title. I mean to type "Innacurate Draw Positions in DX9".   Hello, all. I'm working on a simple project involving drawing a grid using the DirectX 9 API, and I've run into a problem where the position of shapes drawn to my window don't match up to the position my mouse is (supposedly) in. I'm using this code to retrieve my mouse position:       POINT point;     GetCursorPos(&point);     ScreenToClient(givenhwnd, &point);   but when I draw a shape to any specific area, my mouse shows it as being about 10 pixels off in either direction. Strangely, this only happens the further away from the topleft corner of the window. This is making hit testing my grid hell. I'm not sure if my problem lies in my backbuffer size(1024x768), or in my inability of use AdjustWindowRect correctly (I'm sure I haven't), or whether I should use AdjustWindowRectEx instead, but any help that would be greatly appreciated.   Here are my AdjustWindowRectEx and CreateWindowEx calls. RECT rect = {0,0, gnBackBufferWidth, gnBackBufferHeight}; AdjustWindowRectEx(&rect, GetWindowLong(m_hwnd, WS_OVERLAPPEDWINDOW), FALSE, NULL); m_hwnd = CreateWindowEx ( 0, szClassName, "Grid App", WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, rect.right, rect.bottom, HWND_DESKTOP, NULL, hThisInstance, NULL );
  6. Thank you, that was just the type of answer I was looking for. I'll give your suggestion a try, as XML was always on my radar. The website you offered seems to be empty, though.
  7. Hello all. In preparation for a game I'm making that has quite a large dialogue/visual novel portion to it, I've decided that I needed a way for non-programmers(writers, artist and authors) to manipulate screen elements and create scenes and dialogue without having to learn a high-level coding language like C++ or Java. This has led me to begin designing a scripting language to fit the needs of those authors and writers. However, roaming around on the internet, I've heard of XML and how it is said to shorten the time spent making text parsers and custom scripting languages.I am interested in adapting XML for my project, but there is an important question that I have: Since my goal is to allow a non-programmer with no prior knowledge of programming or scripting languages to write his or her dialogue and scenes in a text file, would XML be too complicated or difficult for them to work with? How complicated would the syntax the author has to learn be? If anyone with experience with using XML in C++ could answer these, it would be greatly appeciated. Thanks.
  8. Thank you for the code and the article. I found both of them to be very useful. I managed to cobble together a function that fit my needs for animation with it. It almost felt like I was in school again! And if anyone knows any graphical program used to plot animation, please post or pm me. I'd really appreciate it.
  9. Hello, all. I am currently working on a simple 2D card game and I want to add some simple animations to it. All I want is to move the cards along a curved or circular path in order to add a bit of flair to the game when the player draws a card. Does anyone know any programs that would allow me to plot that path graphically and then create a file with that path's data that I can use in my code?
  10. [quote name='SiCrane' timestamp='1344758094' post='4968637'] Standard library containers store copies of the objects you insert them, not the original objects. Also, calling erase() on an iterator invalidates that iterator, but returns an iterator to the next object in the container. For standard library sequence containers you would want to use a loop like the following: [code] list<SayProcess>::iterator it = List.begin(); for(; it != List.end();) { it->Say(); it = List.erase(it); } [/code] [/quote] Thank you very much for this response. I didn't know that erase worked on iterators like that. My code works like a charm now! Thanks again.
  11. I've been having a small problem with containers in C++, mainly the "list" container. I've been trying to cycle through a list using an iterator and delete items with a certain criteria, but I've been having problems using the list's "erase" and "remove" functions to delete those items from the list. I don't know if I'm misusing the functions or if the list is simply not maid for jobs like this. Here's the code I've been running: [CODE] #include <iostream> #include <list> using namespace std; class SayProcess { public: SayProcess(){} void Say() { cout << "Say" << endl; } ~SayProcess() { cout << "Deleted" << endl; } }; int main() { SayProcess s1; SayProcess s2; SayProcess s3; list<SayProcess> List; List.push_back(s1); List.push_back(s2); List.push_back(s3); list<SayProcess>::iterator it = List.begin(); for(; it != List.end(); it++) { (*it).Say(); List.erase(it); } cout << "List Completely Deleted!" << endl; char x; cin >> x; return 0; } [/CODE] This is a simplified version of the code that is broken, but it has the same problems. I was hoping to simply have the loop print out each Process's message and then erase the Process from the list, but it's not working the way I had intended. When run, this code will repeatedly print the SayProcess's two messages, the "Say" function's message and the destructor's message until infinity. The fact that it is repeatedly calling the destructor confuses me. Is it copying the item somehow? I feel as if the problem is in my understanding of how either lists or iterators work, but I don't know enough about their design to tell why, and MSDN has been unhelpful. Can anyone help out by telling me what I'm doing wrong?
  12. I apologize. I found the solution to the problem, and it wasn't a directx or direct input problem at all. It was actually just a type-casting error(I was using ints when I should have used floats). Sorry for the false alarm.
  13. Hello all. I just found a strange problem in Direct Input that I was hoping someone could shed some light on. I was programming the controls for a simple shooter in C++, DirectX 9, and Visual C++ 2010 Express when I ran into a problem: Direct Input would not register my Up-Left and Down-Right arrow inputs. At first I had no idea why, but with some testing I found that, for whatever reason, when the Spacebar was being pressed (spacebar being my game's shoot command), Direct Input would not register those two directions hybrid, and only those two hybrid directions. I changed my code a bit, to that instead of having to turn with the arrows and shoot with spacebar, you simply turn and shoot with the arrows. This was a fine solution, but unfortunately my game requires a certain amount of accuracy which is ruined by the new control scheme. Can anyone shed light on why I Direct X can't sense DIK_UP, DIK_LEFT, and DIK_SPACE, or DIK_DOWN, DIK_RIGHT, and DIK_SPACE at the same time, or is it something I've failed to do? I notice that a lot of programmers usually use some sort of DEFINE statement on their keys before working with DirectInput, which I did not do, and I haven't tested defining the keys to see that solves the problem, as I don't know how. Any help would be greatly appreciated. Thanks.
  14. [quote name='Tom KQT' timestamp='1331291367' post='4920633'] I should maybe just add that it's not safe to index the pixels this way. A row in the texture's memory doesn't have to be (texture_width_in_pixels * pixel_size) large, you should use lockedRect.Pitch instead. It probably will work anyway, especially for power-of-two textures (512, 1024 etc), but you can never be really sure. And if you are using textures like 800x600 then the chance that DirectX will add some padding to the rows is very big. You may realise that a 800x600 texture in fact occupies the same memory as if it was 1024x600, with 224 unused blank "pixels" added to every row - then width of the texture is only 800 but pitch is (1024 * number_of_bytes_per_pixel). [/quote] I think I see what you mean, here. My program is now compiling correctly, but when I try to access the pixel's memory, I get an access violation message. Could you give an example as to how one would use lockedRect.Pitch to find out, for example, if a pixel at (64x, 14y) is black?
  15. [quote name='RulerOfNothing' timestamp='1331257271' post='4920554'] The first step is to pass a pointer to a D3DLOCKED_RECT structure to the LockRect function, like this: [CODE] D3DLOCKED_RECT lockedRect; surface->LockRect(&lockedRect,NULL,0); [/CODE] where surface should be replaced by the surface you want to get the pixel data from. Next you need to access the raw pixel data, however this depends on what format the surface is in. Assuming 32-bit colour, you could just do this: [CODE] unsigned int *pixels=lockedRect.pBits; if(pixels[52+15*width]&COLOUR_MASK==0) { //then the pixel at (52,15) is black } [/CODE] where COLOUR_MASK is simply a representation of where the colour bytes are (so if you have a RGBA format it should be 0xFFFFFF00) [/quote] One last question, and I'm through. When I try to compile your example, I get an error stating that "Conversion from 'void*' to pointer to non-'void' requires an explicit cast" reguarding the line: unsigned int *pixels=lockedRect.pBits; Do you know how I can correct this?