chringo / ssp Goto Github PK

As a level editor dev, i want a function that receives a ray consisting out of 2 XMVector3's (maybe also overload taking XMFLOAT's) that when called, centers in the directions of that ray. this feature may just require the direction of the ray and not the origin.

1: What type of information needs to be communicated?
2: How will the information be communicated?
3: How will the information be received, interpreted and possibly stored?

With this issue, a project page called "Task board" has been introduced. Its' purpose is to list tasks created via issues or simple notes created directly on the project page. Notes should be created at minimum and only for very minor tasks.
The course has ended and the semester is nearing its' last days. This means that nearly everything will be done digitally on our Discord channel and here. This is the "decentralised workflow" which the git repository must be enabled for, hence, the new project page and the future tasks created on it. Please put your issues on it accordingly, making them public. Perhaps there are others that would like to aid you?
If you have any suggestions or would like to discuss the task board or the future working process for this repository, feel free to add a comment here or on Discord.
In any case, this is our legacy of SSP which I believe will grow slowly but steady with time. Good luck with your careers!

Causes confusion in git, and will make much problems if leaved unattended

In SSP, entities communicate with each other by being subjects and observers. A lever, button or any other trigger entity is the subject for other entities. These other entities are observers to this entity and are added to the subjects' list.
Hypothetically in the editor, entities are linked with each other with a tag index. Entities that should observe an entity such as a button has the same tag index as the button. It's believed that the tag index is used only in the editor and in the process of importing a level which happens in level state.

Hypothetically in SSP during the import of a level, we want to import the subject with a tag index and if an entity is observing this tag index we want to connect these by adding the observer to the subject.

How can the player find out if they are grounded from the physics component/handler?

Syncing between the different components and parts of the system when using in this case: rotations.
The Editor uses degree and physics uses radians. This is now part of a bug where platforms graphic component is rotated (unintentionally) but the bounding boxes are not.

They are currently two-thirds of our warnings.
References:
https://msdn.microsoft.com/query/dev14.query?appId=Dev14IDEF1&l=EN-US&k=k(C4251)
https://www.codeproject.com/articles/28969/howto-export-c-classes-from-a-dll

The situation is the following:

Both the Host and Clients systems is identical:
Player1 EntityID = 1
Player2 EntityID = 2
Ball1 EntityID = 3
Ball2 EntityID = 4

The way we update them over the network is by sending the update together with the ID of the entity.
Then when the client receives the packet, it will check the ID and do one of the following things:
if ID == 1
Player2->GivePacket()
if ID == 2
Player1->GivePacket()
if ID == 3
Ball1->GivePacket()
if ID == 4
Ball2->GivePacket()

The problem is that if we have a condition like this:
if (Player1 && Ball1)
//Do something
it will mean different things on other machines since the object that got moved on one system is not the one moved on the other system.

This is NOT that great of a deal currently since this only involves ONLY the Player1,Player2,Ball1,Ball2 variables in 'LevelState'. The only place we currently uses Fields is to change level between maps, and then the condition is only if both players is inside the field, which both will be on both systems.

NOTE: I only put up this issue to clear this up. If you still have question on what to or not to do, just come and ask me.

The physics is frame dependent.

See also #6 and #15

This originates from certain models not handling these positions like the rest.
Specifically, it affects platforms since they are the ones using the models.

It has been solved for now by fetching the models OBB at different times in the code.

• In LevelState.cpp we fetch rotation data.
• In PlatformEntity.cpp we adjust the world matrix accordingly to the centre of the OBB.
  The latter happens during the update of said entity.

Currently the graphics handler uses the resource handler to get data for rendering.

But there has been talk about using the resource handler in other places of the engine. For example, the animation handler will need animation data quite frequently. And the game(engine) should trigger the "load level" events when moving to a new level.

Currently the resource handler is a singleton. but we might face big issues going forward if we access the data on multiple threads.

As a level editor dev, I want a single function that takes an XMFLOAT3 representing XYZ values and applies these values on the cameras local translations using upvector m.m.

Security check to see that I didnt break Everything in the cleanup I've done in the EditorCleanup branch

