Zotged's Forum Posts

  • Do this.

    The window size is an application setting.

  • Looks like it's related to Visual C++. Maybe you should try reinstalling Construct and remember to allow the VC++ installation. I don't remember which version of VC++ Construct makes use of because I have uh... plenty of them installed.

    <img src="http://i.imgur.com/jFdti.png" border="0">

    If reinstalling Construct doesn't do the trick try installing either the latest Visual C++ redist. or one of the 2008 redistributables. Someone else might know which exact patch is the one you'll need if the problem is related to VC++ at all.

  • It works simply because the next layout won't (obviously) render at all until it's fully loaded and thus during the transition between layouts the last rendered frame of the previous layout is shown but not updated. This means that until the actual game layout is ready to start you'll see only the loading screen layout.

  • As I said it does show the true loading process. If you fill a layout with sprites you'll definitely see the loading screen, which will disappear once the layout loads. This is exactly what it does.

    Unless you have some data loading written by you, such as a level editor, or you're fluent enough with the plugin SDK you could have a progressbar or whatnot. This however is exactly the way you do a loading screen and there's little to argue about.

  • This way. Press 1, 2 or 3 to switch layouts. The layouts are nearly empty so the change of layout is instant but if you have multiple objects the loading works exactly as you'd expect it to; once the layout loading is finished it'll change layouts.

    You store the name of the layout you want to jump to in a global variable. The loading screen has only one event that jumps to the layout stated by the variable. Every time you switch layouts you'll do it the same way: set the variable and jump to the loading screen layout.

  • I'd count our (mine these days) project Stray Senses as one, too. Development has been bumpy for three years and limited to art and assets for the ongoing year but I'll get to it once I'll have a decent desktop to work on. My 2008 laptop doesn't run this. At all.

    It's originally designed with a 'S.T.A.L.K.E.R. meets a Silent Hill' -ish premise but, depending on how demanding turns the development takes, I'm fairly sure I can't deliver the original design at least not by myself. We'll see.

    <img src="http://planar-studios.com/ztg/img/proj/planar/ss/ssdev_1.jpg" border="0">

    I've pasted this screenshot so many times. (I like it so so much)

  • You can do this very easily by making use of the Dropshadow object. Also there's a dropshadow shader that can do this in a similar, albeit not as flexible, way. Being a shader effect it'll also take far more GPU cycles in some situations especially if you have hundreds of objects. Although you could apply dropshadow shader to an entire layer thus reducing the required shader passes to only one that spans the entire screenspace.

    This one uses the Dropshadow object; I found it far more intuitive for this:

    dl.dropbox.com/u/326175/dropshadow1.cap

  • Silver: maybe you could copy a single sprite to another layout and give it the behavior there. It's worth trying. A word of advice though: sine can be quite an fps crusher (at least when it comes to opacity changes) so you might want to experiment a bit if things get icky. Maybe consider using a prerendered animation if fps becomes an issue.

    Edit: yeah as a reply to your post below: you wouldn't actually have had to make it global at all, just copypaste it to another layout and add the behavior there. Yup I figured that that's the kind of thing you're using the sine for.

  • 1, 2, 3: short answer no. Long answer yes.

    To be blunt: yes it's technically possible but it's not going to happen. There hasn't been ANY games made in CC that have done this. While there are network implementations in both Python (PodSixNet) and other libraries, none of which I've followed lately, extensive networking capabilities aren't there.

    Your third question about lag is closely related to what I said: I recall that even one of the more popular and complete network plugins didn't have interpolation (which is essentially data prediction to contravene the inevitable effects of lag). There haven't been any P2P networking plugin releases that I'd know of so you'd have to utilize traditional sockets anyway.

    All in all networking is something that is more often than not immediately out of question for developers with diminishingly little experience.

    4: Sure, look at the behaviors you can add to objects. Construct isn't a package that supports only certain kind of gameplay similar to, say, RPG maker.

    5: Yeah. You'll just have to have a system that remembers a few numbers that you'll be able to use as positions. It's almost laughably easy once you grasp the concept.

    5b: Can be done instantly with built in features. Just have a sprite with Mouse-behavior and tick Center view on me -attribute. It'll need some tweaking though, because the mouse coordinates will change every tick (the game progresses with ticks that for the sake of convenience can be perceived as frames, although they're not one and the same) and the movement will be very quick.

    If you want to scroll when the mouse touches the edges you'll have to compare the mouse coordinates (mousex,mousey), or whatever you use as a cursor, and move the screen accordingly once the cursor is close enough to a viewport edge.

    6: Definitely. There's a built in behavior for Line of sight that can be utilized. If you mean literal fog of war type of darkness, sure, it's easy too. For example you could have a non-transparent pitch black layer with the Multiply-shader. Once you add white objects (similar to built in object Light) to it it'll show through. There's so many ways to do this.

    7: Of course you could. "Anything" is possible gameplaywise. Think of it as a tool, not a mold.

    8: Yeah, in fact it's a built in feature.

    Edit: Disregarding the first three points it doesn't really make a difference whether you want to work with Construct Classic or Construct 2. CC is in its own right more mature and has plenty of 3rd party plugins around. CC also has stackable HLSL shaders, which elevate its graphical capabilities beyond outstanding. C2 on the other hand has had a much more structured approach on its development and is quickly approaching CC's level in both performance and features. C2 however isn't there just yet. C2 does have much more support though, CC is essentially a community supported piece of software nowadays.

    CC is open source and isn't restricted like the free version of C2 is so you might find it more comfortable to learn game development with. Either way knowledge on CC translates to C2 and other way round in case you want to make a switch at some point.

  • Roughly said any CPU can run CC games unless you're doing some crazy Python things similar to what Lucid used to (an animation system with something like 1000 Python operations per tick per bone, or what the hell was all that about?).

    If you want to come up with some indicative numbers on paper look at the VRAM usage, double that and round it up to the nearest power of two. Say, if your game uses 37 Mb VRAM your system requirement would be 64 Mb assuming half of it is reserved for the system (assuming the user has Vista or 7, which have DirectX windowing, XP doesn't).

    Edit: clarified explanation a bit

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • The objects are loaded from the entire layout yes but only the ones visible in the current screen space are rendered thus manually swapping between visible and invisible isn't going to make a difference (and might even cause an actual additional loading header, but being a binary comparison every tick it's not a real issue).

    There are special cases, though, for example disabling shadow casting Light objects disables the shadow rendering too. This became a crucial optimization to a project where we have hundreds of lights but only a couple visible at the time. All of the lights were technically casting shadows (even though they were out of range to even render!) which totally butchered the rendering speed.

    Sprites in CC are quads just like in C2. Having thousands of large sprites definitely ups the loading time. To keep it within reasonable boundaries you might want to have several medium sized layouts you switch between. For example the project I mentioned has somewhere between 2000 and 3000 objects per 2560x2560 pixel space (which is the used layout size) and it takes around 20 seconds to change layouts.

    Edit: Forgot to answer the actual question: in principle the more objects you have on LAYOUT causes longer loading times. The more objects you have on SCREEN causes lower FPS.

  • I still strongly believe that CC flew under the radar for a far too large a demography. Its capabilities are simply outstanding in comparison to other much more popular solutions like GM or anything Clickteam has ever even dreamed of releasing. It definitely doesn't pale in comparison even though its development has been bumpy at best for the last few years.

    But times do change even though I'll echo what Azu said about web gaming, I have little interest in that.

  • It's a tad hard to point fingers at the issues since personally I'm too used to working with CC and its quirks, really. One that instantly comes to mind though are some annoying event sheet editor problems, like drag'n'dropping of events being a surgical operation or issues related to selecting events and such.

    I've also ran into some shaders that need minor fixing by hand, like changing the defined pixel shader version. Some plugins are buggy too and have been for years. There's a lot of this kind of things on the bug tracker.

    Generally some things don't work like you'd expect them to but like I mentioned you'll get used to them.

  • <img src="http://i.imgur.com/CTHyp.png" border="0" />

    I was aggravated already but this made me snap. More people ought to be able to kill this on sight.

    edit: GRRR

    <img src="http://i.imgur.com/1v5oP.png" border="0" />

    <img src="http://i.imgur.com/3OIcf.png" border="0" />

  • The real highlight of CC is the stackable shader effect pipeline, which extends the graphical capabilities beyond belief, and (obviously) far surpasses the C2 renderer. CC is good to start with due to the fact that it's OSS and packed with features while the evaluation version of C2 is rather limited.

    Many of the available CC tutorials are fairly outdated if not straight up obsolete. Despite this the CC wiki still holds a good amount of useful information. Knowledge on CC translates to C2 swiftly so you have little to lose if you try a bit of both.

    edit: fixed typo