Posts by UltimateWalrus

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,

    I needed to port Please login to see this link. to OSX, but it relies heavily on effects, so the Mac exporter wouldn't have been helpful. I've seen pretty impressive results from the Wine emulator, so I wanted to make a wrapper using Wineskin. This brought me to the important realization that, at the time of this writing, Wine is actively maintained, but Wineskin isn't. I ran into too many bugs with Wineskin, and could never quite figure out how to get the audio to work. So, here is a guide on how to create a Wine wrapper without Wineskin. (The guide assumes your game is named Snake2_DX_Reawakening.exe)

    1.) Get the latest version of Wine Stable.app

    2.) Copy and paste Snake2_DX_Reawakening.exe into Contents/Resources/start/bin inside the package

    3.) Script “Content/Resources/start/bin/winehelp” will run on start. Delete contents and change it so it’s just

    DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" >/dev/null 2>&1 && pwd )"
    wine "$DIR/Snake2_DX_Reawakening.exe"

    4.) IF THE GAME CREATES FILES, IT’LL NEED PERMISSION.
    From Finder, do “Get Info” on every folder in the chain of “Contents/Resources/start/bin”, click the lock to unlock, then give everyone Read & Write permissions

    5.) Content/Resources/winehq.icns : change this to your icon. Keep file name the same. The icon may not change right away but if you copy/paste the app you can see it works.

    6.) Rename the app to the name of your game! Done!


    Note that the game will spawn a terminal window that doesn’t go away when you close it. Not sure how to get around that, but it's good enough for my purposes.

    Hi all,

    While I know about the bugbox for reporting bugs, I thought I would post this here so anyone who wants to can use my workaround in the meantime.

    There are some inconsistencies in the way Fusion handles collisions on PC, and the way it handles them in the iOS exporter.
    1.) When using box (non-fine) collision detection on PC, you can still rotate the objects, and collisions will be handled between the two rotated bounding boxes. However, in the iOS exporter, a big imaginary axis-aligned box is drawn around the rotated object and that is simply used for collision detection (it does not handle rotated bounding boxes).
    2.) When doing fine vs. box or box vs. fine on PC, fine collision detection still works. It just tests the bounding box of the box object against the mask of the fine object. However, the iOS exporter doesn't have this capability; it simply assumes both objects are boxes if either of them don't use fine detection.

    These bugs can be most easily seen in Please login to see this link.. Run it on PC, and hold down the mouse button to rotate. Then run it on iOS, and see how different it looks.

    Since this was messing up my current game, and I didn't want to wait for Clickteam, I fixed these problems myself. I implemented collision detection between angled boxes using the Separating Axis Theorem, which is also used as an easy-out for fine collision detection, meaning the performance of pure rotated fine collision detection has been improved as well (it definitely helped my game run smoother).

    To implement the fix, after exporting your project, merge the files inside the attached Please login to see this attachment. into your Xcode project, which will replace the files RunLoop/CRun.m and Sprites/CMask.m with my patched files.

    One note: my changes all have the text CHANGED BY SEB in comments near them, if you want to integrate my code into some other version.

    It's worth noting that, when I turned on fine vs box collision detection in CRun.m, I exposed a serious bug in Clickteam's CMask::testRect routine which was causing it to not test enough mask indices, resulting in detection failure in certain situations. Since fine vs box collision was not possible with Actives until I added my code, I think the only way to experience this bug previously would have been with very specific Active vs. Background collisions. You can see this bug in action if you compare the behavior of Please login to see this link. on PC vs its behavior on iOS (tap the diamonds to nudge the object onto the left edge of the block, then go right). Note that you can only see this bug if you implement my fix for CRun.m, but not my fix for CMask.m.

    I'll submit this to the bugbox and hopefully Clickteam will fix it in a future release. All really they have to do is pull my changes. ***DISCLAIMER*** while I did my best to debug, this code comes without warranty. I didn't test it extensively --- that's Clickteam's job.

    Also, one side note, I am almost always available for freelance :) I'm an ex-Disney engineer and one of the best coders around. I also made Please login to see this link., one of the most widely used Fusion extensions around. Easiest way to reach me is to email admin at ultimatewalrus.com since I don't check these forums that often.

    It might be possible that what you want is possible with UFS, but it will take a lot of fooling around with it. If I were you, I might just hard set the resolution to the highest resolution I'll want, then use the Viewport object or a shader to scale up on "smaller" frames. I kinda remember there is some sort of problem with changing frame window size at runtime, like Clickteam didn't make it possible. Even the Window object claims to be able to do it but doesn't really appear to. I had to create an elaborate workaround for one client to be able to do something similar.

    Remember you can always hire me to either add features or create a workaround. Or, you can take a crack at the Ultimate Fullscreen source yourself --- it's on my website.

    This would be a fairly complex task. One approach would be to make a custom level design tool which saves out level chunks in Array objects. Then, when you run the game, load all your level chunks and pick them at random to be placed into a larger Array, which would define the layout of the entire level. You will have to plan ahead to figure out how these pieces will be connected via hallways; one easy approach would be to just have the random rooms conform to a large grid so all the hallways can be straight.

    If you want more interesting layouts you'll have to plan out a more advanced algorithm. Procedural content generation is practically an entire field of study, and there's a huge Please login to see this link. devoted to it.

    Best way would probably be to write a shader that does this. If you make your background an Active object, you can apply whatever shader you'd like to it and tweak the parameters at runtime. It's possible someone has already written a shader that does this. I know the P3D kit depends on a shader that distorts a sprite across four corners; you might start your search there, and look in the shader packs if it doesn't work out.

    That´s exactly why I wrote my template, UF can not do this by default, at least not on runtime and for flexible resolutions.

    It's actually pretty easy to do this with UFS if I understand correctly. Somebody just emailed me about this thread and I made this example (attached). Note that you could use the Cropped game width and Cropped game height attributes to easily adjust your UI to whatever cropping occurs.

    Using delta time for physics is never a good idea. Even the Unity engine which seems to revolve around a (flawed) variable timestep paradigm, still runs its physics on a fixed timestep. With variable timestep objects could easily go through walls and glitch out as their movement is extrapolated inconsistently. "Real" physics is kludgy and non-deterministic as it is, why make it worse?

    Checking "machine independent speed" in the application settings will run multiple updates to catch up when the drawing is slow. This gives you the best of both worlds --- your game will run on a fixed timestep, but it'll keep a similar speed when the framerate drops, it'll just look chunkier.

    You could try making your game with placeholder art, then try to find an artist to help you with the sprites. It would look much better than something auto-generated. People usually don't take kindly to being asked to do free work, so make sure you offer an equal share in the game, or at least equal credit if it's freeware.

    Alternatively, you could tackle your problem of not knowing how to draw characters, and try to get better at drawing characters. The only way to learn how is to start trying to do it. It's actually pretty easy to do pixel art in Fusion's image editor (though I prefer Photoshop).

    Fusion's handling of alpha channels is a little wonky. Alpha channels are when a pixel in a PNG file, for example, is only 50% opaque, so you can see what's behind it.

    To turn it on and off in the image editor, click on the "alpha" icon (looks like a fish), then switch the radio button between "Transp. Color" (the image will just have an RGB value that means transparent) or "Alpha channel" (the image will have an alpha channel which you can view by checking "Show"). Having an alpha channel definitely makes it difficult to actually edit your image. If you actually do want to use the Alpha Channel, you're better off creating your image in an external tool like Photoshop and reimporting it each time you change it.

    Unfortunately, Fusion's importer is set to use Alpha Channel for all PNG files, even if there are no semi-transparent pixels in the image. An easy way to get around this is to just save all your images as BMP and use magic pink (or some other color) as your transparent color.

    The reason you're having trouble with collision bounds may be related to this; the Flash exporter might just consider all pixels in a sprite that uses alpha channels. The solution would be to disable alpha channels, or if you need alpha in your sprite, use a separate invisible active as its collision mask.

    Again, there should be no problem downloading from Please login to see this link., that's its official permanent home now. Unfortunately it seems like this thread is way too old for me to be able to edit the link in the original post.

    It's nicer if you can download it from my site, because then I can keep track of how many people downloaded it :)

    There is a definite value to being able to see and appreciate what a compiler is actually doing on a low level. If it's all smoke and mirrors, you can unwittingly do things that break your game's performance for apparently no reason, or operate in a way different from what was intended. Of course most of the time it's just easier to operate on a higher level of abstraction, but when it comes to performance-critical segments or bugs, being able to see the generated C code would be a great tool.

    Generating Fusion events from C code would be virtually impossible (in order for this to work, Fusion's event editor language would basically have to be structured exactly like C). However, it would be very useful if you could insert a few lines of pure C code right into the event editor and have it be mixed in with the rest of the generated code (similar to how you can dip into assembly language in C).

    Surface object is flexible enough to allow all sorts of different things like this, and it might be a tad more accessible to beginners. Shaders are likely to be the more efficient method but it depends on your application. If the performance of Surface is adequate in your game then there's nothing wrong with using it (unless you want to export to some platform that doesn't support it).

    If you do want to learn shaders, my suggestion is:

    1.) Find a very simple shader to use as a template.
    2.) Code a shader that just renders every pixel in the sprite as red.
    3.) Code a shader that uses the sprite's alpha mask, but colors all the pixels red.
    4.) Code a "health bar" shader that renders a sprite, but cuts off anything to the right of a given pixel value, which you feed in as a parameter.

    Once you've gone through this learning process, making a hole-cutting shader would be pretty easy. Just feed in an X, Y, and radius for the hole, then have each pixel test if dX*dX + dY * dY > radius * radius before they can be drawn.