Menu
▾
▴
kgb-developer
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
(15) |
May
(4) |
Jun
(2) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
|
Feb
(4) |
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
|
From: Jone M. V. <vi...@ns...> - 2001-09-05 21:35:58
|
Well, things are actually starting to happen with KGB2. I've started fleshing out some of the basic classes, but theres nothing resembling a demo or anything yet. I've decided to use libxml++ instead of libxml (libxml++ is just a c++ wrapper around libxml) because it will make things a whole lot easier. I am still a bit confused as to what I am going to do about the equivalent of the KGB_ConfNode in KGB2, but one thing is sure, I will get rid of the meta-structural information that was necessary in KGB. Anyhow, I just though I should give you all an update (long time, no see to all (both) of you). Hope you're having a nice time in the USA, akawaka (wow - a professional game-developer!). BLiP! from inful |
|
From: Jone M. V. <vi...@ns...> - 2001-09-05 21:29:39
|
Just testing |
|
From: Jone M. V. <vi...@ns...> - 2001-07-06 12:17:43
|
On Friday 06 July 2001 14:10, Jone Marius Vignes wrote: > I have imported a new module into cvs. This is the feeble ... > a redesign of KGB (Yup, it just had to happen). Not much i... > thought I should do the "release early, release often" thing. > If you have any suggestions, wishes etc. for kgb2 - please let me hear > them. > > inful > ...actual announcement follows: I have imported a new module into cvs. This is the feeble start of a redesigned KGB (Yup, it just had to happen). Not much in there yet, but I thought I should do the "release early, release often" thing. If you have any suggestions, wishes etc. for kgb2 - please let me hear them. grumble... |
|
From: Jone M. V. <vi...@ns...> - 2001-07-06 12:11:22
|
I have imported a new module into cvs. This is the feeble ... a redesign of KGB (Yup, it just had to happen). Not much i... thought I should do the "release early, release often" thing. If you have any suggestions, wishes etc. for kgb2 - please let me hear them. inful |
|
From: Randy T. <rt...@un...> - 2001-03-23 18:01:36
|
Please send me an e-mail, I am looking for Guru's in Unix - out of the box developers and engineers as well as system admin's and more. I am not a third party. I do not work with third parties. I am coming to you direct. Please let me know if you have an interest or please forward me on to friend. All my best, Randy Taylor Undoo Technologies 949/743-5133 |
|
From: Jone M. V. <vi...@ns...> - 2001-03-07 14:44:29
|
Well, it's time to harass you again with some news from the cvs-repository. KGB_VectorMovement now has the base functionality I allways wanted, and stuff seems to suddenly turn trivial:) If you take a look at test/movement, you'll find to new movement-patterns used, namely KGB_PointGravityMovement and KGB_GravityMovement. Fun stuff! Akawaka asked for a timeeventhandler, so he got it. You can now fire events at specified intervals (N times or forever) and let objects react to them by subclassing the KGB_TimeeventHandler. Have a look at test/movement to see this in action as well. ..and btw: I fixed a very annoying bug in KGB_LinearInterpolationMovement Have fun! BLiP! |
|
From: Jone M. V. <vi...@ns...> - 2001-03-05 11:39:15
|
Another weekend gone by, and here is the recent changes in KGB:
Moved KGB_Mask *getMask and KGB_Mask *mask into KGB_Surface, as that is where
it belongs (we create it here, not in KGB_BaseSurface - alas: KGB_BaseSurface
should not even know of KGB_Mask's existence).
Added the following functions to KGB_BaseSurface:
Uint32 getFlags();
SDL_PixelFormat *getPixelFormat();
Uint16 getPitch();
SDL_Rect getClipRect();
Removed KGB_PixelWriter, and shoved the functionality into KGB_PixelSurface
(which will eventually supercede KGB_Surface).
Finished Timebased frame-animation (it now works for all KGB_Sprites using
the same KGB_SurfaceFactory).
Removed test/primitives from the compile-line until I've found a good way to
buffer pixelwrites.
Prefect and inful did some memleak-hunting, and squashed one or two of those
(IIRC). We do however suspect libxml of containg memleaks, but this won't be
checked until I get around to compile a debug-version of libxml.
Well then, have a nice day, and remember to do a cvs update:)
BLiP!
|
|
From: Jone M. V. <vi...@ns...> - 2001-02-22 11:39:09
|
I have added several new movement-patterns to cvs: KGB_LinearInterpolationMovement: used to move objects to a specific coordinate within a given timeframe (constant speed) KGB_EaseInOutMovement: used to move objects to a specific coordinate within a given timeframe using the ease in/ease out pattern KGB_InvertedEaseInOutMovement: used to move objects to a specific coordinate within a given timeframe using an inverted ease in/ease out pattern. All of the above movement-patterns are time-interpolated, and will move decoupled from the framerate of the target machine. check it out:) BLiP! |
|
From: Jone M. V. <vi...@ns...> - 2001-02-13 11:53:54
|
Hi, everybody;)
Here's the news from the cvs-trenches:
Introduction of KGB_Singleton: a template-based singleton class that
implements objects inherited from it as singletons. This has been the fate of
KGB_Game and KGB_Time, as these two only should have one instance in a game,
and it simplifies the interface to some other classes constructors.
ex:
KGB_SurfaceFactory("name", game->getConfNode(), game->time) has changed into
KGB_SurfaceFactory("name", game->getConfNode()), and is going to end up as
KGB_SurfaceFactory("name") when I am completely done with this transition.
We also now have time/frame based animation of surfaces. To use this feature,
insert a new value (dTime) in the xml-definition of Surface like this:
<Surface ObjectName="frame1" FileName="gfx/ball-1.png" dTime="10"/>
dTime means displaytime, and is measured in 1/1000 seconds. Watch out, as
this is a minimum-value displaytime e.g. you are guaranteed that the surface
is displayed dTime. I am not sure if we should implement a max-time as well.
Speak up if you think so.
KGB_Game no gets it background-surface from an xml-definition of a
SurfaceFactory with ObjectName="background". This is the first waypoint in
making the background behave as a normal SurfaceFactory, and should
eventually make it possible to write custom scrolling/tiled etc. backgrounds.
I have also cleaned out some memoryleaks, but there are still issues with,
amongst aothers, KGB_ConfNode. If anybody cares to take a look at this
(prefect:)), please do so.
Plans for the coming days: I want to do some rigid-body physics, clean up the
collisionhandling, maybe a finite-state machine class, and I would like to
take a look at sound (it's about time). There are also some weeding to be
done to the sources, as there are classes that are not used anymore, but are
still present in the repository.
If you have any suggestions, please use this list.
...and last, but not least: do a cvs update -d, and check if everythings
working.
btw. After correcting a bug in the EventHandling-code, KGB now compiles as a
shared library again.
Have a nice day!
inful
BLiP!
|
|
From: Jone M. V. <vi...@ns...> - 2001-02-07 22:58:15
|
There has been some extensive changes in KGB_MatrixFactory, KGB_Matrix and KGB_VectorMovement. Take a look at test/movement to see how it is used. phewton is up and running again after adding KGB_NoMovement and implement the rather weird movement of phewton as a subclass of KGB_DiscreteMovement. Please do a cvs update and check out the changes. Have a nice day:) |
|
From: Jone M. V. <vi...@ns...> - 2001-02-06 10:03:14
|
Just commited some changes I've done to KGB_MovementFactory. KGB_MovementFactory now only works as a wrapper around KGB_Movement, and KGB_Movement is just a base-class for the real movement-classes. I have implemented two types of movement for now: KGB_BasicMovement, which provides smooth time-interpolated animation and KGB_DiscreteMovement, which provides discrete movement-steps bound to timelapses (hope that explains what I mean). The new structure breaks some of the tests, and I am in the process of fixing these. If you want to have a look at what has been done, do a cvs update and take a look at test/movement. Looks like I'm finally getting things done:) BLiP! |
|
From: Jone M. V. <vi...@ns...> - 2000-09-01 15:22:31
|
Well, there haven't been much traffic on this mailinglist, but I'll try to grab your attention anyway... I have been thinking about how we should control the rapid (;)) evolution of KGB. Would it be an idea to finalize the current featureset in KGB, document it thoroughly, write some small example games, and then release it as a stable version. This way I think we might grab some attention, as the current featureset isn't too big, and it solves some of the problems most newbies have when starting out with SDL. We could market it as a sprite/animation/blitter/collision-detection library, tag it 1.0 (eventually -we still have some/a-whole-lot-of bugs lurking in there), and start adding features if people actually use it? Writing small games will also help us iron out bugs/interface-inconcistencies and such. What do you say? BLiP! |
|
From: Martin D. <ak...@cs...> - 2000-06-04 15:06:41
|
The only plus point for SDL_net is that it's platform independent. gltron had a hard time with it I think. On Fri, 2 Jun 2000, Jone Marius Vignes wrote: > In my pursuit of making BlockHeads an enjoyable game, I am now trying to add > networking to it (nope, it's not currently playable, I've got 95% of the > game-logic working, and I am about to rewrite the whole thing to be more > generic (support N-players and a self-contained client/server architecture)). > I am currently not sure wether I should create some networking classes for > KGB, if we should depend on an external library or if we should use SDL_Net > (which I've never got to test because it won't compile on my system). I am in > no way a seasoned network programmer, so I fear a rapidly changing interface > for the classes I am working on. Do any of you people have a point of view on > this? > > BLiP! > > _______________________________________________ > Kgb-developer mailing list > Kgb...@li... > http://lists.sourceforge.net/mailman/listinfo/kgb-developer > Martin -- Bother, said Pooh as he cut open a Tauntaun. |
|
From: Jone M. V. <vi...@ns...> - 2000-06-02 09:06:14
|
In my pursuit of making BlockHeads an enjoyable game, I am now trying to add networking to it (nope, it's not currently playable, I've got 95% of the game-logic working, and I am about to rewrite the whole thing to be more generic (support N-players and a self-contained client/server architecture)). I am currently not sure wether I should create some networking classes for KGB, if we should depend on an external library or if we should use SDL_Net (which I've never got to test because it won't compile on my system). I am in no way a seasoned network programmer, so I fear a rapidly changing interface for the classes I am working on. Do any of you people have a point of view on this? BLiP! |
|
From: Martin D. <ak...@cs...> - 2000-05-29 15:13:17
|
Agreed On Mon, 29 May 2000, Jone Marius Vignes wrote: > I think we should bump the verion up to 0.1.3 and release a new tarball of > it. This is because I see that there are people downloading KGB every once in > a while, and I think they should get their hands on something that's somewhat > near what's going on in KGB atm. Either that, or we start releasing > cvs-snapshots? What do you guys think? > BLiP! > > _______________________________________________ > Kgb-developer mailing list > Kgb...@li... > http://lists.sourceforge.net/mailman/listinfo/kgb-developer > Martin -- Bother! said Pooh, as he was forced to watch Babylon 5. |
|
From: Jone M. V. <vi...@ns...> - 2000-05-29 08:01:24
|
I think we should bump the verion up to 0.1.3 and release a new tarball of it. This is because I see that there are people downloading KGB every once in a while, and I think they should get their hands on something that's somewhat near what's going on in KGB atm. Either that, or we start releasing cvs-snapshots? What do you guys think? BLiP! |
|
From: Jone M. V. <jon...@st...> - 2000-05-25 00:46:59
|
I just checked in KGB_Event, an eventHandler that I think is rather neat. Check out sprite.cpp to get an idea of how it works:) Hope you like it. BLiP! |
|
From: Martin D. <ak...@cs...> - 2000-05-09 17:24:52
|
i was just flicking through some of the classes and I was that some stronger naming conventions need to be laid down. For instance I think a "surface/surf/s/Surface" should refer to something dealing with not an SDL_Surface but operations involving surfaces *and* masks (KGB_Surface etc.) Image/image/i/img etc should refer to operations dealing with SDL_Surfaces. So getImage() should return an SDL_Surface while getSurface should return a KGB_Surface. Martin -- Bother, said Pooh as Al disappeared through the Door. |
|
From: Martin D. <ak...@cs...> - 2000-04-15 13:43:13
|
I was digging into KGB_AnimState last night when I realised that it's not
gonna work the way we planned. What we were aiming for was a KGB_AnimState
that would store pointers to SDL_Surface's along with the direction they
would the animated and what would happen when you reached the end of the
frames. The two main functions I had planned were:
int KGB_AnimState::animate(int lastFrame)
which returns the next frame in the sequence
and
SDL_Surface *KGB_AnimState::getFrame(int frame)
There are the KGB_AnimMotion types: KGB_DIRECT, KGB_CIRCULAR and
KGB_REVERSING.
The problem occurs with KGB_REVERSING. When a KGB_AnimState is in
KGB_REVERSING mode it moves backwards through the frames when it reaches
the end. However there is no way for the KGB_AnimState to know if it
should be reading the frames in reverse or forwards without setting the
direction variable in KGB_AnimState which would mess up anything else.
So now, each object will have to have its own KGB_AnimState, it'll only
add about 20 bytes to each sprite so i don't think it matters much
Long live the confused,
Akawaka.
--
Bother! A Pooh poo.
|
|
From: Martin D. <ak...@cs...> - 2000-04-12 12:57:13
|
i don't know, i'd be arguing for dimensions. While locations are easier to use, dimensions are more commonly used by sdl. On Wed, 12 Apr 2000, Jone Marius Vignes wrote: > Well, as SDL_Rect uses dimension, and KGB_Rect provides us with whatever, > maybe we should go with dimension, allthough I find it easier to work with > locations. > ----- Original Message ----- > From: "Martin Donlon" <ak...@cs...> > To: "Jone Marius Vignes" <vi...@ns...> > Cc: <kgb...@li...> > Sent: Wednesday, April 12, 2000 11:52 AM > Subject: Re: [Kgb-developer] Coordinates > > > > Question remains as to what we do with constructors. Which methid do we > > say is our default method? > > > > On Wed, 12 Apr 2000, Jone Marius Vignes wrote: > > > > > If we go with coordyStuffd(int x, int y, int w, int h), we should make > that > > > coordyStuffD(int x, int y, int w, int h) > > > This is according to the unwritten method-call guidelines which states > that > > > a call should look something like this: > > > createSomethingBig() > > > deleteMe() > > > die() > > > > > > I say we go for the coordyStuffD/coordyStuffL. (This will hopefully > avoid > > > some confusion) > > > > > > ----- Original Message ----- > > > From: "Martin Donlon" <ak...@cs...> > > > To: <kgb...@li...> > > > Sent: Wednesday, April 12, 2000 10:52 AM > > > Subject: [Kgb-developer] Coordinates > > > > > > > > > > Short little question. > > > > > > > > When defining functions that take a rectangular area as parameters > will we > > > > go with: > > > > > > > > coordyStuff(int x, int y, int x2, int y2) > > > > or > > > > coordyStuff(int x, int y, int w, int h) > > > > > > > > OR > > > > > > > > do we go with something like > > > > > > > > coordyStuffd(int x, int y, int w, int h) > > > > coordyStuffl(int x, int y, int x2, int y2) > > > > where l stands for locations and d stands for dimensions > > > > > > > > > > > > Long live the confused, > > > > Akawaka. > > > > -- > > > > Bother! said Pooh and lit another joint. > > > > > > > > > > > > _______________________________________________ > > > > Kgb-developer mailing list > > > > Kgb...@li... > > > > http://lists.sourceforge.net/mailman/listinfo/kgb-developer > > > > > > > > > > > > > _______________________________________________ > > > Kgb-developer mailing list > > > Kgb...@li... > > > http://lists.sourceforge.net/mailman/listinfo/kgb-developer > > > > > > > Long live the confused, > > Akawaka. > > -- > > Bother! said Pooh, as he puked all over Christopher Robin. > > > > > > _______________________________________________ > > Kgb-developer mailing list > > Kgb...@li... > > http://lists.sourceforge.net/mailman/listinfo/kgb-developer > > > _______________________________________________ > Kgb-developer mailing list > Kgb...@li... > http://lists.sourceforge.net/mailman/listinfo/kgb-developer > Long live the confused, Akawaka. -- Bother! said Pooh, as Jem'Hadar slid into the Hundred Acre Wood. |
|
From: Jone M. V. <vi...@ns...> - 2000-04-12 11:41:16
|
Well, as SDL_Rect uses dimension, and KGB_Rect provides us with whatever, maybe we should go with dimension, allthough I find it easier to work with locations. ----- Original Message ----- From: "Martin Donlon" <ak...@cs...> To: "Jone Marius Vignes" <vi...@ns...> Cc: <kgb...@li...> Sent: Wednesday, April 12, 2000 11:52 AM Subject: Re: [Kgb-developer] Coordinates > Question remains as to what we do with constructors. Which methid do we > say is our default method? > > On Wed, 12 Apr 2000, Jone Marius Vignes wrote: > > > If we go with coordyStuffd(int x, int y, int w, int h), we should make that > > coordyStuffD(int x, int y, int w, int h) > > This is according to the unwritten method-call guidelines which states that > > a call should look something like this: > > createSomethingBig() > > deleteMe() > > die() > > > > I say we go for the coordyStuffD/coordyStuffL. (This will hopefully avoid > > some confusion) > > > > ----- Original Message ----- > > From: "Martin Donlon" <ak...@cs...> > > To: <kgb...@li...> > > Sent: Wednesday, April 12, 2000 10:52 AM > > Subject: [Kgb-developer] Coordinates > > > > > > > Short little question. > > > > > > When defining functions that take a rectangular area as parameters will we > > > go with: > > > > > > coordyStuff(int x, int y, int x2, int y2) > > > or > > > coordyStuff(int x, int y, int w, int h) > > > > > > OR > > > > > > do we go with something like > > > > > > coordyStuffd(int x, int y, int w, int h) > > > coordyStuffl(int x, int y, int x2, int y2) > > > where l stands for locations and d stands for dimensions > > > > > > > > > Long live the confused, > > > Akawaka. > > > -- > > > Bother! said Pooh and lit another joint. > > > > > > > > > _______________________________________________ > > > Kgb-developer mailing list > > > Kgb...@li... > > > http://lists.sourceforge.net/mailman/listinfo/kgb-developer > > > > > > > > > _______________________________________________ > > Kgb-developer mailing list > > Kgb...@li... > > http://lists.sourceforge.net/mailman/listinfo/kgb-developer > > > > Long live the confused, > Akawaka. > -- > Bother! said Pooh, as he puked all over Christopher Robin. > > > _______________________________________________ > Kgb-developer mailing list > Kgb...@li... > http://lists.sourceforge.net/mailman/listinfo/kgb-developer |
|
From: Martin D. <ak...@cs...> - 2000-04-12 11:01:02
|
Question remains as to what we do with constructors. Which methid do we say is our default method? On Wed, 12 Apr 2000, Jone Marius Vignes wrote: > If we go with coordyStuffd(int x, int y, int w, int h), we should make that > coordyStuffD(int x, int y, int w, int h) > This is according to the unwritten method-call guidelines which states that > a call should look something like this: > createSomethingBig() > deleteMe() > die() > > I say we go for the coordyStuffD/coordyStuffL. (This will hopefully avoid > some confusion) > > ----- Original Message ----- > From: "Martin Donlon" <ak...@cs...> > To: <kgb...@li...> > Sent: Wednesday, April 12, 2000 10:52 AM > Subject: [Kgb-developer] Coordinates > > > > Short little question. > > > > When defining functions that take a rectangular area as parameters will we > > go with: > > > > coordyStuff(int x, int y, int x2, int y2) > > or > > coordyStuff(int x, int y, int w, int h) > > > > OR > > > > do we go with something like > > > > coordyStuffd(int x, int y, int w, int h) > > coordyStuffl(int x, int y, int x2, int y2) > > where l stands for locations and d stands for dimensions > > > > > > Long live the confused, > > Akawaka. > > -- > > Bother! said Pooh and lit another joint. > > > > > > _______________________________________________ > > Kgb-developer mailing list > > Kgb...@li... > > http://lists.sourceforge.net/mailman/listinfo/kgb-developer > > > > > _______________________________________________ > Kgb-developer mailing list > Kgb...@li... > http://lists.sourceforge.net/mailman/listinfo/kgb-developer > Long live the confused, Akawaka. -- Bother! said Pooh, as he puked all over Christopher Robin. |
|
From: Jone M. V. <vi...@ns...> - 2000-04-12 10:27:22
|
If we go with coordyStuffd(int x, int y, int w, int h), we should make that coordyStuffD(int x, int y, int w, int h) This is according to the unwritten method-call guidelines which states that a call should look something like this: createSomethingBig() deleteMe() die() I say we go for the coordyStuffD/coordyStuffL. (This will hopefully avoid some confusion) ----- Original Message ----- From: "Martin Donlon" <ak...@cs...> To: <kgb...@li...> Sent: Wednesday, April 12, 2000 10:52 AM Subject: [Kgb-developer] Coordinates > Short little question. > > When defining functions that take a rectangular area as parameters will we > go with: > > coordyStuff(int x, int y, int x2, int y2) > or > coordyStuff(int x, int y, int w, int h) > > OR > > do we go with something like > > coordyStuffd(int x, int y, int w, int h) > coordyStuffl(int x, int y, int x2, int y2) > where l stands for locations and d stands for dimensions > > > Long live the confused, > Akawaka. > -- > Bother! said Pooh and lit another joint. > > > _______________________________________________ > Kgb-developer mailing list > Kgb...@li... > http://lists.sourceforge.net/mailman/listinfo/kgb-developer > |
|
From: Martin D. <ak...@cs...> - 2000-04-12 10:00:39
|
Short little question.
When defining functions that take a rectangular area as parameters will we
go with:
coordyStuff(int x, int y, int x2, int y2)
or
coordyStuff(int x, int y, int w, int h)
OR
do we go with something like
coordyStuffd(int x, int y, int w, int h)
coordyStuffl(int x, int y, int x2, int y2)
where l stands for locations and d stands for dimensions
Long live the confused,
Akawaka.
--
Bother! said Pooh and lit another joint.
|
|
From: Martin D. <ak...@cs...> - 2000-04-10 11:24:02
|
i check it out. On Mon, 10 Apr 2000, Jone Marius Vignes wrote: > Do you know about any problems with doublebuffering in SDL? > I seem to remember we had some problems with it when we wrote the first > blitter, but I can't recall if it was us or SDL (probably us:)). > If not, I have no objections about moving bginfo into KGB_Blitter. > > > > Something that I was thinking about over the weekend is the matter of > > double buffering, should we always use it, or leave it up to the user to > > decide? Always enabling double buffering removes a problem I have with the > > current KGB_Sprite class. In a perfect world the dirty rectangle > > information (the saved background) would be stored in the blitter. If we > > always used double buffering, then the saved background information could > > easily be moved into the blitter module. > > > > _______________________________________________ > Kgb-developer mailing list > Kgb...@li... > http://lists.sourceforge.net/mailman/listinfo/kgb-developer > Long live the confused, Akawaka. -- Bother, said Pooh as he strafed the lifeboats. |
