Where SDL goes in your game

Hi everyone,

This is my first post in this forum and hoping to find some help. I started
SDL a few months ago and all is well except I have a problem with the entire
program’s structure.

When we create an SDL-based app, where do you put all the SDL data as far as
the entire program’s structure is concerned. An example… suppose we have the
following classes:

  • GameObjects ( super-class )

  • Ball ( derived-class )

  • Paddle ( derived-class )

As for efficiency, planning and game design, is it best to:

A) have a separate class specifically for all the SDL stuff ( surfaces, music,
sound effects, etc. etc. )
B) integrate all the SDL stuff within the GameObjects, Ball and Paddle
classes, in other words, all the SDL stuff is spread around . You have the
Ball surface with the Ball class, the Paddle surface with the Paddle class and
each respective surface with each respective class.

I have learned a great deal when it comes to SDL but my problem is structuring
it with the rest of the program.

In an SDL program, ( speaking in 2D terms ), you have surfaces. Let’s say you
have an image you want to place onto the screen. Let’s say this is an image of
a Ball. Do you:

A) create a separate class to hold all your SDL data and place that surface
(SDL_Surface* ball) into that class
B)
place the surface (SDL_Surface* ball) object in the Ball class

Any help would be appreciated. Thanks!

Regards,

Armond

You’re asking the same questions I’ve been asking myself without voicing
on any forums. Being Old School C but knowing (and preferring) C++ I
have a certain bias towards not having a super class object. This kind
of forces me to put a lot of objects in the global scope. I’ve been
studying the “documentation” (essentially heavily commented demo source)
for the PopCap engine and it seems that they do have an App superclass.
But then, that’s at the heart of having an engine and pretty much the
way MFC apps are structured.

The problem I have is that I lose sight of the scope of any given
object, especially when you’re dealing with an App object that’s really
a derived class. If anyone can provide perspective on this approach I’d
certainly appreciate it. It could help me get over my reader’s block.

Lilith

Hi everyone,

This is my first post in this forum and hoping to find some help. I
started
SDL a few months ago and all is well except I have a problem with the
entire

program’s structure.

When we create an SDL-based app, where do you put all the SDL data as
far as
the entire program’s structure is concerned. An example… suppose we
have
the
following classes:

  • GameObjects ( super-class )

  • Ball ( derived-class )

  • Paddle ( derived-class )

As for efficiency, planning and game design, is it best to:

A) have a separate class specifically for all the SDL stuff (
surfaces,
music,
sound effects, etc. etc. )
B) integrate all the SDL stuff within the GameObjects, Ball and
Paddle
classes, in other words, all the SDL stuff is spread around . You
have the
Ball surface with the Ball class, the Paddle surface with the Paddle
class
and
each respective surface with each respective class.

I have learned a great deal when it comes to SDL but my problem is
structuring
it with the rest of the program.

In an SDL program, ( speaking in 2D terms ), you have surfaces. Let’s
say
you
have an image you want to place onto the screen. Let’s say this is an
image
of
a Ball. Do you:

A) create a separate class to hold all your SDL data and place that
surface>>> On 11/8/2006 at 11:43 AM, in message <loom.20061108T184136-335 at post.gmane.org>, Armond <armond.sarkisian at gmail.com> wrote:
(SDL_Surface* ball) into that class
B)
place the surface (SDL_Surface* ball) object in the Ball class

Any help would be appreciated. Thanks!

Regards,

Armond


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Hello Armond,

Wednesday, November 8, 2006, 5:43:55 PM, you wrote:

Hi everyone,

This is my first post in this forum and hoping to find some help. I started
SDL a few months ago and all is well except I have a problem with the entire
program’s structure.

When we create an SDL-based app, where do you put all the SDL data as far as
the entire program’s structure is concerned. An example… suppose we have the
following classes:

  • GameObjects ( super-class )

  • Ball ( derived-class )

  • Paddle ( derived-class )

My two cents. Please do not get Java-itis and write your games so that
every little thing is an object. It’s inefficient, it’s difficult to
follow, and if you have to port such code (as I do) it’s a total pain
in the ass.–
Best regards,
Peter mailto:@Peter_Mulholland

