tamtaasatiani / tahmlib

Library for Game Development with C++
MIT License
81 stars 11 forks source link

Classes and methods aren't very safe #3

Open tamtaasatiani opened 2 weeks ago

tamtaasatiani commented 2 weeks ago

Some methods can be accessed from places where it doesn't make sense. For example initializations for audio and other modules should only be accessible from anywhere other than the tahm class, however, some other methods for audio SHOULD be accessible

SirJamesClarkMaxwell commented 1 week ago

I think that the problem is in your engine architecture. I quite don't get why are you put definitions Window,Input, and Renderer classes into the Tahm class. Why they can't be stand alone classes defined in the Tahm namespace? Why they are defined in the private part of the Tahm class, if you are exposing all of them to public API by creating public roll pointers in Tahm class? Why did you choose the role pointers instead of smart one?

Javier-Lozano commented 1 week ago

The library is inspired by Love2D, Tham class tries to mimic the "love" structure from Love2D, I think that's why it's structured this way. From what I can understand everything should be managed trough the Tham Singleton, you access Window, Renderer, Graphics, etc "modules" (as they are called in Love2D) trough public members and I think the reason they are nested and private inside the Tham Class is to prevent instantiation from outside the class.

It also ensures a simple syntax, for example, to draw a rectangle you do:

tahm.graphics->draw->rect()

I don't like the use of the -> operator but this could be easily fixed by just statically allocating graphcis and draw variables instead of using Raw pointers. Now the code now should look like this:

tahm.graphics.draw.rect()

It's less cumbersome to write and you don't have to remember to use -> operator.

I think the current code is fine enough, it compiles and does what it supposed to do, it's just weirdly organized. I think we should organize it better before making serious changes.

Then I think all SDL2 subsystems should be initialized right away inside Tahm's constructor with default values (Window, Renderer, Sound, TTF, etc), then call Start() function afterwards not before, the way is implemented right now works because we aren't capable of doing lots of things, like creating a Texture, which wouldn't work because it requires the Video Subsystem and a Renderer to be initialized.

The more I think about how this works the more I like it. Keep it up!