Ashley's Recent Forum Activity

  • > 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.

    >

    really? so it'll kill the speed at 1920x1200?

    It'll just use a lot more VRAM, that alone won't slow it down. But I imagine rendering a lot of objects at that high a resolution could be slow anyway, since you're simply pushing so many pixels to the screen.

  • 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.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 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?

  • 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.

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,443,625 followers

Connect with Ashley

Trophy Case

  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Forum Wizard Made 5,000 posts in the forums
  • Forum Unicorn Made 10,000 posts in the forums
  • Forum Mega Brain Made 20,000 posts in the forums
  • x109
    Coach One of your tutorials has over 1,000 readers
  • x63
    Educator One of your tutorials has over 10,000 readers
  • x3
    Teacher One of your tutorials has over 100,000 readers
  • Sensei One of your tutorials has over 1,000,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • RTFM Read the fabulous manual
  • x36
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs