Developers Corner

by Shockie on 10/19/2002 16:36, 279 messages, last message: 02/04/2006 13:50, 114194 views, last view: 12/09/2021 04:22

i would like to have this thread for development problems/ideas, and what people have done. i believe it could be quite useful!

   Board Index   

#221: Re: md2 file format

by Thalion on 07/26/2003 20:00, refers to #220

Since it doesn't contain any patented algorithms, I don't see any problems. Unless of course you LZW-compress it. =)

reply to this message

#222: Re: md2 file format

by Aardappel on 07/28/2003 10:15, refers to #220

actually, I think that would be illegal. it's just that id software has been so reasonable not to sue anyone yet :)

reply to this message

#223: Re: md2 file format

by Fish HF on 07/28/2003 12:34, refers to #222

i wonder did milkshape3d got a license from id software....

reply to this message

#224: Re: md2 file format

by D.plomat on 07/28/2003 13:50, refers to #223

I suppose not, but as they help create hype and content for id software games, it's some tolerance.
For using them in developping a commercial game, maybe if your game was takin'em large market shares, maybe their attitude would be different, but in this case i sure hope you'd buy a licence from them, or develop your own models format ;)

But, can file formats be patented? i first thought it was algorythms that were necessary to use them that could be, but not file formats themselves, in this case OpenOffice itself would be illegal.

Also you've to be careful with models themselves, some are totally free, others free for non-commercial use, some are trademark movie/anime characters, and some are modifications of original Q2 models, so for them you'd better not include them in a commercial game without a license ;)

reply to this message

#225: Re: md2 file format

by Aardappel on 07/29/2003 09:39, refers to #223

I don't know the details. I remember reading however that this is at least in theory illegal (using md2s for a commercial game, this is different than writing an editor). Though seeing the amount of engines out there supporting md2, and the fact that its an outdated format, I doubt id cares in the least.

reply to this message

#226: Re: md2 file format

by Thalion on 07/29/2003 11:22, refers to #225

I don't see how it can be illegal unless id owns a patent... and do they? Besides, I don't think you can get a patent for a file format (in GIF case, algorithm was patented, not the format itself). Unless you're in US, of course, and even then it would be US-wide only.

Oh, then maybe "md2" extension itself is copyrighted? =)

reply to this message

#227:

by bob on 07/30/2003 01:20

I\'m no expert, but I\'m pretty sure that in the US at least you can patent anything and everything man made, if not more.

With GIFs, they probably made the format publicly available so that things like browsers can use them.

reply to this message

#228: Re: legal

by spentron-postcrash2 on 07/30/2003 02:41, refers to #227

id is publically against software patents -- this and the rate of progress is probably an influence in preventing this obstacle to free progress in the games industry. Of course they still like to make money.

Info is probably to be found associated with the tools used to create the models (is this an id tool?), modified (reduced) by the terms of the source code release. Interpretation is significant.

reply to this message

#229: Re: legal

by Thalion on 07/30/2003 09:07, refers to #228

Hmph. Even if they really patented it in US (although I don't think Carmack would like that any more than we do), I couldn't care less. Luckily, I'm not living in the States (and hopefully will never be).

reply to this message

#230: Re: md2 file format

by Fish HF on 07/30/2003 12:20

maybe in the end, when u made a commercial game and used md2, even id doesnt like it, you already got the money to make id happy lol

i wonder if someone got bsp in cube..

reply to this message

#231: Re: BSP

by Thalion on 07/30/2003 21:15, refers to #230

WHY???

To quote: "this is beyond heresy and into blasphemy!" [Gareth Williams, "A Dark, Distorted Mirror"]

=)

reply to this message

#232: Re: BSP

by pushplay on 07/30/2003 23:36, refers to #231

If you wanted to learn about how the BSP file format works, that would be a good way to do it.

reply to this message

#233: Re: BSP

by Thalion on 07/31/2003 10:50, refers to #232

Just not in Cube, please...

reply to this message

#234: Re: BSP

by pushplay on 07/31/2003 13:37, refers to #233

No one's going to force you to play somebody's weird bsp using Cube version.

reply to this message

#235: Re: BSP

by Thalion on 07/31/2003 19:27, refers to #234

Well, it won't be Cube then, right?

reply to this message

#236: Re: BSP

by pushplay on 08/01/2003 00:08, refers to #235

No more than Quad is Cube.

reply to this message

#237: Weighted projectiles and gluUnproject()

by D.plomat on 08/01/2003 00:38

I'm implementing projectiles with not-straight path (ie grenades).

I first tried by using p->to as velocity vector, and in moveprojectiles():
p->to.z-=p->weight/time;
vec v=p->to;
vmul(v,time); vmul(v,p->speed); vdiv(v,100000);
vadd(v,p->o);

This was working, but there was a small difference in the path depending on fps, this must be due to approximation errors in the first line that are amplified on each frame, and/or the fact that the velocity vector is updated more often on higher fps.
I've solved this by pre-calc the projectile path in newprojectile() and storing in vec* p->projpath[200], using in moveprojectiles:

int inter = (lastmillis-p->launchtime)%50;
int seq = (lastmillis-p->launchtime)/50;
vec curr_o = p->projpath[seq], next_o = p->projpath[seq+1];
vmul(curr_o,inter);vmul(next_o,50-inter);
vec v = curr_o; vadd(v,next_o);
vdiv(v,50);

With 20 predefined path points per sec, that makes an allocation of 2,4K per projectile with a max timeout of 10sec per proj.

This works fine, but i wonder if it's the way to implement this, or if i'm totally missing a simple way to update on every frame with *exact* same path for any ppl at any fps. Maybe using a (sorry i don't know how this is called in english) ax˛+bx+c function. Still, this would maybe make harder implementing bounce.

Also, as i've absolutely 0 skill in OpenGL programming, i wonder if/how i can use the gluUnproject() to detect collision with floor/walls/ceiling, if this can also work with collision on parts that are not visible/occluded?
As it seems to depend on the viewport, i think that i can't.
Or maybe it would be easier-at least, for someone who don't code OGL ;)- to implement a custom function for collision with map, as i'm gonna need to use some informations on the map to calc bounce angle with heightfields and corners.(for now i think so, but maybe gluUnproject() can make this with better/smaller code :)

reply to this message

#238: Re: just another thing...

by D.plomat on 08/01/2003 00:58, refers to #237

I suppose i must also precalc final exploding place, and use a higher time resolution for bounce/collision even if i keep 50ms for path resolution, to avoid very-fast projectiles flying thru thin walls...

reply to this message

#239: ..

by Frank__i (Flameshot leader) on 08/01/2003 04:37

i guess , but he can always take the farcry engine and do cube with that :D !

reply to this message

#240: .

by pushplay on 08/01/2003 06:46

I thought that physics had been made independent of grahpics fps?

reply to this message

   Board Index