Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

2203 Excellent

About gdunbar

  • Rank

Personal Information


  • Twitter
  1. I pretty much agree with corysama, though I have a slightly different conclusion. Yes, assert is a great idea. However, when writing code, you should (almost) always handle errors. Who knows where this code is going to end up being used? And it is much easier to properly handle the error now when writing the code, instead of trying to bolt on error handling 2 years from now. Almost certainly, this means, in addition to the assert, throw an exception. It's trivial for you to write the code, today's processors are fast, and non-thrown exceptions are cheap, so there's no reason to remove the exception for production code. Then, someday if someone wants to handle the case of the non-invertible matrix, all they need to do is catch the exception, instead of having to agonize over what to do. Error codes are a legitimate error handling mechanism as well, but exceptions are preferred modern C++. Unless you are planning to use your code on some limited embedded platform or the like, I would go for exceptions.
  2. gdunbar

    ACotGK Cancelled

    So for the past year or so I've been noodling around with the sequel to "Temple of the Abyssal Winds", tentatively called "The Accursed Crown of the Giant King". Here's a screenshot: I'm happy with the engine, game system, and graphics improvements I've made over that time. The game itself, well, I'm just not feeling it. So, before even announcing the game, I'm cancelling it. But never fear, faithful fans. I'm announcing the successor, and it's called... The Accursed Crown of the Giant King! So what's different? Basically I'm moving away from the carefully manicured scripting and level editing, and going to more of an open world and procedural generated design. The D&D 3rd edition inspired engine and gameplay is the same, but the world and game itself will be much more open and exploration friendly, which is what I really enjoy in similar games. I'm still working out the details, so stay tuned.
  3. I'm a little skeptical of this question; I'm not really sure there is a list of languages that you _must_ know to be well rounded. However, I'm surprised no one has mentioned assembly yet. To be really well rounded, you should at least be able to read assembly, even with an instruction reference in hand. Writing is trickier, but perhaps everyone should write something trivial in assembly at least once. X86, ARM, 68000 (!), it really doesn't matter, you should pick one up if you are really going to claim to be well rounded. It's definitely worth doing if you want to have an understanding of what your computer is actually doing. Hints: ARM is simpler than X86, so if you have a choice... C and C++ compilers will typically spit out disassembly for you; it can be illuminating to look at the assembly code that a (simple) C function produces. Probably a good idea to learn a relatively low-level language like C first. (Is there another choice anymore? Pascal?) The game Human Resource Machine actually isn't a half-bad assembly primer. But, maybe I'm just old. Geoff
  4. My experience is that timeGetTime (albeit with a timeBeginPeriod(1) call) is more than sufficiently accurate for my game on any hardware I've run into. Now, my game is an RPG without really strict timing accuracy requirements, but things would still be a bit jerky if timeGetTime wasn't sufficiently accurate. I haven't seen that at all, even on moderately older hardware. I suspect that much of the QueryPerformanceCounter advice comes from a previous era of flakier hardware and slower processors. My advice to anyone writing a game now would be to try timeGetTime to start, and only move on from there you run into an actual issue.
  5. Cool bug! I can't pick it out through code inspection, but I can offer a suggestion. Do you know how to use your debugger? Are you familiar with conditional breakpoints? In a case like this, where you have a clearly reproducible problem, you should be able to get right to the problem. Set a breakpoint when you are processing the problematic node. Probably right after: x=n.getxPos(); y=n.getyPos(); Set the condition such that x and y are the problem node. (23,6), I think. Then if you step through the code it should become apparent what's going wrong. Particularly, I don't think node (23,5) should even get evaluated in A*, but there it is on the path. Hope that helps, Geoff
  6. Slightly contrarian view: I prefer #2 to #1, and definitely over #4.   #2 is very much a common C/C++ pattern. Pass in the output object (or struct in C) and let the function fill it out. It looks a little weird at first but experienced programmers will understand exactly what's going on. Probably even more so than #1, and definitely more so than #4.   #2 removes any confusion about where the allocation takes place, who is responsible for it, etc. The caller has control over whether the object gets reused, and that decision can easily be refactored at some later point without changing the function at all.   Now, it's not all pretty and functional looking. But, this is C++ we're talking about. If you wanted pretty, you came to the wrong place.   Sorry to disagree. I mostly just wanted to point out that #2 is common C/C++ and you'll run into it all over the place.   Geoff
  7. gdunbar

    Temple of the Abyssal Winds Mac Support

    Unfortunately I couldn't make 10.11 support work easily, so 10.12 is required. I tried! I'm sure it could be made to work, but there is other stuff I'd like to be working on.   Geoff
  8. Announcing version 5.0 of the classic-style role playing game Temple of the Abyssal Winds! Temple of the Abyssal Winds is available on Windows, Mac, iPad, and iPhone. Chapter 1 is free to download and play for all platforms, and chapters 2-6 are available for purchase, as in-app purchases or on the TotAW website. [media][/media] You can find more information, including download instructions, on the website: http://www.prankster.com/totaw Version 5.0 is a huge update! Unfortunately breaking past saved games, but it's totally worth it. Partial list of changes: New effect subtypes like fire and charm, new resistance system for effects, and spells and items to go with the new resistances. Map improvements, both mini-map and world map. Expanded bard-song abilities for budding minstrels. Improved combat, including weapon differentiation and high level enhancements. Many minor RPG system improvements. Visual and usability improvements (check out the new camera!) Many bugfixes and minor features. Merry Prankster Games is a one-man band indie development studio, started in 1995 making the play-by-email game Atlantis. For more information about Merry Prankster Games visit: http://www.prankster.com or email Geoff Dunbar at totaw@prankster.com.
  9. Not a direct solution to your problem, but a hint that I found helpful:   Microsoft provides a number of free virtual machine images:   https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/   These are ostensibly for testing IE compatibility, but are a great way to test out your game on a "clean" install of Windows without having to have a computer dedicated to that purpose. You might have issues with DirectX compatibility with your virtualization software, but I've gotten great use from these.   Hope that helps someone, Geoff
  10. gdunbar

    Temple of the Abyssal Winds Mac Support

    Hmm... apparently your Mac doesn't support the graphics API I'm using:   https://support.apple.com/en-us/HT205073   I'll look into 10.11 support for the next release I do, but sadly it won't help you. Sorry!   Geoff
  11. gdunbar

    Temple of the Abyssal Winds Mac Support

    I'm not sure... I can look into it. I'm using a newer graphics API, but I think it is supported on 10.11.   That said: Why wouldn't you upgrade to 10.12? How many people don't upgrade? I thought Mac users were pretty aggressive about keeping their OS at the latest version.   Thanks, Geoff
  12. That is discouraging. Well, I can't personally vouch for it, but MIT's OS class seems to hit all of the right areas: https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-828-operating-system-engineering-fall-2012/ Good luck! Geoff
  13. This is a great example of why a Computer Science education is a good idea, even for a game programmer. It's been awhile for me, but we had two very relevant classes.   One was something like "Concurrent Programming", where we learned all about synchronization primitives and the theoretical underpinnings. Perhaps most importantly, all the things that can go wrong, conflicts, deadlocks, race conditions, and the like.   The second was "Operating Systems", where we learned all about process and thread management and scheduling. In particular, as I believe is common, we implemented parts of a toy OS (I think it was NachOS, in my case). This totally removed the mystery of how these "magic" synchronization primitives work. Threads and processes are just "things" that can be manipulated, same as any other part of a machine.   So, get your degree, kids! It will be worth it in the end.
  14. Is it an option for you to pick up a used Mac mini or something? Life will be much easier, if that is possible for you. The more time you can spend developing your game, and the less time fighting against Apple, the better, in my book.   Geoff
  15. gdunbar

    Good form using "this" pointer?

    I think the best advice in this thread is to avoid cases where you have the same symbol (x and y, in the original example) referring to multiple things in the same scope. You can work around it, and get away with it for a time, but if the code lives long enough, it will end in tears.   Given that, I find the this-> syntax somewhat distasteful (talking C++, here. Maybe it makes more sense in C# or something, I don't know). At best it is redundant (member variables are in scope in member functions), at worst it is working around the multiple symbol issue above. I would stay away from it.   I generally use m_, but that is just because I'm in the habit from the company I worked at for years. I could easily be talked out of it on a new project.   Good luck! Geoff
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!