Ashley's Forum Posts

  • It would be better to use four animation frames than four sprites - it makes more sense that way, and you wouldn't need a 'destroy object by name' action.

  • Yeah, add a serialize() to the struct that does ar << a << b << c etc, and the same for loading (ar >> a >> b >> c). Then to save the whole vector, save the size, then for each element, call its serialize(). To load it, load the size, clear the vector, then for each element serialize() it in to a temporary struct and push it back to the vector.

  • Normally you'd just save the size then iterate each element saving them. When loading do the reverse - load the number of elements then for that number of times, load an element and add it to the vector.

  • Not right now, no.

  • A degree of reverse engineering is always possible in all programs (if you had the tools you can disassemble any compiled program back to assembly, for example - and this is especially problematic for .NET I think, which relies on obfuscators).

    Considering the amount of work it'd take to reverse engineer a Construct EXE I'd say it's implausible for now - and remember you lose all edittime-only things like comments.

  • You can't (and wouldn't want to) manually save the states of the CRunObject or CRunObjType classes themselves, but you can save pointers to them by using these VRuntime functions:

    	virtual void SerializeObjectPtr(CRunObject*& obj, bin& ar) = 0;
	virtual void SerializeObjectType(CRunObjType*& pType, bin& ar) = 0;[/code:3qpx6ba0]

  • Posting a .cap might help (it's always a good idea IMHO). I think the issue is that you're getting confused with the 'custom' setting - it means you use an action to add the object types that cannot be seen through.

  • You do not have permission to view this post

  • The technical response to this thread:

    The best way to measure the framerate is Mipey's method, and it is also already described on the wiki because it's very common. There is no system expression to retrieve it, but it is trivial to set up the events.

    The correct way to get the instantaneous framerate - which is how many ticks would run in a second if every tick ran as fast as the last single tick did - is 1 / TimeDelta. However, this does vary a lot. The timer is almost perfectly accurate - it is correctly measuring fairly large variations in TimeDelta, which happens for various reasons (eg. the combination of Window's process scheduling and Vsyncing meaning occasionally a Vsync is missed and TimeDelta being around double the normal value). This does tend to make the displayed value unreadable though, because it varies so much. This is why I would prefer the previous method.

    Cheez, you are on your way to a temp ban with your attitude, and you've been like this before. I feel your original "Don't tell me they forgot to add that in" and "should have existed from the very start" is belittling as if we are too stupid to think of putting that in, especially since you could have simply phrased it as "how about adding it if it isn't already there?" like most other forum members do. The rest of your posts have a generally bad and unhelpful attitude. Some people have responded badly but I think you are responsible for winding up, so please chill out and don't make me need to log in to the admin control panel in future.

    I am satisfied my response completely answers the original question so to cool things off I'm closing the thread.

  • There's been much discussion on this before - the short version is DirectX 9 hasn't got native support for vector graphics. Everything is drawn raster by the graphics card so the only way to do vector is to first rasterise it, which is potentially slow to do every frame. I think DirectX 11 might change that, though, but it'd be Vista and up only.

  • It's a nice idea - but I think it's a similar situation to coding for Linux - if not many people have it, we can reach more people coding for mobile devices more people have... wasn't there something called GP32 before this with similar aims? What happened to that?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Construct uses the trig math method. There's no other reasonable way! If you thought the graphics card could do this, just sending the message from the CPU to the GPU instructing it to perform the calculation would take longer than just doing the sum anyway, so I think you're misleading yourself. It can't really be done any other way!

  • OK, you should be editor now.

  • It's a limitation of the Box2D physics engine that we use (I'm not sure what units it uses). You can create a higher angular damping by applying an opposite proportional torque.

  • It's possible, but given that we're all volunteers working in our free time, we'd rather hit the big market. Someone else is free to make a Linux version since it's all open source, but I doubt anyone will.

    Edit 24th November 2009: removed some bot uselessness.