Hi,
I’ve recently wrote a tetris game.
I have a bug in it concerning the proper
re-drawing of the last line on the screen.
(apart from the obvious design problems)
I’ve tried multiple times to correct the bug but I cannot find the cause.
I’d be grateful if any of you would like to have a look and tell me.
It’s written in C++ and SDL.
The game and source can be found here
http://perlhobby.googlecode.com/svn/trunk/tetris/
the second version.–
Stefan Petrea
homepage : http://perlhobby.googlecode.com/
mobile phone : (040) 0732070179
Well, C++ and STL isn’t really my area of expertise, but…On Thursday 09 October 2008, Stefan Petrea wrote:
Hi,
I’ve recently wrote a tetris game.
I have a bug in it concerning the proper
re-drawing of the last line on the screen.
(apart from the obvious design problems)
I’ve tried multiple times to correct the bug but I cannot find the
cause.
I’d be grateful if any of you would like to have a look and tell me.
It’s written in C++ and SDL.
The game and source can be found here
http://perlhobby.googlecode.com/svn/trunk/tetris/
the second version.
void World::Update(){
for(vector<Object *>::const_iterator p=
RenderList.begin();p!=RenderList.end();p++){
…isn’t RenderList.end() the last actual item? If so, the loop will
end when you reach that item, rather than after processing it.
(Oh, and this isn’t really an SDL specific question, unless I’m
missing the point.)
//David Olofson - Programmer, Composer, Open Source Advocate
.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
’-- http://www.reologica.se - Rheology instrumentation --’
Nope, container.end() is one past the last element. I took a brief skim
over the code and nothing stuck out at me as looking horrifically wrong.On Thu, Oct 9, 2008 at 3:56 AM, David Olofson wrote:
On Thursday 09 October 2008, Stefan Petrea wrote:
Hi,
I’ve recently wrote a tetris game.
I have a bug in it concerning the proper
re-drawing of the last line on the screen.
(apart from the obvious design problems)
I’ve tried multiple times to correct the bug but I cannot find the
cause.
I’d be grateful if any of you would like to have a look and tell me.
It’s written in C++ and SDL.
The game and source can be found here
http://perlhobby.googlecode.com/svn/trunk/tetris/
the second version.
Well, C++ and STL isn’t really my area of expertise, but…
void World::Update(){
for(vector<Object *>::const_iterator p=
RenderList.begin();p!=RenderList.end();p++){
…isn’t RenderList.end() the last actual item? If so, the loop will
end when you reach that item, rather than after processing it.
(Oh, and this isn’t really an SDL specific question, unless I’m
missing the point.)
//David Olofson - Programmer, Composer, Open Source Advocate
.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
’-- http://www.reologica.se - Rheology instrumentation --’
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Nope, container.end() is one past the last element. I took a brief skim
over the code and nothing stuck out at me as looking horrifically wrong.
Hi,
I’ve recently wrote a tetris game.
I have a bug in it concerning the proper
re-drawing of the last line on the screen.
(apart from the obvious design problems)
I’ve tried multiple times to correct the bug but I cannot find the
cause.
I’d be grateful if any of you would like to have a look and tell me.
It’s written in C++ and SDL.
The game and source can be found here
http://perlhobby.googlecode.com/svn/trunk/tetris/
the second version.
Well, C++ and STL isn’t really my area of expertise, but…
void World::Update(){
for(vector<Object *>::const_iterator p=
RenderList.begin();p!=RenderList.end();p++){
…isn’t RenderList.end() the last actual item? If so, the loop will
end when you reach that item, rather than after processing it.
(Oh, and this isn’t really an SDL specific question, unless I’m
missing the point.)
//David Olofson - Programmer, Composer, Open Source Advocate
.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
’-- http://www.reologica.se - Rheology instrumentation --’
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
Hi,thank you for taking a look.
If you want to see the bug,please start the game and make a full row.
Afterwards all squares should drop by 1 square because the full row
disappears.
(I also have a matrix which takes account of this which is shown in the
console
that also opens).
The problem is that the matrix is showing correct values but they are not
properly
rendered on the screen.
In particular,some of the old squares remain drawn in the full row that
should disappear
completely and if you click and drag the mouse over them they are
progressively erased.
Speed concenrns:
Also I think this particular method of drawing rectangles on the screen is
not very fast.
I think I should have drawn them on a SDL_surface and then blit that to the
screen ?
What is your oppinion on this ?On Thu, Oct 9, 2008 at 11:06 AM, Josh Matthews wrote:
On Thu, Oct 9, 2008 at 3:56 AM, David Olofson wrote:
On Thursday 09 October 2008, Stefan Petrea wrote:
–
Stefan Petrea
homepage : http://perlhobby.googlecode.com/
mobile phone : (040) 0732070179
[…]
I stand corrected. 
Well then… Maybe it’s time for some good old printf() (or in this
case, cout) debugging? (Or step time debugging, if you prefer and
have nice tools.)
Get some printouts of various relevant data, and see if there’s some
obvious difference between the data for the last line and the others.
//David Olofson - Programmer, Composer, Open Source Advocate
.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
’-- http://www.reologica.se - Rheology instrumentation --'On Thursday 09 October 2008, Josh Matthews wrote:
Nope, container.end() is one past the last element.
[…]
In particular,some of the old squares remain drawn in the full row
that should disappear completely and if you click and drag the mouse
over them they are progressively erased.
Ah! I see…
Sounds like you’re removing the squares, but forgetting to refresh the
display in the case of empty squares. (From what I saw of the code,
it looked like you’re refreshing the whole window, but this suggests
you aren’t…)
Speed concenrns:
Also I think this particular method of drawing rectangles on the
screen is not very fast.
I think I should have drawn them on a SDL_surface and then blit that
to the screen ?
What is your oppinion on this ?
You’re using SDL_FillRect() now…? That should actually be faster
than SDL_BlitSurface(), unless you need to make “many” calls to the
former to render a single object that you can render with one call to
the latter.
Either way, in most cases, you’ll want rendered or hand drawn
graphics, which means you need to use surfaces and SDL_BlitSurface()
anyway. Make sure to use SDL_DisplayFormat() and SDL_RLEACCEL, and be
careful with alpha blending.
//David Olofson - Programmer, Composer, Open Source Advocate
.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
’-- http://www.reologica.se - Rheology instrumentation --'On Thursday 09 October 2008, Stefan Petrea wrote:
You’re using SDL_FillRect() now…? That should actually be faster
than SDL_BlitSurface()
is this true ???
I would expect a blitter to be hardware accelerated…
Well, that’s implementation dependent (backend and API), but
generally, if you have accelerated surface->surface blits, there will
also be corresponding accelerated solid color blits. These may be
implemented by blitting from a 1x1 source surface, or using a
simplified pipeline, so they should be at least as fast as blitting
from a “real” surface.
//David Olofson - Programmer, Composer, Open Source Advocate
.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
’-- http://www.reologica.se - Rheology instrumentation --'On Thursday 09 October 2008, jeroen clarysse wrote:
You’re using SDL_FillRect() now…? That should actually be faster
than SDL_BlitSurface()
is this true ???
I would expect a blitter to be hardware accelerated…
Nope, container.end() is one past the last element.
[…]
I stand corrected.
Well then… Maybe it’s time for some good old printf() (or in this
case, cout) debugging? (Or step time debugging, if you prefer and
have nice tools.)
Get some printouts of various relevant data, and see if there’s some
obvious difference between the data for the last line and the others.
Yes,that’s what I wrote in my previous message
I am printing out in console the configuration which I would expect to see
on screen,
however the screen shows different things.
(there is a print() method in Grid.cpp,that’s where it all happens,the
printf you suggested
I mean )On Thu, Oct 9, 2008 at 11:18 AM, David Olofson wrote:
On Thursday 09 October 2008, Josh Matthews wrote:
//David Olofson - Programmer, Composer, Open Source Advocate
.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
’-- http://www.reologica.se - Rheology instrumentation --’
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
Stefan Petrea
homepage : http://perlhobby.googlecode.com/
mobile phone : (040) 0732070179
[…]
In particular,some of the old squares remain drawn in the full row
that should disappear completely and if you click and drag the mouse
over them they are progressively erased.
Ah! I see…
Sounds like you’re removing the squares, but forgetting to refresh the
display in the case of empty squares. (From what I saw of the code,
it looked like you’re refreshing the whole window, but this suggests
you aren’t…)
Yes I am using SDL_UpdateRect to update,and also using SDL_Flip which I
understand
is used for the same thing(refreshing parts of the SDL_screen object).
However,there is something that I would like to describe.
The Move() routine for a piece is first erasing the square,by that meaning
SDL_FillRect(some background color,black in this case) then switching to new
coordinates then it SDL_FillRect with the actual color of the square
Is there something wrong in the way Move() is working ?On Thu, Oct 9, 2008 at 11:28 AM, David Olofson wrote:
On Thursday 09 October 2008, Stefan Petrea wrote:
Speed concenrns:
Also I think this particular method of drawing rectangles on the
screen is not very fast.
I think I should have drawn them on a SDL_surface and then blit that
to the screen ?
What is your oppinion on this ?
You’re using SDL_FillRect() now…? That should actually be faster
than SDL_BlitSurface(), unless you need to make “many” calls to the
former to render a single object that you can render with one call to
the latter.
Either way, in most cases, you’ll want rendered or hand drawn
graphics, which means you need to use surfaces and SDL_BlitSurface()
anyway. Make sure to use SDL_DisplayFormat() and SDL_RLEACCEL, and be
careful with alpha blending.
//David Olofson - Programmer, Composer, Open Source Advocate
.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
’-- http://www.reologica.se - Rheology instrumentation --’
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
Stefan Petrea
homepage : http://perlhobby.googlecode.com/
mobile phone : (040) 0732070179
Speed concenrns:
Also I think this particular method of drawing rectangles
on the screen is
not very fast.
I think I should have drawn them on a SDL_surface and then
blit that to the
screen ?
What is your oppinion on this ?
Anything that requires moving data between main memory and video memory slows things down and SDL will be shifting hardware surfaces to main memory (making a copy or otherwise) and back for every single blit. If you’re blitting multiple images to separate parts of the display image then it’s best to make a software surface with the same configuration as the display surface and write everything to that before blitting it as a whole to the main surface or even locking both surfaces manually with SDL_MUSTLOCK (which brings a surface into main memory and does other things to make it safely writeable, not 100% sure this can be done with the display surface) and passing the pointers for the pixel arrays to something like memcpy.
That would, of course, require that the buffer surface has the exact same data format as the display surface or the result could be problematic.
Either way, using a back-buffer in main memory and only having the one actual transfer between main/video memory will always help with performance even if you do only use SDL_blitsurface, it’s a trick that’s been used pretty much since the x86 PC came out and now applies even to Macs.— On Thu, 10/9/08, Stefan Petrea <stefan.petrea at gmail.com> wrote:
From: Stefan Petrea <stefan.petrea at gmail.com>
Subject: Re: [SDL] buggy tetris game
To: “A list for developers using the SDL library. (includes SDL-announce)”
Date: Thursday, October 9, 2008, 8:13 AM
On Thu, Oct 9, 2008 at 11:06 AM, Josh Matthews wrote:
SDL-announce)"
Speed concenrns:
Also I think this particular method of drawing rectangles
on the screen is
not very fast.
I think I should have drawn them on a SDL_surface and then
blit that to the
screen ?
What is your oppinion on this ?
Anything that requires moving data between main memory and video memory
slows things down and SDL will be shifting hardware surfaces to main memory
(making a copy or otherwise) and back for every single blit. If you’re
blitting multiple images to separate parts of the display image then it’s
best to make a software surface with the same configuration as the display
surface and write everything to that before blitting it as a whole to the
main surface or even locking both surfaces manually with SDL_MUSTLOCK (which
brings a surface into main memory and does other things to make it safely
writeable, not 100% sure this can be done with the display surface) and
passing the pointers for the pixel arrays to something like memcpy.
That would, of course, require that the buffer surface has the exact same
data format as the display surface or the result could be problematic.
Either way, using a back-buffer in main memory and only having the one
actual transfer between main/video memory will always help with performance
even if you do only use SDL_blitsurface, it’s a trick that’s been used
pretty much since the x86 PC came out and now applies even to Macs.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Do you mean double-buffering ? or how is this called ?
Can you please give an example(code) of how this is done ?On Thu, Oct 9, 2008 at 3:21 PM, Paul Duffy wrote:
— On Thu, 10/9/08, Stefan Petrea <@Stefan_Petrea> wrote:
From: Stefan Petrea <@Stefan_Petrea>
Subject: Re: [SDL] buggy tetris game
To: "A list for developers using the SDL library. (includes
Date: Thursday, October 9, 2008, 8:13 AM
On Thu, Oct 9, 2008 at 11:06 AM, Josh Matthews wrote:
–
Stefan Petrea
homepage : http://perlhobby.googlecode.com/
mobile phone : (040) 0732070179