Messages

1

Window / Re: Invisible window on top of visible one

« on: November 28, 2012, 10:01:17 pm »

What benefits do you get with such a complicated design, compared to a single window that both catches input and draws the graphics?

Honestly? Fairly little. It's more of a design to fit a multiple-view, one data kind of structure. So, with future extensions in mind I could implement this and keep some separate views, for example a user view and a debug view. In the end it's really not what I need for my current game.

If no actual solutions turn up I'll turn to one client and try to separate the control (input) as much as possible from the view. Haven't had much experience with SFML except using my own graphics engine and SFML just for drawing my generated bitmaps, so I haven't quite figured out how to work with classes. I hope time will teach.

Still, any tips greatly appreciated.

2

Window / Invisible window on top of visible one

« on: November 28, 2012, 08:56:20 pm »

I'm currently working on a little game for a project.
My game is designed around a Model-View-Controller pattern. This is where I hope SFML will help me. The ideal idea was to have two separate windows: one that catches input (controller) and one that gives the user some juicy graphics (view). The controller would send some self-defined events to my model (game logic) every grame, the game would update itself accordingly and the view would query the model for a visual update. As said, this would be ideal.

In order for this to work I'd need to create an invisible window that would capture input at all times and a visible window that would never get focus: it's only there for the graphics. A little link has to be laid between them in case of rescaling, quitting,..

This is all still hypothetically speaking. How much of this can I actually realize? Any comments on the matter would be greatly appreciated.


Ruben

3

General / Best way to divide data and view?

« on: November 09, 2012, 09:17:44 am »

I'm not quite sure if this question belongs in the SFML forums, but I'll try it out anyway.

I'm a 19 year old student writing a small game for a long term project. Since I've used SFML before (for visual train simulation with my own graphics engine) I immediately decided it would be my graphics library for this project.

The problem is now: how do I go about dividing data and view in an orderly fashion? I want the blueprints to be just right from the start so I won't have to make any major changes later on. An older colleague has adviced me to use the MVC (Model-View-Controller) model but I haven't found a way just right to implement it.

Just to sketch you some context: The game will be 2D topview. I've got a couple of base classes: graphs and nodes and an abstract factory. All entities or game tiles will be nodes, which the graph will hold. The abstract factories will take care of producing these when asked. The derived class from the graph you can call the PlayField as it will hold the obstacles on the screen and generally decide what the screen should look like as it also holds all entities.

Now.. Just to repeat that tiny, simple-looking question. How best to set up my graphics? One single graphics object that communicates with the playfield to communicate through changes, both ways? One graphical representation object for each entity in the game?

Any help would be greatly appreciated. Same goes for sharing experience: I've got few but I'm determined. Share what you can!