Scripting (3)

Don’t you think that in commercial games, it’s rather the C/C++ engine which calls the script and not the contrary ?

Thank you for your answers.

Julien

Are you making a commercial game? Commercial companies have different
requirements. They may have purchased some pricey piece of middle
ware, or they don’t want to go to large expense redeveloping code when
they have an existing engine written in C++. If you are starting from
scratch, you have the most freedom. I think it is better to focus on
how you want your game to work.

You still haven’t described your game (from what I can see). This is
important. If you are trying to make a AAA 3D action game, then you
might need to make sacrifices to get the performance you need. What
kind of hardware do you want as the minimum specification? If is very
low end, then again you may end up writing more speed critical areas
(such as pathfinding or something) in a lower level language.

For me, I write 2D games that should run on any reasonably modern hardware.

Ever since I’ve discovered Lua, I’ve been using it to program more and
more of the games. At first, it was for configuration. Then, I started
specifying entity behaviour. Soon, most of the game logic was Lua,
with C++ being used for the menu system, graphics, movement and
collision detection.

In my latest game, I’m trying to limit C++ to low level details, such
as graphics and networking. Pretty much everything else is being built
in Lua. At the moment I am still in a hybrid approach because I am
reusing a lot of code from my older program.

My games use OpenGL for rendering, SDL for as much as possible outside
that. I think modern machines can easily handle my games. In fact, the
problems I encountered running my previous game on older hardware were
not slowdowns due to Lua - it was due to a poor integrated graphics
card which couldn’t accelerate my nasty immediate mode OpenGL calls.On Fri, Nov 21, 2008 at 9:04 AM, julien CLEMENT wrote:

Don’t you think that in commercial games, it’s rather the C/C++ engine which
calls the script and not the contrary ?

Thank you for your answers.

Hi,Am 21.11.2008 um 15:27 schrieb Brian:

Ever since I’ve discovered Lua, I’ve been using it to program more and
more of the games. At first, it was for configuration. Then, I started
specifying entity behaviour. Soon, most of the game logic was Lua,
with C++ being used for the menu system, graphics, movement and
collision detection.

In my latest game, I’m trying to limit C++ to low level details, such
as graphics and networking. Pretty much everything else is being built
in Lua. At the moment I am still in a hybrid approach because I am
reusing a lot of code from my older program.

I’m just curious, but what is the advantage of having as much as
possible of the code of your game in the script language rather than
in C++?

I myself like scripting languages also a lot. I have written my own
scripting languages in days where it was not so common. My goal was
always to keep the game as dynamic as possible. And I was thinking
very far into this direction; I dreamed of having more or less
everything scriptable of my game. That thoughts went so far to have
even graphic effects scriptable, the whole input event handling and
basically almost everything, whereby of course such things like
blitting were some extern calls. I didn’t actually implemented it this
way but just thought that it could be cool and I should try it once.

I have recently also seen a lot of other games using scripting
languages heavily. That really went so far as I wanted it by myself
once. The reason was always to have it as dynamic as possible (with
the thought that every part of a script can easily be changed). They
mainly did it for the modder community, to give them as much
possibilities as possible. In the end, the modder was just able to
recode the whole game in a way that it would just be another,
completly independent, not at all related game.

I am recently asking myself if it makes really much sense to do it
this way. Of course, if somebody just prefers Python/Lua/whatever over
C/C++, that would be a reason. But it often seems to me that a lot of
people just code (almost) the whole game in Python/Lua because they
want to have it as dynamic as possible.

I am writing because we had a similar discussion also recently in our
game project (OpenLieroX). We already have a lot of mods by the
community (100+) and you have already a lot of possibilities in there,
but it is rule-based. A mod defines the behaviour of each projectile
and each projectile has a huge number of properties, including also
the spawning of new projectiles on certain events. The possibilities
are so huge that people have done really crazy stuff with it.

But you always hit the limit in such a system and sometimes the
solutions are also not really that nice. A lot of these mods uses for
example some hidden dummy projectiles just to achieve something. We
were discussing a lot with the community how a new modding system
should look like and the main idea was to use some sort of scripting
language like Lua. The discussion about what exactly you should be
able to code there went back and forth. Some people (though not mod
developers) liked the idea of having even the whole physics simulation
and the input event handling on a very low level (each keyboard/mouse/
gamepad event) scriptable. We did not really get to any descision on
that. Somebody suggested that the script just should define one single
"void frame(float dt)" function (which is called from the main loop)
and then just do everything on its own (including mainly everything,
the whole game). Some others suggested of having this frame-functon
for each single projectile and then do everything (physic simulation,
collision detection, other things) there. I just wanted to point out
here that I think this idea of having everything scriptable goes way
to far in some cases, whereby I am not sure yet how far it should get
and where it should stop. Also, we have up to 3000 projectiles in our
game at one time and it can be run on some old PII with 300MHz with
64MB RAM and I am not sure if we move the projectile behaviour
definition out to a script (like just in form of some "void frame()"
definition) that we can keep this performance.

