Posts by Rickshaw

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.


    It pastes/adds backdrops (as obstacles) in the first two frames with the collision images (at each active), and then checks for obstacle overlapping instead.
    You could then delete a backdrop at a certain X and Y position if you wish*. (I very much believe so at least, there's an action for that - but I've never used it.)
    (*which you do, "breaking-wall-behavior dude")

    Thanks so much! This technique should work fine in my larger game since I don't use the backdrop on this layer for anything. You are the hero of the day!

    It sounds like just the usual thing with how MMF2 handles collision detection...
    It basically saves the position, animation frame, angle, etc of all the objects at the start of the frame. Then when you test for a collision, it uses the current state of the object you specify (which is why embedded collision detectors work), but compares that against the saved state of other objects as they were at the start of the frame (which is why collisions between two embedded collision detectors don't work). In your case, you can either rotate & resize the detector OR you can switch to the footprint mode and back - but you can't do both.
    It's all explained more thoroughly in other threads.

    But what I'm doing works perfectly fine in standard display mode, it just breaks in Direct3D 9. You can test it yourself.

    I'm running R256.34 and I'm attaching a .mfa file illustrating the issue. Please login to see this attachment.

    I'm attempting to construct a sort of line-of-sight algorithm using a detector object. The detector is a single pixel. In a fast loop, the X scale of the pixel is set to the distance from the seeing object to the target (mouse, or player object.) Its angle is set to the angle from the seeing object to the target. Then it tests for overlaps with walls. If the detector object overlaps a wall, then the player should be safe from being seen.

    There is slightly more to it: the walls all have their animation directions changed to a "footprint" mode and then changed back after the line-of-sight calculation. It's easy enough for me to see if the detector overlaps any part of any wall, but I need to detect overlap with the walls' footprints specifically.

    Now, in the attached .mfa file, the collision detection behaves exactly as it should if you just load it up and run. However, if you change the display mode to Direct 3D 9, you will see that it breaks the behavior. Also note that while in Direct 3D 9 mode, if you position the seeing object and the mouse just right so that the mouse has the same y coordinate as the object and is to the right of the object, it *will* detect collisions with the walls.


    Anyway it would be nice if this technique still worked in Direct3D 9. It would mean the difference of 10-20 FPS for me in normal gameplay, and that's not an exaggeration.

    I have resolved my issue by following the advice I was given a while ago in this thread: Please login to see this link.

    In short, to fix all of my problems simultaneously, I had to create a launcher application that handles changing the resolution and launching the real application. By doing this, I get full Direct3D 9, fully working subapplication, no weird hangs, the highest FPS without breaking my list objects or having to recode anything.

    My mistake- the Direct3d isn't breaking the "subtract" effect, it's just making it much more subtle. I'd be willing to work with that by adjusting my graphics, but without a working subapplication it's pointless.

    Subapplication does work if I set it to "display as sprite" (again something I'd be willing to work with for the FPS boost) but then none of the activex stuff in my subapplication (list objects + cursor) displays at all. I'd hate to re-code all of this stuff with better-supported objects although the FPS boost is tempting. It'd be a major pain to replace every list object.

    I have narrowed my issue down further:

    In the past, the advice was to force direct draw mode without vram by using /ddraw /novr command line options. I removed these and tried the other modes:

    standard display: significant slowdown, otherwise displays and works fine, doesn't hang on quit.
    directx : works as expected, hangs on quit
    directx + vram: slows to a crawl, ~5 FPS. otherwise displays and works fine, hangs on quit.
    Direct3d 8: doesn't display subapplication (game breaking), breaks "subtract" visual effect on critical object. doesn't hang on quit.
    Direct3d 9: doesn't display subapplication (game breaking), breaks "subtract" visual effect on critical object. doesn't hang on quit. runs fast (very nice.)

    I realize now that subapplications are not recommended but it is well beyond the point where I can change this about my game. I would be happy to go back to however it was before, when I could run and quit without MMF2 hanging. I would be happiest if I could run in Direct3D 9 while keeping my subapplication (deal breaker) and subtract visual effect. As it is, no mode runs without problems whereas it used to be fine before.

    I'm encountering a new issue with MMF2 itself (not the built applications) and I suspect it's from a recent update.

    The game I'm developing uses a full-screen display mode with subapplications. After speaking with developers on this site, I found the only way to get this to work was with the /DDRAW and /NOVR runtime options. Otherwise, the subapplications don't display.

    Now with these options enabled, when I run and then close my application , MMF2 is left in a sort of hung mode where it thinks the game is still running. Including a screenshot:
    Please login to see this attachment.

    (Please login to see this link.)

    Clicking the black "stop" square doesn't do anything, MMF hangs, CPU usage gets pegged to 25% and I have to force quit.

    Taking /DDRAW out of the runtime options fixes this, but then breaks the appearance of subapplications in the game.

    The game itself seems to work fine, it's just MMF that is giving me a problem. I tried uninstalling my antivirus (Avast) but that did not fix it.

    Any ideas?

    Okay, in case any else was wondering, I figured out the image issue.

    The image object (an "Active Picture" object) resides in a subapplication. It loaded images fine in MMF2, but when run as a .ccn from the larger, built application, would not.

    Just to test the pathing issue, I placed an Active Picture object in the frame of my main application, obnoxiously blocking most of the screen, and told it to load one of the images, just to see if it would work. When built and run, it did work- and so did the Active Picture objects in my subapplication, now.

    So now I've just included an Active Picture object in my main application, on the screen where most of this stuff takes place, and it doesn't load anything- it just sits there. Somehow, it makes the Active Picture objects in the subapplication work.

    Okay, I'm narrowing down my problem. As before, I have some .png files in a folder in the directory where the application builds. At runtime, I load these .pngs into an image object and they display.

    This works fine when I'm running in MMF2 Dev. When I build my application, leaving all else the same, it does not work: the images aren't displayed.

    I no longer think this is a pathing issue therefore, but I'm at a loss to explain it.

    AppPath$ gives you the entire path to the folder of your application's working directory. This will work with network paths such as \\MyComputer\My Shared Folder\
    Appdrive$ gives you the Drive letter and a colon (may not work on network paths)
    Appdir$ gives you the rest of the path after the colon (may not work on network paths)
    AppTempPath$ gives you the path to a folder that Windows has allocated for you to temporarily put files.

    Thanks so much! I've been looking for this straighforward, simple information for a while now. This is extremely helpful. I also didn't realize the last bit about relative pathing from the application directory, this changes everything.

    I'm still not sure why my game has trouble finding .pngs, especially since I'm 99% sure I have the path right... But now I can get down to serious testing.

    Can anyone explain in detail the best way to include external files in your application? I'm having weird, inconsistent results when I try to run my game on different computers. Recently I reinstalled Windows on a fresh hard drive, and parts of the game break depending on where I put the whole working directory.

    Here's the basic setup: I have my main application, DataJack.mfa. In the same MMF project, I have a separate .mfa application that is included in the main game as a sub-application; therefore it builds to a .ccn which I have to point to in the subapplication object properties while in the frame editor.

    Living in the same directory of the main .mfa files are several other directories which contain many .ini files that the game references in order to create missions or look up weapon stats, etc. To point to these, I reference them by path in the events editor. I.E., tell the ini object to load Appdrive$+Appdir$+"missions/m1.ini" and go from there.

    If I take my entire working directory and move it to, say, C:/, the inventory subapplication stops working.

    Part of the inventory subapplication uses the path variables to point to various .png files and load them into a Picture Object. When I move the game to a different computer, this completely ceases to work. No pictures are loaded.

    I've had the program spit out the path where it thinks the .png file is, and it looks correct in every way. Yet, for some reason, the picture object will not load the .png.

    I ran into a handful of other problems that seem to come and go at random. Loading .mp3s or .oggs sometimes seems to not work, again based on the path variables method. Not sure if this was an issue with the directshow object.

    So I have a few questions:


    1. Appdrive$ , Appdir$ , Apppath$ , AppTempPath$ : what exactly do these all refer to? Right now, I try to construct my path via Appdrive$+Appdir$ to get to the game's root directory, and then go from there. Is this right? Is there a simpler way? What is AppTempPath? Does this all refer to where the .mfa file lives, where the built .exe lives, or where MMF2 itself lives? What do these variables refer to when I use them in a subapplication?

    2. Because I actually use the subapplication object properties to point to inventory.ccn in MMF2 (instead of passing it a path variable at runtime,) it is included in the data elements "external files" list. I understand that this means it will be built into the installer? How does this differ from pointing to objects at runtime with path variables? Is one preferred over the other?


    Basically, I must be doing something fundamentally wrong and I don't have a consistent, working system in place. I'd like to understand the intricacies of relative pathing and external files in MMF2.

    I just reinstalled my copy of Multimedia Fusion 2 Developer from the DVD to a fresh hard drive. Then I downloaded all of the extension packs from the download center and installed those as well, with no apparent problems.

    When I try to load my project, it complains that:

    "This application requires the following extensions:
    Clickteam Movement Controller (clickteam-movement-controller.mfx)

    Install these extensions and then click Retry."

    So I downloaded the nifty ExtensionView program from these forums and it confirmed what I'd suspected: this extension is supposed to be built-in. If so, why doesn't it seem to be included in my fresh install? Any way I can get this extension somehow?

    1. Yes please zip and send me your MFA (or upload it somewhere). I'll try to see why it crashes.
    3. When you use /DDRAW and /NOVR, are you sure you've set the graphic mode to Direct3D? (so that MMF2 uses the HWA runtime) EDIT: sorry apparently I forgot to mention it in the posts where I was talking about the command line options, oops...

    Ah, that makes sense of course. With /DDRAW /NOVR in Direct3D 9, everything is back to normal. No FPS hit, no crashing and full functionality. I should have figured this out myself, but my brain is severely burnt out today.

    I'm sending you a PM with a link to download a zip of the .mfa files anyway, in case you want to look at it, for MMF research and development purposes.

    Thanks again!

    Ah, yes by default /DDRAW is DirectX+VAM. Use /DDRAW /NOVR for DirectX, sorry.
    They work in windowed Direct3D mode, they don't work in full screen Direct3D mode. If your app is in full screen, use the tip I gae you above to switch to full screen via a launcher application.

    Okay, I tried the windowed launcher method as in the example you posted, and while subapps and lists do work, it now crashes to desktop on the first real level screen. I'm currently looking at four versions of my project:


    1. Launcher + Direct3D 9. Works fine until you try to play an actual level, then crashes immediately.

    2. No launcher, DirectX. Works, but has a noticeably lower framerate (~10 fps hit, nearly unplayable)

    3. No launcher, /DDRAW /NOVR command line. Same framerate issues.

    4. An older version that I built with the HWA beta I was using on 12/5- Runs full screen, full fps, no crash to desktop, no complaints


    Simply put, I wouldn't have installed this latest MMF version if I'd known that it would have caused this much trouble with my project; I would have finished it up in the legacy version and then fully updated MMF. At least wait until the project was done. Is there any way I can roll back to the older version?

    I can provide the .mfa files and exe if you want to look at them, but it's a huge project and the compiled version from 12/5 is 10.5 MB as is. There is a lot going on in the code and picking through it might not be totally instructive.

    I tried the /DDRAW command line option, and it slowed everything to a crawl (down to single-digit FPS.) For some reason, DirectX is still the fastest display mode in which everything works.

    I tried a few test things to get the subapplication working in Direct3D- I could uncheck the popup window thing, check "display as sprite" and do a few other changes to make it work in this way. I could get it to work, but my application (specifically, my subapplication) makes extensive use of displayed list objects, which do not work in Direct3D. I didn't want to go through the trouble of converting my whole application to work in Direct3D if this part would always be broken.

    So, is there any way to make list objects work in Direct3D mode? Alternatively, is there a way to roll back to the HWA version I was using previously? Honestly I would love to have this running in Direct3D 9 for best performance and compatibility, but if that means redoing all of my game I don't think it's worth it.


    One thing was different in the HWA version though, and that could explain your issue. In this version, the collision routines and the collision detection events are better optimized than in the standard version.
    ...
    Possible solutions :

    1. You can force the HWA runtime to work in DirectX mode with the /DDRAW command line option. To run your application in DirectX mode from MMF2, just put /DDRAW in the Command Line box in the properties of the application. When you redistribute your application, add /DDRAW to the command line in the properties of the shortcut to your EXE.

    Thanks very much for the quick reply, this explains it... Yes, my application is running in full screen mode. I'll try your suggestions.

    HWA can be accessed by choosing Direct3D 8 or Direct3D 9 display mode in the application properties.

    I have a question about exactly this. Previously I was developing my project with the HWA beta and I'm pretty sure I was using DirectX as nothing else really worked. Now, using DirectX I have none of the acceleration and I've noticed a very big drop in framerate in most of my levels.

    I'd have no problem switching to Direct3D, except that subapplications don't work with it from the get-go. Apparently, I can create a new sub application once my project is in Direct3D mode and then can check "display as sprite," but I have a good 22 frames each with very complicated rules for the subapplication object, and I can't just go to each frame and check "display as sprite" on my subapp objects because it's greyed out on these.


    Basically, I want to keep using hardware acceleration, but now must switch to Direct3D for this, but this means I have to replace all my subapplication objects and rules in all of my frames. Is there an easier way? Or can I somehow roll back to the HWA beta which was working fine for me?