bunch of math2d and 3d features and test programs #60

UbuntuJackson · 2023-06-19T19:05:50Z

/math2 contains features for ray to line intersection. Can be used for more precise collision detection, as well as detection with polygons. Also has other neat usecases.
/math3 contains some WIP 3d stuff, and I'd recommend we keep it there to be worked on. It can be useful for 2d stuff as well in some cases.
/test contains some test projects. We should keep it in there to demonstrate existing features, though we need to make it a bit tidy. It's a bit harder to describe the rest of the folder I added, but it has to do with how I'd like to make like, a signal system in Brux, something similar to what godot has.

hexaheximal · 2023-06-19T19:19:35Z

rte/src/communication/communication.cpp

What is this, and what is the point of including this?
Also, why is b using the auto type?

The whole communication folder is basically an attempt to connect events between objects in the game. It's supposed to be almost like signals in Godot. I think we should consider other ways to have objects referring to eachother without referencing them directly. Events should be stored in an std::vector. Other objects will look in that list and use the match event function to look for what it's expecting. With this we can indicate everything between indicating that a gameoverscreen should be triggered, a coin has been collected, and what should happen when a button is pressed. This avoids these cluttered update functions with a bunch of for loops. Ideally iteration should not be done in update functions unnecessarily to make it easier to look at.

The whole communication folder is basically an attempt to connect events between objects in the game. It's supposed to be almost like signals in Godot. I think we should consider other ways to have objects referring to eachother without referencing them directly. Events should be stored in an std::vector. Other objects will look in that list and use the match event function to look for what it's expecting. With this we can indicate everything between indicating that a gameoverscreen should be triggered, a coin has been collected, and what should happen when a button is pressed. This avoids these cluttered update functions with a bunch of for loops. Ideally iteration should not be done in update functions unnecessarily to make it easier to look at.

Okay, so basically a pubsub interface. Shouldn't that be done in squirrel though?

Whatever we'd wanna have in squirrel, we should consider to have it in C++ too, as there isn't any debugging interface for squirrel set up yet. I'm very willing to contribute to this project as it seems easy to build on, but not if I'm forced to use a language I can't debug.

And if there is a system to debug squirrel currently... why hasn't anyone told me?

And if there is a system to debug squirrel currently... why hasn't anyone told me?

There is, actually: https://github.com/shatteredmoon/squirrel_imgui_debugger

Kelvin actually starred it a while back.

Then maybe making it more well-known would be a good idea.
Second, I think we should have as many features as possible as a part of the engine. Why would we have almost everything in squirrel, when we can't even inform people on how to debug it?

Then maybe making it more well-known would be a good idea. Second, I think we should have as many features as possible as a part of the engine. Why would we have almost everything in squirrel, when we can't even inform people on how to debug it?

Debugging isn't really the relevant problem here. The problem is that doing it on the native side doesn't seem necessary and could easily cause type-related issues.

Oh, I would absolutely say that debugging is a problem if you ask me.

hexaheximal · 2023-06-19T19:20:05Z

rte/src/assets/Sprite-0001.png

Why is this here?

Testing purposes, but now we have another folder dedicated to testing projects.

Testing purposes, but now we have another folder dedicated to testing projects.

Okay, makes sense!

Should it be moved into there then?

Yes, it should.

hexaheximal · 2023-06-19T19:20:39Z

rte/src/math2/collision_info.hpp

This looks confusing...

Ask more specific questions.

The syntax on lines 15-16 looks really odd. Also, the indentation doesn't make much sense.

I wish it was custom to show me the right way when telling me I am doing it the wrong way.

hexaheximal · 2023-06-19T19:21:18Z

rte/src/math3/matrix4x4.cpp

Why not use something like glm for this instead?

I'm not really at the stage where I can do that. It should be considered later, as I am focusing on one thing at a time. Would never get these features done if I always went the extra mile. Can we end that question at that?

I'm not really at the stage where I can do that. It should be considered later, as I am focusing on one thing at a time. Would never get these features done if I always went the extra mile. Can we end that question at that?