What is your experience with scripting languages? At which parts do
they really give huge advantages (in the sense of giving something
which would not be possible or really complicated otherwise)?

How far have you gone in your games by making things scriptable? Where
has it made things nicer? (Nicer not in the sense of that Python could
be nicer than C/C++ in general for some people.)

  • Albert

May I ask you which library you used to make those nice GUI widgets ?
Is it homemade ?

thanks

— En date de?: Ven 21.11.08, Albert Zeyer <albert.zeyer at rwth-aachen.de> a ?crit?:> De: Albert Zeyer <albert.zeyer at rwth-aachen.de>

Objet: Re: [SDL] Scripting (3)
?: “A list for developers using the SDL library. (includes SDL-announce)”
Date: Vendredi 21 Novembre 2008, 16h50
Hi,

Am 21.11.2008 um 15:27 schrieb Brian:

Ever since I’ve discovered Lua, I’ve been
using it to program more and
more of the games. At first, it was for configuration.
Then, I started
specifying entity behaviour. Soon, most of the game
logic was Lua,
with C++ being used for the menu system, graphics,
movement and
collision detection.

In my latest game, I’m trying to limit C++ to low
level details, such
as graphics and networking. Pretty much everything
else is being built
in Lua. At the moment I am still in a hybrid approach
because I am
reusing a lot of code from my older program.

I’m just curious, but what is the advantage of having
as much as possible of the code of your game in the script
language rather than in C++?

I myself like scripting languages also a lot. I have
written my own scripting languages in days where it was not
so common. My goal was always to keep the game as dynamic as
possible. And I was thinking very far into this direction; I
dreamed of having more or less everything scriptable of my
game. That thoughts went so far to have even graphic effects
scriptable, the whole input event handling and basically
almost everything, whereby of course such things like
blitting were some extern calls. I didn’t actually
implemented it this way but just thought that it could be
cool and I should try it once.

I have recently also seen a lot of other games using
scripting languages heavily. That really went so far as I
wanted it by myself once. The reason was always to have it
as dynamic as possible (with the thought that every part of
a script can easily be changed). They mainly did it for the
modder community, to give them as much possibilities as
possible. In the end, the modder was just able to recode the
whole game in a way that it would just be another, completly
independent, not at all related game.

I am recently asking myself if it makes really much sense
to do it this way. Of course, if somebody just prefers
Python/Lua/whatever over C/C++, that would be a reason. But
it often seems to me that a lot of people just code (almost)
the whole game in Python/Lua because they want to have it as
dynamic as possible.

I am writing because we had a similar discussion also
recently in our game project (OpenLieroX). We already have a
lot of mods by the community (100+) and you have already a
lot of possibilities in there, but it is rule-based. A mod
defines the behaviour of each projectile and each projectile
has a huge number of properties, including also the spawning
of new projectiles on certain events. The possibilities are
so huge that people have done really crazy stuff with it.

But you always hit the limit in such a system and sometimes
the solutions are also not really that nice. A lot of these
mods uses for example some hidden dummy projectiles just to
achieve something. We were discussing a lot with the
community how a new modding system should look like and the
main idea was to use some sort of scripting language like
Lua. The discussion about what exactly you should be able to
code there went back and forth. Some people (though not mod
developers) liked the idea of having even the whole physics
simulation and the input event handling on a very low level
(each keyboard/mouse/gamepad event) scriptable. We did not
really get to any descision on that. Somebody suggested that
the script just should define one single “void
frame(float dt)” function (which is called from the
main loop) and then just do everything on its own (including
mainly everything, the whole game). Some others suggested of
having this frame-functon for each single projectile and
then do everything (physic simulation, collision detection,
other things) there. I just wanted to point out here that I
think this idea of having everything scriptable goes way to
far in some cases, whereby I am not sure yet how far it
should get and where it should stop. Also, we have up to
3000 projectiles in our game at one time and it can be run
on some old PII with 300MHz with 64MB RAM and I am not sure
if we move the projectile behaviour definition out to a
script (like just in form of some "void frame()"
definition) that we can keep this performance.

What is your experience with scripting languages? At which
parts do they really give huge advantages (in the sense of
giving something which would not be possible or really
complicated otherwise)?

How far have you gone in your games by making things
scriptable? Where has it made things nicer? (Nicer not in
the sense of that Python could be nicer than C/C++ in
general for some people.)

  • Albert

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

