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


GDNet+ Basic
  • Content count

  • Joined

  • Last visited

Community Reputation

4544 Excellent

About Aldacron

  • Rank

Personal Information

  1. I doubt the error message is coming from SDL_QueryTexture (it shouldn't be attempting to load any DLLs). I see two problems with your code that you need to correct before reaching that conclusion. First, you aren't checking the return value of the function call. The function is documented to return zero on success and a negative error code on failure. Second, based on your usage of w and h in textRender, it seems you've declared both as pointers. This is likely the source of your segfault. SDL_QueryTexture does not store pointers to ints in the width and height parameters. It stores the actual values of the width and height. That means you have to pass it the addresses of actual int variables, not uninitialized int pointers. In other words: // This is certain to cause a segault int *w, *h; SDL_QueryTexture(tex, NULL, NULL, w, h); The correct way to do this is like so: int w = 0, h = 0; if(SDL_QueryTexture(tex, NULL, NULL, &w, &h) < 0) { fprintf(stderr, "Error on texture query: %s", SDL_GetError()); }
  2. No, that's not quite right. You can throw an exception from inside any class method, but the object you throw has to be in the java.lang.Throwable hierarchy. For instance, you can't, for example, do "throw new Integer(1)" because the class Integer is not a subclass of Throwable. The compiler sometimes inserts instructions into the generated byte code that check certain operations and throw exceptions if you've done something the language spec says you aren't supposed to. For example, accessing a null class reference will cause a NullPointerException to be thrown, or you get an ArrayOutOfBoundsException if you try to access an array with an invalid index. ArithmeticExceptions are thrown when you do something like divide by zero, or some other invalid operation. Conceptually, it's no different than if you were doing the check yourself, perhaps something like this: int divideInts(int lhs, int rhs) { if(rhs == 0) { throw new ArithmeticException("Divide by zero!"); } return lhs / rhs; } Except the compiler inserts the check for you. This is not "throw" but "throws". It's called an Exception Specification and tells both the compiler and the programmer which exceptions a function might possibly throw. Your Java book should have told you that there are two types of exceptions in Java: checked exceptions and runtime exceptions. Any checked exceptions a method might throw must be specified in an exception specification in the method signature. Any methods calling that method must either catch and handle those exceptions, or also include an exception specification. Runtime exceptions are exempt from these rules. They may still be caught, but they are not required to be and they are never included in exception specifications. NullPointerException and ArithmeticException are examples of runtime exceptions (as is any exception type that extends java.lang.RuntimeException). If you have a method that includes a "new ServerSocket", then you need to either wrap that up in a try..catch and handle any IOException that is thrown or add a "throws IOException" specification to your method signature, since IOException is a checked exception. Any other checked exceptions your method might throw, either because you choose to throw them or because you call a method that throws them and you don't catch them, will also need to be added to the specification. I don't know which book you're reading, but I feel I should recommend Core Java by Clay Horstmann. He goes into a lot of detail and covers a number of corner cases that most books don't. He explains exception handling particularly well.
  3. This is the kind of thing you can figure out in two minutes. Knock up a simple test program like this one: class Foo { public static void main(String[] args) { try { throwIfLessThan(5, 10); System.out.println("After function call"); } catch(Exception e) { e.printStackTrace(); } System.out.println("Outside the catch block!"); } static int throwIfLessThan(int i, int n) throws Exception { if(i < n) { throw new Exception("i is less than n!"); } return i + n; } } Then javac Foo.java followed by java Foo should answer your question. Spoiler alert: The first println is never executed if the exception is thrown. Yes. For one, it gives you the freedom to move the error handling from the lowest level call site to the most appropriate place for it to be handled, without worrying that error codes are checked appropriately all along the chain. For another, it provides a mechanism for resources to be automatically cleaned up regardless of whether or not the exception is thrown (in Java, via the AutoClosable interface, in C++, by ensuring destructors are called as the stack unwinds).
  4. SDL

    I strongly recommend you pick up a copy of Understanding and Using C Pointers. It covers a lot of ground, even some that intermediate C and C++ programmers might be ignorant of. If you grok the material in that book, you'll be much more able to recognize any self-inflicted pointer-related bugs (and they almost always are self-inflicted) when they pop up.
  5. Somehow this makes me feel much older than I am. But happy birthday!
  6. In the "In Practice" section at learnopengl.com, you'll find a tutorial for a 2D Breakout game.
  7. You're already doing that anyway, so how does using Kyronet mean you can't continue? You can use Kyronet or any other networking library to implement the server and then use any language + library combination you want to implement the client. All the client has to do is open a single socket, connect to the server, and start parsing packets. It need neither know nor care how the server is implemented.  
  8. In my experience, there are generally three camps on this. One says that namespaces should never be used as an architectural device, but solely to disambiguate symbols and avoid collisions. Another says that the namespace is a great tool for creating a modular hierarchy. Those in the third camp take no position either way and do just whatever feels right at the time.   So the advice I give to you is: do whatever you'd like. Companies that use C++ will have in-house coding guidelines that will (or should) specify how they want you to use namespaces. On your own time, as there's no One True Way here, you can do as you please. If that means not using namespaces at all, that's fine, too. Though, I do advise that if you're considering releasing a library for general consumption and the user experience is important to you, then you should first take a look at existing popular libraries in that domain to see what they do.
  9. I don't touch the OMF stuff anymore. With DMD, it's all -m64 for me now. That's what prompted me to add support to some of the Derelict packages to be used as static bindings -- it's feasible now without the OMF/COFF headache. Unfortunately, until DUB supports -m32mscoff fully, it's still an annoyance for 32-bit.
  10. There are some static and dynamic D bindings for Nuklear already, so you can jump right in. 
  11. I always liked the gridless inventories. What's the issue about stacking items? It can still done automatically when items are added to the inventory, but it can also be done manually through drag and drop. I never had a problem with it in Ultima Online.
  12. Platforms are incidental. Your primary goal should be focusing on the underlying fundamentals of game development. In the beginning, it's difficult to separate one from the other, since it's all new, but once you get the fundamentals down you can put them into effect on any platform you want. Since you are already familiar with Java, you might as well just keep with it while you learn what you need to know about game development. libGDX is fine for that. So is JavaFX, or even Swing.   If you can fork out a little bit of money, 'Mastering LibGDX Game Development', despite the 'Mastering' in the title, gets the best reviews of any book I've seen on getting started with LibGDX (and it's fairly recent). It expects the reader to already be comfortable with Java, so if you're good on that score it should be money well spent. 'Beginning Java 8 Games Development' is also a decent introduction to 2D game programming with JavaFX. If you can afford it, I would recommend you get both. It will help you in mentally separating the platform from the game concepts.
  13. You might try libtcod.
  14.     Any networking library is going to have 'server' and 'client' entities that wrap up all the socket stuff and hide the details. These are just regular old objects that you use to create your actual server and client software. They aren't requiring you to use any sort of proprietary software, which seems to be what you are alluding to. And Kryonet is open source with a liberal license (the BSD three-clause). It won't impact releasing the source of your project at all, so there's no "code licensing" to worry about. If you're doing this as a learning exercise, that's fine, but if you want to just get stuff done, Kryonet is a fine option.
  15. Most of the freely-available spritesheets I've seen, such as those at opengameart, have regularly sized grids. Load the spritesheet up in an image editor, like Gimp or Paint.Net, and use the rectangle tool to determine the size of the grid cells. It should be fairly easy with a grid of regularly sized cells, in which case you can determine the position of each sprite based on the cell size. Irregular cells will be more tedious, but doable with a bit of persistence, and you can then make your own file of meta data.