Sure, that can be saved for a future commit if it works. It just doesn't make much sense to do it from scratch when there are well battle-tested libraries already.

hexaheximal · 2023-06-19T19:22:11Z

rte/src/math3/matrix_multiplication3.cpp

This is very confusing, and I'm still not sure why you would choose to implement this yourself instead of just using a library like glm.

hexaheximal · 2023-06-19T19:23:03Z

rte/src/math3/mesh3.cpp

Brux is not ready for 3D yet. This should be saved for another time when it makes more sense to include.

Okay, but I don't know how to filter it out every time I do a new pull request and simultaneously do my own changes. I am not very neat at operating git and github yet.

Second, I would heavily recommend that we keep the core 3d math features though, as you never know when they come in handy. They are very basic and you are gonna want them either way in the future. It's definitely possible to keep it in there while making it look clean and ready for future use.

Okay, but I don't know how to filter it out every time I do a new pull request and simultaneously do my own changes. I am not very neat at operating git and github yet.

git stash is what you're probably looking for.

Second, I would heavily recommend that we keep the core 3d math features though, as you never know when they come in handy. They are very basic and you are gonna want them either way in the future. It's definitely possible to keep it in there while making it look clean and ready for future use.

Good point, but shouldn't it at least have a configure flag for it so it can be disabled when not needed?

Suggest a practice for how we would handle said configure flags. We might have more WIP things in the future, and the community being informed about how we go about this would be beneficial.

Suggest a practice for how we would handle said configure flags. We might have more WIP things in the future, and the community being informed about how we go about this would be beneficial.

Add option(USE_3DMATH "Include 3D math APIs" OFF) to CMakeLists.txt and add #cmakedefine USE_3DMATH to src/config.hpp.in. Then you can add the ifdef to the relevant files.

hexaheximal · 2023-06-19T19:23:22Z

rte/src/math3/ray_vs_plane.cpp

I have no idea what this does.

Returns collision info for an intersection between two Ray2 instances.

Returns collision info for an intersection between two Ray2 instances.

But... this is in math3?...

My bad. It's a very poweful function for 3d collision. Should be kept so that people are aware of it's existance. There is a lack of good references for ray to plane inersection. We could do first person shooters using this function. Keep it there to be used one day.

hexaheximal · 2023-06-19T19:24:30Z

rte/src/test/game/game.cpp

This shouldn't be included in brux itself. Move this into the squirrel-based test suite.

Squirrel-based? You think it's bad to test basically anything in C++?

Squirrel-based? You think it's bad to test basically anything in C++?

Real brux applications are written in squirrel, so it would make the most sense to test within squirrel.

I am pretty pissed at this point, maybe I should not contribute at all if you're just gonna missinform me on a massive scale.

I put effort into this, and I feel like other people are just puking at what I make.

We can't test this within squirrel because I can't make this within squirrel at the moment. Would having test projects in there to demonstrate the functionality cause any problems at all? I guess I could provide them myself, but like... do you wanna download an external repository to get those examples? If you wanna test how something runs, instantiate an example project. It will demonstrate how it runs pretty quickly.

hexaheximal · 2023-06-19T19:25:13Z

rte/cmake/xylib/core.nut

Why is this here?

You tell me, I don't know everything.

You tell me, I don't know everything.

Appears to be unintentional. You should remove this file.

A more thought-out answer: I didn't add it manually.

hexaheximal · 2023-06-19T19:26:00Z

rte/cmake/squirrel_project-prefix/src/squirrel_project-build/lib/libsqstdlib.so

This (as well as the rest of the build files) should not be included. Use git commit --amend to clean up this mess.

I don't completely know how --amend works.

I don't completely know how --amend works.

It's quite simple, actually.

Just do git rm -rf [filenames] to remove the files you don't need (and you can also use git add [filenames] to add new changes) and run git commit --amend to edit the last commit.

Then you can run git push --force to force-push it into your branch.

hexaheximal · 2023-06-19T20:17:59Z

