Re: [lazarus] Wider use case for gamepack ?
On Fri, 1 Feb 2008 20:05:14 +0200 A.J. Venter [EMAIL PROTECTED] wrote: Background, background, background. I spent the previous 5 years of my life developing software to run on thin-client machines. My current major project is frequently used on them. In other words -less than 1% of MY userbase HAS openGL capable hardware. That's exactly what GamePack is good for. The same goes for many others, including those who are writting for embedded platforms. OpenES. ;) _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Wider use case for gamepack ?
Isn't GLScene good enough as an OpenGL wrapper ? Yes OpenGL ES exists for WinCE. Indeed OpenGL is powerful for both 2D and 3D and most cards support it to some level, however a native 2D engine independent of the other accelerated APIs could be used for many things not just games and with fast bitmap processing it could be an interesting combination, . From my experiments on windblows i noticed that drawing on window based controls is quite fast if you block the useless OS drawing, that is process paint messages and tell it that all drawing is made by you, 30 frames should not be impossible to achieve with CPU only. If we could also use the GPU power it is even better, i read somewhere that it is possible to use GPU for regular calculations and some proprietary drivers already have this ability to use the GPU as the CPU. Razvan _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Wider use case for gamepack ?
On Fri, 01 Feb 2008 08:52:12 +0200 A.J. Venter [EMAIL PROTECTED] wrote: 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? Special FX like particle systems, shots, etc. If you want to see what difference hw acceleration makes, take a look at chromium B.S.U. It is a nice, old 2D shooter and runs on any OpenGL card with more than 4MB RAM. Now imagine what you can do with nowadays cards. Okay I get it - you like using the graphics card :) Exactly. They are developed for doing nicer and faster graphics than CPU based rendering can achieve. If it is 2D or 3D doesn't matter, your gfx card can do it faster than the CPU and you have your CPU left for gamelogic and other stuff. And GPUs are standard in nowadays computers, so why not use them? It's easy enough and you can do it with FPC and Lazarus. 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. Lazarus does not contain an OpenGL wrapper. It offers a rendering context component and bindings to the API, that's a difference. 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. When it comes to graphics we have a very different definition of powerful. regards 666 _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Wider use case for gamepack ?
A.J., Don't worry about Beelzebub's negative comments, I've already noted that your gamepack has a valid place and that I have plans for using it exclusively in one of my projects. Who cares if it doesn't meet someone's expectations of what they want from a package that maximizes OpenGL-whatnots and GPU-excelerometebobs? It meets your expectations, and I've said it meets mine (exceeds it, actually), and I'm sure it will do so for others as well. -- _| () |-| |\| _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Wider use case for gamepack ?
On Fri, 1 Feb 2008 08:49:32 -0600 John Stoneham [EMAIL PROTECTED] wrote: A.J., Don't worry about Beelzebub's negative comments, What do you expect? I wasn't thrown out of heaven for nothing. :) And please forgive me for not living in the past. OpenGL accelerated desktops far beyond what compiz/aero/etc can do are the future. And I am not getting tired of promoting OpenGL. FPC works with OpenGL very nicely and can deliver high quality and high performance graphics as good as any C/C++ application. We just need to show this to the masses. You win people with eye-candy as Ubuntu has shown. Once again it is not against AJs GamePack (it has its purpose and target audience), but it is to show that nowadays graphics are done different than more than 10 years ago. Lord of Hell yadda-yadda-yadda _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Wider use case for gamepack ?
And please forgive me for not living in the past. OpenGL accelerated desktops far beyond what compiz/aero/etc can do are the future. And I am not getting tired of promoting OpenGL. FPC works with OpenGL very nicely and can deliver high quality and high performance graphics as good as any C/C++ application. We just need to show this to the masses. You win people with eye-candy as Ubuntu has shown. Once again it is not against AJs GamePack (it has its purpose and target audience), but it is to show that nowadays graphics are done different than more than 10 years ago. Background, background, background. I spent the previous 5 years of my life developing software to run on thin-client machines. My current major project is frequently used on them. In other words -less than 1% of MY userbase HAS openGL capable hardware. The same goes for many others, including those who are writting for embedded platforms (there is no reason why gamepack shouldn't work fine with lazarus for WinCE). Stating that there is a more modern technology for many uses, does not invalidate the use-case NOT met by that technology. We've had cars for over a hundred years... so why do people still ride bycicles ? Why are bycicles today so much more advanced than a hundred years ago ?Why did people keep researching, improving and refining a technology when there was another one that was so much more powerful ? Because it had a few small advantages that cars don't have (for starters, a 3 year old can learn to use a bycicle safely) - and while this may be a minority case, in over a century those use-cases have, if anything, INCREASED. So in the same spirit don't think developing 2D graphics suites in the age of 3D is a step back, it's merely a step forward in a different direction, for those times when you want to be somewhere else. Anyway, I've said my piece I think. No need to start a flamewar here. I'll be releasin 1.0 soon to the CCR whence it can follow it's own path. From now on though, I will only discuss it on the list when people have tecnical questions, or I want advice on solving technical problems., not in terms of the merit of it's existence. A.J. -- A.J. Venter Director of Product Development Tel.: +27 21 554 5059 Fax: +27 11 252 9197 Outkast Solutions IT www.outkastsolutions.co.za A division of Global Pact Trading Pty Ltd. www.silentcoder.co.za - Blog scartoonz.silentcoder.co.za - ScarToonz webcomic _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Wider use case for gamepack ? [LCL Keyboard handling discussion]
TForm only get's the events from the keyboard if KeyPreview is set, IIRC. Apparently it's not a good way to go because enforcing key preview on the form may spoil some other techniques or hinder existing programs from working. I hope someone having intimate LCL knowledge can jump in here and suggest a less intrusive approach... Well unless I receive it within a few hours :) I'm going to publish the code as I have it now. The fact there is a way to do it via the form (though if I was unaware of it previously) takes this from an urgent priority feature to a nice-to-have one. It may not be the perfect answer, but we can always try to find THAT later :) A.J. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Wider use case for gamepack ? [LCL Keyboard handling discussion]
Am Donnerstag, den 31.01.2008, 08:39 +0200 schrieb A.J. Venter: I haven't looked into the sources deeply, but can't you override some OnKeyXxx-methods to get the key events? I don't think there ARE any to overwrite- perhaps in the parent class for TCustomControl, but they aren't republished. If you use override though - you may as well rewrite them as you'll need to do the same work anyway - it doesn't solve the clutter-and-duplicate problem. Seems to be that way, I couldn't find them either (but I didn't search for hours or try to understand how it may work ;). If not, maybe hooking into the surrounding forms events would suffice. This was my first idea, but unfortunately, it doesn't work at all. The reason is that forms only get keyboard focus onActivate and even then they only keep it if there is no focusable components - else it's hardpassed to the component with focus preference. Running Form.SetFocus throws an exception (Form cannot take focus) - [why is it there if it cannot be called ?] If there is a way to make a form take keyboard focus to itself so it's keyEvents work even if there are focusable components on it then I haven't found it yet. TForm only get's the events from the keyboard if KeyPreview is set, IIRC. Apparently it's not a good way to go because enforcing key preview on the form may spoil some other techniques or hinder existing programs from working. I hope someone having intimate LCL knowledge can jump in here and suggest a less intrusive approach... Marc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Wider use case for gamepack ?
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 OpenGLSDL. 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
Re: [lazarus] Wider use case for gamepack ?
On Jan 30, 2008 1:00 AM, A.J. Venter [EMAIL PROTECTED] wrote: [...] 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. Well, *I* think it's very cool. In fact, when I get back around to my life-long pet project (a chess engine extraordinaire :) this will be the first library I look at for the board UI. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Wider use case for gamepack ?
John Stoneham wrote: On Jan 30, 2008 1:00 AM, A.J. Venter [EMAIL PROTECTED] wrote: [...] 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. Well, *I* think it's very cool. In fact, when I get back around to my life-long pet project (a chess engine extraordinaire :) this will be the first library I look at for the board UI. Thanks, it's nice to have a vote of confidence- a chess board will not even need half the features :) I finished the collisionDetection system today. Now only two things remain on my 1.0 TODO list. 1) The events from the colisionDetection, that's pretty easy, just set up some TNotifyEvents. 2) THIS is the tricky one so I would like some advice on how I should do it. TDoubleBuffer needs to have OnKeyDown,OnKeyUp and OnKeypressed events. Being a TCustomControl descendent, it doesn't have them - TControl does - but it doesn't have a paint handler. Basically - there is no component that has a paint handler that also handles key input. In the Delphi world people get around this by using callbacks and hooks. That's fine, if you are only on windows. Now sure, I could probably go put in a bunch of IFDEF's and try to emulate them on each of the widgetsets... but somehow I don't think that's the right way. The other way I can think of is to just code the keyboardEvents in, by copying and pasting from one of the components that do have it - that seems like clutter though - code duplication is never a good idea right. So is there a third way I haven't thought of ? I am very open to suggestions and I'm sure somebody here knows something I don't :) 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
Re: [lazarus] Wider use case for gamepack ?
On Jan 30, 2008 9:05 AM, A.J. Venter [EMAIL PROTECTED] wrote: 2) THIS is the tricky one so I would like some advice on how I should do it. TDoubleBuffer needs to have OnKeyDown,OnKeyUp and OnKeypressed events. Being a TCustomControl descendent, it doesn't have them - TControl does - but it doesn't have a paint handler. ... The other way I can think of is to just code the keyboardEvents in, by copying and pasting from one of the components that do have it - that seems like clutter though - code duplication is never a good idea right. How about a middle ground: create a new TKeyboardEvents unit using code from one of the components that already has it. Yes you will have the initial code duplication in creating the unit in the first place, but this would allow adding keyboard events to other controls simply by inheriting from the base class. In fact, this may be something that the LCL could use and incorporate itself in the future, if you get it working property. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Wider use case for gamepack ?
Am Mittwoch, den 30.01.2008, 17:05 +0200 schrieb A.J. Venter: Well, *I* think it's very cool. In fact, when I get back around to my life-long pet project (a chess engine extraordinaire :) this will be the first library I look at for the board UI. Me too, I'd like to play around and maybe do something useful (or funny :) with it. It could at least be put on the CCR if not into lazarus distribution itself. 2) THIS is the tricky one so I would like some advice on how I should do it. TDoubleBuffer needs to have OnKeyDown,OnKeyUp and OnKeypressed events. Being a TCustomControl descendent, it doesn't have them - TControl does - but it doesn't have a paint handler. Basically - there is no component that has a paint handler that also handles key input. In the Delphi world people get around this by using callbacks and hooks. That's fine, if you are only on windows. Now sure, I could probably go put in a bunch of IFDEF's and try to emulate them on each of the widgetsets... but somehow I don't think that's the right way. The other way I can think of is to just code the keyboardEvents in, by copying and pasting from one of the components that do have it - that seems like clutter though - code duplication is never a good idea right. So is there a third way I haven't thought of ? I am very open to suggestions and I'm sure somebody here knows something I don't :) I haven't looked into the sources deeply, but can't you override some OnKeyXxx-methods to get the key events? If not, maybe hooking into the surrounding forms events would suffice. Marc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Wider use case for gamepack ? [LCL Keyboard handling discussion]
Me too, I'd like to play around and maybe do something useful (or funny :) with it. It could at least be put on the CCR if not into lazarus distribution itself. That may be a good start. I'll submit it to the CCR as soon as I finish 1.0 Please note I combined two posts below: How about a middle ground: create a new TKeyboardEvents unit using code from one of the components that already has it. Yes you will have the initial code duplication in creating the unit in the first place, but this would allow adding keyboard events to other controls simply by inheriting from the base class. In fact, this may be something that the LCL could use and incorporate itself in the future, if you get it working property. I'm not sure about this one - as it would mean anything that needs keyboardevents cannot be descended from anything else (e.g. a customControl or it's descendents like tpicture). However it might be possible to create a small component TKeyboardListener or something that DOES have these events, can take focus but isn't actually VISIBLE(is this last bit possible ? Perhaps if you hardcode it's width and height properties to be locked to 0) . Then anybody who needs to capture keyEvents globally would be able to drop one on a form and use it, and components like TDoubleBuffer could just instantiate one (or hook into one through a property - perhaps better). This would actually I think be an incredibly useful GENERAL add-on to the LCL as it would create a platform independent way of doing what windows coders do with callbacks and hooks. Somebody with deeper LCL knowledge want to comment on this ? I haven't looked into the sources deeply, but can't you override some OnKeyXxx-methods to get the key events? I don't think there ARE any to overwrite- perhaps in the parent class for TCustomControl, but they aren't republished. If you use override though - you may as well rewrite them as you'll need to do the same work anyway - it doesn't solve the clutter-and-duplicate problem. If not, maybe hooking into the surrounding forms events would suffice. This was my first idea, but unfortunately, it doesn't work at all. The reason is that forms only get keyboard focus onActivate and even then they only keep it if there is no focusable components - else it's hardpassed to the component with focus preference. Running Form.SetFocus throws an exception (Form cannot take focus) - [why is it there if it cannot be called ?] If there is a way to make a form take keyboard focus to itself so it's keyEvents work even if there are focusable components on it then I haven't found it yet. 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
Re: [lazarus] Wider use case for gamepack ? [LCL Keyboard handling discussion]
Am Donnerstag, 31. Januar 2008 07:39 schrieb A.J. Venter: [...] If not, maybe hooking into the surrounding forms events would suffice. This was my first idea, but unfortunately, it doesn't work at all. The reason is that forms only get keyboard focus onActivate and even then they only keep it if there is no focusable components - else it's hardpassed to the component with focus preference. Running Form.SetFocus throws an exception (Form cannot take focus) - [why is it there if it cannot be called ?] If there is a way to make a form take keyboard focus to itself so it's keyEvents work even if there are focusable components on it then I haven't found it yet. Isn't TForm.KeyPreview meant for exactly this purpose? Just set it to true and your form should get the KeyEvents regardless of which component has the focus .. off course this still only works if the form is active .. regards Burkhard _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
RE: [lazarus] Wider use case for gamepack ?
What's the URL? -Original Message- From: A.J. Venter [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 29, 2008 7:56 AM To: lazarus@miraclec.com Subject: [lazarus] Wider use case for gamepack ? Hi all, I've been working on my gamepack component package for a long time (nearly 4 years now) and it's quite a nice set. Not perfect of course, but it's two components for gametype graphics do work very nicely. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Wider use case for gamepack ?
On Tue, 29 Jan 2008 16:55:59 +0200 A.J. Venter [EMAIL PROTECTED] wrote: The components are fully documented and an example is included, also my tappytux game was written using it and I will soon start working on a loderunner clone using it as well. My question then is whether other people are interested in these lgpl'd components. If so, would you like it to be included with lazarus ? I will happily contribute it if people want it. 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? regards The Lord of Hell, Master of Darkness and so on ... _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Wider use case for gamepack ?
Am Dienstag, den 29.01.2008, 16:55 +0200 schrieb A.J. Venter: Hi all, I've been working on my gamepack component package for a long time (nearly 4 years now) and it's quite a nice set. Not perfect of course, but it's two components for gametype graphics do work very nicely. [...] My question then is whether other people are interested in these lgpl'd components. If so, would you like it to be included with lazarus ? I will happily contribute it if people want it. I'd be using it, if this components would allow me for a not so game-type solution: Is it possible to draw some shape and connectors in visio-style having text entires inside a border and arrange using some sort of (semi-automatic, self written) layout algorithm? Think of making a class diagramm, some rectangular shapes with separation lines and texts, some (rectangular or not) connector lines and such. Or some other UML-type diagrams like state charts or so. Some of those diagrams would benefit from showing animated graphics and thus your components are interesting. How about something like those two-color-spiral-progress bars, I think thunderbird use[s|d] sth. like that? Regards, Marc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Wider use case for gamepack ?
I'd be using it, if this components would allow me for a not so game-type solution: Is it possible to draw some shape and connectors in visio-style having text entires inside a border and arrange using some sort of (semi-automatic, self written) layout algorithm? Well there isn't such an algorithm, but if since you can directly use or even blit from any component (depending on need) with gamepack (see my other post) you will find it quite easy to have it do your drawing for you. Think of making a class diagramm, some rectangular shapes with separation lines and texts, some (rectangular or not) connector lines and such. Or some other UML-type diagrams like state charts or so. I don't see anything you couldn't build on it, since this was not my design you'd need to write some event handling code and some drawing code but gamepack will let you do your diagrams nicely I think. And then, if you want to print them, well you just stream TDoubleBuffer.Membuff.Canvas to TPrinter.Canvas. Some of those diagrams would benefit from showing animated graphics and thus your components are interesting. How about something like those two-color-spiral-progress bars, I think thunderbird use[s|d] sth. like that? Easy as pie. That last part is what gamepack is really good at - in fact, that's what it was good at 3 years ago :). 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
Re: [lazarus] Wider use case for gamepack ?
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
