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

Physics

Members
  • Content count

    10
  • Joined

  • Last visited

Community Reputation

146 Neutral

About Physics

  • Rank
    Member
  1. It's probably slow for both libraries, because they use libpng. I'll see if there's anything I can do to speed it up in DevIL.
  2. Thanks a lot for the information, crawfis. I have some ideas on how to do this now.
  3. Quote:Original post by gjaegy I would second the advice to remove all global variables. This is actually evil and not a good-practice anyway. I would suggest you first make Devil object-oriented. This will first remove the need of these global variables, and will consolidate Devil architecture. Once the project has been better structured, you will be able to identify pieces of code that might need mutex protection. This might sound like a lot of work (even if not so many classes would be required - from what I know from the source code), but I think this is actually mandatory to make Devil stable, structured and easier to use. Also, once done, making it thread-safe would be much easier than as in its current state. Just my personal opinion though... I agree. I have been thinking the past few days about rewriting it in C++, though it would still have a C-style interface so that other languages can use it. It will be a lot of work, and it will probably take awhile, since I am really busy with school. Thanks for your thoughts on it.
  4. Kylotan, thanks a lot for the explanation. Forward binary compatibility is important, so if I end up having to pass the structs around, I will just put reserved space at the end like you suggested. Jesse, a look at the mutex page definitely makes me think that this would be the most elegant way to do it. Is there much of a performance hit for locking/unlocking a mutex? This may be a silly question, but how hard is it to debug multiple threads in MSVC++? Normally, you can look at your call stack to see where you are, so I imagine it would change if you had multiple threads running.
  5. That makes sense, though I have a question on it. First off, how large would I make the g_state array? I could initialize it with ilInit and get users to call that before they create any threads. They could specify the maximum number of threads that they may use via a parameter. The problem that I had that prompted me to look at making DevIL thread-safe was an issue I had with two programs using it at the same time. I have been using a program called ThumbView that generates thumbnail images in Windows Explorer with DevIL. I had a folder open that had some images in it while I was testing my image library with a program I wrote. The program wrote an image to that folder, so Windows called ThumbView to update the thumbnail. At this point, both my program and ThumbView were using DevIL. In my program, some global parameters changed in its copy of DevIL when they should not have, and I can only attribute it to ThumbView somehow using the same copy. I always thought that programs using the same DLL would get their own copy of it in memory. It looks like I was wrong on that point.
  6. Okay, hopefully I am putting this in the right forum. This is more of a programming practice question than anything else in my opinion. This post may be a little long, since I will try to explain this as best as I can. I am the lead developer on DevIL, and I have recently been thinking about making DevIL thread-safe. Unfortunately, being away from programming for several years, I am not very familiar with thread safety and proper programming practices with it. Right now, DevIL keeps a list of images in an array that is accessed through ilGenImages/ilBindImage (similar to OpenGL). The images are pointers to structs that contain all the information about an image, including data. When you call ilBindImage, a global image pointer called iCurImage points to an entry in that array. Any functions that you call always operate on iCurImage. Obviously, this would not work at all in a multithreaded application (with multiple threads calling DevIL). The main part of making DevIL thread-safe would not be too terribly hard to implement, since I can just require an image pointer parameter to any function instead of using iCurImage. This is actually what DevIL did in its very first releases (when it was called OpenIL). I can also provide an interface to DevIL that mimics the current functionality, so hopefully people will not be put off by a new interface. Now comes the part that I am really not sure of. There are a lot of parameters that you can set via ilEnable/ilDisable and ilSetInteger. Things like setting the quality of .jpg files that are saved, compression types for files that support them, etc. These values are all currently stored in a global struct. I can see two possible paths to take here. I could require that the user pass a pointer of the struct that they fill out and control (or could be automatically filled out by a DevIL function with defaults). The other option that I see is to have the global struct like I have it now. There are not any pointers in this structure - just integers. This option would be preferable, but I am not sure how safe this is to do. What happens if a user is trying to change the value of one of the members of the struct while a function in DevIL is trying to access the same struct member to find out what it should do? The problem I see with the first option is that if I add a member to the struct in a future version of DevIL, programs compiled against an earlier version will not work properly. I have a similar problem with read/write functions. I allow the user to overload the read/write functions so that DevIL can load from either file streams or memory (along with any other method they wish to implement). I think that I will have to require that a structure with pointers to these functions will have to be passed when loading or saving, especially since one thread may want to load from memory while the other is trying to load from a file. Changing a global file access function mid-load would be pretty disastrous. Does anyone have any suggestions, comments or links to pages that describe proper thread-safe programming practices? [Edited by - Physics on January 14, 2009 6:09:08 AM]
  7. Yep, ilGetData returns a pointer to the pixel data of the frame of the animation after you call ilActiveImage.
  8. Are you enabling ILUT_GL_USE_S3TC and ILUT_GL_GEN_S3TC?