Видео

Sounds like a good tutorial but that oclConsoleGameEngine just doesn't work with my c++. Its a shame, keeps freaking out about // Set Physical Console Window Size m_rectWindow = {0, 0, (short)m_nScreenWidth - 1, (short)m_nScreenHeight - 1}; Saying invalid narrowing conversion from "int" to "short"

Had an error on compiling, "module machine type 'x86' conflicts with target machine type 'x64'". If you get this error switch the linker library directory from "vc_lib" to "vc_x64_lib".

That example with the platformer game really helped me get my head around normal vectors and dot product. Thank you.

Blu Tak wasn't invented yet when the Spiragraph was in it's heyday. You'd have to use sellotape. :)

god what the fuck your code is awful

I want to thank you so much for giving me the idea. I just started to write a program which main goal is RayCasting. I have resources to write the code, but I really wanted to understand what is happening under it. It will be a lie to say that I now understand it 100%, but I have the idea how it works and it's all thanks to you. Subscribe and Like from me, really great job.

12:50, when you said ‘state now’ and ‘state next’ you identified a problem I have been having with my own project that had been throwing me problems for a good part of the year! Thank you!!!’

appreciate you

Hello, First, I want to thank you for your great videos. I started practicing network programming in C++ and discovered your channel. Your content is amazing! I also checked out the olcConsoleGameEngine videos, which are very interesting. I'm running Windows 11 and have encountered some issues with console output size and other aspects. Do you have any solutions for this? Additionally, I wanted some advice about programming in private but couldn't find a way to contact you directly.

Love this format - nice review too.

Did he divorce or what the point of that video

*Summary* This video focuses on controlling an Elegoo Smart Robot Car Kit 3.0+ using a custom C++ application powered by the ASIO library and the olc::PixelGameEngine. *1. Introduction and Robot Car Showcase (**0:00**)* * Recap of a previous video controlling a robotic arm and introducing the concept of hardware programming. (0:00) * Unveiling the Elegoo Smart Robot Car Kit 3.0+, acknowledging its sponsorship for this video. (0:51) * Unboxing the kit and showing the components: Arduino board, sensors, motors, chassis, etc. (2:03) * Demonstration of the pre-programmed robot using the infrared remote: forward/backward movement, turning. (7:01) * Testing the obstacle avoidance mode (using the ultrasonic sensor), observing its limitations. (8:14) * Overview of the official mobile app for Bluetooth control, but the goal of this video is to build a custom PC application for that purpose. (9:39) *2. Analyzing the Pre-existing Bluetooth Program (**10:13**)* * Looking at Elegoo's provided code examples and tutorials, specifically "Lesson 2: Bluetooth Car". (10:25) * Examining the provided Arduino code (11:16): * Motor control using Pulse Width Modulation (PWM). (11:22) * Basic functions for forward, left, right, and backward movement. * Simple communication protocol using UART (Universal Asynchronous Receiver/Transmitter) at a baud rate of 9600. (12:13) * The code listens for single-character commands ('F', 'B', 'L', 'R', 'S' for forward, backward, etc.). (12:38) *3. Building the Control Interface with PixelGameEngine (**13:12**)* * Creating a `sButton` structure to represent clickable buttons in the application. (13:35) * Adding `Clicked()` function to `sButton` for detecting clicks. (13:48) * Adding a `DrawSelf()` function to allow buttons to draw themselves, including text (centered) and borders. (13:53) * Utilizing the `olc::PixelGameEngine::DrawStringProportional` function for visually pleasing text rendering (new feature demonstration). (14:37) * Instantiating and positioning four buttons: forward, backward, left, right. (15:21) *4. Setting Up ASIO for Serial Communication (**16:22**)* * Linking ASIO and defining preprocessor macros to avoid warnings. (16:25) * Creating an ASIO `io_context` object (`ioContext`) (16:59) and a `unique_ptr` to a `serial_port` (`port`) (17:05) for managing communication. * Handling serial port creation and configuration: * Instantiating `port`, specifying "COM3" (determined based on device manager). (18:03) * Setting port options using `set_option`: * Baud Rate: 9600 (matching the Arduino program) (18:45) * Character Size (8 data bits), Stop Bits (1), Parity (none), Flow Control (none) - standard UART 8N1 protocol (19:11). *5. Asynchronous Reading with ASIO (**20:11**)* * Creates the function `AsyncReadFromPort()` (20:28) to asynchronously read single bytes from the serial port: * Utilizes `serial_port::async_read_some()` (20:41) with a one-byte buffer (to process individual characters). * Lambda function (provided to `async_read_some()`) prints received bytes and then re-primes the `io_context` by calling `AsyncReadFromPort()` again, creating a continuous reading loop. * Calls `AsyncReadFromPort()` initially in `OnUserCreate()` to initiate the asynchronous reading process (21:50), and starts the `io_context` thread (21:55). * `OnUserDestroy()`: Includes logic to: * `cancel()` the serial port. (22:40) * `close()` the serial port (22:46), wait for the ASIO thread to finish (22:59), and only then safely reset the `port` pointer. (23:28) *6. Testing Communication with a Bluetooth Terminal App (**23:35**)* * Demonstrates communication between the PC application and a mobile phone acting as a Bluetooth UART terminal: sending and receiving text. (23:53) *7. Adding Functionality for Writing to the Car (**24:32**)* * Checks for mouse button presses and whether a button (`sButton`) is clicked. (24:38) * Uses `port->write_some` to send single-character commands to the car when buttons are pressed: 'F', 'B', 'L', 'R' (25:09) * Sends 'S' (stop) when the mouse button is released (25:37), making button presses momentary actions. *8. Replacing the Bluetooth Module and Testing Car Control (26:33) * * Explains the Elegoo module's limitations - it's hardwired to work with only their phone app. (26:33) * Switches to a more generic Bluetooth module (previously used for the robotic arm project). * Demonstrates successful car control: forwards, backwards, left, and right (using the PC app to send commands and observing real-time responses). *9. Future Possibilities and Outro (**29:03**)* * Briefly explores exciting future possibilities, such as incorporating sensor readings, line following, more complex control mechanisms, and potential for letting viewers on Twitch control the car. * Thanks Elegoo and encourages viewers to consider purchasing the car, providing a discount link in the description. *Key Takeaways:* * The video demonstrates a real-world use case for ASIO to control hardware wirelessly via Bluetooth using serial communication. * By analyzing existing code examples, it's often possible to figure out protocols and adapt existing implementations. * Designing classes that encapsulate their logic (`sButton::DrawSelf()`) makes larger projects more manageable. * Understanding the importance of properly managing asynchronous operations (canceling, waiting, and resetting) is crucial for preventing potential errors, especially in hardware control applications. i used gemini 1.5 pro to summarize the youtube transcript

