AgentC

Hi,

for some of the latest AngelScript versions I've been getting an assert in as_compiler.cpp, function CompileStatementBlock, asASSERT( tempVariables.GetLength() == 0; ) . This still persists in the latest SVN revision.

 

I seem to be able to trigger it (at least) with the following if statement, where RayQueryResult is a value type, Drawable is a reference type, and String is a value type string adapted from the AngelScript addons.

 

 

RayQueryResult res;
if (res.drawable.typename == "AnimatedModel") // compiling this triggers the assert
{
  Print("is animated");
}

 

If I split up the if statement as follows, it will not assert:

 

 

RayQueryResult res;
Drawable@ dr = res.drawable;
if (dr.typename == "AnimatedModel")
{
  Print("is animated");
}

 

 

The relevant class and function registrations should be:

 

 

engine->RegisterObjectType("String", sizeof(String), asOBJ_VALUE | asOBJ_APP_CLASS_CDAK);
engine->RegisterStringFactory("String", asFUNCTION(StringFactory), asCALL_CDECL);
engine->RegisterObjectMethod("String", "bool opEquals(const String&in) const", asMETHODPR(String, operator ==, (const String&) const, bool), asCALL_THISCALL);
 
engine->RegisterObjectType("Drawable", 0, asOBJ_REF);
engine->RegisterObjectMethod("Drawable", "const String& get_typeName() const", asMETHODPR(Drawable, GetTypeName, () const, const String&), asCALL_THISCALL);
 
engine->RegisterObjectType("RayQueryResult", sizeof(RayQueryResult), asOBJ_VALUE | asOBJ_POD | asOBJ_APP_CLASS_C);
engine->RegisterObjectBehaviour("RayQueryResult", asBEHAVE_CONSTRUCT, "void f()", asFUNCTION(ConstructRayQueryResult), asCALL_CDECL_OBJLAST);
engine->RegisterObjectMethod("RayQueryResult", "Drawable@+ get_drawable() const", asFUNCTION(RayQueryResultGetDrawable), asCALL_CDECL_OBJLAST);

Hi,

I'm working on a Commodore64 side-scrolling action adventure, in which there's a continuous big world to explore, divided in several maps, let's say about 20 of 50 screens each. There are two categories of objects (enemies, items) found in the world:

 

1) Placed in the level editor. For example a turret on a wall or a pistol in a weapon closet. For each of these, 1 bit tells whether it still exists, or has been destroyed or collected by the player. I estimate there'll be about 2000 of these in the game total, so it's 2000 bits of storage in the save state.

 

2) Created during gameplay. For example randomly spawning enemies, and weapons/ammunition dropped by defeated enemies. These can be persisted only until as long as the player is in the same map, as the full position and type information needs to be stored, and are not part of the save state. Dying and restarting from the latest save also counts as a map change, therefore losing these kinds of objects.

 

To avoid unnecessary disk IO and allow for the player to quickly restart the latest save is always in memory, so the whole persistent game state is stored twice in the C64's limited memory. Using more memory for the save state (to allow persisting the "created-during-gameplay" objects fully from the whole world) is not really feasible.

 

Now, the question: do you feel it would actually be better and more consistent to never even attempt to persist the created objects for the duration of being in the same map, but rather teach the player that whenever something dropped by an enemy scrolls off the screen, it's gone? I estimate that this will not present a resource problem to the player, as there will always be spawning enemies from which more resources can be collected.

 

For my personal use (Urho3D engine) I've done some modifications to AngelScript, some of which are dubious, but here's something that shouldn't be much destructive to performance, but reduce the executable size, possibly even by a hundred KB or so, if there's a lot of classes & functions being registered.

 

It has to do with the template functions for initializing asSFuncPtr's. While the original template code memclear's the function pointer object (which is possibly also inlined), and then sets the flag member variable according to whether it's a function or method

 

 

// Specialization for functions using the generic calling convention
template<>
inline asSFuncPtr asFunctionPtr<asGENFUNC_t>(asGENFUNC_t func)
{
    asSFuncPtr p;
    asMemClear(&p, sizeof(p));
    p.ptr.f.func = reinterpret_cast<asFUNCTION_t>(func);

    // Mark this as a generic function
    p.flag = 1;

    return p;
}

 

 

I've created a non-inline constructor for asSFuncPtr, which does the memclear and sets the flag

 

 

asSFuncPtr::asSFuncPtr(asBYTE f)
{
    asMemClear(this, sizeof(asSFuncPtr));
    flag = f;
}

 

 

By using that, the template functions become shortened and should consume less memory:

 

 

// Specialization for functions using the generic calling convention
template<>
inline asSFuncPtr asFunctionPtr<asGENFUNC_t>(asGENFUNC_t func)
{
    asSFuncPtr p(1);
    p.ptr.f.func = reinterpret_cast<asFUNCTION_t>(func);

    return p;
}

 

Generally, an Android / iOS app should do as little processing as possible when minimized to the background. And on iOS it's explicitly forbidded from doing any GPU calls during that time. However, to stay in sync properly in a client/server multiplayer game, the app (client) should still receive and execute any commands sent by the server.

How do you / how would you handle this?

I guess the most problematic thing is if the server changed the whole level or map while the client is on the background, which means the client would have to load a CPU-only representation of the map, and only after being maximized would be able to actually load the map's models / textures to the GPU. Spawning a new game object is the same problem, but in lesser scale.

Easier, but uglier method would be to buffer all network packets until maximized again, but this could lead to huge memory use.

Hi,
has anyone managed to build AngelScript for iOS successfully by using CMake? My problem is the inclusion of the assembly source code file as_callfunc_arm_xcode.S. In the Xcode project that CMake generates, it does not set the "lastKnownFileType" to "sourcecode.asm" for that file like it should, instead it sets it to just "sourcecode". As a result Xcode does not know that it's supposed to invoke the assembler for it.

I wouldn't like to rely on CMake actually fixing that bug, because there is no telling how long that takes, or if they even view it as a problem. But any creative workarounds?

EDIT: for now I went with simple postprocessing of the project file using sed. This has the downside that when/if CMake decides to regenerate the project, also the "postprocess" has to be repeated.