Hi,
I am trying to make small games in Linux using SDL. I wrote one game
using C and it works fine, other game I wrote using C++, this works very
slow. All the bitmaps are blitted slow, one can literally see the difference
in PC itself. I agree that classes are heavy but would it make so much of
difference? or should I not be using SDL with C++?
regards,
Paresh.
I’m currenly writing a game in C++ with SDL and getting a decent performance
out of it ( about 110 fps in 800x600 16-bit and 200 sprites ( 32x32 ), no
blitting just SDL_FillRect, also no collision detection on a K6-2 at 450 192 MB
Ram and a 2.4.14 kernel ).
I’m far from finished and haven’t optimized anything yet, but I have hopes
that it will comeout as a playable game 
also if you allocate/deallocate sprites with the new/delete operator I found
( in MPW atleast ) that the performance is greatly reduced. I solved it by
cloning the objects ( when possible ) with a simple malloc, memcpy, and then
having a method ( such as wasCloned() ), to let the object know that it had
been cloned. I haven’t tested this in gcc though.
/Mange—
“Let the programmers be many and the managers few – then all will be
productive.”
----- Original Message -----
From: paresh@w-o-i.com (Paresh)
To: “SDL”
Sent: Wednesday, November 21, 2001 11:07
Subject: [SDL] performace problem using C++ with SDL as compared to using C
with SDLHi,
I am trying to make small games in Linux using SDL. I wrote one game
using C and it works fine, other game I wrote using C++, this works very
slow. All the bitmaps are blitted slow, one can literally see the
difference
in PC itself. I agree that classes are heavy but would it make so much of
difference? or should I not be using SDL with C++?regards,
Paresh.
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
if i could gives you my humble opinion on usual C++ coding.
often C++ fear (exageratly) memory leak, preferring reference to pointer
(as they are automatically destroyed)
and they fear, also global variable.
unlikely the C programmer who use pointer and global variable.
this is faster. you allocate only once and don’t spend your time reading
bitmap data file again and again.
C++ is an improvement but break standard habits.
use global variable, use pointer, and don’t new/delete your sprite every
frame !..
PS: i don’t intend to begin an OT war, i was just expressing my though
as an advice.
Mange wrote:
also if you allocate/deallocate sprites with the new/delete operator I found
( in MPW atleast ) that the performance is greatly reduced. I solved it by
cloning the objects ( when possible ) with a simple malloc, memcpy, and then
Did you know that you can write your own new/delete operators?
Something like that (no error checking here):
class C
{
…
public:
void* operator new(size_t sz);
{
return malloc(sz);
}
void operator delete(void* p, size_t)
{
free(p);
}
…
};
and the usage would be:
C* o = new C;
…
delete o;
when cloning you could consider copy constructor and assignment operator
(clone() function still can be usefull - when your copy ctor does
shallow copy, and you need deep copy, for example).
dishlav
Lloyd Dupont wrote:
if i could gives you my humble opinion on usual C++ coding.
No you don’t. This thread stops right HERE
Lloyd Dupont wrote:
often C++ fear (exageratly) memory leak,
badly written programs always give memory leaks. Hmmm… maybe in Java
you are not afraid of the leaking memory, but performance is a penalty
here.
preferring reference to pointer
both reference and the pointer have their good and bad usages,
preferences should be left alone.
(as they are automatically destroyed)
references you mean? well… not quite true (… totally wrong I should
rather say)
and they fear, also global variable.
that’s not fear, that’s common sense. BTW global objects are still
useful in some cases.
unlikely the C programmer who use pointer and global variable.
oooooohh… going to the source of the all evil
C++ is an improvement but break standard habits.
C++ is a language that let’s you express you OO ideas in relatively easy
way. It is not a remedy to the bad habits - if someone’s code is bad in
C it is unlikely to be good in C++. Think OO.
PS: i don’t intend to begin an OT war, i was just expressing my though
as an advice.
you have just started the war
dishlav
That’s disgusting. Even for C++. =)On Wed, Nov 21, 2001 at 10:07:03PM +1100, dishlav wrote:
void* operator new(size_t sz);
{
return malloc(sz);
}void operator delete(void* p, size_t)
{
free§;
}
–
Joseph Carter Free software developer
“Lord grant me the serenity to accept the things I cannot
change, the courage to change the things I can, and the wisdom
to hide the bodies of the people I had to kill because they
pissed me off.”
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20011121/477e9702/attachment.pgp
There are many C practices that are WRONG to use
in C++. They lead to slow code, create toons of temporary
objects and so on.
C++ is a multiparadigm language and when programming in C++
think C++, not C.
There are many C++ math librarys, Blitz++ comes to mind, that
outperform optimized FORTRAN code, thanks to template metaprogramming.
C still isn’t able to do that.
As for the language war, I couldn’t resist
Paulo> ----- Original Message -----
From: lloyd@galador.net (Lloyd Dupont)
if i could gives you my humble opinion on usual C++ coding.
often C++ fear (exageratly) memory leak, preferring reference to pointer
(as they are automatically destroyed)
and they fear, also global variable.unlikely the C programmer who use pointer and global variable.
this is faster. you allocate only once and don’t spend your time reading
bitmap data file again and again.
C++ is an improvement but break standard habits.use global variable, use pointer, and don’t new/delete your sprite every
frame !..PS: i don’t intend to begin an OT war, i was just expressing my though
as an advice.
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
No, no no, STOP right there!
No, there’s no inherent reason a game using SDL would be faster or slower
using C or C++. End of discussion.
-Sam Lantinga, Software Engineer, Blizzard EntertainmentRight.
(If anyone thinks that Kobo Deluxe uses both C and C++ for any "real"
reason - nope, I just happened to have a “working” C engine lying around,
while XKobo was written in C++. The stand-alone version of the Spitfire
Engine may well be 100% C++. I have yet to decide, but it’s not a matter
of performance.)
Anyway, back to the topic: What can be the reason for the slowdown?
* Are you doing alpha blended blitting in the slow game?
* Did you forget to use SDL_DisplayFormat()?
* Are you accidentally blitting stuff more than once?
* Are you reading from VRAM with the CPU? (Other than
implicitly, by doing alpha blended blits to VRAM.)
* Is some bug causing some function to burn lots of CPU?
* Does one of the games run in a window, while the other
runs fullscreen?
* Are both games using the same pixel format?
* Do both games get the same video driver?
And of course - not trying to offend anyone here, but this is all
irrelevant if the “slow” game is actually blitting ten times more data
than the “fast” game! 
I guess that’s pretty obvious, as SDL - like
most other APIs - doesn’t transparently eliminate overdraw or anything
like that. (Not even h/w accelerated Z-buffering is free…)
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Wednesday 21 November 2001 19:02, Sam Lantinga wrote:
No, no no, STOP right there!
No, there’s no inherent reason a game using SDL would be faster or
slower using C or C++. End of discussion.
you mean style? well… i don’t like it either, but it shows what you can do
in C++ with new/delete. Hope you could read it.
dishlavOn Thursday 22 November 2001 00:49, you wrote:
On Wed, Nov 21, 2001 at 10:07:03PM +1100, dishlav wrote:
void* operator new(size_t sz); { return malloc(sz); } void operator delete(void* p, size_t) { free(p); }That’s disgusting. Even for C++. =)
Zdzislaw Sliwinski writes:> On Thursday 22 November 2001 00:49, you wrote:
On Wed, Nov 21, 2001 at 10:07:03PM +1100, dishlav wrote:
void* operator new(size_t sz); { return malloc(sz); } void operator delete(void* p, size_t) { free(p); }That’s disgusting. Even for C++. =)
you mean style? well… i don’t like it either, but it shows what you can do
in C++ with new/delete. Hope you could read it.
Excuse me, what’s the matter with it. Is there a problem with this
code? Just curious because it’s been a while since I’ve been doing
that stuff.
What you could do to optimize allocation further is to override new
and delete for one class. You don’t have to worry about fragmentation
because all the chunks of memory allocated will be the same size.
–
Vennlig hilsen
Syver Enstad
/Mange—
“Let the programmers be many and the managers few – then all will be
productive.”
----- Original Message -----
From: dishlav@research.canon.com.au (Zdzislaw Sliwinski)
To:
Sent: Thursday, November 22, 2001 0:18
Subject: Re: [SDL] performace problem using C++ with SDL as compared to
using C with SDLOn Thursday 22 November 2001 00:49, you wrote:
On Wed, Nov 21, 2001 at 10:07:03PM +1100, dishlav wrote:
void* operator new(size_t sz);
{
return malloc(sz);
}void operator delete(void* p, size_t)
{
free§;
}That’s disgusting. Even for C++. =)
you mean style? well… i don’t like it either, but it shows what you can
do
in C++ with new/delete. Hope you could read it.dishlav
To get more performance, you could then allocate a big chunk of memory and
then allocate objects within that chunk, no malloc() or free() when objects
needs to be created or destroyed. Something I have to try out as my game
evolves/Mange