Hmm,

So it is better to keep everything minimal under the fewest number of
classes. I must admit, I do tend to want to “over” organize my programs but
I will think this over. Anyone else have any other suggestions?On 11/8/06, Peter Mulholland wrote:

Hello Armond,

Wednesday, November 8, 2006, 5:43:55 PM, you wrote:

Hi everyone,

This is my first post in this forum and hoping to find some help. I
started
SDL a few months ago and all is well except I have a problem with the
entire
program’s structure.

When we create an SDL-based app, where do you put all the SDL data as
far as
the entire program’s structure is concerned. An example… suppose we
have the
following classes:

  • GameObjects ( super-class )

  • Ball ( derived-class )

  • Paddle ( derived-class )

My two cents. Please do not get Java-itis and write your games so that
every little thing is an object. It’s inefficient, it’s difficult to
follow, and if you have to port such code (as I do) it’s a total pain
in the ass.


Best regards,
Peter mailto:darkmatter at freeuk.com


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

So it is better to keep everything minimal under the fewest number of
classes. I must admit, I do tend to want to “over” organize my programs
but I will think this over. Anyone else have any other suggestions?

It’s C and not C++, but consider “PongThing” to be your class in this
example:

 http://icculus.org/~icculus/tmp/sdlpong.c

This just used a color and coordinates for a rectangle, but you could
swap those out with an SDL_Surface for each PongThing if you wanted to
do real graphics.

In the case of Pong, you don’t really care about specializing balls and
paddles, the generic “thing” concept fits both fine, since they have the
exact same properties…no real need for a subclass. That one PongThing
is in an array named “paddles” and the other is in an array named
"balls" is really all the distinguishing needed.

Peter’s absolutely right: you don’t want to go class-crazy.
Over-designing something ruins it before you even get started on
coding…knowing when to stop planning and structuring is a zen art
learned over many years…as is learning that global variables aren’t
necessarily evil, no matter what the textbook says. :slight_smile:

–ryan.

I like to separate SDL into a special video interface, and have an
over-arching input system that tells everything else what to do. This way,
most of the game logic doesn’t have to care about anything to do with
graphics or input and can concentrate on being logical.On 11/8/06, Armond Sarkisian <armond.sarkisian at gmail.com> wrote:

Hmm,

So it is better to keep everything minimal under the fewest number of
classes. I must admit, I do tend to want to “over” organize my programs but
I will think this over. Anyone else have any other suggestions?

On 11/8/06, Peter Mulholland wrote:

Hello Armond,

Wednesday, November 8, 2006, 5:43:55 PM, you wrote:

Hi everyone,

This is my first post in this forum and hoping to find some help. I
started
SDL a few months ago and all is well except I have a problem with the
entire
program’s structure.

When we create an SDL-based app, where do you put all the SDL data as
far as
the entire program’s structure is concerned. An example… suppose we
have the
following classes:

  • GameObjects ( super-class )

  • Ball ( derived-class )

  • Paddle ( derived-class )

My two cents. Please do not get Java-itis and write your games so that
every little thing is an object. It’s inefficient, it’s difficult to
follow, and if you have to port such code (as I do) it’s a total pain
in the ass.


Best regards,
Peter mailto: darkmatter at freeuk.com


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


Cheers,
Josh

PGP: http://revvy.box43.net/Josh_Matthews.asc

Josh Matthews <mrlachatte gmail.com> writes:

Hi Josh,

When you say a special video interface with an over-arching input system, what
do you exactly mean.

Are you referring to a single struct that handles all SDL
calls ?

And also, do you put all your SDL graphics, and such in this one interface?

Armond

On the one non-game full application (presentation) I’ve written I
created a class of SDLObjects. The essence of the object was that it
held a static object that was a pointer to my video display surface so I
didn’t have to keep passing the pointer to the objects. Beyond that I
had position markers and some state indicators; alive, visible, active,
moving, move_type, etc along with associated functions. And of course,
there was the ubiquitous Draw() function. Most of the other
functionality/logic is handled by the program. Some functions that were
part of the system weren’t part of any object. But they were aware of
the nature of the object. That leaves things more flexible. When it
makes sense to add some functionality I decide where it belongs.