It’s all homemade, it just uses SDL. We even have a simple HTML viewer
component (used for the news page and the chat). :slight_smile: (That happens when
bored developers just code too much on a game…)


Btw., “deprecated” because on of our devs is working on a new, more
scriptable/modable/skinable/powerfull widget set (since a year
already, but not complete yet). Thus, this deprecated widget set is
still the default and will probably also be for the next time.

The way the widgets are used in the game is also very different. There
are actually three different methods for example of handling the
events. You can set some callbacks (event based, similar to Object
Pascal), you can also overload and implement some virtual functions
(object oriented way) or you can handle the messages somewhere in the
main loop (as far as I know similar to MFC).

We are trying to make mostly everything event based right now as it
seems to be the most natural and clean way but huge parts of the menu
just works with the messages.

The code is already old (have no idea how old exactly, but could be
around 10 years now) and overworked a lot in the past, thus there are
some ugly parts or also some obsolete parts left from the past. So,
feel free to use it, but be aware of that.

Btw., it is under LGPL.Am 21.11.2008 um 17:31 schrieb julien CLEMENT:

May I ask you which library you used to make those nice GUI widgets ?
Is it homemade ?

thanks

— En date de : Ven 21.11.08, Albert Zeyer <@Albert_Zeyer

a ?crit :

De: Albert Zeyer <@Albert_Zeyer>
Objet: Re: [SDL] Scripting (3)
?: “A list for developers using the SDL library. (includes SDL-
announce)”
Date: Vendredi 21 Novembre 2008, 16h50
Hi,

Am 21.11.2008 um 15:27 schrieb Brian:

Ever since I’ve discovered Lua, I’ve been
using it to program more and
more of the games. At first, it was for configuration.
Then, I started
specifying entity behaviour. Soon, most of the game
logic was Lua,
with C++ being used for the menu system, graphics,
movement and
collision detection.

In my latest game, I’m trying to limit C++ to low
level details, such
as graphics and networking. Pretty much everything
else is being built
in Lua. At the moment I am still in a hybrid approach
because I am
reusing a lot of code from my older program.

I’m just curious, but what is the advantage of having
as much as possible of the code of your game in the script
language rather than in C++?

I myself like scripting languages also a lot. I have
written my own scripting languages in days where it was not
so common. My goal was always to keep the game as dynamic as
possible. And I was thinking very far into this direction; I
dreamed of having more or less everything scriptable of my
game. That thoughts went so far to have even graphic effects
scriptable, the whole input event handling and basically
almost everything, whereby of course such things like
blitting were some extern calls. I didn’t actually
implemented it this way but just thought that it could be
cool and I should try it once.

I have recently also seen a lot of other games using
scripting languages heavily. That really went so far as I
wanted it by myself once. The reason was always to have it
as dynamic as possible (with the thought that every part of
a script can easily be changed). They mainly did it for the
modder community, to give them as much possibilities as
possible. In the end, the modder was just able to recode the
whole game in a way that it would just be another, completly
independent, not at all related game.

I am recently asking myself if it makes really much sense
to do it this way. Of course, if somebody just prefers
Python/Lua/whatever over C/C++, that would be a reason. But
it often seems to me that a lot of people just code (almost)
the whole game in Python/Lua because they want to have it as
dynamic as possible.

I am writing because we had a similar discussion also
recently in our game project (OpenLieroX). We already have a
lot of mods by the community (100+) and you have already a
lot of possibilities in there, but it is rule-based. A mod
defines the behaviour of each projectile and each projectile
has a huge number of properties, including also the spawning
of new projectiles on certain events. The possibilities are
so huge that people have done really crazy stuff with it.

But you always hit the limit in such a system and sometimes
the solutions are also not really that nice. A lot of these
mods uses for example some hidden dummy projectiles just to
achieve something. We were discussing a lot with the
community how a new modding system should look like and the
main idea was to use some sort of scripting language like
Lua. The discussion about what exactly you should be able to
code there went back and forth. Some people (though not mod
developers) liked the idea of having even the whole physics
simulation and the input event handling on a very low level
(each keyboard/mouse/gamepad event) scriptable. We did not
really get to any descision on that. Somebody suggested that
the script just should define one single “void
frame(float dt)” function (which is called from the
main loop) and then just do everything on its own (including
mainly everything, the whole game). Some others suggested of
having this frame-functon for each single projectile and
then do everything (physic simulation, collision detection,
other things) there. I just wanted to point out here that I
think this idea of having everything scriptable goes way to
far in some cases, whereby I am not sure yet how far it
should get and where it should stop. Also, we have up to
3000 projectiles in our game at one time and it can be run
on some old PII with 300MHz with 64MB RAM and I am not sure
if we move the projectile behaviour definition out to a
script (like just in form of some "void frame()"
definition) that we can keep this performance.

