Search options (Page 11 of 60)

For iOS I got this error :

CMake Error at CMakeLists.txt:42 (IF):
  if given arguments:

    "CMAKE_GENERATOR" "NOT" "Xcode"

  Unknown arguments specified

Separately, the non-ios mac Xcode generation goes further but stopped :

CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
FREETYPE_LIBRARY
    linked by target "MaratisEditor" in directory /Users/anaelseghezzi/Downloads/Maratis-ios/M/Maratis/Editor
    linked by target "MaratisPlayer" in directory /Users/anaelseghezzi/Downloads/Maratis-ios/M/Maratis/Player
ZLIB_LIBRARY
    linked by target "MaratisEditor" in directory /Users/anaelseghezzi/Downloads/Maratis-ios/M/Maratis/Editor
    linked by target "MaratisPlayer" in directory /Users/anaelseghezzi/Downloads/Maratis-ios/M/Maratis/Player

Hi Vegas,
yes, thank you for adding the technique to the wiki.

For your game, was the pre-allocation of clone enough
or did you also use the simpler collision detection describe above ?

Yes pushFloatArray require a float array.
There is no string array method implemented, you have the choice between :

pushIntArray(const int * values, unsigned int valuesNumber);
pushFloatArray(const float * values, unsigned int valuesNumber);
pushString(const char * string);
pushBoolean(bool value);
pushInteger(int value);
pushFloat(float value);
void pushPointer(void* value);

Thank you,
it's worth considering an official move to CMake in the near future,
let's see how the experimental branch is moving, I didn't find time to update Maratis editor with the new MGui.

Hi, thank you for the feedback !
are you very familiar with CMake ? What is your opinion about it, compared to Scons and premake ?

There is some thoughts about moving from Scons, but it's hard to see which system is better, active or fully multi platform (ideal would be a unified windows/mac/iOS/Android and linux x86 + linux ARM building system).

It's a natural bottleneck, specially for fast game like this shooting game where hundred of objects are created in a single frame. It's not just the memory allocation, but the fact that a new object need to be added to the scene description, some object data need to be initialized (matrices, references, parenting).

Also, it's possible that the slow down in this example is more related to the physics than a pure memory allocation bottleneck, in an indirect way, like above, because the collision object need to be added to the physics scene, the scene octree probably need to be updated because of that, etc.

Hi Vegas,
your video looks quite interesting, waiting to see more !

About the frame drop, there is some concept that need to be understood :

1 : dynamic object creation is not fast, for multiple reasons :
  - memory allocation : each cloning allocate new memory, fast games usually pre-allocate memory.
  - when using physics, the new object need to be also allocated to the physics world
  - when using sound, the source need to be also allocated to the sound context

2 : collision need to be optimized for your need

There is two things I suggest :

1 : pre-allocate the projectiles :
  - clone a list of each object at the beginning of the scene, think about how much of each projectile
    would be used at max at the same time (let's say 32 of each)
  - when you shot a projectile, use one of the object from the list and turn with this 32 objects

2 : if it's still slow, try to not use physics where it's not necessary :
 
for example, use a simpler collision test for the projectiles :
(if the distance between object and projectile is less than a certain distance, there is a collision)

distance = length(projectilePos - objectPos)

if distance < (projectileRadius + objectRadius) then
  --do something
end

OpenGL ES 1 and 2 contexts are already done, but right now they are only used by the iOS port.

You can totally help with the ARM linux, I don't have any ARM hardware to test it, do you ?
The first thing is to see if the scons building system can work on an ARM linux system.

The video player would work good as a plugin.

About ARM, it won't be a plugin but more a build setup, by default all source should compile for ARM without modification, but might require some optimization or build settings (Bullet for example compiles as-it for ARM but got some ARM specific code for speed).

And for specific platform like Raspberry, it might also need build options for example to force the use of OpenGL-ES instead of OpenGL.

Hi sunnystormy, I don't know what is included in the debian installer.

if it's not included in the package you need :
- the headers from the MSDK/MCore and MSDK/MEngine
- the libraries mcore.so and mengine.so (it could also be named libmcore.so and libmengine.so)
there should be next to Maratis application

from codeblocks, you just have to specify the path where the headers and libraries are

Better to check with Sponk.

ok, the use of "stopSound" seems to relieve the system ?