SDL Custom Events vs. Building a Separate Event System

That's a great design question! You absolutely can build your own event system entirely separate from SDL's. Choosing between SDL's user events and a custom system involves trade-offs between integration, simplicity, type safety, and flexibility.

1. Seamless Integration: Your custom events live in the same queue as SDL's built-in events (keyboard, mouse, window, etc.). You process everything through a single, standard event loop using SDL_PollEvent or SDL_WaitEvent. This simplifies the main application structure.
2. Centralized Polling: You don't need a separate mechanism to poll or check your custom event queue; it's handled by the existing SDL functions.
3. Thread Safety (Pushing): SDL_PushEvent is designed to be thread-safe. This provides a relatively easy way to send notifications from worker threads back to your main (event-processing) thread without manually implementing a thread-safe queue.
4. Leveraging SDL Infrastructure: You're using a core, well-tested part of the SDL library for queue management.

Lack of Type Safety: The biggest drawback. data1 and data2 are void*, requiring static_cast and careful manual type management in the handler. Mistakes aren't caught at compile time. A custom system can use templates, std::variant, std::any, or specific event classes for strong type safety.

Limited Data Structure: You're constrained to the SDL_UserEvent format (type, timestamp, windowID, code, data1, data2). A custom system can define event objects with any number and type of members needed.

Limited Features: SDL's queue is relatively simple. Custom systems can implement advanced features like:

• Event prioritization.
• More sophisticated filtering (beyond SDL_SetEventFilter).
• Synchronous event dispatch (direct function calls) vs. asynchronous (queued).
• Event cancellation.
• Different queue types (e.g., priority queues).

Dependency on SDL: Your core application logic communication becomes tied to the SDL event system. A custom system can be independent, potentially useful if you envision porting the core logic away from SDL later.

Potential Overhead: While usually negligible, creating and pushing SDL_Event objects might have slightly more overhead than pushing a custom, potentially smaller event object onto a highly optimized custom queue, especially for very high-frequency events.

Choose SDL_UserEvent if:

• You need simple communication between components.
• You want easy integration with the main SDL event loop.
• You need a straightforward way to send events from other threads back to the main thread.
• The limited type safety of void* is acceptable for your use case (or you implement careful wrappers).
• You don't need advanced features like prioritization or complex filtering.

Consider a Custom Event System if:

• Compile-time type safety for event data is crucial.
• You need complex event data structures that don't fit neatly into code, data1, data2.
• You require advanced features like event prioritization, cancellation, or synchronous dispatch.
• You want to decouple your core event logic entirely from SDL.
• You are building a larger framework or engine where a dedicated event system is a core architectural component.

Designing robust, type-safe, and feature-rich event systems is a significant topic in itself, often explored in more detail in advanced C++ and game architecture discussions. We touch upon some of these design patterns and alternatives in later parts of the course.

In conclusion, SDL user events offer convenience and integration, while custom systems provide superior type safety, flexibility, and control at the cost of increased implementation effort.