What is your experience with scripting languages? At which
parts do they really give huge advantages (in the sense of
giving something which would not be possible or really
complicated otherwise)?

How far have you gone in your games by making things
scriptable? Where has it made things nicer? (Nicer not in
the sense of that Python could be nicer than C/C++ in
general for some people.)

  • Albert

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

For me, I write 2D games that should run on any reasonably modern hardware.

My games use OpenGL for rendering, SDL for as much as possible outside
that. I think modern machines can easily handle my games. In fact, the
problems I encountered running my previous game on older hardware were
not slowdowns due to Lua - it was due to a poor integrated graphics
card which couldn’t accelerate my nasty immediate mode OpenGL calls.

Note that I have never used OpenGL, and my knowledge of it is
minimal/none. I wonder why is OpenGL used for 2D games instead of SDL
graphic functions? What does it provide that can not be done in pure
SDL that is worth disabling computers without 3D accelerated graphic
card to run the game?

What am I thinking of is that games like Caesar ]]], Age of Empires,
Star Craft and many similar are playable in pentium I processors old
graphic card with 512 kB of memory (maybe less). They do not need
’reasonably’ (what is reasonably in such case anyway) modern hardware.

What I want to ask is (not in offensive way):
Why is OpenGL used for not 3D graphic. Is it because programmers
know how to use it (I do not and hence all this questions!) so
they just use it or is there more to it that I do not understand?

MartinOn Fri, Nov 21, 2008 at 02:27:19PM +0000, Brian wrote:

For me, I write 2D games that should run on any reasonably modern
hardware.

My games use OpenGL for rendering, SDL for as much as possible
outside
that. I think modern machines can easily handle my games. In fact,
the
problems I encountered running my previous game on older hardware
were
not slowdowns due to Lua - it was due to a poor integrated graphics
card which couldn’t accelerate my nasty immediate mode OpenGL calls.

Note that I have never used OpenGL, and my knowledge of it is
minimal/none. I wonder why is OpenGL used for 2D games instead of SDL
graphic functions? What does it provide that can not be done in pure
SDL

OpenGL is an interface where you get (normally) direct access to the
graphics hardware. With pure SDL, you don’t have that (I don’t count
hardware surfaces here, that is a different topic; in most cases, you
cannot use them anyway). Also, OpenGL provides much more functions
than SDL and as they are normally run in the graphics hardware, they
are much faster.

that is worth disabling computers without 3D accelerated graphic
card to run the game?

You don’t disable them. Most OpenGL drivers emulate important
functions if the hardware does not support them. Also, OpenGL is also
for 2D. And then, there is also Mesa which is a full OpenGL
implementation in software (but it also has support for some graphics
hardware and uses them if possible). And even if Mesa is operating
fully in software, it’s probably still faster than any own
implementation in SDL.

What am I thinking of is that games like Caesar ]]], Age of Empires,
Star Craft and many similar are playable in pentium I processors old
graphic card with 512 kB of memory (maybe less). They do not need
’reasonably’ (what is reasonably in such case anyway) modern hardware.

At least Age of Empires is using DirectX (and Direct2D for graphics),
which is similar to OpenGL.

What I want to ask is (not in offensive way):
Why is OpenGL used for not 3D graphic. Is it because programmers
know how to use it (I do not and hence all this questions!) so
they just use it or is there more to it that I do not understand?

The main reason is that it is faster. Also old graphics hardware still
provides some rudimentary functions.Am 22.11.2008 um 15:24 schrieb Martin:

On Fri, Nov 21, 2008 at 02:27:19PM +0000, Brian wrote:

I think the main reason for what you ask is that the programmer doesn’t want
to be limited. With OpenGL, you can make a “2d” game with 3d effects or
other neat effects that don’t come with the performance penalty that a
software implementation does, as well as not worrying much at all about the
rendering bottleneck for simple games. The problem, of course, is when your
computer fails to accelerate such things. I still haven’t gotten my
Macbook’s hardware acceleration working in Debian, and even a simplified
test of my platformer example is terribly slow. When I get the chance, you
can expect a version of Sprig that uses OpenGL but can use the current
software implementation if necessary.

Jonny D> Date: Sat, 22 Nov 2008 15:24:49 +0100

From: wtxnh-sdl at yahoo.com.au
To: sdl at lists.libsdl.org
Subject: Re: [SDL] Why use OpenGL for rendering 2D game? [was] Scripting
(3)

On Fri, Nov 21, 2008 at 02:27:19PM +0000, Brian wrote:

For me, I write 2D games that should run on any reasonably modern
hardware.

