Project Aurora, post 7, (Blog Assignment 4) Camera problem

Ok, following up on previous post, I had a lot of problems getting the light circle to work as I wanted and all the problems basicly led back to how the view or camera of the game was updated and the position of everything. So this post will be about the camera and maybe some light circle stuff.

At first we didn't have a camera class to handle the camera. We used SFML's built in sf::view which handle what the player can see and moved it around when the player moved. But as soon as I added the black filter I mentioned in my last blog post I thought why not add that functionally into a camera class? In the future we might want to use another filter or other effects not thought of right now like stopping the camera at certain positions but the player can for example keep moving with the camera locked in place and not always center on the player.

First lets explain how the coordinates work. When we draw something to the screen the upper left corner has the coordinate 0,0 and the X-value increase every step to the right and the Y-value every step downwards. Like the picture to the right:









But the sf::view use another coordinate system that have the position 0,0 in the middle and is increased to the left and upwards like the picture to the left:












If you combine that you get something looking like the picture to the right.













As you see it can be very confusing, There are alof of positions to keep track of. And to add to this problem all our positions for our sprites we draw out on the screen is calculated from the middle of the sprite and not the upper left corner.
So the biggest problems I had was keeping track of all positions and understanding how they all work together. This created some strange behaviours and effects like the light being drawn infront of or behind the player and not centered on the players position like the picture show below.

I went through all the sprites and all positions of camera and even the windows position checking so all positions was correct but I still got wrong positions of the light effect and the light also move twice as fast as the player. It has been driving me crazy for about a week. There was absolutely nothing wrong with my code or logical reasoning!.....or so I thought. Some position errors I got was because there are some hardcoded numeric values but I found those fairly easy and adjusted my code to fit those values. But it wasn't enough!

So last night I finally solved it. But before I go into the solution I will break down how a sprite is loaded.
When you create a sprite it's created from a texture that is loaded into the program. Like a photo or a picture drawn in paint. SFML has a Texture load from file funtion that can be used. so sf::Texture.loadfromfile("filename") and then sf::Sprite( create from sf::Texture)

But when I created my light circle I loaded the texture from sf::RenderTexture. I thought it worked the same way but I was wrong. The difference is that a sf::RenderTexture is like a drawing board and when I moved the camera the drawing board stayed put where the starting position of the camera and player was.
I moved the black filter I created from the sf::RenderTexure but not the drawing board itself and it was this that caused so many strange behaviours.

To explain. Se the picture below. The red rectangle is the starting view / position and the green rectangle is what I see right now. As you see the original light circles followed me even though I moved and if I bumped into new circles they weren't drawn. And to add to my headache the circles could move themself also.
So if a circle moved into what is shown as the red rectangle they would show up in my current view in the green rectangle.
This was very confusing and hard to understand why it happened.  I have gone through the code over and over again and nothing was wrong but...it was ofcourse wrong.
Only after I started to understand what the problem could be by printing out the position of the camera, the player position, the light position and the black filter position I could see that I got some strange numbers.

The positions of everything didn't match as it should. so slowly I started realizing it was something wrong with the filter or how its drawn and I started testing different things. I got the filter in the right position but the position of the lights was showing position numbers from an area located where the red square is located but should have shown position numbers where the green rectangle is and that got me thinking it had something to do with the sf::RenderTexture and thats when i found the problem.

All I had to do was add one line of code!!!

m_FilterTexture->setView(m_CameraView);

This code updates the position of the sf::RenderTexture to that of the camera. Problem solved and I could sleep well last night.

Project Aurora, post 6, (Blog Assignment 3) Light / Fog of war around the player

So the feature I have been working on this week is the light effect for our light bulb/Fishing rod that light up an area around the player.

This was something I never done before so first I broke down the problem to the basics.
I need a black filter to make everything on screen black and I need to be able to cut through it somehow to show what's under it.

So I draw out the filter as a sprite that covers the whole screen, Done!
Then I read up on SFML to see if there was some information there abouthow to cut through other sprites and I found some people with similar problems and they had solved it in many different ways. One guy had a flashlight solution that seemed simple enough so I went ahead with trying to implement some of what he done into our game.  The reason I went with his example is because it was fairly easy to understand and wouldn't take a lot of time to code.

He used something called sf::RenderTexture. With it you can "draw" stuff without showing it on the screen. like a secret drawing. If you give that drawn stuff to a sprite you can then draw the sprite out on screen using our normal DrawManager..

So first I need a circle that will be the ring of light that cuts through the darkness.
I don't want a clear cut. I want you to see most in the middle and then it gets darker towards the edges of the circle. So when I created the circle I draw it out on another of these sf::RenderTextures one circle after another, each new circle smaller and with different Alpha value than the previous circle. With this way I created the layered circle I wanted.

I then draw this layered circle on to the drawing / sf::RenderTexture that holds the black filter. After that the black filter sprite gets that sf::RenderTexture/secret drawing loaded into it and is then drawn out on the window.

GetFilterTexture()->clear();
if(p_GameObjMgr->m_pxPlayer->GetLightSource()->GetLightStatus() == true )
{
GetFilterTexture()->draw(*p_GameObjMgr->m_pxPlayer->GetLightSource()->GetLightCircle(), sf::BlendNone );
}
GetFilterTexture()->display();

In this code example I clear my secret drawing. draw out my layered circle and the "save" that.
The "GetFilterTexture()->display();"  don't draw it out on screen but only draw it out on the texture surface.
See it as saving your picture or something. Drawing it out on the screeen is done later in the code.


As you can see on the screenshot the other fish has a light around them as well. That's only for testing at the moment and work in progress, I want to be able to merge two light circles if they overlap for other game features that will let us light up some areas of the game world.

This feature was easy enough to understand but I bumped into so many problems adapting this code into our game due to much code we have is hard coded with numeric limits. And with that there was a problem when moving around on the screen because the world limits was hard coded this way and so was some starting positions and sizes of the player and whatnot. The black filter was the easiest to add to the game but the hardest to understand( because of how the camera is handled).

The black filter can be made really big to cover the whole world or just follow the camera. I chose the solution making it big as the screen and follow the camera because that's more dynamic and can be used if the game world is made bigger or smaller. With my solution we don't have to resize the filter all the time. It does that automatic after the screen resolution.
Since all the problems I had was because of the camera and how moving around works in our game I will cover that in another post about the camera and not go deeper into those problems here.

Project Aurora, post 5, (Blog Assignment 2)

This is my second blog post as part of the blog assignment we have in our class.
Today I will go deeper into animations. Earlier we had it so animations could be loaded and played but only one type of animation and animations couldn't be switched.

The player animations is loaded from a .png file then a sprite/picture is cut out using a rectangle in this case sf::intrect. This rectangle is then stored in a vector. So then I had a vector with a number of frames that could be played up with a set duration. So next I had to think of a way of storing multiple animations.
First I thought I would store one animation in a seperate sprite that then is loaded on to a gameobject but that would mean that a gameobject needs multiple sprites and that felt like it would take more resources and could possibly lead to memory leaks if adding/removing sprites isn't handled correctly.

Then I thought, since I already load in a big spritesheet I just re-use that by cutting rectangles out of it. But then I needed a way to keep track of all rectangles positions. So one vector would represent one type of animation. like moving. eating. attacking, etc. and the vector needed to be connected to the frame duration and I also need a tag to know what kind of animation it holds so my choice for storing all this  fell on using std::map< >

I first added so a struct called Anim (top of the picture) is made within the animated class and it holds a float duration and a std::vector <> I then store that anim struct in a map < > together with a string to know what vector/animation it is.(se bottom of picture to the right)

This way I just store a bunch of rects and one float value for duration and I can access it all using a string.

With this in place I had to re-write the code a bit so it fit with what we had. It's still work in progress for when it comes to optimization. Here is a part of the .cpp file. I'm using an iterator to find the animation type I want to update with help of a string that starts at "Idle" as default but that can be updated using the SetActiveAnimation()-method.

Performance is not a big problem here but I think it might become a problem if the number of animations increase in numbers because it checks through the map with every update looking for the right type instead of just updating the current animation without having to look for it first. So we might change it later but it works for now.

I also changed the way the rectangle sizes are read from a text-file. Instead of having to read multiple text files for every type of player animation i have one text file for all player animations like picture to the left.
Numbers and animations are not 100% correct in the screenshot but its just there to show the build up of the txt-file. So I had to do some changes in the spritemanager as well on how all this is read in.

So now we have a good and dynamic way to load future animations into the game and I'm quite happy with the result.

And as always I end the post with the latest screen of the game.
(doors == enemies)

Project Aurora, post 4

Today our group met with our teacher Marcus for a pre-alpha screening and chat how things are going in the project. We didn't get any negative feedback and he thought we were right on track....phew!
After the meeting I went straight to work and now with some more fun stuff. Player mechanics!...I also moved alot of code though.

I started adding some methods for an attack/dash move on the player so it moves more fluently when attacking and not teleports from on spot to another. I will work more on movement, attack and a sneak mode we have to lure in fish. All these are very important to the feeling of the game so they will need alot of attention.

Here is a code snippet of the dash/attack so far:

First I check that we are in the Dash state with help of the enums I created earlier. Then I check what direction the player is facing so the dash will happen in the right direction.

Then the actual movement is set in the velocity variable with a call to the function to SetVelocity();

After that the dashpower is increased until a certain point. then it starts slowing down.

When the dashtimer reach 0 the dash stops. I will add later that it also stops when you hit a target.

So now I can play around with the dash timer and power to change the movement of the attack to for example fast in the begining and then slow in the end or the opposite if i like. This needs alot of testing so it will match the feeling we want to capture in game.
I will probably start making these different player actions to private methods/functions instead that are called in the player update function. I will make them private so they can't be called outside the playerobject somewhere else in our code.

I also brought a class back to life! Our FishObject class Viktor made. I remade the whole thing and made it inherit from our Gameobject class. The PlayerFish and all other fish will then inherit from this FishObject class.

Here is part of the .h file. some things got cut out from the screenshot on top like the 2 enums direction and state I added the other day. This is the basic outline all fish will have. I will build more on this class I will likely add something for animations here as well since all fish will probably be animated.


I also added so the player sprite flips when moving left or right and I had to set the center of the sprite as origin. Otherwise the sprite flipped based on the upper left corner of the sprite creating a fixed flip? like when you flip a domino. but the result we want is like flipping a pancake, does that make sense?

Here is a screen of the latest progress so far:

My groupmate David added the GUI in the top left corner and we also put in the player sprite / Idle animation. Right now its a little too big but it will be resized soon.

Thats it for today.

Project Aurora, post 3, Things are happening!

I have been doing alot of programming and no blogging so I will try to catch up now.

On last sunday I did alot of changes in the code. For better and worse.
I moved all inputs checks from all GameStates handleInput functions and the core file  to the InputManager's UpdateEvent function that Oscar wrote. The group didn't like it and moved it back the day after.
I also changed how the draw function was called within the different states update function to let the actual statemanager handle the call shown in the example below.

It looked like

Gamestate::Update
{
  HandleInput();
  Draw()
}

I moved the draw to be called from the core/main loop like picture on the left side. m_StateManager.Drawn()

I also changed the StateManager to a pointer put that wasn't liked by the group either so that was also changed back.

All in the red squares is what I  moved out of the game loop and I wanted it to be called only in the State where its needed. I lost that battle as well.

I started making all these changes when I noticed that I couldnt get animations to work and I soon realised that I was missing an important piece......time!
So I started thinking of how to Implement it. I knew there was a sf::Time and a sf::Clock class. I have been in contact with them before I started studying like 2 years ago when I just played around with sprites using SFML.

So I looked at Tommi Lipponen's (our teacher) code from a C++/SDL project and I tried to translate that to SFML library and I ended up with the code to the right.

So what it does is it sets a sf::Time object to zero and then get the time passed since last iteration and restarts the clock.
Clock.restart() returns time as well as restarts the clock so its quite handy. I then give the collected time to a float variable called m_DeltaTime that is used throughout the game for updating positions and so on. I also check so m_DeltaTime not get bigger that 0.1. if it does it is set back to 0.1.
I also added a vertical sync on the window just after the window is created (not shown here) to limit the frames to around 60 frames / second so the If-statement here is probably never needed. its just a safety net.

With this in place I started working with adding animations to the player.
First I created an Animation class that inherits from sf::Sprite class. I also added a LoadAnim function so animations is loaded with the SpriteManager and I then add the animation to the playerobject.
How all this happens is still under construction so I will go deeper into how it works next time I blog because I am changing alot in the code now and I have to figure some things out first. like how to add many different animations and how to set which one is playing.

I did some small changes in how the GameObjects and updated and drawn.
I also decided to seperate the player from other GameObjects after some talks with fellow students and our teachers. The reason is because the player differ so much and its just silly to store it together with everything else.

I added movement to the player and also added so that a camera is centred on the player and follows player movement. I will probably play around with that so it behaves less fixed to the player after som tips from Linus (third year student and counselor to us newbies)

Last night after the animations, movement and camera was in place I pushed it up to Github so my group members could take part of it. After that, one of my group pushed his changes as well and because we had been working on almost two different versions of the project it caused major mayhem. Bunch of conflicts and crashes! Visual studio didn't even open. It felt like all was lost. Luckily we have a Github genius in our group ->David  . He fixed it all in about 2 hours and we were up and running again today at lunch time....phew!
Lesson learned.......commit, push and pull things to Github way more often to prevent people working on versions that differ too much. Everything flows more easy this way.

So today:

We got everything to be drawn out at the writing of my last blogpost but it wasn't handled so good. It took between 2-5 seconds for things to be drawn to screen after the GameState was entered.
I knew it had something to do with how the SpriteManager worked. I knew it was a pointer problem and I tried a 1000 different things with pointers everywhere! Today I asked my teacher(Tommi mentioned above)
and he said it was an SFML thing and looked at my code. He found the error in 1 second. A problem I have been sitting with for days! it was right infront of me but i missed it.

So I changed this row in the SpriteManager.h file and made the Texture element in the map a pointer.

I had done that already and all changes in the pictures below as well but It only gave me white squares instead of sprites when I did it...I was about to lose it! Thats when I asked Tommi.

The only thing I missed was whats in  the red square. (new sf::Texture) with that in place it all worked so great!. I would probably have solved it eventually.....I was so close. But Tommi saved me a few days of headache. Thank you!

I then started working on the PlayerObject some more. trying to figure out animations and keeping track of movement. I added 2 different Enums. One that will keep track of the player state. Idle, Moving Dash, Eat, and so forth and one to keep track of the direction the player is moving.

I added an easy dash mechanic that makes the player  dash forward a few pixels when spacebar is pressed. I will keep working and fine tuning movement and animations to the player the following days. So I will get back to you on the next blog on how that works out.

Here is latets screen of our game so far: Player and Camera movement in place as well as animation.

(animation not show in the screenshoot....duh!)

Project Aurora, post 2 (Blog Assignment 1)

So we have laid down some plans for the game which we based our SCRUM on but we haven't finished the design document yet. This is causing some smaller problems. It's been kind of hard to organize the programming of the game. Who will code what and when does it need to be finsihed and what does it need to have.

Result is that we have been doing some unnecessary things. I had to redo the whole GameObjectManager and the Sprite and FishObject class that Viktor made was removed from the project.

The other day we met with our game design teacher Adam Mayes from our other class of game design we had last autumn. He gave some feedback on what we had and we all realised that our aestethic goal  was not the one we had planned for in our SCRUM. So he guided us in the right direction and I felt the group became more focused on what we needed to do after that meeting. Our main aestethic goal now will be challange and not exploration/discovery that we had planned.

One of the assignement in the course Introduction to game development is to write six blogposts where i need to reflect on one artefact/feature i made during the week. so this week I merge this post together with the game programming course that we have in parallel to game development.

So this week and last week I've been working on the GameObjectManager class. This class will handle all the game objects in game. I chose to write about this one because its been giving me most grief the last two weeks. 

First i designed and wrote the code for this so all different objects are stored in their own container (C++ vector class.)  like this:

PlayerFishObject *m_pxPlayer;
LightObject *m_pxLight;
std::vector<TerrainObject*> m_apxTerrain;
std::vector<EnemyFishObject*>  m_apxEnemy;
std::vector<PowerupObject*>  m_apxPowerup;
std::vector<InfoObject*>  m_apxInfoObject;
std::vector<TrapObject*>  m_apxTrapObject;
std::vector<ParticleObject*> m_apxParticles;

Because I made one container for each type I had to make alot of functions within this class to handle all these objects. How they are stored when loaded into the game. How they update during gameplay and how they are deleted. This wednesday I got feedback from the last game I made. (See earlier blogpost.) In it was explained that i did alot of workarounds and storing in so many different containers was kind of bad. So now I rebuilt it all so all different kinds of game objects are now stored in the same container.
So now i use this instead of the above:

std::vector<GameObject*> m_apxGameObject;

When doing it this way we need to use C++ polymorphism to access child classes that inherit from the parent GameObject class that i also created for this. Within this new class I added a virtual function which means that all classes that inherit from the GameObject class can have the same function.

virtual void Update();

If they have a function with the same name, the child class function will be called and not the parent function of the same name.

This is really smart but since we all are new to programming this is a bit unfamiliar grounds we are stepping on. But thats how you learn right? So the reason we felt like going this way is for learning new ways to program more effectively and for increasing perfomance.....i hope.

We have only tested this with one type of object so far. So we will probably have to improve this class further when we bump into problems. With this in place I also had to add some functions to the spritemanager class that Viktor had built so it fit with our Gameobject class and SFML library we are using.

I based it from the same way of thinking that we learned from our C++ teacher Tommi Lipponen's platformer that was made in C++ using SDL library. But because SFML have a built in sprite class and handle sprites differently some changes had to be made. What these two functions basicly does is loading a texture from a png file and storing it in a C++ map container. Then a new sprite is created and allocated in the heap memory using the stored texture.

So today we could finally draw game objects to the screen that is loaded from a text file in a dynamic way where we reuse the same texture when we load and add the sprites to the background objects.

Here is a screen using placeholder sprites:

Beautiful right? well it will improve in looks as soon as we get some real art to work with.

Today we had a sprint review of this weeks work where i was supposed to do this:

Camera / View
EnemyFish (class)
TerrainObject (class)
PowerupObject (class)
InfoObject NonInteractive's (tutorial)

I finished the PowerupObject class but its not in the game yet. It inherits from the GameObject class that i made (that wasn't in the sprint planning / backlog) The PowerupObject will handle the Power-ups in game and I only did a basic outline of the class so we have something to start with

In it I created an Enum that will keep track of what type of powerup it is.

enum eType

{

ROD,

LIGHT,

SPEED,

ENERGY,

TYPECOUNT

};

I then added the following functions:

eType GetType();

void SetIdleMovement(float p_fMovement);

/*void SetGlowEffect();*/

void Update(float p_fDeltatime);

• GetType returns an enum with what type of power-up it is. 

• SetIdleMovement is the speed the which the power up will move with up and down. We want it to move up and down slowly so it feels like its floating around in the ocean.

• The SetGlowEffect I just put there put its not implemented yet because no one in the group know how to implement lighting/bloom effects. If we learn that we will add it in. There is an example in the SFML-book that I will read through when we come to that. (Special effects will have to wait until basic mechanic is in place)

• And then there is an Update function that updates all the movement made in the current frame.

Since I rebuilt the GameObjectManager and added a GameObject class we could basicly skip making the Terrain and info objects because they are created/integrated in the GameObjects, atleast for now. If we need them to have alot of different functions we will probably break them out in their own class.

I then played around with camera management in SFML and they have built in functions that are quite good so I think we will skip adding a camera class to the game. If we come up with new ways to maipulate the camera we might add it in. I made a small prototype playing around with the camera so I will use what i learned and implement that in our main project. I thought of showing that here but its not that good so I will show some screens when I've implemented it in a better way. I will continue work with the camera during the next week as well.

I think this is all for today. feel free to comment.