Not logged in, Join Here! or Log In Below:  
 
 News Articles Search    
 

 Home / Game Design & Programming / Hit Fly 0.1 Account Manager
 
Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.
 
FrancoisSoft

January 03, 2005, 10:14 AM

Hey, remember me? The Platformisis guy? I recently killed that project because it was so poorly implemented. I took some advice and fixed up my programming. I began developing this game where you catch flys. You are a walking hotdog that attempts to get its revenge on a fly for trying to lay on it. I find the game to be funny. This game is not done yet but I have managed to implement some important things such as graphics processing, a resource compiler, and some of the OS backends that will allow the game to run. I'm probably about 60% done with the game at this point but I need some input from you. Can you find anything that I need to improve? I haven't compiled much of the game yet so are there any errors that you found? I would greatly appreciate this. I just set up a site for the project. So you can find it at http://www.geocities.com/hitthefly
 
Chris

January 03, 2005, 10:20 AM

> I recently killed that project because it was so poorly implemented.

We told you it is.

> I haven't compiled much of the game yet

So you expect us to compile it and fix the errors for you ?

> are there any errors that you found?

The compiler's output will tell you !

Sorry, I was just in the mood to flame around a bit. Honestly, what is your post about ? I'd happily test your game, but upload a working executable somewhere. Then I'll also happily post sincere feedback on how you could improve it.
 
Rui Martins

January 03, 2005, 10:27 AM

Just Curious.
How old are you ?
 
FrancoisSoft

January 03, 2005, 10:30 AM

You didn't understand what I said. I want you to look at the game. I make very few syntactical mystakes. Most of the mystakes I get are symantical. Just take a look at the code and tell me if you notice anything weird. I'm not asking you to compile the code. Right now you can only compile the resource compiler and that sould compile on just about anything that calls itself a c++ compiler.
 
FrancoisSoft

January 03, 2005, 10:32 AM

What does that have to do with anything? How old are you?
 
Rui Martins

January 03, 2005, 10:36 AM

I said I was curious!
The question derives mainly from your ideia, and the excitement about it.
No pun intended.
 
Chris

January 03, 2005, 10:44 AM

So you want me to comment on style and structuring of your code ? That's ok, and I had a look.

First of all, why do you use C++ when you're not doing anything in an object oriented fashion ? All the non-member functions, global variables, it's getting nasty whenever a project grows over a thousand lines.

All those #defines, what are they doing ? One uses consts or enums, best enclosed in a class that uses them.

You use C++ in an abusive procedural way. 15 levels of nested ifs trailed by 15 repetitions of the same abort&return statement may be semantically correct but it's really bad style. Rethink it, modularize your design.