It looks like this can't actually be merged due to merge conflicts since breaking changes have been made since the previous commit on your branch. Can you try running git reset --hard HEAD && git pull, making your changes again, and then force-pushing to your branch?

UbuntuJackson · 2023-06-19T21:46:40Z

It looks like this can't actually be merged due to merge conflicts since breaking changes have been made since the previous commit on your branch. Can you try running git reset --hard HEAD && git pull, making your changes again, and then force-pushing to your branch?

What does making my changes again mean, and how do I do that efficiently? You mean literally resetting it to an earlier head, pulling and copy pasting my backed up stuff in there? I feel like I'm being misdirected, can you make really sure that I don't misunderstand this? I'd need more details.

hexaheximal · 2023-06-19T21:50:19Z

You mean literally resetting it to an earlier head, pulling and copy pasting my backed up stuff in there?

Correct. That would be needed to properly fix the commit as it would make it based on the latest upstream commit, which would fix all of the merge conflicts and also give you a chance to fix some of it.

UbuntuJackson · 2023-06-19T21:54:11Z

You mean literally resetting it to an earlier head, pulling and copy pasting my backed up stuff in there?

Correct. That would be needed to properly fix the commit as it would make it based on the latest upstream commit, which would fix all of the merge conflicts and also give you a chance to fix some of it.

Is this like, how you do it every time you do a pull request, or can I avoid it most of the time in the future? Again, I wanna be properly directed with this.

hexaheximal · 2023-06-19T22:04:01Z

Is this like, how you do it every time you do a pull request, or can I avoid it most of the time in the future? Again, I wanna be properly directed with this.

Usually, no. If the commit history is new enough, it can be merged just fine.

However, in this case it's old enough that the code has changed significantly since you last pulled into your branch.

There are a few solutions to the merge conflicts in this case:

Merge upstream back into your branch and fix the merge conflicts in the merge commit.
Upsides:
Really easy to do
Downsides:
Creates another merge commit and further complicates the commit tree.
Amend the conflict fixes into your commit
Upsides:
Doesn't create an additional merge commit
Downsides:
Makes the commit history even more confusing since you're targeting a different commit than the actual parent commit, and it can easily look confusing since you're adding in existing changes again into your own branch, in your commit, in a weird way, which would just make the git blame look confusing.
Revert the commit, pull from upstream, and re-commit (This is what I'm recommending)
Upsides:
Doesn't have any of the downsides of the previous 2 options.
Downsides:
Requires you to back up your changes somewhere else and re-commit them later in a way that works properly with the latest upstream commit.

tulpenkiste · 2024-05-17T16:24:55Z

This PR is now incompatible with the unstable branch (due to #71) so this would need to be reworked or closed without merge.

bunch of math2d and 3d features and test programs

83d9048

hexaheximal suggested changes Jun 19, 2023

View reviewed changes

bunch of math2d and 3d features and test programs #60

Are you sure you want to change the base?

bunch of math2d and 3d features and test programs #60

Conversation

UbuntuJackson commented Jun 19, 2023

hexaheximal Jun 19, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hexaheximal Jun 19, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hexaheximal Jun 19, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hexaheximal Jun 19, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hexaheximal Jun 19, 2023 • edited Loading

Choose a reason for hiding this comment

hexaheximal commented Jun 19, 2023 • edited Loading

UbuntuJackson commented Jun 19, 2023

hexaheximal commented Jun 19, 2023

UbuntuJackson commented Jun 19, 2023

hexaheximal commented Jun 19, 2023 • edited Loading

tulpenkiste commented May 17, 2024

hexaheximal Jun 19, 2023 •

edited

Loading

hexaheximal Jun 19, 2023 •

edited

Loading

hexaheximal Jun 19, 2023 •

edited

Loading

hexaheximal Jun 19, 2023 •

edited

Loading

hexaheximal Jun 19, 2023 •

edited

Loading

hexaheximal commented Jun 19, 2023 •

edited

Loading

hexaheximal commented Jun 19, 2023 •

edited

Loading