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.
Fair enough. I didn't think it was being bashed, just that I needed to
explain their purpose and features.
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.
I'm not sure what you mean by this. This is a toolkit for 2D games, like
pacman or animated scenes in your app. Tilebased games etc. work fine,
why do you need blending in this environment?
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?
Not everybody HAS a gpu. Even if everybody did, that's not my target
audience or developer.
I use a ttimer to handle all the screen updates, on each timer the
user's character sprite is moved as per his request, ditto the game
character sprites - and finally we flip the buffers - so in a sense
there IS a fixed framerate - since there is a fixed number of screen
updates per second- but it can be intercepted by other events if needed.
In the openGL type idea though where you repaint as often as possible -
there isn't really 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.
Sounds ok, but I don't consider this a killer feature. More complex games
demand a level editor nonetheless.
True enough, and that is easy to write and load, but having onscreen
design makes it easier to write the game that will load the level editor.
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.
TTimer worked for me - but then at 41ms you'r close enough to 25FPS. It
depends on your game.
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.
This is only a drawback if he has one.
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
I merely pointed out that you can do what siera did without the
complexity of code. If you want real 3D then you use opengl, if you want
to write a clone of kings quest, you use gamepack.
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.
Okay I get it - you like using the graphics card :)
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.
I am well aware that SDL <> OpenGL - that is why I compared my suite to
SDL and NOT to openGL. It isn't OpenGL nor is it meant to be. We already
HAVE an OpenGL that works wonderfully. This is a toolkit that's meant to
do the same work the SDL does when you do NOT use the OpenGL wrapper. I
also don't intend to add an OpenGL wrapper to gamepack since the
environment it's created for (Lazarus) already contains one. The reason
people use SDL with OpenGL is to tap into it's event handlers and such -
since they are no longer using it's graphics features. This wouldn't
make any sense in GamePack as gamepack is JUST the graphics
features(specifically it's THOSE graphics features that are NOT already
in lazarus - like a twin-buffer screen) and some powerful utility
components to automate blitting and motion controlls.
--
"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