My games use OpenGL for rendering, SDL for as much as possible outside
that. I think modern machines can easily handle my games. In fact, the
problems I encountered running my previous game on older hardware were
not slowdowns due to Lua - it was due to a poor integrated graphics
card which couldn’t accelerate my nasty immediate mode OpenGL calls.

Note that I have never used OpenGL, and my knowledge of it is
minimal/none. I wonder why is OpenGL used for 2D games instead of SDL
graphic functions? What does it provide that can not be done in pure
SDL that is worth disabling computers without 3D accelerated graphic
card to run the game?

What am I thinking of is that games like Caesar ]]], Age of Empires,
Star Craft and many similar are playable in pentium I processors old
graphic card with 512 kB of memory (maybe less). They do not need
’reasonably’ (what is reasonably in such case anyway) modern hardware.

What I want to ask is (not in offensive way):
Why is OpenGL used for not 3D graphic. Is it because programmers
know how to use it (I do not and hence all this questions!) so
they just use it or is there more to it that I do not understand?

Martin


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[…] The problem, of course, is when your computer fails to
accelerate such things. I still haven’t gotten my Macbook’s
hardware acceleration working in Debian, and even a simplified test
of my platformer example is terribly slow. […]

But even in this case, simple 2D operations in OpenGL should be much
faster than 2D software operations in SDL.

Btw., if you have a Macbook, you should have an Intel based graphics
card. As far as I know, the newer Xorg versions and also Mesa should
support this card with hardware acceleration. I also have a Macbook
and I got it working under Linux (but I use Gentoo).Am 23.11.2008 um 21:30 schrieb Jonathan Dearborn:

Jonny D

Date: Sat, 22 Nov 2008 15:24:49 +0100
From: wtxnh-sdl at yahoo.com.au
To: sdl at lists.libsdl.org
Subject: Re: [SDL] Why use OpenGL for rendering 2D game? [was]
Scripting (3)

On Fri, Nov 21, 2008 at 02:27:19PM +0000, Brian wrote:

For me, I write 2D games that should run on any reasonably
modern hardware.

My games use OpenGL for rendering, SDL for as much as possible
outside

that. I think modern machines can easily handle my games. In
fact, the

problems I encountered running my previous game on older
hardware were

not slowdowns due to Lua - it was due to a poor integrated
graphics

card which couldn’t accelerate my nasty immediate mode OpenGL
calls.

Note that I have never used OpenGL, and my knowledge of it is
minimal/none. I wonder why is OpenGL used for 2D games instead of
SDL
graphic functions? What does it provide that can not be done in pure
SDL that is worth disabling computers without 3D accelerated graphic
card to run the game?

What am I thinking of is that games like Caesar ]]], Age of Empires,
Star Craft and many similar are playable in pentium I processors old
graphic card with 512 kB of memory (maybe less). They do not need
’reasonably’ (what is reasonably in such case anyway) modern
hardware.

What I want to ask is (not in offensive way):
Why is OpenGL used for not 3D graphic. Is it because programmers
know how to use it (I do not and hence all this questions!) so
they just use it or is there more to it that I do not understand?

Martin


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

It all depends on how you implement them with SDL. In that way, SDL is
low-level. You can choose a faster algorithm than what OpenGL uses
(algorithmically fast or trade-off quality). I like to think that Sprig is
fast :slight_smile:

Jonny DOn Sun, Nov 23, 2008 at 3:41 PM, Albert Zeyer <albert.zeyer at rwth-aachen.de>wrote:

Am 23.11.2008 um 21:30 schrieb Jonathan Dearborn:

[…] The problem, of course, is when your computer fails to accelerate

such things. I still haven’t gotten my Macbook’s hardware acceleration
working in Debian, and even a simplified test of my platformer example is
terribly slow. […]

But even in this case, simple 2D operations in OpenGL should be much faster
than 2D software operations in SDL.

Btw., if you have a Macbook, you should have an Intel based graphics card.
As far as I know, the newer Xorg versions and also Mesa should support this
card with hardware acceleration. I also have a Macbook and I got it working
under Linux (but I use Gentoo).

Jonny D

Date: Sat, 22 Nov 2008 15:24:49 +0100
From: wtxnh-sdl at yahoo.com.au
To: sdl at lists.libsdl.org
Subject: Re: [SDL] Why use OpenGL for rendering 2D game? [was] Scripting
(3)

On Fri, Nov 21, 2008 at 02:27:19PM +0000, Brian wrote:

For me, I write 2D games that should run on any reasonably modern
hardware.

My games use OpenGL for rendering, SDL for as much as possible outside
that. I think modern machines can easily handle my games. In fact, the
problems I encountered running my previous game on older hardware were
not slowdowns due to Lua - it was due to a poor integrated graphics
card which couldn’t accelerate my nasty immediate mode OpenGL calls.

Note that I have never used OpenGL, and my knowledge of it is
minimal/none. I wonder why is OpenGL used for 2D games instead of SDL
graphic functions? What does it provide that can not be done in pure
SDL that is worth disabling computers without 3D accelerated graphic
card to run the game?

What am I thinking of is that games like Caesar ]]], Age of Empires,
Star Craft and many similar are playable in pentium I processors old
graphic card with 512 kB of memory (maybe less). They do not need
’reasonably’ (what is reasonably in such case anyway) modern hardware.

What I want to ask is (not in offensive way):
Why is OpenGL used for not 3D graphic. Is it because programmers
know how to use it (I do not and hence all this questions!) so
they just use it or is there more to it that I do not understand?

Martin


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org_______________________________________________
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

OpenGL offers very fast zooming/scaling/rotating primitives. Transparency is
also a lot faster with OpenGL than with SDL. Besides tat OpenGL is much more
powerful in every way, you can do more effects with it and of course all
gets hardware accelerated.On Sat, Nov 22, 2008 at 3:24 PM, Martin wrote:

On Fri, Nov 21, 2008 at 02:27:19PM +0000, Brian wrote:

For me, I write 2D games that should run on any reasonably modern
hardware.

My games use OpenGL for rendering, SDL for as much as possible outside
that. I think modern machines can easily handle my games. In fact, the
problems I encountered running my previous game on older hardware were
not slowdowns due to Lua - it was due to a poor integrated graphics
card which couldn’t accelerate my nasty immediate mode OpenGL calls.

Note that I have never used OpenGL, and my knowledge of it is
minimal/none. I wonder why is OpenGL used for 2D games instead of SDL
graphic functions? What does it provide that can not be done in pure
SDL that is worth disabling computers without 3D accelerated graphic
card to run the game?

What am I thinking of is that games like Caesar ]]], Age of Empires,
Star Craft and many similar are playable in pentium I processors old
graphic card with 512 kB of memory (maybe less). They do not need
’reasonably’ (what is reasonably in such case anyway) modern hardware.

What I want to ask is (not in offensive way):
Why is OpenGL used for not 3D graphic. Is it because programmers
know how to use it (I do not and hence all this questions!) so
they just use it or is there more to it that I do not understand?

Martin


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Others have answered, but not given much detail, which seems relevant
IMHO since you say you don’t know much about OpenGL.

OpenGL provides access to functionality that can be very useful for 2D
games, and free the developer from having to write (or optimize) this
functionality:

  • (scalable) vector graphics
  • rotation
  • scaling
  • stretching
  • mirroring / flipping
  • other deformations
  • alpha blending

OpenGL is not fundamentally “3D.” Your screen is 2D (probably,)
display 3D graphics on it is generally a matter of applying the
correct deformations to 2D texture graphics, blending, and depth
testing. Also fragment shaders (or pixel shaders) can offer a whole
lot of massively parallel computational power for use in 2D graphical
environments.On Sat, Nov 22, 2008 at 9:24 AM, Martin wrote:

On Fri, Nov 21, 2008 at 02:27:19PM +0000, Brian wrote:
What I want to ask is (not in offensive way):
Why is OpenGL used for not 3D graphic. Is it because programmers
know how to use it (I do not and hence all this questions!) so
they just use it or is there more to it that I do not understand?


http://codebad.com/

Also, it’s worth noting that some types of games will be much slower
if you try to implement them using a lot of OpenGL. Any code that
needs fast access to pixels in the frame buffer will operate very
slowly (for instance, suppose you took an old school fire demo and
instead of operating on a framebuffer residing in system RAM to which
you have direct access, you made each pixel operation an OpenGL
function call that required talking to the graphics card – this is a
very undesirable situation.)On Sun, Nov 23, 2008 at 11:54 PM, Donny Viszneki <@Donny_Viszneki> wrote:

On Sat, Nov 22, 2008 at 9:24 AM, Martin wrote:

On Fri, Nov 21, 2008 at 02:27:19PM +0000, Brian wrote:
What I want to ask is (not in offensive way):
Why is OpenGL used for not 3D graphic. Is it because programmers
know how to use it (I do not and hence all this questions!) so
they just use it or is there more to it that I do not understand?

Others have answered, but not given much detail, which seems relevant
IMHO since you say you don’t know much about OpenGL.

OpenGL provides access to functionality that can be very useful for 2D
games, and free the developer from having to write (or optimize) this
functionality:

  • (scalable) vector graphics
  • rotation
  • scaling
  • stretching
  • mirroring / flipping
  • other deformations
  • alpha blending