*Summary* This video dives into designing a game using the previously built client-server framework. The core focus is achieving *passivity* - keeping clients simple, responsive, and non-disruptive to the overall game world. *1. Introduction: Recap & Philosophy* (0:00) * Recaps previous parts, acknowledging that this is a simplified introduction and encouraging viewers to deepen their learning through experimentation and further research. * Explains how the game design philosophy will prioritize passivity: Clients should passively observe and respond to server commands, minimizing their impact on the shared game world. *2. Understanding Player Handling in Different Game Architectures* (2:01) * Walks through the evolution of multiplayer game architectures from: * Single-player (2:13): Tight game loop with input, player, and world updates. * Local 2-Player (2:38): Distinct game modes, but often code reuse for player logic. * Early Networked Multiplayer (3:46): Often direct client-to-client, player roles tied to "server" and "client." * Introduces the MMO philosophy: * The server is responsible for running the game world, not individual clients. (5:20) * Clients connect, observe a portion of the world, interact locally, and send minimal state changes to the server, which are then relayed to other clients. (5:37) *3. MMO Design: Achieving Passivity* (6:26) * *Key Concepts:* * *Server as Authority:* Manages the authoritative state of the game world (player positions, actions, etc.). * *Passive Clients:* Primarily display information sent by the server, performing local collision checks and other visual enhancements to ensure a responsive player experience. * *Minimize Server Load:* Offload work (like collision detection) to clients whenever possible. * *Example Gameplay Loop:* 1. Clients receive state update commands from the server for ALL players, including their own (id-based updates). (6:31) 2. Clients locally control their player's movement (smooth and responsive because it's instant). (7:20) 3. Clients send their updated player state to the server. (7:27) 4. The server relays updated player states to all clients. (7:33) 5. Clients apply received updates to their local game worlds, performing client-side collision checks on all player representations (both local and remote). (7:38) * *Avoid Unresponsive Designs:* Highlights issues of client-to-server-to-client round-trip delays, emphasizing the importance of immediate local responsiveness. (9:44) *4. Game Implementation: `MMOClient` (**10:35**)* * Based on `olc::PixelGameEngine` (11:23) and the `olc::net::client_interface` (11:40) from previous videos. * Utilizes code from Part 3's `TransformView` class for a 2D world representation (pan, zoom, etc.). * New Data Structures in `mmocommon.h`: * `sPlayerDescription`: Structure holding player properties (position, velocity, health, etc.). * `mapObjects` in the `MMOGame` class (derives from `olc::PixelGameEngine` and `olc::net::client_interface`): `std::unordered_map` holding all player objects using IDs as keys (facilitating efficient lookup). * `OnUserCreate()` (19:46) * Attempts connection to the server (19:39). * Displays "Waiting to connect..." until the connection is established. * `OnUserUpdate()`: * Main game loop, first checks for connection state (`bWaitingforConnection`) (21:44) and messages from the server. * *Handles Incoming Messages:* * `Client_Accepted`: Acknowledges server acceptance, and the client sends a `RegisterwithServer` message with initial player information. (22:36) * `Client_AssignID`: Extracts the assigned ID from the server and sets `nPlayerID` locally. (23:34) * `Game_AddPlayer`: Adds the received `sPlayerDescription` to `mapObjects`. If it's the local player (`nPlayerID` match), set `bWaitingforConnection` to false, allowing the main game loop to proceed. (24:48) * `Game_RemovePlayer`: Erases the specified player ID from `mapObjects`. (25:19) * `Game_UpdatePlayer`: Uses `insert_or_assign` to efficiently update the existing entry in `mapObjects` or create a new one. (25:55) * *Player Movement:* Reads input and updates the player's velocity (`vVel`) in `mapObjects` based on `nPlayerID`, ensuring smooth and responsive movement on the client side. (17:03) * At the end of `OnUserUpdate()`: Sends the locally controlled player's updated state (`sPlayerDescription`) to the server as a `Game_UpdatePlayer` message. (26:42) *5. Server Implementation: `MMOServer` (28:56) * * Uses the `olc::net::server_interface` from previous parts. * Contains the authoritative `player_roster` (`std::unordered_map` for efficient player management). * Key overrides: * `OnClientConnect()`: Accepts all connections for simplicity. * `OnClientValidated()`: Empty in this video. * `OnClientDisconnect()`: Instead of directly sending removal messages (which could cause recursion), the player's ID is added to `vGarbageIDs` for handling in `OnMessage()`. (36:39) * `OnMessage()`: Handles incoming client messages: * `RegisterwithServer`: * Generates a unique ID. (30:44) * Assigns it to the received `sPlayerDescription` (from the client) and adds the player to `player_roster`. (30:50) * Sends back `Client_AssignID` (with the ID) and `Game_AddPlayer` messages to the client. (31:02) * Broadcasts `Game_AddPlayer` to ALL other clients, including the one that just registered (using insert_or_assign on the clients). (31:19) * Sends `Game_AddPlayer` for ALL existing players to the newly connected client. (31:43) * `UnregisterwithServer`: Placeholder for future implementation. (32:27) * `Game_UpdatePlayer`: Forwards the update (received from one client) as `Game_UpdatePlayer` to ALL clients *except* the one that originally sent it. (32:38) * *Garbage Collection:* After processing messages, iterates through `vGarbageIDs`, removes them from `player_roster`, and sends `Game_RemovePlayer` messages to ALL clients for each. (37:26) *6. Running the MMO and Demonstrations (**32:55**)* * Shows multiple clients connecting to the server and seamlessly controlling their respective avatars in real time. * Highlights client responsiveness (due to local movement updates). * Demonstrates that server-side garbage collection correctly handles players leaving, removing them from all clients' views. *7. Future Developments & Conclusion (**38:35**)* * Explains the need to handle clients with differing update speeds and introduces plans for adding interactivity between players in future videos. *Key Takeaways:* * This part lays out the groundwork for a simple but functional MMO using the client-server framework. * *Passivity is key:* Clients focus on local interactivity and responsiveness while relying on the server as the central authority and source of truth for the game state. * Efficiently leveraging data structures like `std::unordered_map` and well-designed communication protocols are essential for MMO design. i used gemini 1.5 pro to summarize the youtube transcript

