Re: [Soya-user] soya svn not compiling on Archlinux anymore
Bonjour, I usually use Cython 0.16 to compile Soya (and no longer Pyrex). Can you verify that _activate() is defined (it should be in shader.pyx) ? I'm currently rewriting the Soya's shading system (and almost all Soya ;) but nothing has been committed yet in the SVN, so it should not be a problem. Cordialement, Jean-Baptiste Lamy Le Wed, 09 May 2012 14:50:39 +0200, Fabio Varesano fabio.vares...@gmail.com a écrit : [fabio@gamma soya]$ python2 setup.py build Pyrex found - compilation enabled Remove pyrex and install cython. Does it fixes the issue ? It doesn't seem to work.. it seems to fail with exactly the same kind of problems.. something wrong with the code? Below the errors. Error compiling Cython file: ... cdef class _ARBShaderProgram(_CObj): cdef readonly GLuint shader_type cdef readonly GLuint _prog_id cdef readonly object code cdef public object _filename cdef void _activate(self) ^ ./definitions/model/shader.pxd:8:20: C method '_activate' is declared but not defined Error compiling Cython file: ... cdef readonly GLuint shader_type cdef readonly GLuint _prog_id cdef readonly object code cdef public object _filename cdef void _activate(self) cdef void _inactivate(self) ^ ./definitions/model/shader.pxd:9:22: C method '_inactivate' is declared but not defined Error compiling Cython file: ... cdef readonly GLuint _prog_id cdef readonly object code cdef public object _filename cdef void _activate(self) cdef void _inactivate(self) cdef void _set_env_parameter(self, int index, float v0, float v1, float v2, float v3) ^ ./definitions/model/shader.pxd:10:29: C method '_set_env_parameter' is declared but not defined Error compiling Cython file: ... cdef readonly object code cdef public object _filename cdef void _activate(self) cdef void _inactivate(self) cdef void _set_env_parameter(self, int index, float v0, float v1, float v2, float v3) cdef void _set_local_parameter(self, int index, float v0, float v1, float v2, float v3) ^ ./definitions/model/shader.pxd:11:31: C method '_set_local_parameter' is declared but not defined Error compiling Cython file: ... glPopAttrib() global _texture_on_depth_buffer_shader if _texture_on_depth_buffer_shader is None: _texture_on_depth_buffer_shader = _ARBShaderProgram(SHADER_TYPE_FRAGMENT, !!ARBfp1.0 ^ soya3d/atmosphere.pyx:487:75: undeclared name not builtin: SHADER_TYPE_FRAGMENT building 'soya._soya' extension creating build/temp.linux-x86_64-2.7 gcc -pthread -fno-strict-aliasing -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -DNDEBUG -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -fPIC -I. -I/usr/include -I/usr/local/include -I/usr/X11R6/include -I/usr/X11/include -I/usr/include/freetype2 -I/usr/X11/include/freetype2 -I/usr/local/include/freetype2 -I/usr/include/cal3d -I/usr/local/include/cal3d -I/sw/include -I/opt/local/include -I/opt/local/include/freetype2 -I/usr/include/python2.7 -c soya._soya.c -o build/temp.linux-x86_64-2.7/soya._soya.o -w -fsigned-char soya._soya.c:1:2: error: #error Do not use this file, it is the result of a failed Cython compilation. error: command 'gcc' failed with exit status 1 ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] MMORPG
Le Wed, 19 Dec 2007 15:10:38 +0100, Souvarine [EMAIL PROTECTED] a écrit : Jan Ciger wrote: in that case the design evolved from a single player game, where the weapon is a particle system and the individual particles cause damage. when we needed to quickly make that a dogfight thing that works over LAN, was simple and optimally efficient to keep the client-side damage calculations, and currently trust is no issue there. dunno if that is interesting also w.r.t p2p ideas. This will work until the first player connects with a hacked client reporting vastly increased damage and ruins the game play for everybody. This is precisely the thing you *do not* want to be on the client or the client has to be locked down tightly (cryptographically signed, closed source, etc.). Even then you will face cheating - see games such as Counterstrike where various aimbots (most of them are client hacks) almost wiped the scene until some countermeasures appeared. For your example about client side computation of damage, wouldn't it be possible to compute the damage on several clients and have clients to verify if the result they get from other clients is good ? Player A is playing with a hacked client, it compute a damage of 1000 HP instead of 10 HP as it should be, a good way to cheat. Player B and C are playing on good client. Those clients compute that the damage should be 10 HP, when they get a result of 1000 HP from client A they both know that something is wrong. Then client B and C report client A as a cheater to the server, the server ban client A. Another interesting possibility : if players A and B are fighting, let the player C do the computation. Ideally, player C should be as independent from player A and B as possible (e.g. he never met them before, he is far away,...). It does not really prevent cheating, but it makes it much complex since, for cheating, players A or B need player C agreement. Cordialement, Jean-Baptiste Lamy ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] render problem
Hi, Part of the problem is that we lack windows developers... As I said above, I have no windows computer, so I can hardly test everything under this OS... (even if i do some test at work :-)). About the window-resizing problem, if I remind well, SDL behaves differently under windows and linux, although both behaviors should be taken into account by Soya. However, Soya processes the SDL event only when you call process_event(), consequently if you never call it, you may experience troubles. I'm currently thinking about a new widget system (well, that would be only the third for soya ;) and a different event processing system (e.g. process events systematically each round, and make process_event() simply returns the events). Cheer, Jiba Le Thu, 8 Nov 2007 13:15:36 +0100, Ting Li [EMAIL PROTECTED] a écrit : Thank you for the reply, julian! I agree Soya3D is indeed a good and easy-to-learn game engine. (Although I'm not intending to use it to develop a game. ) And maybe you have more insights and experiences on also Panda3D and Ogre3D and know their problems, but I didn't have any problem with running their examples/tutorials! It's true that any software has its weak points. But the support for the product varies a lot. E.g. the bug tracking system, response speed, and the timing for the real solution. As I know, Panda3D, Ogre3D and maybe plus Blender GE, they all have very active user community and fast support from the develop team, which makes one always feel safer/comfortable. The point I'd like to repeat here is I like Soya3D. I would be very happy if I can use it on my Windows OS (smoothly). But is there somebody can help me to solve the problems I found there? If I have to dig into the source by myself instead of enjoying developing my own program, perhaps I have to stop it and find some other solution as I mentioned. I hope you could understand and help. (BTW, I think the problems I have are not serious for the engine itself, they are just something about the cross-platform compatibility, which could/should be taken care while developing and testing. For instance, the manner to redraw the scene while switching/resizing/moving the graphic window and correctly handle the mouse/keyboard input events.) ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
