gdunbar

Members
  • Content count

    295
  • Joined

  • Last visited

Community Reputation

2198 Excellent

About gdunbar

  • Rank
    Crossbones+

Personal Information

  • Interests
    Design
    Programming
  1. 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
  2. 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.
  3. 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
  4. 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
  5. 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
  6. 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.
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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.
  12. 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
  13. 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
  14. ASCII C++ Graphics Library

    Are you already familiar with PDCurses? http://pdcurses.sourceforge.net/ That is probably the most commonly used for things like roguelikes. There appears to be a more win32 centric version as well: http://www.projectpluto.com/win32a.htm   Using SDL might be just as reasonable at this point, though.   Good luck! Geoff
  15. A good example of why keeping your code clean of compiler warnings is a good idea. In this case, it was pointing out a completely legitimate issue.   Also, consider using "static const int ..." instead of #define when possible. It would have probably prevented this issue in the first place.   Good luck! Geoff