I guess you could say that rather than top-down programming I tend to
do inside-out programming.

Lilith

Hmm,

So it is better to keep everything minimal under the fewest number
of
classes. I must admit, I do tend to want to “over” organize my
programs but
I will think this over. Anyone else have any other suggestions?

Hello Armond,

Wednesday, November 8, 2006, 5:43:55 PM, you wrote:

Hi everyone,

This is my first post in this forum and hoping to find some help.
I

started

SDL a few months ago and all is well except I have a problem with
the

entire

program’s structure.

When we create an SDL-based app, where do you put all the SDL data
as

far as

the entire program’s structure is concerned. An example… suppose
we

have the

following classes:

  • GameObjects ( super-class )

  • Ball ( derived-class )

  • Paddle ( derived-class )

My two cents. Please do not get Java-itis and write your games so
that

every little thing is an object. It’s inefficient, it’s difficult
to

follow, and if you have to port such code (as I do) it’s a total
pain>>> On 11/8/2006 at 1:54 PM, in message <36e6d5110611081154t199435cdw426fcdec80a012cd at mail.gmail.com>, “Armond Sarkisian” <armond.sarkisian at gmail.com> wrote:
On 11/8/06, Peter Mulholland wrote:

in the ass.


Best regards,
Peter mailto:darkmatter at freeuk.com


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Well, for graphics I create a Surface class that contains the SDLSurface and
coordinates and such. Game objects will all have a Surface. Then I have
video functions such as draw_rect, draw_text, draw_surface, etc. thereby
hiding the nitty gritty SDL details. A nice way of handling input would be
to have a list of game objects with common mouse/keyboard input functions.
The input could be passed to each object to be dealt with however the object
wants.On 11/8/06, Armond <armond.sarkisian at gmail.com> wrote:

Josh Matthews <mrlachatte gmail.com> writes:

Hi Josh,

When you say a special video interface with an over-arching input system,
what
do you exactly mean.

Are you referring to a single struct that handles all SDL
calls ?

And also, do you put all your SDL graphics, and such in this one
interface?

Armond


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


Cheers,
Josh

PGP: http://revvy.box43.net/Josh_Matthews.asc

I want to thank everyone who participated in this forum. I have a better
idea of how I want to design my next app.

Thanks,
ArmondOn 11/8/06, Lilith Calbridge wrote:

On the one non-game full application (presentation) I’ve written I
created a class of SDLObjects. The essence of the object was that it
held a static object that was a pointer to my video display surface so I
didn’t have to keep passing the pointer to the objects. Beyond that I
had position markers and some state indicators; alive, visible, active,
moving, move_type, etc along with associated functions. And of course,
there was the ubiquitous Draw() function. Most of the other
functionality/logic is handled by the program. Some functions that were
part of the system weren’t part of any object. But they were aware of
the nature of the object. That leaves things more flexible. When it
makes sense to add some functionality I decide where it belongs.

I guess you could say that rather than top-down programming I tend to
do inside-out programming.

Lilith

On 11/8/2006 at 1:54 PM, in message <36e6d5110611081154t199435cdw426fcdec80a012cd at mail.gmail.com>, “Armond Sarkisian” <@Armond_Sarkisian> wrote:
Hmm,

So it is better to keep everything minimal under the fewest number
of
classes. I must admit, I do tend to want to “over” organize my
programs but
I will think this over. Anyone else have any other suggestions?

On 11/8/06, Peter Mulholland wrote:

Hello Armond,

Wednesday, November 8, 2006, 5:43:55 PM, you wrote:

Hi everyone,

This is my first post in this forum and hoping to find some help.
I

started

SDL a few months ago and all is well except I have a problem with
the

entire

program’s structure.

When we create an SDL-based app, where do you put all the SDL data
as

far as

the entire program’s structure is concerned. An example… suppose
we