*Summary* This video focuses on addressing two key issues in the framework from Parts 1 & 2: CPU load and client validation. *1. Problem: High CPU Usage on Server and Potential Solutions* (0:00) * The server example consumes a full CPU core even when idle (demonstrated at 0:58). * Client applications also utilize 100% of a CPU core, but this is less of a concern (since games typically demand high processing for logic and rendering). (3:06) * *Application-Specific Considerations:* Whether high CPU usage on the server is a problem depends on the type of server-side logic. (2:20) * A server primarily focused on relaying messages should be efficient and not constantly consume CPU. * A game server running AI or simulations might legitimately need full CPU power. * *Solutions:* * *This video's focus: Server sleeps until a message arrives.* (4:00) * Other potential solution: Utilizing a dedicated server framework (briefly discussed) for applications demanding maximum server performance. (2:54) *2. Implementing a Sleep Mechanism for the Server* (4:05) * *Threadsafe Queue Enhancements:* * `wait()` function added to `net_tsqueue.h`. This function blocks the calling thread until a message is pushed into the queue, thereby releasing the CPU resource until needed. (4:44) * Implemented using a `std::condition_variable` to signal when the queue transitions from empty to non-empty. (4:54) * A `std::mutex` is used to protect access to the condition variable. (4:58) * `notify_one()` is used to signal the condition variable in the queue's `push_back` and `push_front` functions. (6:35, 6:39) * *Server (`net_server.h`):* * A boolean flag `bWaitforActivity` added to control whether `Server::Update()` utilizes the `queue_incoming_messages.wait()` functionality. Default is set to `false` (7:16) to allow user control. *3. Problem: Server Vulnerable to Malicious Clients* (7:58) * Demonstration using telnet to send random data (8:31) results in massive memory allocation on the server (a sign of the server misinterpreting the data). (8:34) * The server is open to attacks from malicious actors (like port sniffers). (9:09) * Compatibility issues might arise when using different versions of the client and server. (9:25) *4. Solution: Client Validation* (9:42) * The goal is to add a step where the server verifies that the client understands the network protocol and is "friendly". (9:42) * A basic "Hello" handshake is considered, but rejected as too easily bypassed. (14:31) * *Challenge-Response Validation* (15:04): * The server generates random data. (15:37) * Server sends the data to the client. (15:40) * Server calculates a "scrambled" version of the data using a secret function. (15:42) * Client receives the data, performs the *same* scrambling function on it, and sends the result back to the server. (15:51) * Server compares the client's result with its own scrambled version. (16:00) * If they match, the client is validated as authentic. (16:05) *5. Implementation of Validation* (14:31) * `Connection` class (`net_connection.h`): * A `scramble(uint64_t)` function is added to handle scrambling the data (specific implementation intentionally kept simple in this tutorial, with emphasis on needing a more secure approach). (17:28) * Variables added: * `nHandshakeOut`: Stores the random data sent by the server. * `nHandshakeIn`: Stores the data received from the client. * `nHandshakeCheck`: Stores the server's scrambled data. * *New Functions:* * `WriteValidation()`: Asynchronously writes the `nHandshakeOut` data to the client. (20:52) * `ReadValidation(olc::net::Server* pServer)`: Asynchronously reads the response (`nHandshakeIn`) from the client, calls the `scramble()` function as needed, and triggers further actions. (21:36) * `Server` Interface (`net_server.h`): * Function `OnClientValidated(olc::net::connection<CustomMsgTypes>& conn)` added (as virtual). Called from `Connection::ReadValidation()` when a client's response passes validation. (23:22, 24:25) * Control Flow Changes: * `Connection` constructor: * If server-owned: Generates random data for `nHandshakeOut`, calculates `nHandshakeCheck` (using `scramble()`). (19:15) * `Connection::ConnectToClient()`: Calls `WriteValidation()` to initiate the handshake. (20:35) * `Connection::ConnectToServer()`: Calls `ReadValidation()` to start the client-side validation process. (20:21) * `Connection::ReadValidation()`: * If client-owned: After receiving the challenge, calls `scramble()` on it, assigns the result to `nHandshakeOut` and then calls `WriteValidation()`. (22:36) * If server-owned: Compares the received `nHandshakeIn` with `nHandshakeCheck`. If they match, the client is validated and `pServer->OnClientValidated()` is called. Then `ReadHeader()` is triggered to resume normal message handling. (23:03) * *If validation fails in either case, the connection is closed immediately.* (24:10) *Key Improvements & Takeaways:* * *Reduced CPU load:* By using a condition variable and waiting for messages, the server significantly reduces its idle CPU consumption. (7:28) * *Basic client validation:* The added handshake process significantly improves server security by preventing most connection attempts by non-conforming clients, including malicious ones. * *Modular design:* Validation logic is contained within the framework, making it transparent to users and simplifying client/server application development. * *Room for Improvement:* The `scramble()` function's simplicity is highlighted (17:28), stressing that more sophisticated cryptographic techniques are crucial for robust real-world security. i used gemini 1.5 pro to summarize the youtube transcript

