On Wed, 30 Jan 2008 09:00:38 +0200
"A.J. Venter" <[EMAIL PROTECTED]> wrote:
First of all, I never wanted to bash your components and I think the CCR is a
good place for them. I just don't think that it should be shipped with lazarus.
And you have every right to be proud of your work.
> 1) Firstly, EVERYTHING is done with lazarus native calls and components
> - this means you don't need any issues getting buttons to show or menu's
> design with SDL or anything - whatever you need you just add next to the
> game window. TSprite is a TCustomControl descended, TDoubleBuffer is
> descended from TBitMap.
Very amazing, considering that it is written with Lazarus in FPC.
> 2) As a result of 1, things like image scaling is already there - just
> use the same calls you would have used before to manipulate the sprite
> in ram before blitting.
And as a result of 1 blending misses.
> 3) Framerates are hard to work out actually as the system is
> update-on-change so the nature of the game has a massive impact. BUT
> because of the way it works- the number of sprites have no impact
> whatsoever on framerates. Each sprite blits when it's changed, and when
> you've made all the changes you want to show, you flip. This means the
> 'framerate' is whatever you need. If you flip too much you will
> seriously abuse the CPU - but you will be hard pressed to get flicker -
> that's a case of a good design.
Sounds good, only that the CPU instead of the GPU is doing the graphics work is
so old school. Btw how do you asure that a games runs at the same speed on
different machines if you don't measure/have a framerate?
> 4) Lazarus native event handling - e.g. there is NO need for me to
> handle key/mouse events- lazarus does, and any device that works with
> lazarus toolkit you're using on the OS you are using will ALSO work.
That's what I am using, too, at the moment and I am not really impressed. You
can get mouse and more or less key input but that's it.
> 5) Design your game screens using the form designer.
> 6) Sprites and backgrounds can be stored in resources or loaded at
> designtime.
> 8) TSpriteMover a component that connects to a sprite and a doublebuffer
> and handlles 'correct' game movement FOR you. You can use multiple
> instances as well. It can (if you want) do gamescreen constraint
> allready. It supports full 8-directional movement using
> toggle-to-go-toggle-to-stop and prevents impossible concepts like left
> AND right at once. AND it handles animating the sprites, including
> playing different sets of frames for each direction (again, you can
> configure this).
> 9) But it does NOT actually repeat itself, you call TSpriteMover.Move to
> move the sprite a configurable distance of pixels in the direction(s)
> you have active.
Sounds ok, but I don't consider this a killer feature. More complex games
demand a level editor nonetheless.
> 10) Answering another question: the timer I use in my games is ttimer,
> but you can use a tthread or anything else that works in lazarus. If you
> want serious acuracy epiktimer will work just as well.
In my tests I came to the conclusion, that epiktimer is the only usable timer
(very nice component), as the other timing methods seriously lack accuracy.
<snip>
> 11) Very nearly complete is my latest component TConstraintList which
> lets you store a list of TRects. SpriteMover will (if you have
> constrained motion on) refuse to enter any of the areas on the
> double-buffer represented by the coordinates of these trects - any or
> all of them. And when it 'bump's into one will trigger an event. Whats
> more it will be able to determine whether the collision was:
> -edge of screen
> -An arbitrary area in the list
> -An area containing another sprite
> And throw different events. That's right LAZARUS events, so you can
> immediately do anything you want, including updating other components
> outside the gamearea - from the coder's point of view, handling
> collision detection in his game is no more difficult than handling the
> onClick event of a tbutton.
> Just think a little about the power this gives a game designer. My
> little demo app is nearly a little pacman game - in SDL that would need
> about 15000 lines of new code. In GamePack - I have written less than
> 200 lines (in the demo itself, not in the units).
Ease of use is always a good thing. But the power you give the game designer
comes with the drawback that he can put his graphics card in sleep mode.
> 12) Because it uses lazarus components, you can put other components on
> top of the gamearea, and you can allow sprites to move across one
> another in a pseudo 3D way (remember the old siera games?) - but there
> is no need to create a complex mapfile overlay to do it - just adjust
> the ZOrder of the components (be they sprites or buttons) to put what
> you want on top.
ZBuffers are standard in hw accelerated rendering. Meaning you get this out of
the box with OpenGL. And not only in pseuodo but in real 3D if you like.
> 13) And all this with remarkably little overhead - the worst part is the
> ram to store loaded images - but if you're a little smart, even that is
> small.
If you are even smarter the images are stored in the RAM of your graphics card.
> 14) You asked about sound - I don't handle it, I leave that to OTHER
> lazarus native components like ACS which are specialized for the task
> and ergo much better at it than any games library could be.
I always wanted to try ACS but never did. Sounds like you can recommend it.
If I find the time I give your gamepack a try.
But please remeber that OpenGL<>SDL. They have nothing to do with each other
except that SDL provides a wrapper for the OpenGL API.
Keep coding.
Satan
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
