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

Luctus

Members
  • Content count

    859
  • Joined

  • Last visited

Community Reputation

584 Good

About Luctus

  • Rank
    Advanced Member
  1. I would say that in a nutshell, game programming consists of doing simulations. If you can program a simulation of a ball bouncing, you can also program games. A ball-bouncing simulation in it's most basic form consists first of all of a description of the current state of the system: The location and velocity of the ball and the position of any walls. Then at regular intervals, the state of the system is updated by moving the location of the ball a tiny bit according to its velocity and time elapsed since last update, taking any necessary collisions with walls into account by reversing the velocity of the ball along the normal of the wall. After that the walls and the ball at it's current location are drawn to the screen. The repeated application of updating the state of the simulation and drawing will make the apperance of a ball bouncing around on the screen. Now add in an additional step of sampling an input device and using that information for moving the walls in the simulation and you've essentially created a very basic pong game. Any other game will at some abstract level also consist of those same concepts[list] [*]A description of the state of the game [*]Sampling of input [*]Updating the state according to input and rules of the game [*]Rendering the state to screen and other output devices. [/list] The only thing that differ pong from the latest multi-million dollar title is the scale and complexity of how those things are done and the specifics of what is stored in the state and what rules are being applied when updating.
  2. OpenGL

    python setup.py install
  3. Quote:Original post by Zipster But yes, if you think C# is usable, try Python. In another two years you might just be saying the same things about C# as you are about C++ :)Then after that, try a functional language for two years. [wink] Quote: First off, I do not want a compiler between my program and the execution. Compilers are fine for many everyday things. General purpose business applications are fine running compiled code, but when it comes to real-time application development (primarily game development), a compiler is simply not acceptable. I do not want a compiler generating operations how it wants to; I'll manage my own registers, thank you very much. I'll take care of the low level optimizations. I don't want a compiler rewiring my instructions before they're run. I just don't want a compiler at all!Heh, is this what it would have looked like thirty years ago? [smile] Quote:Original post by ApochPiQ Of course one of the big steps to gaining major acceptance will be to target an existing hardware architecture directly, probably through cross-compilation to something that already has a good machine code optimizer.LLVM?
  4. Change the projection matrix to a 2D setup while drawing your UI layer: int viewportWidth = ...; // Set this to width of window int viewportHeight = ...; // Set this to height of window float projectionMatrix[] = {2.0/viewportWidth, 0, 0, -1, 0 -2.0/viewportHeight, 0, 1, 0 0 1 0, 0 0 0 1}; /* Setup 2D drawing */ glMatrixMode(GL_PROJECTION); glPushMatrix(); glLoadMatrixf(projectionMatrix); /* Draw 2D parts */ // A 200x200 pixel rectangle drawn at 100, 100 pixels from the top-left corner of the window. glBegin(GL_QUADS); glVertex2i(100,100); glVertex2i(100,300); glVertex2i(300,300); glVertex2i(300,100); glEnd(); /* Restore to previous coordinate system */ glPopMatrix();
  5. ScummVM is another example of such an opensource engine. Of course, none of these examples actually prove the legality of such projects. Since you would reverse engineer any code and not distribute any original game assets, copyright might not be a problem. Other things such things as patents conceivably could be though. E.g. if the any of the data used in the game needs to be decoded by algorithms that are patented, you would [at least] need to acquire the rights to those in order to be able to legally create an engine for that game. And of course, IANAL.
  6. The generic_hid project I linked to earlier contains the entire process from enumerating all USB HID devices to opening them with CreateFile. Look in the CUsbhidiocDlg::FindTheHID() function in usbhidiocDlg.cpp file from the Usbhidio_vc6 Visual C++ project on that page.
  7. I'm surprised that there isn't an active thread about the PS3 USB jailbreak device here (or I just failed spectacularly in finding it). Since I actually have an Atmel USBKey lying around I've been tempted to try it, but haven't mostly since there seems little point to it until there's a development tool chain available. The possibility of being able to do some PS3 homebrew development is alluring though. How about you though? Are you planning on trying to do some homebrew PS3 development or maybe already have some project in mind? Will you hold off performing any firmware updates as Sony is more than likely to release a patch sometime soon disabling this particular hack? Personally, I bought my PS3 rather recently so I still have a large backlog of older games to go through, so I likely won't be forced to update in he near future by buying some new game. I also don't use PSN, so I imagine I could hold out updating for some time if I needed to. And please, leave the inevitable piracy discussion to some other thread.
  8. For something as simple as a set of buttons, you don't need to write a full-fledged driver yourself. The windows USB-HID (Human Interface Driver) driver is capable of taking care of that for you. For communicating with a HID device, the only thing you actually need is actually the CreateFile function. The tricky part (from the client side) is finding out what device address to pass to CreateFile, for which you would use SetupDiEnumDeviceInterfaces and friends from the Windows Driver Kit. Once you've opened a file on the correct device address, the only thing you actually needs to do to exchange data with the USB device in question is the plain file I/O read and write functions for sending and receiving messages in the format that is defined by the USB device. Lakeview research's HID page have more information regarding developing (for) USB HID devices. The generic_hid project in particular may be of interest. Of course, the above explanation is only for the client side of the communication. You would then either have find a suitable existing device and find out what data format it uses by dumping the device descriptors and decoding them. While that isn't exactly rocket science, it does require some fundamental understanding of the USB protocol specification. That is, if you don't build the device yourself, in which case you would require quite a bit more than just a fundamental understanding of USB devices.
  9. http://www.liberatedgames.com/ keep a reasonably complete list of games and game source code that have been released for free to the public. I'm not too optimistic regarding finding many games released post 2004 there though.
  10. Quote:Original post by MatsVed Unreal still crashes btw. I think you are correct about me wanting to know the number of characters in the string... but my current code doesn't seem to be working... : wchar_t *RightSize = new wchar_t[i]; for(int j = 0; j <= i; j++) RightSize[j] = Line[j]; RightSize is i characters long, but the loop goes from 0 to i which is i+1 characters. I.e. you're writing 1 position past the end of the allocated memory. Quote:Original post by MatsVed This isn't about memory. It's about needing to use the line that was read from the file to load a level in Unreal, and to do that I need to have only the levelname, not a bunch of non-ASCII characters at the end... Doesn't Unreal take null-terminated strings like pretty much every other API? If it does, not only could you skip copying the string into a new array altogether, but it's probably also (one of) the reason it crashes. Unreal simply starts reading one character at time from the beginning of the character array you pass it until it reaches a character with value zero. The string you return from ReadLine don't have a null-terminator, which means that Unreal will read past the end of the allocated memory and likely trigger a memory access violation error. Just add a zero value after your read-loop: while(/*...*/) { ControlChar = Stream->get(); cout << ControlChar; Line[i] = ControlChar; // ... } Line[i] = 0; // Null-terminator But unless you really need to echo the input, I would consider instead just using: wstring Line; (*Stream) >> Line; return Line.c_str();
  11. When you have an #include statement somewhere, what the compiler does is that it actually replaces the #include statement with entire content of the the included file. This means that your definitions: SDL_Surface *screen; SDL_Event event; Will actually be pasted into both Engine.cpp and your main cpp file. When the compiler then tries to link the Engine.o object file with the object file of your main file, it finds that the same variable has been defined twice and don't know what to do. This is resolved by instead of having variable definitions in Engine.h, you prefix them with extern keyword as such, making them into variable declarations: extern SDL_Surface *screen; extern SDL_Event event; This will tell the compiler: "These are defined someplace else, just take my word for it that they will exist and you can use them". Then in one cpp file, it doesn't really matter which one, you put the actual definitions: SDL_Surface *screen; SDL_Event event; For a detailed explanation, see this article. Specifically, you want to read the section Fixing Problem 4.
  12. Quote:Original post by Windryder Quote:Original post by Luctus There isn't a problem connecting to the same address and port more than once, but a single socket can only handle one connection at a time. Therefore the server needs to hand of new clients to separate sockets as they connect which should then be handled separately. Not quite. A single listening socket is perfectly capable of accepting as many connections as needed. I didn't mean to say that a listening socket can only accept a single connection. What I meant was that each call to accept will spawn a new socket, each of which will handle a single connection to a client. Each socket would then need to be handled separately in order to not block each other. Looks like I did quite a terrible job of explaining that though. [smile]
  13. Quote:Original post by Antonym The code tries to wait start reading and sending data to clients until atleast 2 clients are trying to connect. unsigned int NbSockets = Selector.Wait(); //Wait until there are atleast 2 clients in selector if(NbSockets > 2){ // ... serverSocket.Accept(client, &clientAddress); std::cout << "Client connected ! (" << clientAddress << ")" << std::endl; // Add it to the selector Selector.Add(client); // ... } Your problem lies here. Selector contains a set of sockets that it is currently monitoring and Selector.Wait() returns how many of those that are ready for reading. The problem is that Selector can never contain more than exactly one socket at that point (the server socket) since you don't add any more sockets until after the condition (NbSockets > 2). Thus, the condition will never be true and the call to serverSocket.Accept will never happen. When a client connects to the serverSocket and serverSocket.Accept isn't called, any further connection attempts to the listening socket will be denied until the client currently waiting to be accepted have been handled. // Edit: Also, you're actually checking for more than 2 ready sockets, not at least 2 as your comment says.
  14. There isn't a problem connecting to the same address and port more than once, but a single socket can only handle one connection at a time. Therefore the server needs to hand of new clients to separate sockets as they connect which should then be handled separately. My guess is that your server code at the moment is only capable of handling one client at the time, which causes your second client to be refused. You'd have to post the server code too if you need further help than that though.
  15. You also don't need the offscreen buffer. All swing components are already double buffered.