BTW you can't use "break" in an if-statement, it's (mis)used to terminate looping statement (and it's best not used anywhere).

You've got to decide what you want to receive from the community ?

Do you want to show a nice little game ? Then get it finished, show it, and receive praise, flame, and ideas for improvement.

Or do you want a debate on coding techniques ? Then I need to say that very many of the members here are so much more advanced that you are, you're cannot even imagine what advanced techniques they can come up with (nor can I sometimes).
 
Juan Carlos Arevalo-Baeza

January 03, 2005, 11:55 AM

As Chris said, there are things that really don't look very good. a sample:

---8

  1.  
  2. #define DontKnow 0
  3. #define AreStringsEqual(String1, String2, StringSize) (StringSize == DontKnow) ? (memcmp(String1, String2, StringSize) == 0) : (strcmp(String1, String2) == 0)
  4.  


That has a bug (StringSize will _only_ be used if it is equal to DontKnow). That's made harder to see because of the single-line layout. In any case, you should use something like:

  1.  
  2. size_t const DontKnow = 0;
  3. inline
  4. bool AreStringsEqual(char const* str1, char const* str2, size_t size = DontKnow)
  5. {
  6.     if (size == DontKnow) {
  7.         return strcmp(str1, str2) == 0;
  8.     } else {
  9.         return strncmp(str1, str2, size) == 0;
  10.     }
  11. }
  12.  


---8
  1.  
  2. long BmpDataPointer = 0; // A register that points to the bitmap data.
  3.  
  4. unsigned char* LoadBmp(char* FileName)
  5. {
  6.   ...
  7.     if (SkipBytes(BitmapFile, BmpDataPointer, SEEK_SET)) { // Could we move to the data?
  8.       ...
  9. }
  10.  


be better implemented like this:

  1.  
  2. unsigned char* LoadBmp(char* FileName, long BmpDataOffset = 0)
  3. {
  4.   ...
  5.     if (SkipBytes(BitmapFile, BmpDataOffset, SEEK_SET)) { // Could we move to the data?
  6.       ...
  7. }
  8.  


---8
  1.  
  2.   BitmapFile = fopen(FileName, "rb"); // Open the bitmap file.
  3.   if (BitmapFile) { // Was the bitmap file opened?
  4.     if (SkipBytes(BitmapFile, BmpDataPointer, SEEK_SET)) { // Could we move to the data?
  5.       if (fread(&Bitmap, sizeof(BmpFile), 1, BitmapFile) == 1) { // Did we get the bitmap information?
  6.         if (AreStringsEqual(Bitmap.Type, "BM", 2)) { // Is this a bitmap?
  7.           ...
  8.         }
  9.         else { // No?
  10.           fclose(BitmapFile); // Close the file.
  11.         }
  12.       }
  13.       else { // No?
  14.         fclose(BitmapFile); // Close the bitmap file.
  15.       }
  16.     }
  17.     else { // No?
  18.       fclose(BitmapFile); // Close the file.
  19.     }
  20.   }
  21.  


is error-prone at best. Much better is to do something like this:

  1.  
  2.   BitmapFile = fopen(FileName, "rb"); // Open the bitmap file.
  3.   if (BitmapFile) { // Was the bitmap file opened?
  4.     ... // (I don't care what goes in here, as long as it doesn't "return")
  5.     fclose(BitmapFile); // Close the file.
  6.   }
  7.  


Also, it is generally regarded as much better to declare variables at the point they are used. I also prefer to keep them within the scope where they are used, and to remove comments that don't add anything to the meaning of the code itself, so...

  1.  
  2.   if (FILE* const BitmapFile = fopen(FileName, "rb")) {
  3.     ... // (I don't care what goes in here, as long as it doesn't "return")
  4.     fclose(BitmapFile);
  5.   }
  6.  


---8
 
Juan Carlos Arevalo-Baeza

January 03, 2005, 12:15 PM

why do you use C++ when you're not doing anything in an object oriented fashion ? All the non-member functions, global variables, it's getting nasty whenever a project grows over a thousand lines.

Heh... you tickle me on my own particular war... You might hate me for this, but I believe object-orientation is way overrated, overused, and misused.

And it's not just me. Scott Meyers advocates using global (non-member) functions whenever possible. He wrote it all in the February 200 issue of the C/C++ Users Journal magazine, but here you can read the gist of it:

http://www.artima.com/intv/mincomp3.html

C++ is most emphatically an object oriented language. It is totally multi-paradigm. For instance, the Boost Spirit library has very little of object-orientation in it, even though it is very hard-core C++.

Global variables are bad, as you say. They are bad because they break encapsulation and because they are not thread-safe. They should be avoided as musch as possible, but I have found that, as long as you're fully aware (and take care) of the issues, and as long as you document (in a comment) why it is a good thing to use the global anyway, they can be useful.

Salutaciones,
JCAB
 
FrancoisSoft

January 03, 2005, 12:26 PM

Then we can learn from eachother. I can teach you to write good comments and you teach me good C++ programming. I looooooooooooooooooove macros! My whole philosophy in programming revolves around the macro. I don't want to get rid of them. Thanks for the advice on globals and other parts of programming. Perhaps you can rewrite some of the code for me?
 
FrancoisSoft

January 03, 2005, 12:28 PM

But what if you want register variables in your program?
 
FrancoisSoft

January 03, 2005, 12:30 PM

I'm young. Very young but not a kid. I'm sort of a little bit beyond the teen years. Actually I'm 22 but do I act like it? No way! I act like I'm 16.
 
Chris

January 03, 2005, 12:52 PM

Register variables ? Variables that the compiler holds in CPU registers, or what ? It never does that with globals.
 
Chris

January 03, 2005, 12:53 PM

Macros are evil, let you be told that. There is no philosophy to be found in using macros, and by your over-use of them you'll not be looked at as a good coder.
 
TobeyThorn

January 03, 2005, 01:37 PM

why do you ask for comments and then stubbornly refute that your obsessively rediculous coding style(or lack thereof) is better? i am an amateur coder myself, but even i know your coding blows, and you are delerous in your ambitions. learn to write a decent "helloworld" before you attempt some inevitably doomed project.
 
Chris

January 03, 2005, 01:40 PM

Now, that also IS a way to express it. I deliberately tried to be a bit more careful, but it's good to see some straight words.
 
I'M BRIAN FELLOWS

January 03, 2005, 02:53 PM

THAT GRAPHICS CODE IS CRAZY, DID YOU EVEN TEST IT YET?
 
FrancoisSoft

January 03, 2005, 06:15 PM

How is it crazy? Be more specific.
 
Victor Widell

January 03, 2005, 08:20 PM

Yoda-style wisdom:

The dark side Macros obey. Avoid them you should! Start simple, you fool. When the time is right, Templates, you should learn to master.




Seriously, hang around the forum and you will learn tons of stuff by just reading other peoples posts. That's how I learned most of my C++ coding techniques.
 
I'M BRIAN FELLOWS

January 03, 2005, 08:24 PM

YOU WILL SEE ONCE YOU TRY IT OUT FOR THE FIRST TIME.
 
FrancoisSoft

January 03, 2005, 09:13 PM

I know that my coding style might be bad but I'm happy with it and it's pretty readable to me. I looooooooooove macros. I understand them better than enums or typedefs. In fact this is where I am strongest in C++. You sound very negative and pissed. Why? Everyone has their own way of coding and being the newbie that you are you have no right to judge my coding style. Could you do better? You probably don't even know what a macro is. So before you go storm at me the way you did just think about what you are saying. I did take some advice from people but I have learned something valuable. No matter how you code people will always dind something wrong with the way you code. So I have learned to take people's advice but to a certain extent. There is a point where I draw the line and that ppoint concerns macros. I really did not want people to comment on the coding style so much. I just wanted people to look at the game itself and maybe catch bugs. Why do people always go for the code???
 
FrancoisSoft

January 03, 2005, 09:15 PM

This still doesn't help. What is wrong with the code? If nothing is wrong then why should I change it? I want to use my own stuff not someone else's. And, no, YOU'RE NOT BRIAN FELLOWS!
 
FrancoisSoft

January 03, 2005, 09:27 PM

I know how to use templates. Macros are not bad if you truely understand them. Most people hate them because they don't code them right. I'll give you an example. Take this piece of code:

  1.  
  2.  
  3. #define IsOk(Answer) (if (Answer == 1) SayHello())
  4.  
  5. if (Ok)
  6. IsOk(Ok);
  7. else
  8. printf("Bad!");
  9.  
  10. // Did you see what happened in the above? Let's take a closer look.
  11.  
  12. if (Ok)
  13. if (Answer == 1) SayHello();
  14. else
  15. printf("Bad!");
  16.  
  17. // Else is not longer attached to the outer if statement, right?
  18. // This could have been avoided like this:
  19.  
  20. #define IsOk(Answer) (if (Answer == 1) { SayHello() })
  21.  
  22. if (Ok) {
  23.  
  24.   IsOk(Ok);
  25.  
  26. }
  27. else {
  28.  
  29.   printf("Bad!");
  30.  
  31. }
  32.  
  33. // Expanded, we have:
  34.  
  35. if (Ok) {
  36.  
  37.   if (Answer == 1) { SayHello() };
  38.  
  39. }
  40. else {
  41.  
  42.   printf("Bad!");
  43.  
  44. }
  45.  
  46. // See what I did?
  47.  
  48.  


I think many programmers are full of themselves but they don't realize this. The constructs of the language is not bad. It's how you use them. I personally
think not putting curlies around single statements is a bad style. But look,
when I put the curlies the syntax error went away. Lots of hype from programmers about not using macros but they just want the easy way out. I like
macros and that's the one thing in C++ that I understand the most. They're not
evil like you said.
 
FrancoisSoft

January 03, 2005, 09:31 PM

Object oriented programming is useful in some circumstances but when it comes to po pure unrelated function calls it's just a pain. I use both C and C++ coding. What can I say that's my coding style.
 
monster

January 03, 2005, 09:52 PM

Tragically you've just proved that;
a) You don't truely [sic] understand macros, and that
b) Macros are evil

Your first macro actually expands to;

  1. if (Ok)
  2. (if (Answer == 1) SayHello());
  3. else
  4. printf("Bad!");

Which doesn't even compile, and your "fix" expands to;
  1. if (Ok) {
  2.   (if (Answer == 1) { SayHello() });
  3. }
  4. else {
  5.   printf("Bad!");
  6. }

Which also doesn't compile. If I assume you meant
  1. #define IsOk(Answer) if (Answer == 1) { SayHello();}

Then that compiles, but the 'else' is still 'attached' to the inner (macro expanded) if. What you probably meant, for your "fixed" macro was;
  1. #define IsOk(Answer) {if (Answer == 1) SayHello(); }
  2. if (Ok) IsOk(Ok)
  3. else printf("Bad!");

Yuck!

At least make it obvious that your macros are macros, and not functions or variables, e.g. make them all upper case.
 
Juan Carlos Arevalo-Baeza

January 04, 2005, 02:03 AM

The first and most important stage of learning is to be aware that there's something to learn. I have gone through that with comments. Now I just need to catch myself (or be caught) when I'm not doing it right, and fix it until it becomes second nature. Practice, practice, practice. I'm on it. :-)

You need to reach this stage with your obsession with macros. Really. Believe me. I'm not the only one saying so. It's become, nowadays, common wisdom.

Salutaciones,
JCAB
 
Rui Martins

January 04, 2005, 04:44 AM

Just for your information, macros aren't exactly C++.
You could say that are C, but in fact they are just a pre-processor directive (#define) that is part of the C language definition.
Later they were assumed by C++, for compatibility issues.
 
Danny Chapman

January 04, 2005, 04:58 AM

Bit early in the year for trolls to come out of hibernation, isn't it?
 
Chris

January 04, 2005, 05:00 AM

Francois, your macro obsession, including your example, is just plain ridiculous. And you're not accepting advice, just like you didn't in you last post. I'm sorry to say that you're not yet in the position to tell us anything about good coding style and pratice.

Macros hide variable names, macros create multiple evaluation of the same expression, macros can create nasty side-effects with operators (especially overloaded ones), macros obfuscate code so other can't understand it.

As I said before, WHY are you here with us ?

If you want to show off, get your game done and show it. We'll gladly test and comment.

But if you actually want to *learn* something, be patient and *listen to us* !

And the fact that you've not yet received a single supporting response really should be telling you something.
 
Rui Martins

January 04, 2005, 05:06 AM

Maybe is just Masochist or plain Hard Headed.

I don't believe he is a troll, at least not yet, he still as to learn how to become one.
Don't teach him !
 
This thread contains 48 messages.
First Previous ( To view more messages, select a page: 0 1 ... out of 1) Next Last