Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Decoupled Engine Architecture  (Read 1869 times)

0 Members and 1 Guest are viewing this topic.

e_barroga

  • Jr. Member
  • **
  • Posts: 76
    • View Profile
Decoupled Engine Architecture
« on: July 25, 2010, 12:02:34 pm »
I am trying to develop an engine with a very decoupled architecture. This way, in the future I can easily replace the graphics component, input component, audio component, etc. easily.

The problem is that SFML's graphics and input seem to be closely coupled together.

Any ideas?

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6276
  • Thor Developer
    • View Profile
    • Bromeon
Re: Decoupled Engine Architecture
« Reply #1 on: July 25, 2010, 01:24:07 pm »
Quote from: "e_barroga"
The problem is that SFML's graphics and input seem to be closely coupled together.
Could you explain that in detail? I don't see why events/realtime input or graphics depend on each other.

Do you have an example?
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Decoupled Engine Architecture
« Reply #2 on: July 25, 2010, 01:36:00 pm »
Quote
The problem is that SFML's graphics and input seem to be closely coupled together

No they are not ;)

Input is coupled with windows, which is perfectly normal because SFML provides window-based inputs, not global ones (ie. if you press a key, only the current focused window will receive the event).

I don't think it's a problem to separate graphics and input (well, windowing stuff) with SFML.
Laurent Gomila - SFML developer

Recruit0

  • Jr. Member
  • **
  • Posts: 66
    • View Profile
Decoupled Engine Architecture
« Reply #3 on: July 26, 2010, 10:56:47 pm »
I'm developing cpGUI and I haven't had any problems encapsulating media functionality (SFML).

 

anything