Re: I need advices to make a game with delphi 7.

From: Nicolás (nicolas_at_notvalid.com)
Date: 11/26/03 

Date: Wed, 26 Nov 2003 05:05:52 -0000

Hi,

Sorry for the delay, I had to fly to barcelona.

**Thanks a lot** for the detailed info, I catch it (almost all ;-), I've
saved the message for reference.

But I suck, xDD, if you have time and could teach me from raw, with a few
examples, just a maximized form, with a background image, a few other images
dispersed on some parts of the form, and a mouse-moving image (with some
transparents parts, like the rounded borders of a cardset) that respect w/o
flicker all the back while moving. Down of the message is what i'm doing for
the image-moving, sure its crap, xDD, but it works fine, lot of flicker for
sure.

If you have time only, i don't want to disturb anybody.
I think it could be interesting for the group.

Thanks a lot again.

And sorry again for my english, I learned it mainly watching "the
osbournes" tv show.

Greetings. []
soul_hass678assin@hotmail.com, remove the numbers.

-----

procedure TForm1.Image1MouseDown(Sender: TObject; Button: TMouseButton;
  Shift: TShiftState; X, Y: Integer);
begin
  down:=true;
  posx:=form1.left+x;
  posy:=form1.top+y+23; //the "+23" is my window upper bar height.
end;

procedure TForm1.Image1MouseMove(Sender: TObject; Shift: TShiftState; X,
  Y: Integer);
begin
  if down=true then
  begin
    Image1.Left:=mouse.CursorPos.x-(posx+4); //don't know the "+4" reason,
xDD, but if i dont add it I get a little jump at the start of the image
dragging.
    Image1.top:=mouse.CursorPos.y-posy;
  end;
end;

procedure TForm1.Image1MouseUp(Sender: TObject; Button: TMouseButton;
  Shift: TShiftState; X, Y: Integer);
begin
  down:=false;
end;

-----
Notes:

I've tested the "DoubleBuffered := true;" on FormCreate procedure, but the
results are very slow, even the mouse pointer gets out of the moving-image
if dragging fast.

The "TForm1.WMEraseBkgnd(var message:TWMEraseBkgnd);" procedure makes my
form transparent, and the moving-image paints it, like a stamp.

"Peter Below (TeamB)" <100113.1101@compuXXserve.com> escribió en el mensaje
news:VA.0000a700.0036afef@nomail.please...
> In article <3fc06e07@newsgroups.borland.com>, Nicolás wrote:
> > I have delphi 7, I want to make a cards game (a personal challenge),
> > probably a poker game, something easy to code (game core), but I'm
worried
> > about the flickering and graphics in general, the game will have an
image on
> > background, other images, and lot of objects (cards and other stuff),
and
> > they will move, dealing movement (x1y1 to x2y2), and dragging movement
(move
> > and place cards with the mouse), and some of them with transparent parts
> > (cards borders, etc.), and I want them to move smooth and without
flicker at
> > all, respecting all the images and other objects, and maybe some simple
> > effect on the dragging card, like a simple shadow effect or some change
on
> > the colour or palette of the card. But no idea the best way to make the
> > game, i don't want to use directx neither opengl, a "normal window"
using
> > objects, but no idea. ¿default gdi, some graphic component/s, gdi+...?.
I'd
> > like to inform me well before starting to write code, I don't want to
make a
> > bad move from the begining, advices will be gladly welcome.
>
> Please do not crosspost on these groups, select the most appropriate group
(in this case
> perhaps b.p.d.graphics) and post there only.
>
> The key to this is to use double buffering. You draw the whole scene to a
background
> TBitmap (background here meant as: not visible, only handled in code).
Then you draw
> the bitmap to the screen. I would in fact not even use a TImage as display
surface
> here but a TPaintbox. This way you control all the drawing, including
clearing (or not
> clearing) the images background. The latter is a major source of flicker,
so you
> want to avoid filling the display surfaces area with a background color
first. If it is
> covered completely by your image anyway there is no need to clear a
background.
>
> The animation works this way:
>
> create the next scene in the background bitmap
> call the paintboxes Refresh method (or Invalidate, see below)
> the paintboxes OnPaint event triggers and you draw the background
> bitmap on the paintboxes canvas there.
>
> There are tradeoffs to be made here. If you use the paintboxes Refresh
method
> the visible image will redraw immediately. If you do this while dragging a
sprite
> around with the mouse (sprite: movable element of the picture, like a
card) you
> may miss mouse move events. Windows does not accumulate mouse move
messages in the
> message queue, instead a new message replaces the last one still in the
message
> queue. If your drawing is too slow the movement will not be smooth since
you do not get
> to redraw on every point of the mouse trajectory. If you use Invalidate
instead of
> Refresh the image is not repainted immediately. Instead a paint message is
placed into
> the message queue and will be retrieved only when no other messages are in
the queue
> anymore. So, moving the mouse very fast, can cause the paint message not
to be
> executed since there are always mouse messages to be retrieved. The image
will only
> redraw when the mouse moves slow enough or stops moving. Paint messages do
also not
> accumulate in the queue, so the image will only redraw once. If you use
this mode it is
> very important to process the mouse messages as fast as possible, so you
would not
> compose a new background image on each move but only update the internal
coordinates of
> the moved object. You would compose the background image as part of
repainting the
> visible image in this case.
>
> The most important part in getting a smooth animation is to optimize the
drawing itself
> (in this case the drawing on your background bitmap mostly). Try to not
redraw the
> complete bitmap, redraw only the parts that have changed between the last
animation
> frame and the new one. If you move a sprite, for example, the movement
will uncover some
> part of the background and cover another part. You can handle the move
with two drawing
> operations: first copy a rectangular part of the background (that matching
the bounds
> rect of the sprite at the original position) to the old sprite position,
then draw the
> sprite at the new position. For large sprites this can be optimized
further by
> decomposing the area to redraw into a series of smaller rectangles: if you
move the
> sprite by dx and dy pixels you actually only have to repaint two
rectangular areas
> of size dx * heightofsprite and dy * widthofsprite of the background,
since the new
> sprite position will cover much of the old one anyway.
>
> > Sorry for my english, I'm spanish and I don't speak it very well.
>
> Don't worry, your english is OK. I've seen MUCH worse here <g>.
>
>
> --
> Peter Below (TeamB)
> Use the newsgroup archives :
> http://www.mers.com/searchsite.html
> http://www.tamaracka.com/search.htm
> http://groups.google.com
> http://www.prolix.be
>
>

Loading