*Summary* This video focuses on building a functioning client-server system with ASIO and the framework outlined in Part 1. Here's a breakdown: *1. Server Functionality & Design* (1:09) * The server must handle: * Accepting client connections (1:14) * Handling client disconnections (2:10) * Implementing game logic (2:16) * An asynchronous `asio::acceptor` (10:38) object continuously listens for connections. * The server needs a task to keep the ASIO context alive: continuously wait for and handle client connections (10:38) *2. `Server` Interface* (1:09) * A template class designed for inheritance by user's application logic. (3:00) * Contains: * An ASIO context shared by all connected clients (10:20) * A single thread for the context. (10:25) * An `asio::acceptor` object to handle connections. (10:38) * A deck to store connected client `Connection` objects. (15:54) * An ID counter for assigning unique IDs to clients. (10:43) * A `queue_incoming_messages` (Threadsafe Queue of `OwnedMessage` objects) to hold received messages (10:08) * Key functions: * `Start()` (11:59): Creates a task to wait for connections and starts the ASIO context thread. * `Stop()` (13:08): Stops the ASIO context and joins the thread. * `WaitforClientConnection()` (13:32): An *asynchronous* task run by the ASIO context that waits for incoming connections using `asio::acceptor`. * `OnClientConnect()` (15:32): Called when a client attempts to connect, allowing the server to approve or deny it (customizable by the user). * `OnClientDisconnect()` (18:11): Called when a client disconnects. * `OnMessage()` (19:52): Called from within `Update()` (20:12) to handle messages in the incoming message queue (customizable by the user). * `Update()` (20:12): Processes messages from the incoming queue, calling `OnMessage()` for each. Users can control the number of messages processed per call to `Update()`. * `SendToClient()` (8:55): Sends a message to a specific client (using their ID). * `MessageAllClients()` (9:00): Sends a message to all connected clients (optionally excluding a specific client). *3. `Connection` Object* (24:14) * A template class representing a connection to a client (whether created by the server or by a client). * Includes: * An `owner` field (using `Owner` enum class) to distinguish between server-owned and client-owned connections. (24:26) * A socket (`sock`) (24:57) * References to the ASIO context and the relevant message queue (server's or client's) (24:45, 25:02). * A unique ID (`id`) if owned by a server. (25:54) * Key *asynchronous* tasks executed by ASIO: * `ReadHeader()` (27:54): Reads a message header from the socket. * `ReadBody()` (29:24): Reads a message body based on size indicated in the header. * `WriteHeader()` (31:30): Writes a message header to the socket. * `WriteBody()` (32:22): Writes a message body to the socket. * `AddToIncomingMessageQueue()` (30:16): Adds a completed message to the appropriate message queue, and re-primes the ASIO context to read the next header. * `Send()` (33:13): Called by either the server or client to send a message. Uses ASIO's `post()` to add a task to write the message to the socket (avoiding concurrent header/body writes). * `Disconnect()` (35:03): Uses ASIO's `post()` to add a task to close the socket cleanly. *4. `Client` Interface* (35:35) * Template class with most implementation already present from Part 1. * Uses an `asio::resolver` (36:25) to translate a domain name into an IP address/endpoint. * Key function: `Connect()` (35:59) now fully implemented. It resolves the host address, creates a `Connection` object (client-owned) (37:02), starts the ASIO context thread (37:29), and then calls `Connection::ConnectToServer()`. *5. Example: Ping Server and Broadcasting a Message* (38:37) * This part includes modifications to the client and server examples from Part 1 to showcase sending and receiving custom messages: * The client can now: * Send "Server Ping" messages with timestamps for calculating round-trip time. * Send a message to the server asking it to broadcast a message to all other clients. * The server responds accordingly, including: * Reflecting the "Server Ping" messages. * Receiving the broadcast request and distributing the message to all other clients. *Key Improvements:* * *Robust error handling:* Network failures and disconnections are detected and managed to prevent application crashes. * *Asynchronous design:* Network operations are handled by the ASIO context in a background thread, allowing the application logic to continue without blocking. * *User-friendly API:* Complexities of ASIO are hidden from the user, allowing for streamlined development of client and server applications. *Note:* While the framework is functional at this stage, it is still not ready for production as it lacks security and other necessary features. This is planned to be addressed in future videos. i used gemini 1.5 pro to summarize the youtube transcript