OpenGL is not fundamentally “3D.” Your screen is 2D (probably,)
display 3D graphics on it is generally a matter of applying the
correct deformations to 2D texture graphics, blending, and depth
testing. Also fragment shaders (or pixel shaders) can offer a whole
lot of massively parallel computational power for use in 2D graphical
environments.


http://codebad.com/


http://codebad.com/

Hi Martin,

What I want to ask is (not in offensive way): Why is OpenGL used for not 3D

graphic. Is it because programmers know how to use it (I do not and hence
all this questions!) so they just use it or is there more to it that I do
not understand?

I can give you the reasons why we (www.mysterystudio.com/aboutus.php) do :

  1. Performance. A long, long time ago our framework did only SDL-based
    software rendering only, I had terribly complex dirty tile code to make
    things go more or less fast on the screen, and even then there was a limit
    on what could move simultaneously on the screen. Our last game to be
    software-rendering only is Wild West Wendy (2004)

  2. Effects. A hardware-accelerated backend lets us do scaling, rotation,
    alpha blending, additive blending and color tinting “for free”, while doing
    that on software would be extremely cpu and/or memory consuming, to the
    point of being impractical.

In the end, it boils down to this : a huge fraction of our target market
does have 3D hardware of some sort, so it would be a waste NOT to use it.

–GabrielOn Sat, Nov 22, 2008 at 12:24 PM, Martin wrote:

On Fri, Nov 21, 2008 at 02:27:19PM +0000, Brian wrote:

For me, I write 2D games that should run on any reasonably modern
hardware.

My games use OpenGL for rendering, SDL for as much as possible outside
that. I think modern machines can easily handle my games. In fact, the
problems I encountered running my previous game on older hardware were
not slowdowns due to Lua - it was due to a poor integrated graphics
card which couldn’t accelerate my nasty immediate mode OpenGL calls.

Note that I have never used OpenGL, and my knowledge of it is
minimal/none. I wonder why is OpenGL used for 2D games instead of SDL
graphic functions? What does it provide that can not be done in pure
SDL that is worth disabling computers without 3D accelerated graphic
card to run the game?

What am I thinking of is that games like Caesar ]]], Age of Empires,
Star Craft and many similar are playable in pentium I processors old
graphic card with 512 kB of memory (maybe less). They do not need
’reasonably’ (what is reasonably in such case anyway) modern hardware.

What I want to ask is (not in offensive way):
Why is OpenGL used for not 3D graphic. Is it because programmers
know how to use it (I do not and hence all this questions!) so
they just use it or is there more to it that I do not understand?

Martin


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Hello,

It all depends on what type of game you want to create. I use 2D SDL graphic
functions, because we create games for children with a lot of draws and
educational programs, where we draw or colour pictures.

