Crystal Space
Welcome, Guest. Please login or register.
September 25, 2017, 10:47:45 am

Login with username, password and session length
Search:     Advanced search
9054 Posts in 2047 Topics by 74516 Members
Latest Member: Harperoluwal563
* Home Help Search Login Register
  Show Posts
Pages: 1 [2] 3 4 ... 114
16  Crystal Space Development / Support / Re: Cannot install a usable crystalspace library anywhere on: August 30, 2012, 07:03:06 am
I have so far tried this on Fedora 16, Fedora 17, CentOS 6.2, and Cygwin under Windows 7 home premium.

Cygwin: won't even build.  Claims it needs wfopen() which is a MSFC class which Cygwin doesn't provide.  end of line - crystalspace's docs say cygwin is supported, but this seems particularly non-supported to me Smiley
All of the Linuxes: builds great.  Runs and displays a white screen sometimes with some 3D artifacts, otherwise just white.  Yes I'm running linux under VMWare, but VMWare is supposedly passing through the 3D acceleration, and other 3D apps in the same VM work fine (ie, vegastrike).

I get similar results using 2.0 or the latest release from SVN, except that 2.0-stable won't compile under fedora 17.  I'm kind of stuck here - I've been a programmer since 1981 so I feel kind of dumb not being able to get this to work right, but I keep running into roadblock after roadblock just getting the basic stuff up and running, and after following the docs to the letter.  Please advise Smiley

