• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

j3p

Members
  • Content count

    50
  • Joined

  • Last visited

Community Reputation

1363 Excellent

About j3p

  • Rank
    Member
  1. QT Creator is a good choice. The code completion support is almost VS-like. Debugging with gdb also works as expected.   Personally I've been trying more Atom these days. With packages you can extend it to be a semi-decent IDE, featuring all the basic or fancy stuff, clang-completion, build systems and even a debugger. It comes with a great git support. Also, it looks pretty. Only thing a miss are the symbol tooltips when you hover over something.
  2. e: mixed posts, please ignore.
  3. Alright, I changed that and it seems to be working now.   Thank you for your help. Sorry this turned out to be my personal buglog. 
  4.   Yes, I double checked that. Everything is now from the latest r1916, unmodified. My case is much like the following: void Loop(ref @r){ //r is null when using opHndlAssign } void main(){ Actor a; //any class or object ref @r = @a; ExecuteAsync(Loop,r,0.0f); } This is how I register ExecuteAsync: static void SCRIPTF_ExecuteAsync(asIScriptFunction *pfunc, CScriptHandle *pref, float t){     //...     if(pref)         psg->AddRefScriptObject(pref,psg->GetObjectTypeByName("ref"));     pscript->Execute(pfunc,...,pref); //basically finds a free context, prepares it and executes in a concurrent manner } psg->RegisterFuncdef("void ExecFunc(ref)"); psg->RegisterGlobalFunction("void ExecuteAsync(ExecFunc@, ref, float)",asFUNCTION(SCRIPTF_ExecuteAsync),asCALL_CDECL);
  5. Ok, sorry about this.. It was an overflow at my end, found it deep in my dumb ***.   I'm still getting null pointer accesses though. Something's going on with the new scripthandle add-on. Simply calling psg->AddRefScriptObject(pref,psg->GetObjectTypeByName("ref")) and passing it as an object to another preparing context doesn't seem to cut it anymore.   E: must be that new opHndlAssign. Changing it back to opAssign solves it...
  6. I'll just put some data breakpoints and see what happens. Of course it's possible that there's an overflow at my end...
  7. The methods array is still ok after script api registration. Only after some random CompileFunction() the first element is set to 0. No Build() calls have been made so far.   But I'm not sure about anything anymore. I tested with two memory allocators, Intel's scalable and the system default. When using Intel's allocator something overwrites the first element in methods, maybe because the allocated block is more continuous and optimized. (Note that I've always used the Intel's allocator for angelscript and it's been working so far). The default allocator on the other hand produces different behaviour. I'm getting "empty script section" errors. This may or may not be related...   Some of the script sections in single module look like this after the preprocessor stage:   script.as, AddScriptSection (mostly empty, some newlines or spaces)   header.as, AddScriptSection (actual code)   script.as, AddScriptSection (actual code)   The first one being empty hasn't been a problem before. Have you perhaps changed this?   I'll be doing some more testing and report back if I find something. It's a bit hard to debug since the buffer for elements is reallocated every once in a while  (e2: nope, just realized that the buffer stays constant after registration ...presumably) For now I'm going to fall back to default allocator and maybe solve this empty section issue...   e: If the script section report is not an error, I'm still getting a script null pointer access. It's a bit vague..
  8. Sure, here's the relevant part: #define RegisterVectorMethods(n,t,c) void RegisterVectorMethods_##t(asIScriptEngine *psg){\ psg->RegisterObjectMethod(n,n" &opAssign(float)",asFUNCTION((SCRIPTF_assign<t>)),asCALL_CDECL_OBJFIRST);\ psg->RegisterObjectMethod(n,n" &opAddAssign(const "n" &in)",asMETHODPR(t,operator+=,(const t&),t&),asCALL_THISCALL);\ psg->RegisterObjectMethod(n,n" &opSubAssign(const "n" &in)",asMETHODPR(t,operator-=,(const t&),t&),asCALL_THISCALL);\ psg->RegisterObjectMethod(n,n" &opMulAssign(float)",asMETHODPR(t,operator*=,(float),t&),asCALL_THISCALL);\ psg->RegisterObjectMethod(n,n" &opDivAssign(float)",asMETHODPR(t,operator/=,(float),t&),asCALL_THISCALL);\ psg->RegisterObjectMethod(n,n" opAdd(const "n" &in) const",asMETHODPR(t,operator+,(const t&) const,t),asCALL_THISCALL);\ psg->RegisterObjectMethod(n,n" opSub(const "n" &in) const",asMETHODPR(t,operator-,(const t&) const,t),asCALL_THISCALL);\ psg->RegisterObjectMethod(n,n" opMul(float) const",asMETHODPR(t,operator*,(float) const,t),asCALL_THISCALL);\ psg->RegisterObjectMethod(n,n" opMul_r(float) const",asMETHODPR(t,operator*,(float) const,t),asCALL_THISCALL);\ psg->RegisterObjectMethod(n,n" opMul(const "n" &in) const",asMETHODPR(t,multiply,(const t&) const,t),asCALL_THISCALL);\ psg->RegisterObjectMethod(n,n" opDiv(float) const",asMETHODPR(t,operator/,(float) const,t),asCALL_THISCALL);\ psg->RegisterObjectMethod(n,n" opNeg() const",asMETHODPR(t,operator-,(void) const,t),asCALL_THISCALL);\ psg->RegisterObjectMethod(n,"bool opEquals(const "n" &in) const",asMETHODPR(t,operator==,(const t&) const,bool),asCALL_THISCALL);\ psg->RegisterObjectMethod(n,"float length() const",asMETHODPR(t,magnitude,(void) const,float),asCALL_THISCALL);\ psg->RegisterObjectMethod(n,"float LengthSq() const",asMETHODPR(t,magnitudeSquared,(void) const,float),asCALL_THISCALL);\ psg->RegisterObjectMethod(n,"float normalize()",asMETHODPR(t,normalize,(void),float),asCALL_THISCALL);\ psg->RegisterObjectMethod(n,n" GetNormalized() const",asMETHODPR(t,getNormalized,(void) const,t),asCALL_THISCALL);\ psg->RegisterObjectMethod(n,"float dot(const "n" &in) const",asMETHODPR(t,dot,(const t&) const,float),asCALL_THISCALL);\ psg->RegisterObjectMethod(n,"bool IsZero() const",asMETHODPR(t,isZero,(void) const,bool),asCALL_THISCALL);\ } RegisterVectorMethods("float3",PxVec3,3); template<uint a, uint b> static PxVec2 Float3Swizzle2F(const PxVec3 *p){ return PxVec2((*p)[a],(*p)[b]); } template<uint i> class Float3Swizzle2{ public: static inline void Do(asIScriptEngine *psg){ char sw[32]; sprintf(sw,"const float2 get_%c%c() const",(i/3)%3+0x78,i%3+0x78); psg->RegisterObjectMethod("float3",sw,asFUNCTION((Float3Swizzle2F<(i/3)%3,i%3>)),asCALL_CDECL_OBJFIRST); Float3Swizzle2<i-1>::Do(psg); } }; template<> class Float3Swizzle2<0>{ public: static inline void Do(asIScriptEngine *psg){ psg->RegisterObjectMethod("float3","const float2 get_xx() const",asFUNCTION((Float3Swizzle2F<0,0>)),asCALL_CDECL_OBJFIRST); } }; template<uint a, uint b, uint c> static PxVec3 Float3Swizzle3F(const PxVec3 *p){ return PxVec3((*p)[a],(*p)[b],(*p)[c]); } template<uint i> class Float3Swizzle3{ public: static inline void Do(asIScriptEngine *psg){ char sw[32]; sprintf(sw,"const float3 get_%c%c%c() const",i/9+0x78,(i/3)%3+0x78,i%3+0x78); psg->RegisterObjectMethod("float3",sw,asFUNCTION((Float3Swizzle3F<i/9,(i/3)%3,i%3>)),asCALL_CDECL_OBJFIRST); Float3Swizzle3<i-1>::Do(psg); } }; template<> class Float3Swizzle3<0>{ public: static inline void Do(asIScriptEngine *psg){ psg->RegisterObjectMethod("float3","const float3 get_xxx() const",asFUNCTION((Float3Swizzle3F<0,0,0>)),asCALL_CDECL_OBJFIRST); } }; void RegisterScriptMath(asIScriptEngine *psg){ psg->RegisterObjectType("float3",sizeof(PxVec3),asOBJ_VALUE|asOBJ_POD|asOBJ_APP_CLASS_ALLFLOATS|asOBJ_APP_CLASS_CAK); psg->RegisterObjectProperty("float3","float x",offsetof(PxVec3,x)); psg->RegisterObjectProperty("float3","float y",offsetof(PxVec3,y)); psg->RegisterObjectProperty("float3","float z",offsetof(PxVec3,z)); psg->RegisterObjectBehaviour("float3",asBEHAVE_CONSTRUCT,"void f(float, float, float)",asFUNCTION(Float3Constructor1),asCALL_CDECL_OBJFIRST); psg->RegisterObjectBehaviour("float3",asBEHAVE_CONSTRUCT,"void f(const float2 &in, float)",asFUNCTION(Float3Constructor2),asCALL_CDECL_OBJFIRST); psg->RegisterObjectBehaviour("float3",asBEHAVE_CONSTRUCT,"void f(float, const float2 &in)",asFUNCTION(Float3Constructor3),asCALL_CDECL_OBJFIRST); psg->RegisterObjectBehaviour("float3",asBEHAVE_CONSTRUCT,"void f(float)",asFUNCTION(Float3Constructor4),asCALL_CDECL_OBJFIRST); Float3Swizzle2<9-1>::Do(psg); Float3Swizzle3<27-1>::Do(psg); //removing this fixes the problem //Float3Swizzle3<2>::Do(psg) registers the maximum set without crashing: xxz, xxy, xxx. Next one would include xyx. RegisterVectorMethods_PxVec3(psg); psg->RegisterObjectMethod("float3","float3 cross(const float3 &in) const",asMETHODPR(PxVec3,cross,(const PxVec3&) const,PxVec3),asCALL_THISCALL); }
  9. Hi,   The compiler crashes while trying to access the first element in engine->scriptFunctions which is null in CompileOverloadedDualOperator2() (Windows, x64). I tried a few different versions with relevant changelogs and found that the problem appears when upgrading from r1777 to r1778 (still happens with r1914).   Here's roughly what happens: angelscript.dll!asCString::Compare(const char * str) Line 291 + 0x23 bytes C++ angelscript.dll!operator==(const asCString & a, const char * b) Line 340 + 0xf bytes C++ > angelscript.dll!asCCompiler::CompileOverloadedDualOperator2(asCScriptNode * node, const char * methodName, asSExprContext * lctx, asSExprContext * rctx, asSExprContext * ctx, bool specificReturn, const asCDataType & returnType) Line 10781 + 0x1c bytes C++ angelscript.dll!asCCompiler::CompileOverloadedDualOperator(asCScriptNode * node, asSExprContext * lctx, asSExprContext * rctx, asSExprContext * ctx) Line 10736 + 0x7b bytes C++ angelscript.dll!asCCompiler::CompileInitialization(asCScriptNode * node, asCByteCode * bc, asCDataType & type, asCScriptNode * errNode, int offset, unsigned __int64 * constantValue, int isVarGlobOrMem) Line 2373 + 0x32 bytes C++ angelscript.dll!asCCompiler::CompileDeclaration(asCScriptNode * decl, asCByteCode * bc) Line 2110 + 0x46 bytes C++ angelscript.dll!asCCompiler::CompileStatementBlock(asCScriptNode * block, bool ownVariableScope, bool * hasReturn, asCByteCode * bc) Line 1027 C++ angelscript.dll!asCCompiler::CompileFunction(asCBuilder * builder, asCScriptCode * script, asCArray<asCString> & parameterNames, asCScriptNode * func, asCScriptFunction * outFunc, sClassDeclaration * classDecl) Line 552 C++ angelscript.dll!asCBuilder::CompileFunctions() Line 724 C++ angelscript.dll!asCBuilder::Build() Line 241 C++ angelscript.dll!asCModule::Build() Line 230 + 0xe bytes C++ (engine->scriptFunctions).array,8 0x0000000003a40100 asCScriptFunction * * [0] 0x0000000000000000 {refCount={...} gcFlag=??? engine=??? ...} asCScriptFunction * [1] 0x0000000003c0bec0 {refCount={...} gcFlag=false engine=0x0000000003c32040 ...} asCScriptFunction * [2] 0x0000000003c0bd80 {refCount={...} gcFlag=false engine=0x0000000003c32040 ...} asCScriptFunction * [3] 0x0000000003c0bc40 {refCount={...} gcFlag=false engine=0x0000000003c32040 ...} asCScriptFunction * [4] 0x0000000003c0bb00 {refCount={...} gcFlag=false engine=0x0000000003c32040 ...} asCScriptFunction * [5] 0x0000000003c0b9c0 {refCount={...} gcFlag=false engine=0x0000000003c32040 ...} asCScriptFunction * [6] 0x0000000003c0b880 {refCount={...} gcFlag=false engine=0x0000000003c32040 ...} asCScriptFunction * [7] 0x0000000003c0b740 {refCount={...} gcFlag=false engine=0x0000000003c32040 ...} asCScriptFunction * (ot->methods).array,8 0x0000000003c35300 int * [0] 0 int [1] 103 int [2] 104 int [3] 105 int [4] 106 int [5] 107 int [6] 108 int [7] 109 int The object that causes it is a vector3 pod with some typical math methods. What's interesting though is that removing the swizzler template<uint a, uint b, uint c> PxVec3 Float3Swizzle3F(const PxVec3 *p){ return PxVec3((*p)[a],(*p)[b],(*p)[c]); } template<uint i> class Float3Swizzle3{ public: static inline void Do(asIScriptEngine *psg){ char sw[32]; sprintf(sw,"const float3 get_%c%c%c() const",i/9+0x78,(i/3)%3+0x78,i%3+0x78); psg->RegisterObjectMethod("float3",sw,asFUNCTION((Float3Swizzle3F<i/9,(i/3)%3,i%3>)),asCALL_CDECL_OBJFIRST); Float3Swizzle3<i-1>::Do(psg); } }; template<> class Float3Swizzle3<0>{ public: static inline void Do(asIScriptEngine *psg){ psg->RegisterObjectMethod("float3","const float3 get_xxx() const",asFUNCTION((Float3Swizzle3F<0,0,0>)),asCALL_CDECL_OBJFIRST); } }; Float3Swizzle3<27-1>::Do(psg); makes the problem vanish. It's strange because enabling a similar swizzler for vector4 type has no effect (despite the fact that it spams multiple times more methods than the code above). Currently I'm hacking around by putting some null-checks in some places.   I'll be happy to provide more info if needed...  
  10. If I'm not mistaken, the character controller shouldn't automatically push objects around it (see documentation). Normally you would apply the pushing forces manually. There's onShapeHit -callback for this purpose. This way you have more control over the forces anyway. The character controller pushing objects in your previous build might have been a side effect caused by invalid scene configuration.   I don't know about the offset though, so I can't really help with that... Have you tried fixing that offset between ground and bottom with setFootPosition ?(e: nevermind, I don't think this is related to the actual issue).
  11. Okay, I didn't notice anything odd in the code. But by looking that video I noticed that your world scale is enormous compared to that grid (it's not possible to scale that grid, is it?). What units are you using? It's known that too small units can cause jittering when using inappropriate contact offsets. There's something in the documentation about this and here: http://www.nvidia.com/object/physx_knowledge_base.html (it's for the previous version but probably still valid).
  12. Yes, it should be called on dynamic actors only. Otherwise static/dynamic actor initialization should look quite similar. I assume you're not manually applying impulses on the box (at onShapeHit callback)? Does your box behave like that if you're not pushing it with the character controller? Does it penetrate the static actor if it falls? I still suspect there's something wrong with how you're creating your dynamic actors. Even if the cc pushed the box in to the wall/ground, it should jump right off. Post some initialization code maybe so that can be ruled out?
  13. Are you calling PxRigidBodyExt::setMassAndUpdateInertia (possibly instead of setMass) after all the shapes have been created? That behaviour in your video is exactly what happens if this call is omitted.
  14. Internally the controller framework uses setKinematicTarget() so one can only guess what PhysX does beyond that point. I don't know if it's even valid to use getLinearVelocity with kinematic actors...   However, since the displacement is accurate, why not use it to calculate the velocity yourself? Just keep the previous and current position between updates and divide the displacement with your timestep.