JeffCarp

Members
  • Content count

    37
  • Joined

  • Last visited

Community Reputation

597 Good

About JeffCarp

  • Rank
    Member
  1. (Sorry, no idea about FIFA, but...) Study up on game ROM hacking (i.e.: SNES, PSX, whatever if need be) What you are ideally looking for when doing this sort of thing is called a "game trainer", AKA Game Shark for PC :-) Hex editor on steroids, basically. There's a piece of software called Bit Slicer for OS X -- https://github.com/zorgiepoo/Bit-Slicer -- that works well for real-time game hacking. Not sure about other platforms, but I'm sure you can find one fairly easily! Good luck.   Cheers, Jeff
  2. Hi,   I don't have yet any experience with anything past rudimentary collision detection, but I've been watching the Handmade Hero series, and skimming through your post reminds me of several key points that the series illustrates in great detail how to go about solving. Although his game genre is not a platformer, most all the math applies equally the same.    Check out the episode guide -- starting at roughly "Week 10: Player Collision" and onwards; "Basic Minkowski-based Collision Detection", at an absolute minimum, should be watched. It might even be best to start at "Week 9: Vector Math and Player Movement", tough to say.   Cheers, Jeff
  3. Where do I begin?

    If you are new to programming, I'd strongly suggest starting out with a higher-level language like Python or perhaps C# in order to familiarize yourself with the basic constructs of a programming language. All programming languages share the same basic foundation; program flow, algorithms, data structures and so on -- these are the things you should start getting comfortable with.
  4. On Mac, the standard location would be ~/Library/Application Support/<app_name>. Another fairly common spot is ~/Documents/<app_name>. For saved games that you wish to access across multiple users: /Users/Shared/Library/Application Support/<app_name> or even /Users/Shared/<app_name>. For data that you shouldn't touch ... this sort of data typically reside in the application's bundle.
  5. What are the apps which you use most ?

    I see. Fair enough! :-) I feel much the same way in regard to performance -- stability & performance (in that order) are my two minimum requirements for me using any piece of software on a daily basis. It's often surprising to me just how much half a second can make a difference!   Funny you mention command line ... I find myself preferring it often times purely because of performance :D In oh so many different ways!   I dunno how old of a development system you are talking about, but holy hell is SourceTree completely useless on an old AMD64 (1 core), 1GB RAM, 5200 RPM SATA disk drive ;<o 
  6. What are the apps which you use most ?

      I'm curious ... what are your mixed feelings? Personally, I love using the app for daily git stuff, but I find that the hg UI feels a bit ... lacking to me. The UI terminology changes for doing what is conceptually the same thing in the git UI -- thankfully, most are obvious to me -- and otherwise behaves in a completely different fashion than what I am use to with the git UI.   Granted, most of my complaints are probably just out of ignorance of hg (I know just the bare minimum to get around on the command line, and nothing of the app conceptually) ... it is also probably true that abstracting the UI seamlessly between git and hg is fundamentally incompatible as they imaginably go about doing things differently (i.e.: deleting a branch).
  7. Totally did not know that you could use 'using' keyword like that. Cool stuff!   I learn something new every day! :-) 
  8. What are the apps which you use most ?

    (My primary development box runs on Mac OS X, but I also have older Windows 7 and Xubuntu Linux systems setup for testing builds out on)   Sublime Text 2* clang* (C++ building all day long!) iTerm2 for general usage of the shell via BASH* git* SourceTree Google Chrome* GIMP Xee3 (image viewer) nvAlt (additional notes)   These are some of my everyday, MUST HAVE or DIE apps :-)
  9. At the given units, 10ms *probably* isn't noticed by the player, but it may certainly matter to the simulation, i.e.: you are expecting the results of such and such to be an exact value (or perhaps somewhere in between values). This has been my case in a somewhat similar problem to the OP. Perhaps not the best way of going about things, but just sayin'. (One alternative to expecting precise values might include looking for a particular "event" being broadcast?)   Sorry, no idea if this really pertains to the OP, though ...
  10. Wow, Eric Lengyel's advice was really inspirational for me! Thank you for sharing it. :-)     I just wanted to try augmenting his advice here, saying just how important this cruel, but vital this can be for the success of the engine. No body enjoys throwing away code that they've poured blood and tears into, but you gotta do what you gotta do at the end of the day when the long haul is what matters. It reminds me of my difficult decision resulting in throwing away ~10k lines (in other words, ~3..4mo) of in-house GUI code in favor of an external library. Ultimately saved me a ton of time, I think -- ~3..4mo is nothing but a drop in the bucket in the long haul. After all, throwing away code is somewhat misleading, as you still retain all that you learned during the course of development.
  11. better way of loading images? SDL2

    The ways you would go about not using a pointer still involve using a pointer, so you must still become comfortable with the concept in order to go about abstracting away the detail (a fancy term for hiding the implementation details). You cannot (sanely) change the underlying implementation to not use pointers, but you certainly can hide the fact that it does use them. The most common method of going about doing what you want is by creating a "wrapper" class that maintains the SDL_Surface pointer and operates on it internally (the fancy term for this is, I believe, "encapsulation"), but exposes a public API for doing the things it needs to do -- 99% of the time without ever needing to deal with the pointer. Doing so also has the side benefits of being able to conveniently do other things related to the task of SDL_image (such as conversion of image surfaces). Most importantly of all, it allows you to do the Right Thing (TM) and perform the appropriate checks for error states that can occur.   For example, I have done just that in a class called Image (admittedly, not a great name for it!), that is really nothing more than a glorified SDL_Surface pointer with many convenience helper methods for working with the struct in a more pleasant manner, such as disk I/O, color keying, creation, etc. I would gladly share the source with you, but I'm afraid it would further compromise / post-pone learning about pointers, but if you insist... I suppose I would. It really does become obvious / trivial once you understand pointers a bit better.       You are well upon your way to understanding, then! :-) Manually managing memory (pointers), in practice, often times boils down to: a) remembering to free it at the appropriate time; b) always ensure the pointer is valid (not NULL) before usage -- failure can include, but is not limited to, running out of memory, incorrect usage of the API and so forth. Easier said than done, sometimes. As for the first case (remembering to free) -- this is why **after** you have a solid understanding of pointers, people will often suggest considering the use of smart pointers when applicable; these help to eliminate the most common problem with pointers, and that is ... forgetting to free 'em! They aren't perfect, but no single programming tool ever is :-) (Note that "raw pointers" simply refer to the use of non-smart pointers). Whether you end up using them is purely preferential, in my opinion (that's probably going to be a very controversial opinion there...)   P.S. Although pointers may appear scary at first, I promise you that once that ah-ha! moment comes, you'll realize how beautifully simple they are :-) For me, I came to find out that it was just the syntax of the pointer that was "scary" (more like confusing in my case).    My ah-ha! moment came when I realized that everything in a program is represented by a sequence of memory offsets, filled with values that you've set (sometimes indirectly), executed in the fashion you've set forth by jumping to and fro the memory offsets. Pointers do not hide this "secret" implementation detail, and let you manipulate these values stored in the memory offsets directly, whereas other language constructs do the same but through hiding that detail, to help facilitate ease of use. I apologize if mentioning this was a waste of your time, I was just trying to help facilitate your ah-ha! moment in the way that it helped me.   (Sorry, that must be like the longest P.S. ever written lol)
  12. I'd suggest developing the engine around a game, and not the other way around, so to help prevent bloated, over-engineered APIs. It will give you an obvious and immediate "roadmap" at any given time. Major engine milestones / dev cycles (versions?) can be considered in terms of what it means to the game. A completed game then signifies an important evolution in the development of the engine.   I suggest this also because I've found even if you write unit tests that mimic the game for the engine during the development cycle of a feature, you'll never be able to anticipate everything. Game states are a wonderfully complex beast. Sometimes the issues are simple things like mere API usage, other times obscure bugs that only happen when in the context of a particular hierarchy of parts working together. In other words: engine tests represent theory, whereas a game represents practice.   Allocate time. Lots of it. It becomes an enemy that you can only win through accepting that you only have so much of it. Use it wisely.   These are a few of the many lessons I've been learning as I've delved into game development non-professionally in the past ~2 years, anyhow. Above all else, remember to have fun and often take deep breaths! :-)
  13. Wow. Plethora of great information!