Posts by CeriJC

Welcome to our brand new Clickteam Community Hub! We hope you will enjoy using the new features, which we will be further expanding in the coming months.

A few features including Passport are unavailable initially whilst we monitor stability of the new platform, we hope to bring these online very soon. Small issues will crop up following the import from our old system, including some message formatting, translation accuracy and other things.

Thank you for your patience whilst we've worked on this and we look forward to more exciting community developments soon!

Clickteam.

    Hello all, it has been a while. Rest assured, I've been happily clicking these intervening years. :)

    Just interested to hear what people use to run the games they've made in Fusion? To clarify, just talking about where you run the completed games: Not your 'development environment' machine.

    I've used Android on phones, tablets, Windows XP, Windows 7 and Windows 10 machines. I know about the various exporters.

    In terms of reason for my question, aside from just my interest:

    In a perfect world, I'd like some sort of single-board computer that'd be able to run some sort of minimal OS that is fast to boot, direct to the game, for use in a straight to TV console/arcade cabinet. I don't lean heavily on extensions, but I do tend to use the Viewport and ideally would like to be able to use Shaders.

    Thanks in advance folks. :)

    +1 on amiman99's comment. TxK is sorely overlooked.

    If I was doing a Tempest style in clickteam, rather than the "more obvious" solution of high resolution display to simulate vector graphics and 3d extensions, I'd be inclined towards using sprites and scaling them, to create the effect of them coming down the tunnel. It'd look blocky, but I think you could end up with something nostalgic of the old Sega games like spaceharrier, etc. in graphical style.

    On a related note, Tempest-type games really benefit from spinners. If you fancy making your own, use mouse controls in clickteam and then build one of these:
    Please login to see this link.

    Ouch! That looks a nasty bug. I know from past experience that when they change the pipeline (typically to make it *more* tweakable/programmable) in new graphics card architecture, it can make for big problems that are often non-trivial to patch with regards running functions designed for the old card. :|

    Schrodinger:

    Sorry for delay replying, real life got in the way for a bit and I've hardly started Clickteam up the past month but getting back into it.

    1. Thanks for you help, oddly, I upgraded to the latest version of clickteam (didn't update viewport) and it now works great, even not having updated the viewport itself. Just about to go and test the real CRT works perfectly on the viewport/border setup I have, but I'll be amazed if it doesn't now. :)

    2. I'm certainly "up to something". ;) Now I've got all the other bits in place, my main focus will be on the shader. I am certainly a noob with shaders' syntax (and certainly HLSL's), if not the concepts. I did my undergrad thesis on procedural textures, which shares a lot of the same concepts so, I feel I'm picking it up much faster than someone without that background, but I'm a long way off being a guru! That said, I certainly feel I owe you one (several) and if you want to send me a PM I'll try and help, even if it'll take me a few weeks to get to the level where I can be of any use.

    Hi Schrodinger, you remember correctly! ;)

    I'll try '1.' . Please can you confirm what the 'correct' way of getting the Viewport (version that you have, that works) into Fusion and the specific version of Viewport that you have?
    EG did you use "right click, insert object, manager, viewport, install", or did you do it the old MMF2 way in windows folder (in which case, where did you get the .mfx files and where exactly did you put them?). Many thanks!

    2. The workaround I was doing earlier involved using a large, semi-transparent active (consisting of black horizontal lines), continually brought to the top layer. Previously, it wasn't working well at fullscreen, because, as you suggest, the scanlines themselves scaled up and looked much too wide. Losing 1/4 pixel (IE, one physical pixel at x4 magnification) is fine as your eyes see the other 3 pixels representing that (one) pixel and your brain does a great job of filling it in. The problem is primarily that 'whole frame' shaders apply over the top of the 'border' area (see above diagram) which is fine if the border is solid black, but terrible if you make it look like an arcade machine's bevel lined with 'stickers' as I'm doing for this game.

    What it is that I dreamt of, which now seems painfully obvious (as is usually the way with these things), is that you can write shaders to have a 'virtual resolution' and only apply the visual effect to certain areas of the frame. In this instance, I'll just make the shader whole frame, but only apply the effect to the area covered by the "Viewport" bit in the above diagram. It'll mean needing to mod any shaders used to make them compatible with these specific ratios/borders, but 'meh' I was planning on making my own, or at least porting a GLSL one anyway. :)

    Fingers crossed, the outcome will be, I'll have a 1920x1080 application, with a "Faux-CRT" option for use when it's used on a modern screen. That'll be a shader, which can be turned off when run on a real CRT. The ratio of the borders is such that when the 1920x1080 is output to a real CRT (through a hardware scaler I have), the same application, with no other sizing will display fullscreen in 4:3 ratio: It'll just be the border that's left out. The only potential stumbling block I can see (aside from my HLSL skills not being up to the job X)) is that according to how the shader pipeline is implemented for "whole frame" shaders, I might end up having the shader applied twice for areas of the screen covered by the viewport. Oh well, easy to test and I'll know soon enough.

    Wish me luck!

    mobichan, sorry for the late reply, I forgot to turn on subscriptions for this thread!

    Firstly, I am not an iOS exporter user, so cannot check, or be sure, but I believe that the Shaders are not supported in iOS. I think that they are Windows only, sadly...

    I have not progressed with porting it since my last post, largely because I've been working on getting my game scaling up properly using the Viewport extension (I wanted to avoid spending hours of effort on porting it, if I could not run it the way I wanted to in the particular game I'm working on).

    Back on topic: I still want to try and fix this Please login to see this link.I'm having first, but when (if?) I do, I'll resume working on this.

    If you subscribe to this thread, I will update it when I come back to this.

    In the meanwhile, you might be amused by the old-school 'workaround' I've devised in the meantime: Running a Please login to see this link. and using the Viewport extension to resize it so that the game appears in 4:3 aspect ratio, filling the TV screen perfectly.

    1. Firstly, I have next to no experience of extensions (aside from the Android ones), so please assume I'm an idiot/n00b. :)

    Until now, I've consciously avoided using extensions, because I regularly port my projects to/from Android/Windows and rather than keep track of which are supported on which platform and then hit Please login to see this link. type of error when I come to build a project, I leave them out.

    For something I'm working on (Windows only), however, I've had to use resort to using Viewport, as there's no other way of doing what I want to achieve. It seems to be working great, but when I build it I get that dreaded message,

    "Warning the following extensions are not compatible with this build type:

    Viewport.mfx

    Do you want to build anyway?"

    The Viewport works exactly as expected when running the frame/application within Clickteam, it's only on build that it fails. I've double-checked and the build type is, "Windows EXE".

    I don't understand why I'm getting the error, I thought Viewport *was* solely Windows-specific? I'm using R281.1, Clickteam Fusion 2.5 (standard, non-developer version). Is there anything I can try/check?

    ----

    2. One other Viewport related question: Is it possible for me to apply a shader to the Viewport display?

    Essentially, what I want to do is use a viewport to "magnify" an area of the frame's field and then apply a shader to *just* the viewport, not the whole frame. The nature of the shader concerned precludes my applying the shader to every object/backdrop within the magnified area as a workaround. Under other objects' "Settings" or "Display Options", there's normally an area where you can edit the 'Effect' and stipulate a shader. Viewpoint seems not to have this. Is there any other way of applying a shader to it?

    Please login to see this attachment.

    Alternatively, is there another extension that does what Viewpoint does that supports shaders in the way I describe?

    I've found a good trick when making spinners (that you don't want the player to be able to 'game' with 100% accuracy once they learnt it) is to add a 50% chance that 0.25 seconds *after* it has stopped to move one position on. It also creates a nice moment of excitement/worry when it has landed on (or one space short of) something they want, waiting to see whether they'll get it or not.

    Because it is so soon after the spinner has stopped, the effect is just that the spinner is moving very slowly.

    Hope that makes sense?

    Sorry, can't open the example as not at my studio. For examples like brick games, where there will be more than one of the same object (IE, Brick) you're better off using alterable values of the object to be destroyed, rather than counters. The reason being, this way, you can write the event that decreases the block's health once and it'll apply to all blocks you create, even those spawned mid-game.

    Thanks for the tips.

    I think one I'd add (as a general game tip, but especially true for mobile devices) is that you should always default to mono sounds. Then, for each sound, think if you can really justify the "cost" of stereo for that particular sound.

    You should really think about the environment in which it'll be played. I remember studying multimedia in a lab where the (tower) PCs had a built in soundcard at the front with two tiny speakers six CM apart on them. To quote my lecturer, "Unless you have an exceptional facility for detecting stereo width in your left knee, you should be using mono!" The same is equally true of phones. Even though a large modern smartphone will use clever phasing tricks to make its "stereo space" sound bigger than the couple of inches it really is, as Fernando says, it's still not like being in an opera. ;)

    It's not appropriate in all games of course; in horror games where you will be encouraging players to be playing in the dark, with some headphones on (even if it's on a phone/tablet) stereo will probably be worth the cost of it.

    For a Flappy Bird clone though? Mono every time.

    I produce electronic music and used to DJ a lot. One thing a lot of non-musicians will probably be surprised to hear is that a lot of things actually sound better in mono. I think there's probably an innate sense in most people (particularly the 30-somethings who can recall stereo sound in games being a new and exciting thing) that Stereo must be superior. It's a common technique in many genres of music to "narrow" the stereo field of particular sounds, particularly basses and drums, or even convert them completely to mono. It's slowly going out of fashion and becoming stereo (as very clever room dynamics processing becomes more affordable), but the majority of nightclubs you'll have been to will have had mono speaker systems and until now, I bet you never noticed! :)

    What does this mean in games? In anything retro styled or 2D, SFX like a "jump", or "coin get" should almost always be mono: Think about it, the player picked up a coin in on place, not two! Unless you want to give a real sense of space and draw attention to the 'echo' of the sound off the block to the left of the coin, stereo on something like this will add nothing.

    Hi All,

    I hope that this is the most appropriate place to post these. This is the first time I've shared any files on the forums.

    An old friend and I running our own game jam and one of the restrictions we've placed on ourselves is 4 colour palettes only.

    To get a bit of a head start, I made 3 palettes this morning and I'm happy with how they turned out. Each includes the RGB values of each colour.
    Why am I sharing here rather than on a more general videogame palette site? Because these are "optimised" for Clickteam, in so much as each colour exists within the default palette of the built-in editor. This makes it really quick to do edits as you learn 'where' the colour is (and don't have to keep selecting the dropper tool). This makes them a lot quicker to work with.

    So, without further ado.

    Palette:"Tinytim"
    Notes: Strain your eyes unnecessarily with this murky green palette. Use to simulate a popular handheld.
    Colours (top to bottom):
    1. You call that white?
    2. Goblin Green
    3. Swap Ivy
    4. Stagnant Lagoon

    Please login to see this attachment.


    Palette:"So 80's"
    Notes: It may have been acceptable then, but who'd choose these colours now? Use to simulate CGA games, or to coordinate a narcotics bust that you're conducting off the books.
    Colours (top to bottom):
    1. Bolivian White
    2. Cloudless Blue
    3. Flamingo Pink
    4. Burnt-in CRT 'Black'

    Please login to see this attachment.


    Palette:"Midnight Shadows"
    Notes: Inspired by Lemmings 2's Shadow Tribe. Use for Splinter Cell Demakes, or 2D re-imaginings of Zork.
    Colours (top to bottom):
    1. Sodium Vapour
    2. Stealth Grey
    3. Moonlit Sky
    4. Coalmine at Midnight

    Please login to see this attachment.

    Would be cool to see any projects you make that use these and if they're helpful, give me a shout out in your game (but this is not necessary). :)

    1. Tried sub-apps at lunchtime. Looks promising, but I'll need a couple hours' more poking, will report back with outcome.

    2. Ooh! Now we're talking. :D
    Viewport could well be the answer. Haven't ever played with that, but from the description it sounds right. I see they're
    currently having some Please login to see this link.with it, though.

    With regards the zooming/shader bit, if it fixed it, it'd be great: It'd allow me to display a zoomed in 336x240 ("blown up" by a factor of 4) and then apply a 'scanlines' effect and crt distorition, etc. at the higher resolution and then overlay an image like an old arcade machine "screen decal" over the top of that.

    In terms of other ways to test what it's actually displaying, theoretically I could borrow an expensive (and reliable/trustworthy!) 400fps camera and film a simple app running that just has a big number counter incrementing each frame and see what sort of proportion wound up on film.

    My first method is to use groups hierarchically as much as possible so it's easy to collapse whatever is not relevant to what you are currently doing.

    Agreed; when thinking up a set of related actions (EG, Player hit by bullet, reduce player's health, if health is 0 then die and drop items), I always put these under a single heading, for example "Dealing with player being hit". If nothing else, it makes it quicker to collapse and more legible. Where it gets even more useful is where you can make the enabling/disabling events (which is a great practice, but very time consuming and easy to do wrong if you don't approach it in a structured way) just disable the 'top level' group, rather than each of the sub groups. Of course, you can't always do this. So, in order to make it more legible, I have a comment (in a particular comment) at the top of each group and sub-group that details whether this is "self-disabling" or not.

    It's one of those things that slows you down writing the code, but it saves so much time when bug-fixing or revisiting old code that overall it saves you time.

    So, original problem solved, but two additional queries have now arisen (isn't that the same with every area of learning? :)):

    1. Is there any way to make number of fps specific to a frame and not the whole application (possibly using sub-apps?)

    2. Clearly my monitor isn't even capable of actually drawing 400fps (see previous post). Presumably, it is 'dropping' frames. Is there a way to control *which* frames are dropped, or better yet, have 1000 frames per second for the timing purposes drawn in this thread, but have some event that effectively says, "only redraw the frame every 10th frame"?

    Thanks!

    Call me obsessed with arrays, but if your system used arrays instead of INI, you could run a nested loop through the main array and simply have the other array copy each index. So you effectively have a "copy" function. Might also make checking for corruption easier, since you can move through cells the same way and compare.

    For sure. Presumably, you could even (if you're not using all 3 dimensions already) use an unused dimension in one array for the 'mirrored variables' and even do it with one logical array. :)