Hi, I am an indie game developer and a programmer who is going to help you learn game development. I also will post tutorials about general programming, along with other stuff like graphics programming.
Hi, I've got a problem that I cant seem to solve, after adding the die function to the enemy, all I am getting is assertLocked, as I cannot delete them during the world step. The solution to solve it was to add them to an unordered list in the physics class, marking them for deletion and then do it after the world step. But in doing so removes them being squished as they get deleted right away. Is this something that has occurred with the newer version of box2d specifically? Otherwise I have tried comparing the code to the githhub version and I haven't been able to spot a difference other than not making world a reference at first and changing it(all the functionality stayed the same even if the world wasn't a reference till that point) but deleting anything from world with physics::world->deletebody causes the same error. Also want to note that between release and debug, giving different things; debugg instantly kills them without the squishing part and release does it "correctly" My Repo is ReminaGH/CpStuff on git, you should see it there(cant tell if youtube is hiding my comments or not)
That is weird behavior. Debug and release shouldn't really behave differently in terms of the functionality. I cannot say much without looking at the code. Do you have a GitHub repo?
@@thehelloworldguyofficial Ah, I see. I was trying to copy it from my school's internal giblab server and just pasting it into my own hub repo, I'll try again and see if I can get it working. Otherwise thanks for at least trying :)
Are you going to make a C++ quake-like engine after this series? If you use imgui you can make a small map editor for it as well. Anyway this series is nice, because it's fully featured, but the explanations are lacking and mostly somebody who has read up on the subject beforehand will understand a lot of it.
That is an idea that I plan to do soon. Right now, I have a plan for another series. After that, I'll probably consider the quake-like engine. Anyways, thanks for your feedback. I'll try to make the explanations more detailed in the future.
Hi man! Really great series. I have some questions: You re using FixtureData* fixtureData = new FixtureData(). Where do you actually do delete on this? I can't see this. The same in Physics.DebugDraw there is debugDraw = new MyDebugDraw(renderer.target); without freeing it.
You re using FixtureData* fixtureData = new FixtureData(). Where do you actually do delete on this? I can't see this. The same in Physics.DebugDraw there is debugDraw = new MyDebugDraw(renderer.target); without freeing it.
Wow! Never knew this existed. Maybe Unity isn't as intimidating as I thought... (That's also probably why there are so many of those crappy mobile games)
Hey dude, I want to be a opengl game developer, but i dont know where to start. I also need to get a better grasp of the C++ language. Would you be interested in making a C++ tutorial applied to opengl?
Khronos themselves has good tutorials for both OpenGL and Vulkan. As for C++, there are a bunch of resources for all skill levels. My personal favorite is Cherno, his C++ series is excellent for early to mid learning.
I do have a very basic OpenGL tutorial, and I might make a more advanced one at some point. For now, I would recommend learncpp for C++ and learnopengl for OpenGL. Once you get the basics done, for reference, cppreference.com and the OpenGL specs will be usefel.
That depends on the nature of the map and the type of the A* heuristic used. A bad heuristic can result in worse performance compared to BFS. Since we have relatively simple maps, I decided that BFS might be better. Of course, the correct way to find that would be to implement both and then profile.
I'm watching this video to prepare myself for college. I want to learn how to do this stuff because i LOVE it!! Is there more Mario videos after this one? Or is this the only one?
Brother, I am stuck in some early stage of implementing ur way in raycasting , would u give me ur e-mail or something to send u my code? I would appreciate it a lot
I do use the last column for the translation. However, in OpenGL, the matrices are usually interpreted as column-major. This means that whenever we type out the matrix in code, the outer array will be an array of columns, not rows. So, in the C code, the matrix will appear to be "transposed", but will be correct when we use it in the shader. NOTE: Column-major or row major is just a notational convention. Post-multiplying by column-major is the same as pre-multiplying by row-major. Historically, OpenGL apps have generally used column-major.
I would imagine a game like "Doom" is pretty easy to recreate nowsdays with graphics API's and a dedicated GPU...but back in 1993 when it first came out it was cuttnig edge and all the graphics where done in software on the cpu with many optimizations to speed it up. Like bsp and pre calulcating many math functions. I look forward to seeing the rest of this series.
Well, we will just reload the game and the editor with a different map. Main menu will probably be implemented separately. So, perhaps a basic scene management system. I haven't really decided on the details yet.
Good video! I have a few suggestions to give this engine more of a "game" feel: 1. Fix the sprites so we don't have to hard code them into the game. It would be better to implement them into the editor and save the sprites to the map file as well. 2. Reimplmement the fog effect. In the raycasting episode #15, you created a blue fog effect. That was when the engine wasn't using DDA algorithm, but I'm curious if it's still possible to reimplement in our current engine. 3. Probably the easiest one, implement mouse controls so the player looks left and right with the mouse, and the cursor is locked to the screen. You could have another button to unlock the cursor.
Cool suggestions! Incorporating sprites into the editor is one of my top priorities. Also, mouse control should be pretty easy. As far as fog goes, I don't think it would be any different than how we did it earlier.
Hmmm... well, I changed the speed to 4x and it seems about right. I believe my calculations of dividing by 360 were not correct, because this isn't a *skybox* but rather only a single texture (in other words, one side of a "skybox"). So, 90 degrees seems like a more appropriate for division.
@@thehelloworldguyofficial That makes a lot of sense. Multiplying it by 4 looks pretty good to me too. I've also changed the while loop for the xOffset to an if statement, and it seems to be working just fine. Here's my code for the portion of the sky if you want to steal it. //Sky //Calculate the sky offset to match the player's rotation float textureWidth = static_cast<float>(skyTexture.getSize().x); float pixelsPerDegree = (textureWidth * 4.0f) / 360.0f; int xOffset = static_cast<int>(angle * pixelsPerDegree) % static_cast<int>(textureWidth); //Ensure the offset is positive if (xOffset < 0) { xOffset += static_cast<int>(textureWidth); } //debug //std::cout << "Angle: " << angle << ", PixelsPerDegree: " << pixelsPerDegree << ", xOffset: " << xOffset << " "; sf::Vertex sky[] = { sf::Vertex(sf::Vector2f(0.0f, 0.0f), sf::Vector2f(xOffset, 0.0f)), sf::Vertex(sf::Vector2f(0.0f, SCREEN_H), sf::Vector2f(xOffset, skyTexture.getSize().y)), sf::Vertex(sf::Vector2f(SCREEN_W, SCREEN_H), sf::Vector2f(xOffset + textureWidth, skyTexture.getSize().y)), sf::Vertex(sf::Vector2f(SCREEN_W, 0.0f), sf::Vector2f(xOffset + textureWidth, 0.0f)), }; target.draw(sky, 4, sf::Quads, sf::RenderStates(&skyTexture));
There's 2 bugs that I have run into: The sky box isn't perfect. If you look at a spot in the sky and rotate the player 360 degrees, you'll be looking at a different spot than before. The second one is kind of a bug...The textures on the north and south sides of the wall are different than the east and west. The textures are flipped. You can see this when you're looking at the texture that has the purple eagle banner.
Hello. Will you do a quake series similiar to doom? The ioquake3 engine is open source from id software to get inspiration from. ( quake 3 i mean) ? Very nice content btw, i think you dont get enough credit!
Would you consider doing something with OpenGL and C++? You could make your own 2D library with OpenGL and use that instead of SFML for the raycasting engine. Awesome series bro. Keep up the great work!
Don't use raw pointers any more, user shared pointers instead. Btw: You did not clean up the raw pointer you created which means it would leak that memory.
