# Cagnazzo

Member

9

140 Neutral

• Rank
Newbie
1. ## Trying to solve mathematical problem using programing skills

[quote name='hupsilardee' timestamp='1354200231' post='5005306'] Python is great for this kind of thing. I just pull up the shell and hack a quick function together. Great for GCD, LCM, co-primality, etc. Quicker than C++ to compile and run. I just rewrite the function every session I want to use it, which ends up with me learning the definitions of these things very thoroughly (and degrading my mental arithmetic). [/quote] Python is pretty good, but you'd be amazed at how well Haskell does with Project Euler. There are tons of problems that it just chews through with no thought. Which is exactly what you'd expect from a purely functional language, really [img]http://public.gamedev.net//public/style_emoticons/default/tongue.png[/img]
2. ## Bitwise Confusion

I think you might be mixing 16 up with 15. 255 is, in binary, 11111111. 16 is, in binary, 0001000. The reason you can take any number up to 255 and logical and it with 255 and get that number back, is because 255 is basically ones everywhere - so if the number you're &ing has a zero in a slot, the result is zero in that slot - if it has a one, the result is one. 1&x is simply equal to x. 0&x is always equal to zero though. So if you're &ing with 16, the the sixteenth place is [i]always [/i]going to be the only place that could possibly be nonzero. You'll end up with either 16 or 0. Does that make sense? I suspect you meant to be using 15, which would be 00001111.
3. ## What is the difference between CPU and GPU?

[quote name='Bacterius' timestamp='1353737350' post='5003684'] [quote name='superman3275' timestamp='1353733380' post='5003673'] I think about it like this: CPU does the math, GPU does the rendering. Ta-Da [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img] (I'm not a smart programmer [img]http://public.gamedev.net//public/style_emoticons/default/tongue.png[/img] ). [/quote] GPU does the math too. I would say it's more like, CPU does the logic that brings everything together, and GPU is the powerhouse that drives rendering, and possibly physics (and perhaps other stuff too). [/quote] Perhaps the best way to say it is that a CPU is a generalized processor, and a GPU is a processor designed to efficiently operate on graphical entities. It's more or less a very specialized CPU - what it is designed to do, it does much faster than a general CPU, and what it wasn't designed to do, it does much, much, much slower.
4. ## Ordering Byte Pairs by Frequency In A File

Yeah, if you can make a file in storage, things will be a lot easier. You can make a 64k bytemap and count up to 256 occurrences there - if you have more crop up, make a 64k temp file and increment the corresponding byte in it, then set the one in your memory to zero. Unless a number comes up more than 65536 times you won't need to worry (and if it does, you can create a second file in storage). After you're done reading your input, you just have to go through the files in storage in descending order - the highest there is the highest overall, and ties are broken by a lesser storage file if there's more than one or the one in memory as the base case.
5. ## How to avoid game state hell (huge switchs)?

Yeah, the need for experimentation is pretty often unstated, but very important. People are notoriously bad at seeing what actually is costing them time so they try to optimize everything. It's variable on the code, of course, but I have a software engineering book here whose author mentions several times that 5% of his code caused about 90-95% of the slowdown. Optimizing everything as it's written in that case means 95% of the work is wasted. You might call that habit suboptimal [img]http://public.gamedev.net//public/style_emoticons/default/tongue.png[/img] (Not that you shouldn't ignore obvious inefficiencies as you write, of course, but weigh "this'll be easy to change later" and "this is easy to read" over "it'll run faster if I do this," especially before you actually profile it)
6. ## [C#] Game Saving Problems, Files are too large

[quote name='iXenocider' timestamp='1339616452' post='4948898'] [quote name='szecs' timestamp='1339615413' post='4948890'] *Um.... How about using multiple files? One file per map. [/quote] That would not help with anything, the total file size would be exactly the same. [quote name='szecs' timestamp='1339615413' post='4948890'] *If there's a lot of repetition on the maps you could compress the map (for example with [url="http://zlib.net/"]zlib[/url]) [/quote] I can try that thanks, but it takes time to compress and decompress. I don't want them to be waiting for 3 minutes just to save or load their game. [/quote] Combining those two will solve each others' problems, actually. You break the massive world object down into subobjects, and compress those (or encode them in an efficient manner of your own devising, which is really the same thing.) Your world is smaller, as everything is compressed. And since you don't have to decompress it all at once, you don't have huge lag spikes - only the portion being loaded has to be decompressed. It has other benefits too - your RAM usage will be a lot lower, your disk reads will be a lot smaller (though, admittedly, they'll happen less predictably), and so on.
7. ## Looking to start programming, where to start?

