Ashley's Forum Posts

  • Call pRuntime->CallOnFrame()/CallOnFrame2() to start calling OnFrame/OnFrame2 again.

  • Sorry, it looks like us devs are all a bit busy this summer! But don't worry, we should have a new build out in a couple of weeks with bug fixes.

  • Check out a tutorial if you haven't already - Ghost Shooter covers private variables for storing enemy's health, for example.

  • You're missing lots of stuff, and you might cause problems in the event engine if you don't do it properly. Here's a snippet of how the File object does 'for each directory':

    long ExtObject::cForEachDirectory(LPVAL theParams)
{
	CDiskObject Obj;
	CStringArray Files;
	Obj.EnumDirectories(GetStringParam(theParams, 0), Files);

	EventParametersInfo2 epi;
	pRuntime->GetCurrentEventPtrs(epi);

	for (int i = 0; i < Files.GetSize(); i++) {

		curDir = Files.GetAt(i);

		pRuntime->NewSOLCopy();

		if (epi.pCnds && !pRuntime->RunConditions(epi.pCnds)) {
			pRuntime->RestoreSOL();
			break;
		}

		if (epi.pActs)
			pRuntime->RunActions(epi.pActs);

		if (epi.pSubEvents)
			pRuntime->RunSubEvents(epi.pSubEvents);

		pRuntime->RestoreSOL();
	}

	return false;
}[/code:3da8vbc0]

You have to do all of the loop contents there - they all take care of some important apsect of picking and running events, so you can't skip any of it.  Except, of course, [i]curDir = Files.GetAt(i);[/i] is simply there so the file object knows the current directory to retrieve in expressions.

It's pretty complicated, but basically you'll notice the condition returns false, meaning the event runner in Construct stops running the event.  Instead, the code in that loop essentially hijacks the event runner, running the event actions and subevents manually, in a loop.  It works recursively so it works with two looping conditions in one event.

If you want to pick a particular object in an iteration, after the call to NewSOLCopy(), do your SelectAll() followed by Select() (and, of course, set the SOL_MODIFIER flag).

  • Yeah, they're only four bytes. Pointers, to any type at all, are just an address in memory. The type of the pointer (eg. the type of thing at that memory address) is just for the compiler, so it can tell if you're accidentally trying to get an X from the memory address of a Y. Also, if you use a vector, it won't use (much) more memory than you need, so I'm sure your 1000s case is unrealistically extreme

  • I'd advise against going over 1024x1024 since the runtime requires temporary textures the size of the window and some video cards will create a 2048x2048 surface for anything bigger.

  • I think I've said this before, but simply the existance of a large number of objects can slow down the event engine and collisions engine, so you might want to avoid that anyway if you can... why might someone need to create thousands of objects anyway? What's the purpose of all of this?

  • vectors in particular seem to have a bad reputation in game dev use

    I keep reading that vectors, and the stl in general are very inefficient

    and that they are strongly discouraged in game use, and forbidden in some studios altogether

    I'm one of the complete-disagreers. The STL, especially vectors, are no slower than the equivalent code with ordinary arrays and new/delete, and sometimes faster, because they are very cleverly written. In MSVC++, though, you need to define _SECURE_SCL as 0 otherwise it adds a lot of security checking to the STL containers, which is where the myth about the STL being slow may have come from. There's another define for iterator debugging, which is invaluable for debug builds, but should also be off in release builds. Then the STL runs perfectly fast, and it's so invaluable to writing code I honestly don't know what I'd do without it, so I wouldn't hesitate to use it thoroughly in games.

    You do have to be careful sometimes though - there are some tricks for optimal performance. Vectors have to resize their internal memory if you insert too many items, which means allocating new memory, copying everything, and freeing the old memory. If you clear() a vector it frees all of its memory, then if you push_back 1000 times it will need to keep resizing its internal memory to fit in the new data. This can be slow, but a useful tip is calling resize(0) returns the vector to an empty state, but keeps the memory capacity, so you'll need to add at least as many items as it used to hold before it reallocates. So if you bear that in mind you'll find vectors are overall at least as fast as not using vectors - so use them!

    [quote:324uqtj5]

    C: what is sizeof(CRunObject*) can I make a thousand or 2 of these without a crippling ram impact?

    The size of any pointer on a 32 bit system is 4 bytes! The size of CRunObject, on the other hand, is not specific - plugins have different sized classes and the runtime never assumes they have any particular size.

    Creating a thousand Construct objects is almost universally a bad idea and I can't imagine why you'd want to do that. What are you trying to do?

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • Just those simple formatting tags. It won't show full pages.

  • Maybe post a .cap of a simple WAV file playing not working.

  • Deadeye's right, anything that changes continually over time needs to use timedelta, including acceleration, rotations, opacity, sound effect volumes (eg. if fading out), effect parameters etc. etc. Otherwise, your opacity based fade is tied to the framerate, and the framerate could be anything. The Fade behavior is, of course, framerate independent.

  • I think Rich made that object, maybe he can comment. In the meanwhile, is there anything on the bug tracker about it?

  • The sound files were originally .wav. I had to convert them to .wma because it won't work any other way. If I try using them as .wav, and use "autoplay resource", the sound won't play. Just silence.

    Then you should submit a bug report for that and try and get that fixed, because 'play music' certainly is not intended to play your sound effects, which may well be the source of this problem.

    Note that only WAVs with certain codecs work with XAudio2, see the wiki for more info.

  • Mort is right, you can't combine Physics with other movement behaviors, otherwise the Physics sees the object as teleporting short distances every tick.

  • Would that be doable with a custom plugin?

    No, there is no interface provided to plugins to do this, and the runtime doesn't support it. The SDK doesn't have the capability to fundamentally change the way the runtime works, it merely communicates.

    Besides, if you could, how would you add events to the new object type? It couldn't possibly appear in the event sheet editor.