Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
[Chapter 05] KamaKazi Base code
#11
Code is always written in the cpp file Jon, the h file only has the defintions for a class. You're doing well so far.

You are creating an overloaded class constructor with Shooter(char*, Myfiles), which is great, but your compiler might not be giving you the default
Shooter::Shooter(){}; so you need to write that also, just as an empty class since youre not going to use it. I've found that some compilers do that for you, and some don't, it depends on a setting I'm not sure about. I tend to just write default classes anyway.

Um yeah I am kinda expecting you to have worked it out, cos we did it in Invaders, I will have a re-read of the invaders code/text to see if the specific mention is still there. If its not clear enough I'll update the Kamikazi base to make it clearer.

(btw, even though I am "pretty" sure its all in the book, I really do appreciate you keeping me informed of your sticking points, it shows me what needs to be made clearer and I will do my best to add content the source to push you through it all)
Brian Beuken
Lecturer in Game Programming at Breda University of Applied Sciences.
Author of The Fundamentals of C/C++ Game Programming: Using Target-based Development on SBC's 



Reply
#12
Yeah, the actual error was for "Shooter::Shooter(char*, MyFiles*); i just shorted it for the post.

The issue is that the code listed in the book shows the initialization list being placed in the header file and no reference to that Constructor in the code to be placed in the .cpp file. There is no Shooter.h or Shooter.cpp in the KamaKazi project files so it must be added by the reader from the code shown in the book, or their code, which is why I am pointing this out. The code for Invaders from the previous example has it correct and compiles without issue so that is at least a good reference. Actually, the code between Invaders and KamaKazi is quite different so it can be a bit confusing when comparing the two.

This is a good exercise and helps me learn this stuff since I have to dig deeper to understand what is happening rather than just copy from the book or other files.
Reply
#13
Ok I get what you are saying, but again...you're building up from the Invaders code,  which shows the process, and while the code is a little different it does have the same principles, re-read page 123, where I say:

"Download the Kamikazi base project from the support site, you will see its essentially still the InvaderStart project we achieved before adding gameplay, but I’ve renamed a few things, this is going to be our base line project for the next few games."

So that for me was making it clear things were basically the same, but we've shuffled things about a bit.  But I take it on board that you were confused so I'm adding something to the base Kamikazi code to make that clearer.

You indeed must use the previous code for reference, (that will be a recurring theme) and as you say its good exercise for you to recognise patterns in the code even if the names and order get altered.

Page 124, lays out a list of the things we have to do and some reference to what we already know what to do.  The Rand should indeed be taken from the Invaders so I will add that as a macro to game.h

Page 128 shows the creation of 2 shooter constructors, but I don't list the code for Shooter::Shooter(char*, MyFiles*) as you note, but, there's a good reason for that. Its actually defined in the header itself and you have the code listed there.
Shooter(char* filename, MyFiles* filehander)
: GameObject(filename, filehander) {};
Which indicates that if you try to create a shooter and pass a char* filename, and a MyFiles* pointer, it will in fact call the GameObject constructor which is a base class Big Grin
Now, I don't think I've explained that at all well here, so am adding these files to the Kamakazi code with comments to clear that up.

We now have this code for shooter.h and cpp files 
Code:
#pragma once
//I'll start you off with this, as there is something here not well reviewed in the book, thanks to reader Jon Morrs for pointing this out
#pragma once
#include "GameObject.h"


class Shooter :
    public GameObject
{
public:
    Shooter();
    ~Shooter();

    Shooter(char* filename, MyFiles* filehander)
        : GameObject(filename, filehander) {}; // <<<< Look here, we provide the constructor with info to use a GameObject constuctor, and {} indicates that this shooter part does nothing.
    
    // these replace the pure virtuals    
    bool Update(Surface* s, Input* InputHandler);
    bool Update(Game* g);
    void Draw(Surface* TheScreen);
    
// feel free to add more methods and variables

};
and shooter.cpp

Code:
#include "Shooter.h"
#include "Game.h"

// we are using an overloaded constructor so we must give it a default constructor
Shooter::Shooter()
{
}

Shooter::~Shooter()
{
}
// now its important to note, we don't need to define this because we already did in the header file, if we add more code here we get errors..but if you feel
// you want to expand on this constructor, you can remove the {} from the end of the definition in the h file, and uncomment this code to add what you want.
// Thanks for Jon Morss for his help in identifying and clearing up confusion here.
//Shooter::Shooter(char*, MyFiles*)
//{
//    
//}

//
bool Shooter::Update(Surface* s, Input* a_Input)
{
    // this is up to you
}

bool Shooter::Update(Game* g)
{
// fill this in yourself
}


void Shooter::Draw(Surface* TheScreen)
{
    Image->CopyAlphaPlot(TheScreen, Xpos, Ypos);
    
}
Brian Beuken
Lecturer in Game Programming at Breda University of Applied Sciences.
Author of The Fundamentals of C/C++ Game Programming: Using Target-based Development on SBC's 



Reply
#14
Brian,

I am finally getting back to this and ran into another issue.
In the example code , in the GameObject.h file, there is an enum for Types that define, Bullet, Missle1, Missle2, Alien and so on. However, the there is also an Alien class where there is an Alien.h and Alien.cpp for this Alien class but the Types Alien conflicts with the Alien class name. I ended up renaming the Alien type to kAlien but may look at convert this to an enum class so it is does not conflict.


Also, I have finally been able to get the Alien on screen, but I am doing this from Game.cpp but it seems it may need to be in GroupManager.cpp. Can you verify where you think it would be best to place this?

One other thing, on page 130 under the heading "Da Baddies. it describes the AlienCoords array which I have created. However, later on page 165 there is a reference to EnemyCoords which looks just like AlienCoords. Can you clarify this for me?

Cheers,

Jon
Reply
#15
I'll try to review at the weekend Jon, thanks for letting me know
Brian Beuken
Lecturer in Game Programming at Breda University of Applied Sciences.
Author of The Fundamentals of C/C++ Game Programming: Using Target-based Development on SBC's 



Reply
#16
sorry I just didn't have the time this weekend, but its top of my todolist so i'll get to it during the week
Brian Beuken
Lecturer in Game Programming at Breda University of Applied Sciences.
Author of The Fundamentals of C/C++ Game Programming: Using Target-based Development on SBC's 



Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)