Ashley's Forum Posts

  • The 2.0 SDK should be compatible with a number of compilers. The 1.0 SDK can, in theory, work with other compilers, but they have to implement member function pointers with a compatible binary format, and support ATL.

  • <img src="http://www.abikestore.com/Merchant2/graphics/00000002/mtb_gmc-topkick.jpg">

  • I think it might be better if the sine behavior has a 'value only' mode, where it simply stores the value of the current oscillation. Then you could do 'always - set <anything> to self[sine].value' or something like that. Skew, private variables, meshes, can do anything that way.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • It's not a DEP issue, the plugin was configured incorrectly. It should be fixed in the next build.

  • It might be badly installed to the case, a loose screw could make it buzz. Maybe tightening everything up would fix it. Did you install it yourself?

    If the wattage is sufficient don't be fooled in to thinking higher wattage equals more quality - you should get the lowest wattage that covers your computer, then find a good model. Once I bought an el cheapo PSU and it exploded after six months. 500W should be more than enough for most desktops if you actually calculate the peak power consumption.

  • just tried it with 3d enabled, but now the shadow is passing threw the hills.

    If you don't want something to be obscured by 3D objects, put it on another layering with '3D layering' off.

    [quote:2l59c07o]Is there a way to disable z depth sizing, and still keep z height?

    No, the runtime is using a real 3D engine with perspective, and since something closer to you is bigger, that's what happens. Besides, I don't think it makes much sense to have 3D if it doesn't do that... isometric isn't real 3D, so you'd use other layering methods for that.

  • Event based programming is completely different to scripting. To give you a feel for it, try one of the tutorials.

  • I've no idea what this code is meant to be doing, but some quick observations:

    • Don't use C++ terminology in events (avoid referring to pointers or other programming terms unless they are truly appropriate)
    • %o (letter 'o') in action text is your object icon, not the first parameter - the first parameter is %0 (number zero)
    • GetObjectParam, GetLayerParam and many other functions in the SDK are allowed to return NULL eg. if the user types the name of a layer that doesn't exist - always check for NULL pointers
    • Why does your 'create object' action define an object type parameter as PARAM_VALUE?

    Anyways, there's nothing in this snippet that tells me why it wouldn't work. If you debug the call to pRuntime->CreateObject, what are the values of the parameters?

  • That's cool, but you didn't enable 3D layering for that layer, so the hills glitch in certain places. Then when I enable 3D layering, the hills are so high the chopper disappears inside them!

  • If you're new, many of your initial questions may be answered by trying a tutorial.

  • What do you mean by overlapping? You want two sounds to play at the same time? If you read the XAudio2 documentation you'll find that 'autoplay file' or 'autoplay resource' will pick a free channel to play a sound on.

  • I thought it would also be good performance-wise

    Bad assumption! A 2048x2048 texture will take up a huge amount of VRAM. Construct is 100% hardware accelerated, which uses the graphics card to render the game, and VRAM (the memory on the actual graphics card) is an important consideration when creating a game. A 2048x2048 texture uses (2048 x 2048 x 4 bytes/pixel) 16mb of VRAM. Some people still have crusty old 32mb video cards hanging around, and these tend to be half full of system stuff already, so you might have already eliminated those users from being able to play your game already - with one background texture.

    When designing a hardware accelerated game, it's always better to make levels using many small textures rather than single big ones. It's even better if you can do as much as possible with a Tiled Background object with a power-of-two size texture (eg. 128x128, 256x256...). You may think it would slow down rendering a bit having lots of small images on top of each other, but in many cases, surprisingly, you may actually measure zero change in the framerate! (This is because of the way the CPU and GPU work in parallel together) Even if you can find a difference, it's such a tiny change it's not worth bothering with at all: graphics cards can render simple images shockingly fast, generally only things with effects will impact the framerate.

    As for your filesize issue, Construct doesn't care what the source image is when you import it. It copies it to an internal image, so the format or optimisation of the source file makes no difference.

    Edit: linkman, images are compressed PNGs when they are stored in Construct, but they're lossless but not optimized.

  • Currently the camera is stuck looking down at the layout. It might be possible to support a camera that can be located at any position and looking at any position in Construct 2, however, even if that is possible, we'll still be focusing on Construct as a 2D game creator.

  • You do not have permission to view this post

  • at runtime MyInt stays unique to each instance of the plugin

    pMyPointer is like one variable shared by all instances of the plugin

    No it's not! If you wanted it shared, you'd declare it static, but since it's not, a copy of the pointer is held by every object instance. They could all point to the same object if your code does that - but each instance is holding a separate pointer which can be uniquely changed.