*Summary* This video is the first in a series to create a custom C++ networking framework based on ASIO (Asynchronous Input Output) library, aiming for simplified client/server communication. Here's a breakdown: *Why ASIO and a Custom Framework?* (0:00) * Sockets are platform-dependent and complex to handle. * ASIO offers portability and error handling for networking. * The framework simplifies ASIO's asynchronous nature for the user. *Networking Challenges (and How This Framework Tackles Them):* (14:43) * *Unpredictable Timing:* (14:45) Network operations are asynchronous, meaning they don't happen instantly. This framework utilizes ASIO's asynchronous capabilities to run network tasks in the background without blocking the main program. * *Unknown Data Sizes:* (14:57) We don't know how much data a server will send. This framework mandates using messages with headers: * Header: Contains a unique ID (using enum class for compile-time validation) and the size of the entire message (including header). * Body: Contains the actual data (payload) of varying size. *Framework Components:* (22:48) * *Threadsafe Queue (`net_tsqueue.h`):* (45:02) Stores messages being sent and received. Utilizes mutexes to prevent data corruption from simultaneous access by multiple threads. * *Message Structure (`net_message.h`):* (27:46) * Contains the message header (ID and size) and a body (vector of bytes). * Allows easy serialization/deserialization for transmitting data. * Provides overloaded operators to push and pop data like a stack. * *Connection Object (`net_connection.h`)* (49:14) * Represents the link between client and server, handling sending and receiving messages through its socket. * Manages outgoing and incoming message queues specific to the connection. * *Client Interface (`net_client.h`):* (51:23) * Provides a simplified way for applications to connect to servers and send/receive messages. * Owns the ASIO context and the socket before a connection is established. * *Server (Discussed, Implementation in Future Videos):* (40:36) * Accepts multiple client connections and processes messages from all clients through a single incoming queue (facilitating single-threaded server design). *Key Points:* * Modern C++ features (like templates, enum classes) ensure code readability, type safety, and compiler assistance. * The goal is to abstract away the complexities of ASIO and asynchronous programming for users of this framework. * This video lays the groundwork for the series, focusing on architecture and initial implementations. The following parts will demonstrate a fully functional framework and eventually its use in a game. i used gemini 1.5 pro to summarize the youtube transcript

