Jump to content
  • Advertisement

The Perfect K

  • Content Count

  • Joined

  • Last visited

Community Reputation

103 Neutral

About The Perfect K

  • Rank

Personal Information

  • Interests
  1. The Perfect K

    How is Discrete Math used in video games

    Heh, I do suppose that's true, and much to your sub-point at the end of your original post. Funny thing though, the very first bits of calculus I learned was pretty much this how to transform to discrete values in order to solve equations by hand (or with a calculator). It sort of blurs the line, in my mind at least, when calculus ends and begins. But hey, at least through this back and forth we gave the OP an other example of how discrete computation is important in computer programming.
  2. The Perfect K

    How is Discrete Math used in video games

    Hoo boy, I know this is a topic on discrete math, but I just wanted to chime in and say that I use calculus all the time in programming. Any type of signal processing is going to need calculus. Fourier transforms in particular are extremely useful for, say, virtual reality or eeg programming. Dead reckoning positional tracking is essentially all calculus. Any time you have anything that is sample based over time, you're going to be using calculus. This applies to both EE and general comp sci.
  3. I think there is real value in lowering the barrier for entry to computer programming, personally. Game development is a perfect example of how many different disciplines a person must be competent in before they can start pumping out programs of real worth. Using an example from non-game dev experience I've had, I once did a project with a doctor, who had all sorts of doctor problems and wants he needed solved by a computer program, but who wasn't a computer programmer. He very intimately understood his industry and the type of problems he'd run into, but had no way to put it into a program. After several weeks of back and forth of him teaching me things he'd needed to communicate for me to build his program for him, it wound up that the programming aspect of the project was actually pretty simple. Most of the time was actually getting me, the developer, up to speed in his area of expertise. I often think of the number of people who have life-altering ideas that they just cannot translate into a program. Every skill someone is required to pick up is a barrier to entry that'll turn away a percentage of the potential total developer population. This is a bit at odds with my general advice that someone looking to strengthen their grasp of computer programming should start low, with old hardware, so that they can fully grasp the ins and outs of talking to a machine. Indeed, computer programming knowledge is very cumulative. But put it this way -- how many great authors would we have lost, if it was a prerequisite that one knows how to press and form their own paper by hand?
  4. The Perfect K

    What am I not understanding about programming?

    A couple of things to note - It sounds like you have a high level understanding of how various concepts work (i.e. a integer variable is used to store numbers you need to use) but not a low level understand of how or why they work. I've been there, when I started programming 26 years ago, I really remember the frustration that came form this incomplete grasp of how computers actually worked. I remember being your shoes, telling my dad "I wish there was some sort of perfect *variable* that could communicate everything I need to other parts of my program at once." What you are missing is an understanding of how memory works. I notice you didn't really mention any understanding of pointers. Understanding how computer memory works will open all sorts of doors for you. Part of the reason C and C++ are very powerful is because they completely expose all memory management to the individual. That's both a perk and a huge responsibility. I would say begin with a tutorial on pointers in C. This is a pretty good one, it's only about 3 hours long tops but it'll drastically increase your understanding of memory: To your other questions about how to structure your program, that falls more into design patterns than understanding of the mechanics of computers. Where you seem to be concentrating is on the rote basics of computer programming (syntax, etc). Nobody on this or any other forum can tell you definitively how you should structure your program, because there is no single right or wrong way to do this. However, over decades, a bunch of design patterns have popped up that'll really make things simpler. These patterns tend to rely on a pretty good understanding of the memory management stuff I posted above. This is a terrific guide for learning the types of patterns you are interested in, written from a former EA programmer: http://gameprogrammingpatterns.com/ Again, I strongly urge you gain a good grasp of memory before diving into any books or tutorials on design patterns, because they are conceptually very deeply intertwined. It's basically impossible to describe a union, for example, if you have no grasp of memory. My final bit of advice (from experience) is to pick a retro computer or game console and learn it inside and out. I started with the Sega Genesis. Learning m68k microprocessor assembly is actually how I taught myself memory management (there was no youtube back in those days lol). Retro computers are simple enough that a single person can grasp every bit of their architecture, and the things they teach are very much applicable today. EDIT: Forgot to post some links for retro computer programming help. Today, there are lots and lots of really wonderful guides out there that'll walk you through some low level assembly. My personal area of expertise is the motorola 68000 microprocessor, a wonderful chip to learn. It's got a very wide pedigree, being the chip that powered the Amiga and Sega Genesis, along with countless arcade machines. Scoopex is one of the best known Amiga Demoscene groups, and there is a long series of tutorials online by Photon, one of their main coders. This is probably pretty advanced, but I still want to give it a shout: A slower reference for beginners is MarkeyJester's Sega Genesis guide: http://mrjester.hapisan.com/04_MC68/ MarkeyJester is actually a regular poster over at Sonic Retro, which itself has become a pretty wonderful repository for 68000 programming. Diving into their hacking guide will reveal all sorts of goodies: http://info.sonicretro.org/SCHG:Sonic_Community_Hacking_Guide And finally, a more modern tutorial is this one by the dev behind the new Megadrive game, Tanglewood: https://bigevilcorporation.co.uk/2012/02/28/sega-megadrive-1-getting-started/ These 68k ASM guides are probably all beyond you at the moment, but this is the type of stuff I started with, so who knows! I'd definitely recommend starting with the C pointers tutorials I posted above, but didn't want to leave you stranded if you wanted to dive much deeper. Once you start grasping this stuff, you'll come to understand why C was colloquially called ASM++ once upon a time. Best of luck, and most importantly don't give up! Everybody goes through these growing pains.
  5. The Perfect K

    SDL - Saving large images?

    I'm having a strange problem with SDL and I'm not too sure where to find out how to solve it. My dad bought a commercial large scanner to help him archive a bunch of architectural drawings he has. Only problem is that the scanner's thread is messed up, and thus a large, thick black line appears in the middle of all his scans. He's not too computer savvy, so he asked me if I could write a program that would automatically crop out the black line that appears on his scans. That normally wouldn't be a problem, except that his scans are 14650x14650 big. I'm running into a problem with SDL when I'm trying to save the resulting cropped image as a bmp. I've tried two methods with differing results. If I load the image into a surface then try to save that surface, I get a small blank BMP as a result. Pseudo code as follows: SDL_Surface* Image; Image = load_image("Scan.bmp") ~~a bunch of stuff that crops image~~ SDL_SaveBMP(Image, "Output.bmp"); that would result in a file called output.bmp that is just a tiny white square. If I blit image onto a screen surface (or really any other surface that's not that big) I can save the bmp, but it'll only save the size of the surface. Pseudo code as follows: SDL_Surface* screen; SDL_Surface* image; ~~~code which sets up screen to be 1280x768 big~~ image = load_image("Scan.bmp"); ~~~code which blits image to screen~~ SDL_SaveBMP(screen, "Output.bmp"); That would result in a bmp called Output, which is 1280x768 big, which contains a corner of the scan. I'm guessing the problem lies with trying to work with such a large image. I've been trying to look up documentation to see if there are any size restrictions on SDL_SaveBMP but I can't find anything. Anyone know what could be causing this? Or maybe an alternative method I could use?
  • 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!