Sounds like you put some serious work into your gamepack, but I don't
think that something as specialised as this should be a standard component.
Remember that it is only usefull for 2D games on old hardware as you can get
all of this (and some nice features more) by using OpenGL for your rendering.
All your gamepack can do can be done hardware accelerated on any card that
supports OpenGL 1.1 (this means really, really old gfx cards and most newer
integrated gfx chips, too).
But I have some questions regarding it nonetheless.
How do you handle sound, input (keys/mouse/gamepad/etc) and what timing method
do you use?
How many sprites can be used simultaneously with interactive framerates (30 fps
or more)?
Do your sprites support rotation and/or scaling?
Do your sprites support transparency and blending? If yes, what blending
functions?
Your case against gamepack is my case for it. If we're going to include
opengl, gamepack makes at least as much sense. And gamepack has some
VERY advanced features, and lacks some others.
So the best idea is to summarize by comparing to SDL (which is most like
it I think). Everything on this list is something SDL cannot (ever) DO.
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.
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.
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.
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.
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.
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. Like I said,
gamepack is built with lazarus components and works with them all the
way. It's a bit like opengl context in that it sits in a component
window, but much easier to do 2D games in because you can drag-and-drop
place everything in the form designer (you can also load from files so
you can always later change a setting).
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).
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.
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.
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.
Basically, I think that as it is now (about a week from the final 1.0
release which will contain tconstraintlist) it is one of the easiest and
most powerful games-coding toolkits around, comparable in capability to
things like alegra but with a far lower learning curve and much less
actual code of it's own since it can rely on LCL functionality to
provide the nuts and bolts.
As for specialized components, well I wouldn't suggest it be compiled
into the default lazarus package, but there are many good specialized
components which are shipped with it for users to install if they do
want it.
I am pretty proud of it, because I worked hard on it. I tried a bunch of
other graphics/gaming libs, and they ALL sucked - not to mention having
horrible fpc support at best. So I wrote my own that didn't.
I never even suggested it for inclusion in the past, simply because my
standards on it was very high. Even now I would, if it was accepted,
prefer to wait until I finish the collision detection code because I
would really love for that to be a standard feature right from the start.
I would not have suggested it if I didn't think that others might find
it useful - or for that matter if it was shoddy code I couldn't proudly
put on display to some people with very high standards.
Anyway, I think I explained now what makes it special in depth. Either
the dev's will think it's cool, or they won't. I won't feel bad if they
don't - it's their prerogative, but at least let it be judged fairly.
Ciao
A.J.
--
"Any sufficiently advanced technology is indistinguishable from magic" -
Clarke's law
"Any technology that is distinguishable from magic is insufficiently
advanced" -Gehm's corollary
"Any technologist that is distinguishable from a magician is
insufficiently advanced" - My corollary
The worlds worst webcomic: http://silentcoder.co.za/scartoonz
The worlds best cybercafe manager: http://outkafe.outkastsolutions.co.za
begin:vcard
fn:AJ Venter
n:Venter;AJ
org:Global Pact Trading Pty. Ltd.;OutKast Solutions
email;internet:[EMAIL PROTECTED]
title:Director of Product Development
tel;work:+27 21 554 5059
tel;fax:+27 11 252 9197
tel;cell:+27 83 455 9978
url:http://www.outkastsolutions.co.za
version:2.1
end:vcard
