Reputation: 560 Enlightened
- Active Posts:
- 1,259 (1.53 per day)
- 24-April 12
- Profile Views:
- Last Active:
- Yesterday, 10:37 AM
- OS Preference:
- Favorite Browser:
- Internet Explorer
- Favorite Processor:
- Favorite Gaming Platform:
- Your Car:
- Who Cares
- Dream Kudos:
- Expert In:
- Game Programming, XNA
Posts I've Made
Posted 24 Jul 2014For full disclosure, I might also mention that there was a time way back when when I was the one writing the rogue code. I did some really ugly things to the database as an application developer way back in the day before I became a DBA. ;-)
It's a totally different way of thinking between database programming and most other programming and a lot of developers don't realize that. I certainly didn't until I switched roles.
Posted 24 Jul 2014@BBeck: Wow, um, you must have dealt with some seriously crappy developers... />
I've worked with various different developers all the way down to "I learned Access last week and I'm using it as a front end to hack on the production database."
But I also think in terms of "What could a hacker do if they get in?" following the principle of least privledge: no one should get any permission that they don't actually need. Having spent a little time hacking in my early days, I still think about that and what a more malicious hacker could do to stuff I'm responsible for.
There are those "developers" who know just enough to get in trouble. And there are those who really know their stuff. I'm much more comfortable handing over the keys when they demonstrate they know what they're doing. It's somewhat of a case by case situation. Most of them are great guys, but everyone is going to come to me when the database slows to a crawl.
And I also look at performance problems caused by people running rogue queries of various degrees. And I see a lot of lazy stuff where they're trying to just get something to do the job rather then do it right. I can't performance tune things I have no control over.
But in the real world, I rarely get to lock things down half as much as I would like.
A lot of this really depends on the size of the database too. As I'm sure you know, you can do pretty much everything imaginable wrong and still not have a real problem with performance on a 100GB database. Start getting over a terrabyte, and minor problems can bring the whole thing to it's knees very quickly. So, I tend to think big even when I'm working with small partially just out of habit.
Posted 24 Jul 2014I don't know PyGame, but there are several common ways collision detection is done.
One way is to test for overlapping circles. This is one of the most simple and thus most efficient ways to test for collision. Basically, you take the center points of the two possibly overlapping sprites. You take the radius of the circle that you imagine bounding each of them. Then you draw a mathematical line between the two center points. If the length of that line is less then the sum of the radius of both circles, then the two circles must be overlapping.
Another way is with axis aligned bounding squares. In this case, you make mathematical squares around each based on their center point rather then circles. Because the squares are aligned with the X,Y axis, the test is fairly simple. You take each side of one square and test if the any of the other square's sides are within those bounds.
So, square 1 might have X=10 for a the left side and X = 15 for the right side. For an intersection/collision to occur, either the X of the left side or the X of the right side of the second square must be between the two sides of the first square. This doesn't really deal with the space between the two sides, but if you do the same test in reverse, so that square 1 becomes square 2 and square 2 becomes square 1, you'll caputre that exception. The exception occurs when one square is entirely inside of the other, but if you test the squares in the opposite order it will discover the overlap. Do the same thing for the Y sides of the squares.
That assumes the squares are axis aligned. The next most difficult is determining if non-axis aligned squares are overlapping. This is seriously mathematically ugly unless you have a math degree. It's also seriously expensive in terms of computing power. You want to avoid it if you don't need it.
For 2D, often a better solution is to test for pixel overlap. You might use one of the methods above to detect initial collision, but the shape of the circle or square will probably not match the shape of the object in the sprite. So, you do the initial circle or square test to determine that further testing is needed. Then you can test whether individual pixels of the two sprites actually overlap.
PyGame may do all of this for you; I don't know if it has built in collision detection routines.
Posted 24 Jul 2014I don't do MySQL, but I'm sure it's the same as any other database in this case.
For several reasons, I am opposed to ever doing an Update on a database. If I had my choice, no-one would ever be allowed to do anything ever under any circumstance without going through a stored procedure unless they are an administrator.
For one thing, developers have no business writing queries in the database, they are generally not properly trained in optimizing queries which is really a server side thing in a client server environment anyway. And if it's a properly designed client-server application all of the logic should be server side anyway which means the DBA/Architect should be completely familiar with all of the logic.
Along those lines, administrators have little to no control of ad-hoc queries and their effect on the database, including problems like SQL injection attacks, runaway queries, and just general mischief. A DBA can't fully optimize server performance if he can't control the queries running against the database.
And you have better control of exactly what's going on in the database if access is granted per stored procedure rather then broad table access. No one can ever do anything the DBA disapproves of if the only access is through stored procedures. And at the end of the day, the DBA will be the one who's head is on the chopping block when things go bad.
And database servers are built with a client-server architecture which means they perform well when 100% of the work is done on the server side, and they don't perform well the less that's true. Applications should be nothing but pretty displays - thin clients. The worst thing you can do is tell the server to give you all of the data so that you can do the work client side, which is counter intuitive to a lot of developers because they think they're saving the server work by requesting all the data to work on it client side. That's a good way to crash a server. Again, that is the absolute worst thing you can do. Of course that's a Select operation and you're talking about an Update, but it's still something to keep in mind.
I mean, just think about it this way. Which is going to be more optimal in a 500 Exabyte database? "Return to me the rows for the employees that were hired last week?" (which is something the server is designed to do and designed to answer such questions very quickly) or "Send me all 500 Exabytes so that I can figure out which employees were hired last week?" The first query returns a few thousand bytes of data after it does what it's designed to do by finding those records as efficiently as possible using indexes and query optimization and such. The second will spend the next 4 years just pulling it off disk and transporting it across the network which will not only lock everyone in the company out of the server while it gets bogged down in a data transfer it's not designed for but it will also take all network band width so no one in the company can send emails or get any work done of any type throughout the entire company.
So, in a perfect world, I would never allow anyone to communicate with the database except through a stored procedure, especially the developers. Of course, we don't live in a perfect world.
Still, I would recommend considering how much of the logic you can put server side in stored procedures. I'm not sure what the limit on the number of parameters you can pass simultaneously is, but I think you could pass all of those at once. It will be individual Updates inside the stored procedure, but you should be able to pass all the parameters at once.
Posted 22 Jul 2014Run it in a debugger. Set a break point on that section of code. Evaluate the value of each to make sure they are what you think they should be. Step into the methods if they are not returning the correct value. You can seperate this out into more lines of code for the purpose of debugging, to make it more clear their values, if needed. That should make it clear why, if there is a final result that is incorrect.
I would specifically watch out for rounding errors and overflow errors caused by implicit data type conversions or just unhandled overflow of a variable going out of range. Whatever is causing it, a debugger should be able to tell you.
- Member Title:
- Here to help.
- Age Unknown
- Birthday Unknown
- Dallas, Texas, US of A, Planet Earth, Sol System, Milky Way Galaxy
- Rock music composition and performance, Grunge Music, Bebop (think Thelonios Monk), Swing (think Cab Calloway), Gaming, Astronomy, RPGs, Scuba, Sail Boats, Furniture Building, Cooking, Rocky Patel Cigars, Character Driven Dramas(like HBO's Deadwood), Story Telling (plot writing), Linguistics, Economics, Target Shooting, Electronics (don't know as much as I'd like to), all aspects of 3D game programing including music, physics, modeling, texturing, annimation, probability, AI, lighting, etc., Texas Holdem' Poker, Learning, Dogs, the love of my life (my pit bull), guns (especially 19th century black powder), putting make-up on ogres, etc.
- Programming Languages:
- C, C++, C#, Visual Basic, Java, Pascal, T-SQL, HTML, FoxPro, ASP.Net(very little), Assembler, Machine Code(conceptually anyway)
- Website URL: