Open ghost opened 9 years ago
I'm trying to get 1 line of code working for 4 hours. And it has to do with the include loop interdependency. I decided not to push the broken code until I got your thoughts on the problem.
env->addObject(this); // this thing is in object.h, and I can't include environment.h because environment.h already includes object.h
Ok I found a solution, but you may criticize it for its design. I hate it too, but at least the object management is more automatic. The environment provides the object the object pool to add itself upon creation, and the Environment deletes the object if it sees the object set itself to be destroyed. I am pushing the new code since it runs.
ok, im going to take a look.
I made the environment a singleton, now the object class doesn't depend on environment. We should be able to go pretty far with this design
I think it is a good idea if you enable all compiler's warnings. For example the "extern friend class" was just an error for me because of that. Warnings are always good.
Good idea.
Also I was thinking of making the visual style of the game unique. Can we use layers to give a some what depth effect? Almost like paper mario. The tank will be made of many smaller objects like wheels, body and cannon. Imagine those pieces flying apart if the tank is hit by a rocket. It's just a rough idea, and maybe we can improve on that.
On Thu, Nov 13, 2014 at 4:47 PM, Sherushe notifications@github.com wrote:
I think it is a good idea if you enable all compiler's warnings. For example the "extern friend class" was just an error for me because of that. Warnings are always good.
— Reply to this email directly or view it on GitHub https://github.com/Sherushe/tanks/issues/14#issuecomment-62972247.
I like it. I will create the tilemap class with that in mind.
Whoever gets the assignment for an issue about implementing the rectangular collision first gets to work on it. I don't think the vector based collision is of high priority right now. I will probably get back to it when we will be doing fancy effects like highlighting a projectile's path. So, If I don't get the assignment for collision first, I will work on either:
1) Scene code 2) Object Layering 3) GUI objects class
Which one of there is more important?
I already assigned myself for the rect vs circle collision, but you can do it if you want. I just thought maybe you had enough of vector calculations. Do you want to work on that?
Restructuring the environment class is the highest priority.The 1). We can't do any GUI stuff without it and object loading is also dependant of the implementation we make.
I cleared the assignement so go ahread if you want to do it.
You can do it if you want, I'm going to be rather busy today and and tomorrow. So if you need the collision to to further the development, I suggest you do it because otherwise I will be slowing down progress. I would rather work on other features at my own pace in that case. If it won't slow down the development then I can take on the assignment.
On Mon, Nov 17, 2014 at 10:53 AM, Sherushe notifications@github.com wrote:
I cleared the assignement so go ahread if you want to do it.
— Reply to this email directly or view it on GitHub https://github.com/Sherushe/tanks/issues/14#issuecomment-63325114.
ok I do it. It isn't the most interesting thing anyway and we can finally add walls.
I added a new programming guideline: If a new file has been added to the project relating to an issue, add a "new file(s)" label to the issue and state the name of the files added. If the issue pertaining to the added files doesn't exist, then create it.
This is due to visual studio not seeing new files that are pushed into the repo that don't exist locally.
I have the same problem here. I have to tell cmake so its a good idea.
Hey Sherushe! One more day left until I can put college work aside for a bit. So what's the status of the component system? Also, be sure to follow at least some guidelines. You added a bunch of files and renamed some others, so it would take me extra work, following through the commits, to see what to import.
Since you are far into the component based design, I'd rather not repeat the same incident as what happened with the camera. I will instead proceed to work on the GUI and HUD.
Hi, Alright, it's a good thing that you work on the GUI. But what do you mean by same incident? We are working on different things. If you fix the Dev branch and optimize the architecture, we could do a better comparaison between both.
For the component system, sorry the repositry is still in an "in-between" state. Once i get the system to work I will properly name the files and tell you how it works. For the status, i'm struggling a bit with the design, because i wanted to have a strongly typed system but the consequence of it is that everything needs to be in the headers ( because of templates ). I hope I can find a solution soon.
For the status, i'm struggling a bit with the design
Take your time. Just keep me posted, so I'm not in the dark.These last couple days were very busy such that I didn't go over to github to check the status until yesturday, and github never sent me updates about the new commits. So try writing something in the issues so I know the project is not on hiatus.
On Tue, Nov 25, 2014 at 4:51 AM, Sherushe notifications@github.com wrote:
Hi, Alright, it's a good thing that you work on the GUI. But what do you mean by same incident? We are working on different things. If you fix the Dev branch and optimize the architecture, we could do a better comparaison between both.
For the component system, sorry the repositry is still in an "in-between" state. Once i get the system to work I will properly name the files and tell you how it works. For the status, i'm struggling a bit with the design, because i wanted to have a strongly typed system but the consequence of it is that everything needs to be in the headers ( because of templates ). I hope I can find a solution soon.
— Reply to this email directly or view it on GitHub https://github.com/Sherushe/tanks/issues/14#issuecomment-64337747.
I can write things in the issues, but the design is constantly changing so if I say something it will probably be wrong the next day. Don't worry if you don't see updates, I'm working on it whenever I can. I pushed the last updates so you can see the current state.
Everything is in include/core/memory.h, but it's still evolving.
I will tell you when it's ready so no messages means I still have problems.
the design is constantly changing so if I say something it will probably be wrong the next day.
Nothing like documenting the history of the project. This is also know as a changelog
On Tue, Nov 25, 2014 at 6:44 PM, Sherushe notifications@github.com wrote:
I will tell you when it's ready so no messages means I still have problems.
— Reply to this email directly or view it on GitHub https://github.com/Sherushe/tanks/issues/14#issuecomment-64492143.
Good idea. I will make one once I get the base system running which sould be pretty soon ( probably tonight ).
Are you planning to merge the experimental branch with the dev branch?
Well, I think we can keep the oop architecture for a souvenir. I think the best would be to directly merge with master once we reach a millestone or something.
We will merge with master after the scoring system is implemented at least. A game is no game without game mechanics; it's a demo otherwise.
On Thu, Nov 27, 2014 at 5:00 AM, Sherushe notifications@github.com wrote:
Well, I think we can keep the oop architecture for a souvenir. I think the best would be to directly merge with master once we reach a millestone or something.
— Reply to this email directly or view it on GitHub https://github.com/Sherushe/tanks/issues/14#issuecomment-64768883.
As soon as you are ready to merge with the dev branch I will begin implementing the GUI/HUD code. Visual Studio is giving me issues when switching to a different branch (as if it was another project). Meanwhile I will make sure I understand how to use the new code.
On Thu, Nov 27, 2014 at 5:05 AM, A Braker abraker95@gmail.com wrote:
We will merge with master after the scoring system is implemented at least. A game is no game without game mechanics; it's a demo otherwise.
On Thu, Nov 27, 2014 at 5:00 AM, Sherushe notifications@github.com wrote:
Well, I think we can keep the oop architecture for a souvenir. I think the best would be to directly merge with master once we reach a millestone or something.
— Reply to this email directly or view it on GitHub https://github.com/Sherushe/tanks/issues/14#issuecomment-64768883.
Alright, I will merge with Dev. I will keep the oop code in the "old" folder.
I added a wiki page explaining how to work with the entity component system. Maybe look at some existing projects to give you an idea of how the components and the systems look like.
Ok sounds good On Nov 27, 2014 3:47 PM, "Sherushe" notifications@github.com wrote:
I added a wiki page explaining how to work with the entity component system. Maybe look at some existing projects to give you an idea of how the components and the systems look like.
— Reply to this email directly or view it on GitHub https://github.com/Sherushe/tanks/issues/14#issuecomment-64829205.
One thing about the compilation: You will probably have to add the "include" folder in the include directories in vc++. Every include is relative to that folder.
I have successfully pulled, built, and ran the project.
I'm done for today. Changelog:
okay. good job.
I will try to fix the bugs.
I cant push. Git is giving me this errors which I have been trying to solve for hours:
current branch does not have an upstream branch configured
You cannot publish local branch Dev to the remote repository origin because a branch with the same name already exists there. You might want to rename your local branch and try again.
My Changelog for today:
So I looked through the SFML docs, and found a function in the RenderWindow class that is going to resolve the coordinates not matching up if the view is altered:
I won't be able to work on the game tomorrow, but I am planning to get at least the buttons done this week. One thing I wonder: Using the ECS system, how would you go about having relative values. For example: A button has text and an icon relative to the button's location, and a scrollbar causes it to move up and down. I am thinking a reference component might do it, but I don't know how it will work for multiple values. The reference component would be updated by the system, where the system gets the referenced value, creates a copy, operates on it and returns the relative value. What do you think?
That function should work. Also when the view will be correctly set, the conversion won't be necessary anymore, I think.
For the relative position, I'm not sure how you want it to work. I guess like it's a parent-child system. Because we won't have a complex GUI, the easiest would to just keep the id of the parent entity and when an object gets rendered, go up the parent chain and compute the absolute position. But do it how you like.
For the project, you don't have to work everyday on it. Do it when you're motivated. In other words, you don't have to tell me when you're busy I will understand.
For the project, you don't have to work everyday on it. Do it when you're motivated. In other words, you don't have to tell me when you're busy I will understand.
I just feel that me working on it once every 2 to 3 days is a bit to little for me. I used to put in hours a day programming back in highschool, so seeing how college takes away that time is a bit sad.
On Sun, Nov 30, 2014 at 4:13 AM, Sherushe notifications@github.com wrote:
That function should work. Also when the view will be correctly set, the conversion won't be necessary anymore, I think.
For the relative position, I'm not sure how you want it to work. I guess like it's a parent-child system. Because we won't have a complex GUI, the easiest would to just keep the id of the parent entity and when an object gets rendered, go up the parent chain and compute the absolute position. But do it how you like.
For the project, you don't have to work everyday on it. Do it when you're motivated. In other words, you don't have to tell me when you're busy I will understand.
— Reply to this email directly or view it on GitHub https://github.com/Sherushe/tanks/issues/14#issuecomment-64979820.
Yea, I agree. Well, if you just have little time to spare, use it wisely!
For some reason the function I mentioned from the renderWindow class is not working. I tried setting the view to screen size and that didn't work either. I am running out of ideas on why the mouse coordinates do not match the view coordinates.
How are you getting the mouse coordinates? Did you get the coordinates relative to the window like this?
oh. I was using sf::Mouse::getPosition().x, but the one with the relative to window parameter could simplify my code a bit, but still not solve the problem. Look closely at how sprites are rendered in the view. The pixels look zoomed in; they have this blinear zoom effect to them, and setting the view to (0,0), (window width, window height) doesn't resolve it even though it should put the view in a 1:1 ration with the window, per-pixel.
Changelog for today:
I see you're progressing with the UI. Nice.
Sorry if I'm inactive, my mind is elsewhere. I will push some code once I'm restored.
ok, and I want to figure out how to resolve the mouse-view coordinate problem
Changelog for today:
I red the code. Looks like you understood what an ECS is. Good work.
I'm getting used to it. It has its limitations that OOP doesn't have that I need to work around, such as getting a certain entity from the list.
What do you mean? An entity is an ID. You can get all its components based on the id.
ok, i am back. Here is the changelog for this commit ( I will probably make one more today ):
I made two separate components for the sprite and the texture. Reason, obviously flexibility but the most important one is that the tilemap is a vertex array. So now tanks = sprite + texture, tilemap = vertexarray + texture.
Also now every sprite entity must have a Sprite component attached to it. It includes UI elements ( I made the changes ).
I copied the code of the camera into this version:
sorry for the messed up namings. I will correct everything soon.
We will use this "issue" for the main discussion.