Since entities now have unsigned ints instead, I'm guessing we need to update this wherever we handle entities?

Every handler has a set amount of resource containers at start. When this is exceeded it is expanded.

every handler has a vector that holds the data.
Then an unordered_map that holds pointers to that data.

When pushback happends in the dataVector. Every element is copied into new elements.

This makes the pointers in the unordered_map completely obsolete.

How can i get around this?

include <malloc.h> needed in the physicHandler.cpp?

Sometimes the mouse input wont register yaw, im on it. Just restart the game if it happens. Let me know if it becomes too much of a problem.

PBR branch currently have some bug issues.
See also #6

It's a checkbox that does nothing. We should remove this to avoid confusion.

If the player is left in ragdollstate on a moving platform and the players ball is resting on that platform, the player will not be able to leave ragdoll state

There is a bug that causes the object to dissapear when an object has great force and are stuck between two AABBs.

The camera moves faster the lower the framerate is.

As of now we don't have a code standard for what to return when errors, successful, and warning states occurs.

There is screen tearing in the development branch. One probable reason is the introduction of dynamic objects in LevelState.

I noticed when the character is supposed to fall down he falls too slow. This allows for the character to run in the air, which allows him to run over gaps, such as the gap at the end of the intro level. The forward velocity is greater than the velocity down i think.

In order to make an installationfile we need to get some spring cleaning done, the only one remaining are Shaders. This is for the moment read from "SSPSolution/graphicsdll/Shaders" instead of "SSPSolution/Assets/Shaders".

I've changed so that the hlsl are read from the Assets folder in the shader code but DirectX screams in agony if I remove the "SSPSolution/graphicsdll/Shaders" folder. The linker is dependent on something here

When the player is in animation state, the physics components is not updated with the along with the animation components. This can be problematic when objects interact with this. Possible frame drops

The dependencies that are to be required for the animations is the ResourceLib (to gain access of the skeleton and animation data). The overall structure of handling animations in the engine is currently none. Several people are required to solve this matter,

I would suggest that we fix these errors on everything except temporary code since it's not that much work.
See also:

• https://msdn.microsoft.com/query/dev14.query?appId=Dev14IDEF1&l=EN-US&k=k(C4018)
• https://msdn.microsoft.com/query/dev14.query?appId=Dev14IDEF1&l=EN-US&k=k(C4244)
• https://msdn.microsoft.com/query/dev14.query?appId=Dev14IDEF1&l=EN-US&k=k(C4305)

When a player pick upp the ball of the other player, the player will after a prief period leave BALL_IDLE state and play IDLE state. This will be reset when the player moves

as level editor dev i want to set an offset based on rotation

See also #6, #15, and #16

There is some major issues due to unstructured code in the level editor. This needs to be attended to.

There are probably several unknown problems that prevent us from running it in release-build. The more we stall this issue the harder it will get to solve it.
If you encounter a problem or solved something that helps us build in release, please log it in this issue so that we can perhaps run it in release eventually.

If my changes work for everyone, including laptops, then I'll propose a pull request migrating Bullet from the solution. However, future me should rebuild Bullet into dynamic libraries, with debug information for debug builds, so that we can avoid compiler errors caused by having a different compiler.

It might be a good idea to change std::map in Subject to something else since it is really slow.

Many crashes happens with handling XMMATRIX and std::vectors in functions like InterpolateKeys, to play and interpolate animations. Looking at the animation components, they seem to be fine, although further checks with these need to be made, to further isolate what the problem might be.

Any ideas what could possible cause these crashes? Could the data I get from resources be corrupt or could just handling XMMATRIX and std::vectors be an issue.

There are a few files that are generated each time we build the editor beginning with moc_*. We might not need to include these in the repository if they are generated at each build. However, they might be needed if we're supposed to run the editor outside of VS. This would mean that we commit these "moc"-files at each release.

The camera is not working the way it should, this needs to be fixed as soon as possible

It's not set to true or false, thus defaulting to garbage values and interpreted as true. Can this become a problem?

Random crashes on acer-laptop on following line.
https://github.com/Chringo/SSP/blob/dev/SSPSolution/GraphicsDLL/GraphicsHandler.cpp#L194