Pure SDL gives us easy access to pixels. In our newest adventure game (
http://dagiel.pl/index.php?menu=programy&submenu=roboty ) we draw in
gimp-like program, we put patterns, filters, watch graphic algoritms or
program in LOGO.

SDL gfx gives us scaling and rotating, which is enough for 3 dynamically
scalled heroes, with some backgrounds. We don’t have many effects, but our
games don’t need them. Software surfaces give us opportunity to mix all types
of games.

The cost is slow fps but in 2d games, there are usually drawed animations so
animators draw i.e. 12fps.

Last thing, quite funny, I had problems with nvidia and wacom drivers on
Debian and I had to remove nvidia. 2D without OGL works normally on it.

I think unless you need fast gfx effects, SDL surfaces are enough.

Regards,
Dominik

Monday 24 of November 2008 13:00:36 Gabriel Gambetta napisa?(a):> Hi Martin,

What I want to ask is (not in offensive way): Why is OpenGL used for not 3D

graphic. Is it because programmers know how to use it (I do not and hence
all this questions!) so they just use it or is there more to it that I do
not understand?

I can give you the reasons why we (www.mysterystudio.com/aboutus.php) do :

  1. Performance. A long, long time ago our framework did only SDL-based
    software rendering only, I had terribly complex dirty tile code to make
    things go more or less fast on the screen, and even then there was a limit
    on what could move simultaneously on the screen. Our last game to be
    software-rendering only is Wild West Wendy (2004)

  2. Effects. A hardware-accelerated backend lets us do scaling, rotation,
    alpha blending, additive blending and color tinting “for free”, while doing
    that on software would be extremely cpu and/or memory consuming, to the
    point of being impractical.

In the end, it boils down to this : a huge fraction of our target market
does have 3D hardware of some sort, so it would be a waste NOT to use it.

–Gabriel


  1. Effects. A hardware-accelerated backend lets us do scaling,
    rotation, alpha blending, additive blending and color tinting “for
    free”, while doing that on software would be extremely cpu and/or
    memory consuming, to the point of being impractical.

Ooo… is there a GL API for color tinting? Last time I checked, you had to blit your
sprite to the screen, then blit a solid rectangle of color on top of it using partial
transparency and making sure it gets restricted to the original sprite’s mask.
Is there a simpler way?>From: Gabriel Gambetta

Subject: Re: [SDL] Why use OpenGL for rendering 2D game? [was] Scripting (3)

I guess what you think “tinting” means matters, but one simpler (but
not equivalent) action you can take with OpenGL is to multiply the
color values of your image with some other color value(s) using
glColor*().On Mon, Nov 24, 2008 at 8:58 AM, Mason Wheeler wrote:

Ooo… is there a GL API for color tinting? Last time I checked, you had to blit your
sprite to the screen, then blit a solid rectangle of color on top of it using partial
transparency and making sure it gets restricted to the original sprite’s mask.
Is there a simpler way?


http://codebad.com/

Ooo… is there a GL API for color tinting? Last time I checked, you had to blit your
sprite to the screen, then blit a solid rectangle of color on top of it using partial
transparency and making sure it gets restricted to the original sprite’s mask.
Is there a simpler way?

I guess what you think “tinting” means matters, but one simpler (but
not equivalent) action you can take with OpenGL is to multiply the
color values of your image with some other color value(s) using
glColor*().

OK, I just looked up documentation on GLColor, and it just says that it sets the
current color. I can understand using that with GLVertex to create colored primitives,
but how does that apply to sprite images, which pretty much by definition come with
their own colors already?>----- Original Message ----

From: Donny Viszneki <donny.viszneki at gmail.com>
Subject: Re: [SDL] Why use OpenGL for rendering 2D game? [was] Scripting (3)
On Mon, Nov 24, 2008 at 8:58 AM, Mason Wheeler <@Mason_Wheeler> wrote:

Please ask an OpenGL mailing list – or better, RTFM

http://www.opengl.org/documentation/red_book/On Mon, Nov 24, 2008 at 4:19 PM, Mason Wheeler wrote:

----- Original Message ----

From: Donny Viszneki <@Donny_Viszneki>
Subject: Re: [SDL] Why use OpenGL for rendering 2D game? [was] Scripting (3)

On Mon, Nov 24, 2008 at 8:58 AM, Mason Wheeler wrote:

Ooo… is there a GL API for color tinting? Last time I checked, you had to blit your
sprite to the screen, then blit a solid rectangle of color on top of it using partial
transparency and making sure it gets restricted to the original sprite’s mask.
Is there a simpler way?

I guess what you think “tinting” means matters, but one simpler (but
not equivalent) action you can take with OpenGL is to multiply the
color values of your image with some other color value(s) using
glColor*().

OK, I just looked up documentation on GLColor, and it just says that it sets the
current color. I can understand using that with GLVertex to create colored primitives,
but how does that apply to sprite images, which pretty much by definition come with
their own colors already?


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


http://codebad.com/

Why the F attitude? If you don’t have something to add to the discussion please just ignore the emails. You don’t have to replay to this discussion if all you have to say is RTFM.Sent from my Verizon Wireless BlackBerry

----- Original Message -----
From: donny.viszneki@gmail.com (Donny Viszneki)

Date: Mon, 24 Nov 2008 16:27:42
To: A list for developers using the SDL library. (includes SDL-announce)
Subject: Re: [SDL] Why use OpenGL for rendering 2D game? [was] Scripting (3)

Please ask an OpenGL mailing list – or better, RTFM

http://www.opengl.org/documentation/red_book/

On Mon, Nov 24, 2008 at 4:19 PM, Mason Wheeler wrote:

----- Original Message ----

From: Donny Viszneki <donny.viszneki at gmail.com>
Subject: Re: [SDL] Why use OpenGL for rendering 2D game? [was] Scripting (3)

On Mon, Nov 24, 2008 at 8:58 AM, Mason Wheeler wrote:

Ooo… is there a GL API for color tinting? Last time I checked, you had to blit your
sprite to the screen, then blit a solid rectangle of color on top of it using partial
transparency and making sure it gets restricted to the original sprite’s mask.
Is there a simpler way?

I guess what you think “tinting” means matters, but one simpler (but
not equivalent) action you can take with OpenGL is to multiply the
color values of your image with some other color value(s) using
glColor*().

OK, I just looked up documentation on GLColor, and it just says that it sets the
current color. I can understand using that with GLVertex to create colored primitives,
but how does that apply to sprite images, which pretty much by definition come with
their own colors already?


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


http://codebad.com/


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org