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

Indifferent

Members
  • Content count

    29
  • Joined

  • Last visited

Community Reputation

576 Good

About Indifferent

  • Rank
    Member
  1. This can happen if you've accidentally targeted a different architecture from the one you're running, so give the project settings a check. You could be building a 64-bit binary and then trying to run it on a 32-bit copy of Windows, as an example.
  2. I'm trying to load a font from a buffer using AddFontMemResourceEx and then creating a D3D font with D3DXCreateFont. This works fine on every platform except Windows XP, where it causes the wrong characters to be printed.   The problem seems to occur with OpenType (.otf) fonts whereas TrueType (.ttf) seem to work fine.   Here's the relevant code (modified slightly for brevity): char* fontName = "FontName"; HANDLE hFont = AddFontMemResourceEx(data, size, 0, &loaded); if(!hFont || !loaded) { //error handling } HRESULT res = D3DXCreateFont(device, 30, 0, FW_NORMAL, 1, FALSE, DEFAULT_CHARSET, OUT_DEFAULT_PRECIS, ANTIALIASED_QUALITY, DEFAULT_PITCH | FF_DONTCARE, fontName, &font); if(res != S_OK) { //error handling } ...some code later... //DrawTextA/W, makes no difference to the result font->DrawTextW(NULL, message, -1, &rect, DT_LEFT | DT_NOCLIP, colour); Here's an example render:     Interestingly, if I make a small change to the code to save the font to disk and then reload it with another API function, everything works fine: char* fontName= "FontName"; char* fileName = "FontName.otf"; FILE* file = fopen(fileName, "w+b"); fwrite(data, size, 1, file); fclose(file); //non-ex version works fine too AddFontResourceEx(fileName, FR_PRIVATE, 0); HRESULT res = D3DXCreateFont(device, 30, 0, FW_NORMAL, 1, FALSE, DEFAULT_CHARSET, OUT_DEFAULT_PRECIS, ANTIALIASED_QUALITY, DEFAULT_PITCH | FF_DONTCARE, fontName, &font); if(res != S_OK) { //error handling } ...some code later... //DrawTextA/W, makes no difference to the result font->DrawTextW(NULL, message, -1, &rect, DT_LEFT | DT_NOCLIP, colour); It seems this is likely some issue with XP's API but before I go converting to TTF, I'd be happy to hear any ideas/theories on what could be going wrong.   Edit: Seems I was misled into believing that converting to a TTF was a possible solution. After using AddFontResource(Ex) in prior testing, the font hadn't been freed correctly and was still being silently used rather than the TTF version I was loading with AddFontMemResourceEx.   Second edit: After going through the same tests again, ensuring it wasn't quietly using an already opened font without my knowing, it seems setting the FR_NOT_ENUM flag in AddFontResourceEx causes the same corruption issue under XP. If providing a name to load isn't valid when using the flag, I'm not entirely sure: Why it'd work fine on later versions of Windows. How you'd ever make use of the font. Why, rather than failing, it'd find the font but display the incorrect glyphs.
  3.   I have to disagree entirely. Your code and the interfaces to said code ought to designed in a way that prevents any potential misuse and mistakes by programmers that need to make use of them. Having to document gotchas because you didn't bother to design properly is a sign of lazy implementation on your part, not the other way around.   If there's something you don't want programmers to do with your code, do what you can to prevent it.
  4. 32-bit applications will run on both 32-bit and 64-bit versions of Windows whereas 64-bit applications will only work on 64-bit versions.   One advantage that 64-bit applications can afford is a potential performance boost and another is that they can exceed the 32-bit memory limit, allowing them to use more than 4GB (the limit varies depending on hardware and OS).   For small personal projects, it usually doesn't matter which you choose.
  5. Nope, there's absolutely nothing wrong with using an existing engine. See [url=http://scientificninja.com/blog/write-games-not-engines]this[/url] article.
  6. Books and tutorials are great but they're simply no substitute for trying things out on your own, outside of the examples the present. Therefore, I'd recommend that you get your hands dirty and start writing code for your own projects.   Once you've got the basics of the language down, you should be in a strong position to start solving your problems by using the techniques shown in the examples you've covered. Sure, the examples won't be identical to what you're trying to achieve but the logical thinking and language elements covered should give you a starting point with which to approach your own problems.   You may well benefit from a good book or two on C++ or even game development as I don't know what resources you've used thus far but the point still stands; roll your sleeves up, get your hands dirty and write code! ;)
  7.   Playstations use OpenGL.   Not quite. The PS3 uses Sony's PSGL which is based on OpenGL ES (Embedded Systems) and [url=http://en.wikipedia.org/wiki/Cg_%28programming_language%29]Cg[/url].
  8. You'll need to give us information on what you're using to build the game.
  9. My point was that a slight bit of reformatting won't really get around the fact that it's copy/pasted tutorial code.   Ultimately, it's a Pong clone to help him understand the basics of game programming and there's nothing wrong with following along with and using code from a tutorial if that's what you're comfortable with. It's just my opinion that having him go back for the sake of it isn't a productive use of his time.
  10. Others may disagree but I'd just go ahead and credit the code at the top of the file, providing a link to the tutorial. You've made an effort to contact him and waited a more than reasonable amount of time for a response.   It's such basic code that any rearrangement is likely going to be largely superficial.
  11. I place constructors at the top the class and then I'll usually group public and private methods together and within those groups I'll try to keep closely related methods (accessor methods, for example) in close proximity to one another. Granted, all methods in a class should be related but some are more so than others.   In regards to NetBeans' refactoring options, I don't believe you can reorder methods in a class automatically.
  12. You need to focus on code organisation and formatting at this stage. Split each class into its own [url=http://stackoverflow.com/questions/1106149/what-is-a-translation-unit-in-c]translation unit[/url] with a header and accompanying source file and then include them where appropriate.   You should also be a little bit more liberal with spacing your code out; the extreme density makes it difficult to follow.   For example: if(adjustment==1){adjustment=-distance; foundEnd1=true; //switch adjustment to other side }else if(adjustment==-1){adjustment=distance; foundEnd2=true; //an end has been found }else if(adjustment==distance){adjustment=-1; foundEnd1=true; }else{adjustment=1; foundEnd2=true;}   Compared with: if (adjustment == 1) {     adjustment = -distance;     foundEnd1 = true; //switch adjustment to other side } else if (adjustment == -1) {     adjustment = distance;     foundEnd2 = true; //an end has been found } else if (adjustment == distance) {     adjustment =-1;     foundEnd1 = true; } else {     adjustment = 1;     foundEnd2 = true; }   You don't have to format your code in this exact style, it's just an example of spacing your code out to make it more readable.   As a tip, you don't need to compare bools to true or false explicitly. if(foundDirection==true) if(foundDirection==false)   The shorter way is simply: if(foundDirection) if(!foundDirection)   There are a few other points that could be made but I think you should focus on getting the code structured into a more readable form before you're bombarded by minutiae.
  13.   There are no hard and fast rules in programming, even when it comes to some of the more controversial constructs. Although a global or two likely won't hurt, you should get into the habit of doing what you can to avoid needing them.
  14. There are a few possibilities that spring to mind: You're using a single core CPU (doubtful). The program's affinity mask restricts it to using one core (doubtful, can check with Task Manager). Your physics thread has some form of synchronisation that causes it to wait for the rendering/main thread. One of the two threads is doing some heavy lifting that makes use of multiple cores, perhaps through libraries or system calls, that bottlenecks the other. Beyond the above reasons and assuming I haven't overlooked anything obvious, it's difficult to say without seeing any code or the program run.   As a note, you ought to double check to make sure that the time wasting white loop is actually indeed wasting CPU time. The common compilers are generally smart enough to optimise out code that has no side-effects.
  15. Just a note but this is Microsoft's code (if the header didn't give it away) that forms part of the CRT (C runtime). This particular feature is a fairly basic mechanism for attempting to detect buffer overflows that have written over the return value on the stack. By placing a cookie before the return address and then comparing a saved cookie with the global copy before returning, the runtime can tell whether the return address may have been modified by an overflow, either accidentally or maliciously. If you want disable it, just make sure the /GS switch isn't set. I'd advise against this though as it's most likely that the problem is in your own code or that of some library you're using, not the runtime's. Either posting a copy of the faulty executable or better still, the source, would be helpful.   Edit: Site went down during posting, not having much luck tonight. Glad to hear you've got it sorted one way or another.