VoidElite wrote:So I should use them? Ahh I sorta understand now. Hey how do I create and use variables in Makefiles?
http://mrbook.org/tutorials/make/ is a very good starting tutorial, complete with a makefile that you can customize for a simple method of compiling almost any project!
Ok guys so I've tried Makefiles, I understand their syntax and all but I don't have enough time on my hands(finals next week). I've been planning to port over to Visual C++ for quite some time and now I have. By leaving G++ and Notepad++ behind I have realized that it is pointless having a 'interface and implementation' as it justs leaves me with loads of random files as suppose to the one .h file. So as you can guess much to your disagreement I have moved to using '.h's for classes. By looking through Sprite.h I have discovered some errors which were highlighted upon build-time. These errors caused by the Sprite class within Sprite.h and I have reason to believe they caused all of the original errors.
1>------ Build started: Project: Engine, Configuration: Debug Win32 ------
1> Main.cpp
1>c:\users\marcareed\documents\visual studio 2010\projects\engine\engine\sprite.h(41): error C2106: '=' : left operand must be l-value
1>c:\users\marcareed\documents\visual studio 2010\projects\engine\engine\sprite.h(47): error C2106: '=' : left operand must be l-value
1>c:\users\marcareed\documents\visual studio 2010\projects\engine\engine\sprite.h(53): error C2106: '=' : left operand must be l-value
1>c:\users\marcareed\documents\visual studio 2010\projects\engine\engine\sprite.h(59): error C2106: '=' : left operand must be l-value
1>c:\users\marcareed\documents\visual studio 2010\projects\engine\engine\player.h(75): error C2061: syntax error : identifier 'Base'
1>c:\users\marcareed\documents\visual studio 2010\projects\engine\engine\player.h(77): error C2065: 'base2' : undeclared identifier
1>c:\users\marcareed\documents\visual studio 2010\projects\engine\engine\player.h(77): error C2227: left of '->getBox' must point to class/struct/union/generic type
1> type is ''unknown-type''
1>c:\users\marcareed\documents\visual studio 2010\projects\engine\engine\main.cpp(52): error C2660: 'Player::move' : function does not take 2 arguments
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
So hopefully I'll be able to get this stable again and have collision done soon. BTW thanks for all your help so far.
Any ideas on these errors?
I love 16-bit Assembly language programming. I'm currently having an affair with C++. I'm working on a 2D Game Engine called Lunar Sanity for PC and soon DC. I own three games consoles: Dreamcast, Xbox 360 and Atari Flashback. I'm on a Mac and soon a PC. I love Windows XP as it works great(can run 16-bit GUIs). I've been programming for 3 years(since I was 11).
I settling into my hybrid(procedural&object orientated) life. It's all good so far.
Well, first of all, it mentions "Base" (a type) and "base2" (a variable) being used, and I can't see it anywhere. Secondly, getBox() returns a value, but you are assigning to it as though it's a reference in the setX(), setY(), etc. functions (which is syntactically wrong, logically wrong, and even if the compiler let you do it, wouldn't have the desired result).
Now, you say that you think interface-implementation is foolish, and yet you fail to understand why they're desirable. Eventually you're going to have a large project, that can take upwards of 10 minutes to compile completely. At that point, you don't WANT to compile it all every time, and interface-implementation eliminates that need. Yes, it's a good idea to have some small functions inlined in the header, but you certainly don't want them all that way. Also, what about having a class that, even with the same interface, is capable of using 2 completely separate APIs on its backend?
In my graphics and windowing library, I strictly maintain the interface-implementation rule. For example, my Screen class has exactly ONE interface, although it is implemented quite differently on different platforms. If I were to remove the interface-implementation separations, I'd have one header file with TONS of preprocessor directives to determine which sections should be compiled for a certain platform, not to mention that each individual implementation would add about 600 lines of code, making it a gigantic header THAT MUST BE RECOMPILED EVERY SINGLE TIME I BUILD. Forget about the fact that I don't want to force the inclusion of XLib or winAPI onto the user of my library (which would happen if I just had a header, and didn't hide the library interface inside the implementation), that much compile-time bloat is ridiculous!
And that's just one source file. If you include all of the various files, my library is about 2600 lines of code. If you separate the interface and the implementation, the compiler will probably only have to compile 100 or 200 lines of code each build if I'm not making any super-huge changes. Do you know how much longer compiling 2600 lines of code takes compared to 100 or 200? 100 or 200 can take 10 or 20 seconds, at max. 2600? More like 3 minutes.
If you go into the programming industry, you won't be dealing with 2600 lines of code. You'll be dealing with tens of thousands lines of code. You do NOT want to have to recompile the whole thing when you make one tiny change.
Quit procrastinating and make something awesome.
Ducky wrote:Give a man some wood, he'll be warm for the night. Put him on fire and he'll be warm for the rest of his life.
Ginto8 wrote:Well, first of all, it mentions "Base" (a type) and "base2" (a variable) being used, and I can't see it anywhere. Secondly, getBox() returns a value, but you are assigning to it as though it's a reference in the setX(), setY(), etc. functions (which is syntactically wrong, logically wrong, and even if the compiler let you do it, wouldn't have the desired result).
Now, you say that you think interface-implementation is foolish, and yet you fail to understand why they're desirable. Eventually you're going to have a large project, that can take upwards of 10 minutes to compile completely. At that point, you don't WANT to compile it all every time, and interface-implementation eliminates that need. Yes, it's a good idea to have some small functions inlined in the header, but you certainly don't want them all that way. Also, what about having a class that, even with the same interface, is capable of using 2 completely separate APIs on its backend?
In my graphics and windowing library, I strictly maintain the interface-implementation rule. For example, my Screen class has exactly ONE interface, although it is implemented quite differently on different platforms. If I were to remove the interface-implementation separations, I'd have one header file with TONS of preprocessor directives to determine which sections should be compiled for a certain platform, not to mention that each individual implementation would add about 600 lines of code, making it a gigantic header THAT MUST BE RECOMPILED EVERY SINGLE TIME I BUILD. Forget about the fact that I don't want to force the inclusion of XLib or winAPI onto the user of my library (which would happen if I just had a header, and didn't hide the library interface inside the implementation), that much compile-time bloat is ridiculous!
And that's just one source file. If you include all of the various files, my library is about 2600 lines of code. If you separate the interface and the implementation, the compiler will probably only have to compile 100 or 200 lines of code each build if I'm not making any super-huge changes. Do you know how much longer compiling 2600 lines of code takes compared to 100 or 200? 100 or 200 can take 10 or 20 seconds, at max. 2600? More like 3 minutes.
If you go into the programming industry, you won't be dealing with 2600 lines of code. You'll be dealing with tens of thousands lines of code. You do NOT want to have to recompile the whole thing when you make one tiny change.
I do understand that. But to be honest I'm 14 and my only prime objective right now is to make my first SDL game, a platformer. That follows the concept of a universal game engine as such. It is for my personal use only. Later I will implement such methods. But to be honest my friend follows no such conventions in his C# code which is 6000 lines of code for a COSMOS OS and he has no problems compiling as in time. Look him up he's Hack3rINC on YouTube(Caleb Roberts). Normally a JIT compiler would take longer than a normal one so you get my jist.
The Base class is in Base.h which is included into Globals.h which is included by ALL files(Main.cpp&the headers). So if I made getBox() a reference function or something like that would it fix the errors? And if so what modifications would I have to make to the function's code within the header?
I love 16-bit Assembly language programming. I'm currently having an affair with C++. I'm working on a 2D Game Engine called Lunar Sanity for PC and soon DC. I own three games consoles: Dreamcast, Xbox 360 and Atari Flashback. I'm on a Mac and soon a PC. I love Windows XP as it works great(can run 16-bit GUIs). I've been programming for 3 years(since I was 11).
I settling into my hybrid(procedural&object orientated) life. It's all good so far.
VoidElite wrote:I do understand that. But to be honest I'm 14
As are both me and Ginto8
VoidElite wrote:
my only prime objective right now is to make my first SDL game, a platformer. That follows the concept of a universal game engine as such. It is for my personal use only. Later I will implement such methods. But to be honest my friend follows no such conventions in his C# code which is 6000 lines of code for a COSMOS OS and he has no problems compiling as in time. Look him up he's Hack3rINC on YouTube(Caleb Roberts). Normally a JIT compiler would take longer than a normal one so you get my jist.
Even with this said you may make some silly mistakes and skip over a few things because you're lazy (we all did at one point) but when it comes to wasting compiling time, you're making a big deal out of what takes nothing.
As for how your friend, if he has bad programming habits then please don't learn from him.
VoidElite wrote:
The Base class is in Base.h which is included into Globals.h which is included by ALL files(Main.cpp&the headers). So if I made getBox() a reference function or something like that would it fix the errors? And if so what modifications would I have to make to the function's code within the header?
I'm not sure what the function is actually returning but it should work returning a reference yes.
VoidElite wrote:I do understand that. But to be honest I'm 14
As are both me and Ginto8
VoidElite wrote:
my only prime objective right now is to make my first SDL game, a platformer. That follows the concept of a universal game engine as such. It is for my personal use only. Later I will implement such methods. But to be honest my friend follows no such conventions in his C# code which is 6000 lines of code for a COSMOS OS and he has no problems compiling as in time. Look him up he's Hack3rINC on YouTube(Caleb Roberts). Normally a JIT compiler would take longer than a normal one so you get my jist.
Even with this said you may make some silly mistakes and skip over a few things because you're lazy (we all did at one point) but when it comes to wasting compiling time, you're making a big deal out of what takes nothing.
As for how your friend, if he has bad programming habits then please don't learn from him.
VoidElite wrote:
The Base class is in Base.h which is included into Globals.h which is included by ALL files(Main.cpp&the headers). So if I made getBox() a reference function or something like that would it fix the errors? And if so what modifications would I have to make to the function's code within the header?
I'm not sure what the function is actually returning but it should work returning a reference yes.
It returns the SDL_Rect within the Sprite node named sprite. So that it can use it for box collision.
Maybe I'll sort the compiler shiz out later but like I said I'm too busy to worry about that anyway I'm working on a 4GB(RAM) MacBook Pro so speed isn't that much of a problem or atleast now.
Are you and Ginto American?
I love 16-bit Assembly language programming. I'm currently having an affair with C++. I'm working on a 2D Game Engine called Lunar Sanity for PC and soon DC. I own three games consoles: Dreamcast, Xbox 360 and Atari Flashback. I'm on a Mac and soon a PC. I love Windows XP as it works great(can run 16-bit GUIs). I've been programming for 3 years(since I was 11).
I settling into my hybrid(procedural&object orientated) life. It's all good so far.
N64vSNES wrote:Obviously there is nothing forcing you but I can still say I strongly disagree compiling like that irrelevant of what you're compiling with.
Although with a IDE this will be taken care of for you (or it should be unless you explicitly tell it not to)
No I'm from the UK, I believe Ginto8 is amercian?
Cool.
I love 16-bit Assembly language programming. I'm currently having an affair with C++. I'm working on a 2D Game Engine called Lunar Sanity for PC and soon DC. I own three games consoles: Dreamcast, Xbox 360 and Atari Flashback. I'm on a Mac and soon a PC. I love Windows XP as it works great(can run 16-bit GUIs). I've been programming for 3 years(since I was 11).
I settling into my hybrid(procedural&object orientated) life. It's all good so far.
VoidElite wrote:But to be honest my friend follows no such conventions in his C# code which is 6000 lines of code for a COSMOS OS and he has no problems compiling as in time.
This is because C# is VERY DIFFERENT in structure. It automatically handles separating its interface and implementation in the compilation itself, so he doesn't have to worry about it. Keep in mind that this is C++, not C#, and that coding conventions that work in one language may be vastly different (in implementation, if not in concept) than those that work in another.
Quit procrastinating and make something awesome.
Ducky wrote:Give a man some wood, he'll be warm for the night. Put him on fire and he'll be warm for the rest of his life.
You have every right to embrace shitty programming practices, true, but I also have every right to judge you as an ignorant noob for doing so.
The way that you are structuring your code is enough to make any C/++ programmer laugh at you.
Thanks Falco, you're a very nice person.
As for me being a noob which I am not, I may be a noob at C++ OOP quite frankly because it's, I am certainly not a noob at Assembly language(Intel syntax), C#, PHP ext. I have experience with languages which do not use such conventions(part of the reason why I chose to un-implement it also the fact that I acknologe(spelling fail) why you would use such things and I choose not too is due to the fact that I think it makes my code hard to read, crummy and I don't like classes streching over multiple files. For example: if I want to change to operands or the return type of a function, I'd have to change it in two files which is not ergonomic at all.
Maybe later I will re-implement it but right now all I care about is my SATS exams tomos and getting the code working which it is not.
I love 16-bit Assembly language programming. I'm currently having an affair with C++. I'm working on a 2D Game Engine called Lunar Sanity for PC and soon DC. I own three games consoles: Dreamcast, Xbox 360 and Atari Flashback. I'm on a Mac and soon a PC. I love Windows XP as it works great(can run 16-bit GUIs). I've been programming for 3 years(since I was 11).
I settling into my hybrid(procedural&object orientated) life. It's all good so far.
If someone can tell me how the hell I get VC++ to link the Main.cpp with the other .cpps then maybe I'll consider it.
I love 16-bit Assembly language programming. I'm currently having an affair with C++. I'm working on a 2D Game Engine called Lunar Sanity for PC and soon DC. I own three games consoles: Dreamcast, Xbox 360 and Atari Flashback. I'm on a Mac and soon a PC. I love Windows XP as it works great(can run 16-bit GUIs). I've been programming for 3 years(since I was 11).
I settling into my hybrid(procedural&object orientated) life. It's all good so far.
You have every right to embrace shitty programming practices, true, but I also have every right to judge you as an ignorant noob for doing so.
The way that you are structuring your code is enough to make any C/++ programmer laugh at you.
Thanks Falco, you're a very nice person.
As for me being a noob which I am not, I may be a noob at C++ OOP quite frankly because it's, I am certainly not a noob at Assembly language(Intel syntax), C#, PHP ext. I have experience with languages which do not use such conventions(part of the reason why I chose to un-implement it also the fact that I acknologe(spelling fail) why you would use such things and I choose not too is due to the fact that I think it makes my code hard to read, crummy and I don't like classes streching over multiple files. For example: if I want to change to operands or the return type of a function, I'd have to change it in two files which is not ergonomic at all.
Maybe later I will re-implement it but right now all I care about is my SATS exams tomos and getting the code working which it is not.
I'm just going to say for future reference: If Gyro bullies you, take it as a compliment.
EDIT:
VoidElite wrote:If someone can tell me how the hell I get VC++ to link the Main.cpp with the other .cpps then maybe I'll consider it.
Normal linking of your project should be done automatically when you click build. What version of Visual Studio are you using?
You have every right to embrace shitty programming practices, true, but I also have every right to judge you as an ignorant noob for doing so.
The way that you are structuring your code is enough to make any C/++ programmer laugh at you.
Thanks Falco, you're a very nice person.
As for me being a noob which I am not, I may be a noob at C++ OOP quite frankly because it's, I am certainly not a noob at Assembly language(Intel syntax), C#, PHP ext. I have experience with languages which do not use such conventions(part of the reason why I chose to un-implement it also the fact that I acknologe(spelling fail) why you would use such things and I choose not too is due to the fact that I think it makes my code hard to read, crummy and I don't like classes streching over multiple files. For example: if I want to change to operands or the return type of a function, I'd have to change it in two files which is not ergonomic at all.
Maybe later I will re-implement it but right now all I care about is my SATS exams tomos and getting the code working which it is not.
I'm just going to say for future reference: If Gyro bullies you, take it as a compliment.
Why should I? He was practically nailing me just because he has a biased view on conventions?
I love 16-bit Assembly language programming. I'm currently having an affair with C++. I'm working on a 2D Game Engine called Lunar Sanity for PC and soon DC. I own three games consoles: Dreamcast, Xbox 360 and Atari Flashback. I'm on a Mac and soon a PC. I love Windows XP as it works great(can run 16-bit GUIs). I've been programming for 3 years(since I was 11).
I settling into my hybrid(procedural&object orientated) life. It's all good so far.