thank god we have chat gpt

Honestly, love the drawing teaching us how we can visualize this in effect. But as a new game dev to Unity and C#, this guide is quite hard to follow as CPP a quite different and the amount of usage of your engine makes it hard to understand what I am able to use and what I can't. Edit: Well actually this turned out to be quite great! Converted the github to C# using Copilot and with a bit of adjustment on my part. The code makes more sense now! Thx for the tutorial

I would love to see a good example of collision when a player takes up 2x2 units of tiles. Running against a jagged square slant. So that the player is pushed to the side of the slant. like \ or / for example. Moving both up and left or right.

Man, I love your videos and moderate paced teaching method. I'm not even c++ programmer.

Bravvo this was very informative many thanks

Hello! Why "OnClientDisconnect" function is not working ?

Amazing video thank you! Since the direction vector is normalized to begin with, isn't there no need to do a Sqrt? - you can simply divide 1 / dx and 1 / dy to get the step size per unit length in those directions

why use namespace std?

while initialising the cube, the bottom face is not initialized in clockwise order right? why is that

why are we only multiplying x with the aspect ratio and not y

hello i wonder is it better to use Microsoft visual studio or is visual studio code the same thing. I have seen you use the latter in all projects and I'm wondering why?

i get like 67 errors while running, all the errors are in olcConsoleGameEngine.h please help!!

