Hi
Henry Daniel wrote:
Hi again,
I was checking out the repository and the old GSoC projects related to
CS, I found some projects interesting to me. I'm not sure if the
pathfinding algorithm is already done, but if it's no I could do it.
In addition to the pathfinding, I was thinking about
Tim Shannon wrote:
The current blender2crystal documentation states that the default mesh
type is thing, and lightmaps only apply to thing meshes
(http://b2cs.delcorp.org/index.php/Object_Type_Reference#Mesh_Types)
and not genmeshes. I'm assuming it's out of date right, and the
default mesh
Daniel Esser escribió:
currently my CRYSTAL environment variable is set to
.../crystal-sdk:.../crystal-sdk/lib/crystalspace-1.4:.../crystal-sdk/etc/crystalspace-1.4.
I just wondered because you wrote CRYSTAL should point to only one
directory. If I do so CS doesn't find any plugin or cfg
Daniel Esser escribió:
res wrote:
On 27.10.2008 16:52, Pablo Martin wrote:
B2cs will use just the first path component in CRYSTAL, which should be
the path where data/shaders can be found.
CS itself on the other hand looks into every dir in the var, scans for
plugins, looks
Ill clarify about the cel patch (and i think the info is good to know
for all cs users too).
I didn't commit it yet, because the patch changes billboard-text drawing
order in an incorrect way (explanation below). It is not a problem with
no billboard overlap, but it is not 100% correct.
The
I considered it one of the great features of cs, but, given its not
maintained any more, and far from the rendering glory of the old days,
we can't do much, so it has to be ditched.
Just for the record, i started using cs because of the software
renderer, and it used to be faster than opengl
That seems to come from out of date swigpyruntime.h, which is a file
generated by swig. Make sure it is generated, and the correct one is
used (maybe by overwriting the frozen one). There's been some issue with
the build system using the wrong one, so it can be that, otherwise, not
sure. About
I think you cant do it in the factory, just in the object (as b2cs
does), but i might be wrong.
Pablo
Amir Taaki escribió:
Looking through documentation I can't see how describing geometry in
factory files is done. Here's what I have,
library
textures
texture name=laser_blue
, 2008 at 8:51 PM, Pablo Martin [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
I think you cant do it in the factory, just in the object (as b2cs
does), but i might be wrong.
Pablo
Amir Taaki escribió:
Looking through documentation I can't see how describing
Hi, i believe the version in b2cs server has these,
http://b2cs.delcorp.org/index.php/Debian_Packages
it is very dated though (nothing for feisty or gutsy), new packages are
in development and will hopefully soon (1-2 weeks) be ready.
still, you can use the sources for the deb files to roll
Lukas Erlinghagen wrote:
Pablo Martin schrieb:
res wrote:
On 04.10.2007 19:58, Pablo Martin wrote:
3.: pysimp can't load the cspace module. I changed cspython.cpp to add
scripts/python/frozen to pythonpath in addition to scripts/python.
However, I'm not sure whether
Hi!
In order to start using new optimization features in swig the required
version was changed to 1.3.28 (only for python though).
Note people with an older version will just use the pregenerated files
(now done with 1.3.31), so i strongly believe it shouldnt be a problem
to anyone.
Please let
Hi
Lukas Erlinghagen wrote:
Hi!
I just tried to build the split python modules on MSVC 2005, using CS
trunk revision 27806. Unfortunately, there were some errors.
1.: The variable called PYTHONPATH in
plugins\cscript\cspython\cspython.cpp, lines 101 ff, conflicts with a
Win32-specific
Hi!
I just merged bindingsplit branch into trunk. This means now the swig
files are ready for building bindings in several modules instead of just
one big module, which should help memory and linking problems for most
users. Keep in mind atm only python is using the new approach to
building the
Hi!
I think many of you are aware of the bindingsplit branch, which
rearranges the swig files so that it is possible to build bindings for
different languages in several modules instead of just one big one.
This is beneficial for the following reasons:
- Solves problems in os's that cant link so
The problem could be the python tutorials are using software renderer
(this should be changed), try adding -video=opengl to the command used
to run them.
About the glcg oddity its just a side effect of using software renderer.
Greetings
Pablo
Diez B.Roggisch wrote:
Hi all,
I've
Last year we installed software from that repo (well it was a different
one but same packages basically), computers there had debian. I hope
this year will be just as easy to setup as last. :)
The procedure was: arrive there the day before, install on one machine,
and have it magically deployed
Hi
Richard Boehme wrote:
On 6/27/07, Amir Taaki [EMAIL PROTECTED] wrote:
Hi!
Even better! We made an example!
https://b2cs.delcorp.org/svn/cspop
Thanks. I'll check that out later tonight. Is it in active
development? What's the license on it (didn't see that info looking
Hi
Eric Sunshine wrote:
- It may not necessarily be true that breaking the bindings apart
into smaller modules would improve build time (in fact, it might
lengthen it).
- Breaking the bindings apart into smaller modules, although not
necessarily improving overall build time, might
Hi!
I think many people is aware that current swig bindings generation is
creating way too big modules, that take loads of ram to build and in
some systems arent even linkable due to too many symbols. The problem is
already very visible from python and a lot of people is complaining
(either that
Hi!
I have been working on a solution to be able to access cspace get/set
methods as language specific accessors (in my case python).
Ie, i want to be able to do:
movable.Position = somevector
somevector = movable.Position
instead of:
movable.SetPosition(somevector)
somevector =
Hi
res wrote:
but i noticed the method of
blitting from the texture handle is quite slower than changing the
texture target (20 fps against 120 with a 256x256 video). Is this
normal?
Make sure the textures are uncompressed (nocompress class). Also try
disabling mipmaps.
Seems
Hi!
I've been working on an ffmpeg image loader for crystalspace that allows
to use videos as textures.
First i'd like to ask if it would be good for crystalspace itself, or
maybe better suited for CSExtra repository, so i can commit it.
You can check its code at:
res wrote:
actually the same happened on first pure proctex implementation of the
same concept, but i thought it was something i was doing wrong there
(proctex implementation was more messy). Maybe somebody knows what might
be wrong here? I have checked carefully with mng loader but i dont see
res wrote:
On 10.01.2007 17:04, Pablo Martin wrote:
Another question that arises is it seems all loaders get tested against
any given texture (until one works at least), so defining the handled
mimetypes doesnt seem of much use here, maybe i'm also overlooking
something here
Hi!
I want to comment i added today the pycscegui module to crystalspace.
This is an additional python module that allows to use the cegui wrapper
plugin in cs, plus makes the link between cegui and cs bindings so they
can be used together.
Note to build this you'll need the following:
* cegui
people think? Would any of these be appropiate for the standard
input console? I like the second option more (define a callback for user
selectable completion key).
Greetings!
Pablo Martin
-
Take Surveys. Earn Cash
Ho!
I was thinking maybe we could move all swig .i files to a separate
folder from include/ivaria. I propose include/bindings but maybe
somebody has a better idea :-)
Is there anybody against this?
Greetings!
Pablo
-
Take
28 matches
Mail list logo