Inukai linked to some good posts. I answered another topic with a post that may be of some help [url=http://www.gamedev.net/topic/625685-cxna-or-pythonpygame-for-game-development-2d-side-scrolling-like-terraria/page__st__20__p__4946951#entry4946951]here[/url]. Basically, I'd recommend checking out university websites that have online computer science departments. MIT is the one I use the most, but there are others out there. Of course, going through all the courses is unnecessary unless you have the goal of learning computer science rather than just getting the ability to code games, but the foundations of the introductory courses will serve you well in programming. Another pretty good advantage is you won't be stuck thinking "what should I program...?". The professors already have laid out exercises to teach you fundamental things like using classes and recursion, which, personally, was exactly what I needed and is something a lot of tutorials don't provide. As for 'good programs to program with', are you talking about the text editors and development environments that you can program in? Those will be very language dependent. Python usually comes bundled with IDLE, which is an excellent (in my opinion) environment. For C++, I liked Code::Blocks, but my libraries got all screwed up recently so I started using the command line. I've never programmed in Java, but I know people recommend Eclipse and NetBeans. I would probably recommend starting with Python - the two main reasons I've seen people try to start with C/C++ is because it's the industry standard and it's so fast. The reason it's the industry standard is partially just based on inertia, and industries tend to use what they know because it's what they know, rather than because it's actually better, so don't read too much into that. As for speed, it is certainly very fast - but a good coder with good knowledge of algorithms will be able to write something faster in Python in about a fifth the time it takes a newcomer to write a less elegant solution. People get pretty obsessed with speed (myself included), but the truth is that if a program is running slowly in Python, it's probably because the programmer took the naive approach and brute forced a solution rather than implementing an efficient algorithm. And if you're just starting out, Python is good because it's not going to make you deal with some of the nasty, nasty low level stuff that C++ does. I have spent far more time hunting down segfaults than is reasonable, because I jumped into C++ before I knew how to handle its power.

9. ## 2D basic collision detection help

Hey there! If your code seems to be working ok, that's the most important thing - but I think I see a few nasty bugs (and a few ways to clean up the code, while I'm at it). [CODE] if(moveRight == true && moveLeft == false) { if (xVel <= maxSpeed) { xVel = int(0.40 * speedTimes); speedTimes +=1; } } if(moveRight == false && moveLeft == true) { if (xVel >= (maxSpeed * -1)) { xVel = int(-0.40 * speedTimes); speedTimes +=1; } } [/CODE] You can, in theory, switch between these two instantly. Since you reset speedTimes only if there is a frame where the left and right are both pressed or both unpressed, if someone were to release right and hit left at such a time that the code below isn't executed, your xVel would invert itself entirely, causing the object to fly off in the other direction. (A clever person could also abuse this to get arbitrarily high speeds, as speedTimes is incremented each time the trick is pulled off) [CODE] if(moveRight == false && moveLeft == false) { if(xVel >0) { speedTimes = 1; xVel = -0.20; } if(xVel <0) { speedTimes = 1; xVel = +0.20; } } if(moveRight == true && moveLeft == true) { if(xVel >0) { speedTimes = 1; xVel = -0.20; } if(xVel <0) { speedTimes = 1; xVel = +0.20; } } [/CODE] First off, you can simplify this. The bodies of the conditionals are the same, and you can test for both conditionals at once by seeing of moveRight and moveLeft are the same. But, this doesn't seem to be what you want. If the person lets go of the keys, then xVel will be set to a constant - no matter how fast they were going, it'll be set. I suspect you want something more along the lines of xVel-=0.20;, as that will cause slowing down instead of instantly changing the speed to a constant. Also, you set xVel to a negative value if it's positive, then have an if (xVel<0) clause right afterwards. That'll get triggered even if it's positive, since it will pass through the if(xVel>0) loop first, which will set it to a negative value. I suspect an else if clause was what was meant. Though, even if you do all that, you'll still be vulnerable to the glitch in the other part of the code - pressing left or right will instantly set the velocity to that direction, regardless of your prior direction. In fact, every time you change xVel, you change it to a constant or a multiple of another variable (speedTimes) which is actually independant. I would not recommend that - set it based on its own value. It's easier and far less likely to end up with bugs like the directional switching one. I'd probably rewrite the thing like this: [CODE] if (moveRight == moveLeft) { if (xVel>0) xVel-=1; if (xVel<0) xVel+=1; } else if (moveRight && xVel<maxSpeed) { xVel+=2; } else if (moveLeft && xVel>(maxSpeed * (-1))) { xVel-=2; } [/CODE] You could also use xVel as a float, and cast it as an int when using to to physically move the object. I just chose to make it an int here so I wouldn't have to deal with rounding errors (like it possibly never actually hitting zero and thus oscillating when moveRight==moveLeft).