have the

following classes:

  • GameObjects ( super-class )

  • Ball ( derived-class )

  • Paddle ( derived-class )

My two cents. Please do not get Java-itis and write your games so
that

every little thing is an object. It’s inefficient, it’s difficult
to

follow, and if you have to port such code (as I do) it’s a total
pain

in the ass.


Best regards,
Peter mailto:darkmatter at freeuk.com


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

i have only written one app that uses sdl. in that i keep the core
code separate from sdl. perhaps think about how would it be ported to
another system. the less dependent sdl calls or system specific calls
there are the easier it is to port. not that you would port from sdl
to something else but hopefully explains the organization.

matt

Armond wrote:> Hi everyone,

This is my first post in this forum and hoping to find some help. I started
SDL a few months ago and all is well except I have a problem with the entire
program’s structure.

When we create an SDL-based app, where do you put all the SDL data as far as
the entire program’s structure is concerned. An example… suppose we have the
following classes:

  • GameObjects ( super-class )

  • Ball ( derived-class )

  • Paddle ( derived-class )

As for efficiency, planning and game design, is it best to:

A) have a separate class specifically for all the SDL stuff ( surfaces, music,
sound effects, etc. etc. )
B) integrate all the SDL stuff within the GameObjects, Ball and Paddle
classes, in other words, all the SDL stuff is spread around . You have the
Ball surface with the Ball class, the Paddle surface with the Paddle class and
each respective surface with each respective class.

I have learned a great deal when it comes to SDL but my problem is structuring
it with the rest of the program.

In an SDL program, ( speaking in 2D terms ), you have surfaces. Let’s say you
have an image you want to place onto the screen. Let’s say this is an image of
a Ball. Do you:

A) create a separate class to hold all your SDL data and place that surface
(SDL_Surface* ball) into that class
B)
place the surface (SDL_Surface* ball) object in the Ball class

Any help would be appreciated. Thanks!

Regards,

Armond


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Hi, There:
This really took my attention. I have some answers but not truths.
I throw them for the sake of discussion.

  • GameObjects ( super-class )

I have a similar thing with methods to draw it at some position in the game world, and to update it every few frames. Yes, sometimes I need to downcast a GameObject to a derived class, but the books of C++ I read tells this is quite unavoidable in some circumstances. This is a limitation of C++ type system, I think. And C type system is not better …

As for efficiency, planning and game design, is it best to:

A) have a separate class specifically for all the SDL stuff ( surfaces, music,
sound effects, etc. etc. )

Yes! A! A thin layer over the API lets you tweek its semantics to better fit your needs. Then if you whish you can always make the layer functions or methods inlined to remove the call overhead.

In an SDL program, ( speaking in 2D terms ), you have surfaces. Let’s say you
have an image you want to place onto the screen. Let’s say this is an image of
a Ball. Do you:

A) create a separate class to hold all your SDL data and place that surface
(SDL_Surface* ball) into that class
B)
place the surface (SDL_Surface* ball) object in the Ball class

?Are you going to share image data across objects who use the same image?
?Who is responsible for freeing the image data?
?Do you have something like a resource manager to make the housekeeping?
You need for sure some way to link an image to (some of) your game objects, there’s
more than one way to do that. I think there’s not a one for all solution, since it
depends a lot on the resource management you are planning.

Regards.

Hi, There:
This really took my attention. I have some answers but not truths.
I throw them for the sake of discussion.

  • GameObjects ( super-class )

I have a similar thing with methods to draw it at some position in the
game world, and to update it every few
frames. Yes, sometimes I need to downcast a GameObject to a derived class,
but the books of C++ I read tells
this is quite unavoidable in some circumstances. This is a limitation of C++
type system, I think. And C
type system is not better …

Hi Facundo,

Yes, I believe I will take the (A) route and create one struct/class that will
handle all my SDL needs. Also, another lesson I learned is not to go class-
crazy. I will try to keep things simple and minimal but effective. Just in the
past, I had a lot of problems with scope but hopefully I will create this new
design which will solve that problem.

Thanks!
Armond