I recommend you use MSYS/Mingw instead of cygwin. It works for sure (I'm using it).

17  Crystal Space Development / Support / Re: noob question alert!: having trouble getting started.... on: August 28, 2012, 07:07:48 am
What do you mean by 'the install is not able to be read by my computer'? What happens exactly? What are you doing and what errors are you getting?

18  Crystal Space Development / Support / Re: Bullet iBodyGroup not implemented on: July 19, 2012, 06:52:17 am
Currently a new physics library (also based on bullet) is being made. It will be much more complete and with a better API as
well. We will not improve the old bullet plugin anymore given that a new one is coming.

19  Crystal Space Development / Support / Re: Question on CS dependency on CG on: July 01, 2012, 07:38:38 pm

I saw that in the mandatory dependency list, CG for nvidia is needed. Does that mean that CS can only run nvidia graphics hardware?
What happens if I wish to port CS to an embedded platform that has its own GPU hardware?

Three things: In version 2.0 or older CG is not *really* required. It is just very recommended since a lot of shaders depend on it.

Additionaly the CG from nvidia is not restricted to nvidia hardware. It works for AMD, Intel Graphics, ...

Starting in CS 2.1 (not released yet) we also support GLSL so then the dependency on CG is even lower.

But in summary, you should not worry. There is no limitation to nvidia hardware at all. Look up the CG toolkit
on google. You can see that it is also for other hardware.

20  Crystal Space Development / Support / Re: Can't compile CS...slowly going insane... on: June 26, 2012, 07:21:36 am
I strongly recommend using 2.0 of CS btw. 1.4 is very old and 2.0beta3 is really rather stable.

21  Crystal Space Development / Support / Re: Can't compile CS...slowly going insane... on: June 26, 2012, 04:49:07 am
Hmm, I'm not experienced with MSVC but can you give a bit more information? For example, which version of CS, which version of cswinlibs and so on. And also a log of the computer output.

22  Associate Projects / CEL Discussion / Re: Behaviours depricated according to iPcActorMove Struct Reference? on: June 03, 2012, 06:35:33 am
Ok, I put your code in svn. Thanks a lot!
23  Associate Projects / CEL Discussion / Re: Behaviours depricated according to iPcActorMove Struct Reference? on: June 03, 2012, 06:12:06 am
Thanks a lot! I will incorporate your changes today.

An update to the manual would be very welcome.

24  Associate Projects / CEL Discussion / Re: Behaviours depricated according to iPcActorMove Struct Reference? on: June 02, 2012, 06:59:27 pm
Yes the tutorials are a bit outdated. I have no really easy ready to use examples at this moment
but Ares does this right now. The way ares does this is having the following property classes:

  • pcinput.standard: taking care of input
  • various pclogic.wire property classes taking care of receiving messages from pcinput.standard
    and sending them to the application logic property class (which is a custom property class made
    by ares that handles main game logic).
  • this is a physics based movement class that directly understands
    messages from pcinput if you use the right names (like 'strafeleft' and so on). If you don't
    want to use physics you can also the actormovement property class. It has a Subscribe
    message that you can use from xml (or from code too if you want). When you call that it will
    also understand the messages sent by pcinput.standard directly without the need for
    an intermediate behaviour layer

There are many ways you can set this up. The way above works fine for Ares. You may also opt
to let your custom property class do the mapping between keyboard events and movement. In that
way it would act like what many behaviour layers do now.

The behaviour layer system is really redundant because everything you can do with this can
also be done with property classes using the new message system.

If you need more detailed information then tell me.

25  Associate Projects / CEL Discussion / Re: Behaviours depricated according to iPcActorMove Struct Reference? on: June 02, 2012, 05:45:14 am
I was looking through the api documentation for the iPcActorMove interface, since I wanted to know what possibilities it offers for character control (I'm new to CEL, and I'm trying to move past the starting tutorial stage). I've noticed that it has the following line:
Note! Since behaviours are deprecated this property class can now also listen to messages from pclinmove directly.
What does this mean? I'm guessing that behaviours are not being deprecated for the entire CEL framework, since I never seen it mentioned anywhere else in the documentation. Does this just mean that you don't have to use the behaviour layer anymore to translate between input and movement, unlike you had to in the walktut example?

This basically means that eventually the behaviour layer will go away completely. The new way to do things is using property classes. Everything a behaviour can do you can do just as well in a (self-written or not) property class. So for new CEL apps you should try to avoid using the behaviour layer for anything.

26  Crystal Space Development / Support / Re: how to fly on: May 29, 2012, 07:08:15 pm
In simplemap you cannot fly. You can do it in walktest though (press '8' key to disable
gravity). And of course you can modify simplemap to have any kind of movement you want.

27  Crystal Space Development / Support / Re: How to pack the project on: May 10, 2012, 03:21:32 pm
Can't you use an USB stick? CS should fit on that. But be sure to try it out first on someone elses computer.

I would just try to copy the entire CS dir (without sources and without some of the data files perhaps) and then also the dll's which are in cswinlibs install.

28  Crystal Space Development / Support / Re: How to pack the project on: May 10, 2012, 03:02:53 pm
Unfortunatelly that is not very easy. I assume you are on windows? If you use the mingw compiler you could try to make a static walktest: 'jam walktest_static' which is considerably smaller since all the plugins are included. With Visual Studio compiler I have no idea how to do that.

In addition to CS you will also need some of the dll's that are provided by the cswinlibs package.

My best advice is to try 'jam walktest_static' and copy that to another directory. Then also get the 'data' directory (you can remove all levels you don't need) and also the dll's from the cswinlibs package. Then try if it still works.

29  Crystal Space Development / General Crystal Space Discussion / Re: world editor? on: April 06, 2012, 08:16:10 am
Scene management is what a 3D engine internally uses to keep track of the world and the objects in the world.

A world editor is a tool with which one can make worlds for 3D engines. So it is not the same as scene management
but with a world editor you can define a scene for the engine.

To make worlds for Crystal Space there are four ways currently:
  • Blender: Blender has a very good exporter for Crystal Space so this is probably the most powerful way to make Crystal Space worlds right now
  • 3DsMax: Crystal Space also comes with an exporter for 3DsMax. The PlaneShift project uses this to make their worlds.
  • CSEditor: CS has itself an editor included but it is in heavy development so not really useful right now
  • AresEd: I'm working on a world/game building tool which is also in heavy development: more information:

Let me know if you have more questions.

30  Crystal Space Development / General Crystal Space Discussion / Re: Wheezy i386 on: March 14, 2012, 08:09:37 pm
Not all packages are required. The ones you listed are pretty optional so you could
do without.
The two most important ones to try to get are bullet and cg.

'cg' can usually be found as the nvidia-toolkit package but note that it is an
non-free package.

'bullet' I don't know. What distro are you using?

Pages: 1 [2] 3 4 ... 114
Powered by MySQL Powered by PHP Powered by SMF 1.1.2 | SMF © 2006-2007, Simple Machines LLC Valid XHTML 1.0! Valid CSS!
Page created in 6.878 seconds with 17 queries.