Ugh... void*. I used to have a team member that would change every void to void* and then NEVER RETURN ANYTHING. Either the compiler warnings didn't bother him or he didn't understand what htey meant. He just couldn't wrap his head around the fact that void* means that the function actually returns SOMETHING when we REPEATEDLY spoke to him about using void instead.

brother i still am at ur shadow casting video but im learning so much. props to what you do and i genuinely feel that you bring practical tips for noobs so thank you!

How are you supposed to stop the game?

To anyone having problems with drawing to the screen for the first time at 12:22, consider matching your nScreenWidth and nScreenHeight (num of columns and rows) with your console defaults. My consoles width (nScreenWidth) meaning number of columns is 120 and height (nScreenHeight) is 30. If you want to find your consoles dimensions, there's a handy solution on stackoverflow called "Get size of terminal window (rows/columns)"

I alwais think ohh javid japping again.. then i liste and i go ugabuga smart man veri wise thinking

Nice explanation, I did something in my free time where I need to do multiple raycasts in 3D space from the same point to just slightly different target points and adapted the algorithm to advance every ray one step at a time, so every ray roughly checks blocks in the same area.

i have a question, why using dyanmic isntead of static, like whitch one is the best coz i've noticed that a lot of projects do the same

You should extend this example at some point, I would love to see how you handle seeds for stuff generated on a planet. like give them each a world map of countries, each with information about them, then you can view cities in that country, then buildings in each city, rooms in each building, characters in each room.

What if two adjacent rays have common voxels? Why should we re-test these common voxels for intersection while casting the second ray?

E

Could this be improved with templates?

Forgot almost everything maths related and thanks to you I got a better idea on these cool maths stuff (I still have no clue but Im at least trying)

i prefer high-level programming languages but i couldn't stop watching this

After lots of research, and many MANY videos, i can proudly say i understand the projection and rotation matrices, though how z normalization works remains a mystery to me (for now)

goto statements are terrible to look at.

"I like this a lot". Mee too brother, ty

Wow, just wow! I need to implement midi in my project and this has been a huge help. Thanks mate!

hey, do you happen too know how does a 3d cad software work and how to make one? there is really a lack of content about cad

everytime i see this calculation i wonder, what if z = 0?

I think there is a problem with the precedence of the addition (+) and subtraction (-) operators. Consider the expression 3-1+1 that should be equal to 3. Using the specified precedence rules (addition = 2, subtraction = 1) we get: RPN: 3 1 1 + - Then: Calculation 1st round: 3 2 - Calculation 2nd round: 1 Which is obviously wrong! In the case of 3-1+1 the minus can be translated (*by humans*) as unary minus and become 3+(-1)+1 and then if we calculate first -1+1 we get 0 and finally 3+0 is the correct answer 3. But in the described algorithm we treat this minus as binary operator. In division and multiplication there is no "sign" problem. Hence: 18*3/2 = 18*(3/2) = (18*3)/2 = 27 Or maybe I miss something?! I think that operators (-) and (+) and should be marked with the same precedence level, and the rule of popping operator in case that it is with higher precedence should be applied even on the same precedence level. I would also mark (/) and (*) with the same precedence level. Please, tell me where I'm wrong?!

Wow, thanks A LOT!

for some reason when i try to run the program the screen just flickers with random white boxes in random order at first i thot it was my buggy code then i copied everything from github and pasted it onto visual studio still the problem persists i asked chatgpt it keeps on giving me different versions of the code where it changes the buffering technique and what not but the problem still persists