Posts by Mathias

Like others have said, as long as your game can boot up and there are no immediate technical issues with the game, you can publish your game.
SteamPipe (the tool for uploading builds) is a bit confusing at first, but once you have it setup, you can easily upload builds.
For Steamworks features (achievements, etc.), you will need to use the Steamworks extension (Please login to see this link.).
Obviously, you might want to consider other features such as trading cards, Steam Cloud, and so on. Steam Cloud can be enabled automatically and requires little configuration.

This is a neat game! Your pixelart is nice as always, and the sound design was cute
Out of curiosity, did you do the music yourself?

[MENTION=12521]Julian82[/MENTION]: Perfect! Then I'd say that a sleep margin of 10ms is a fairly good value (it's what we use for Iconoclasts).
I'll see about updating some of my previous ports (e.g. Freedom Planet) to do this, since it seems to be doing so much better.
The maintainer of the Windows Fusion runtime could definitely incorporate this, based on the sample code I posted before

[MENTION=12521]Julian82[/MENTION]: You need to put it to "00" to see how it runs without any busy loop. 99 will just make it not sleep at all, which is very CPU intensive. I think we're mostly curious how lenient your system is when using a sleep margin of "00", "05", "10", so we can see what a good value is.

I see! I checked Flynn - Son of Crimson, and that uses a sleep margin of 10ms. You can experiment with this by opening data.win with a hex editor, and changing the "10" after "@@SleepMargin" to e.g. "05".
Curious what e.g. a sleep margin of 0ms, 5ms, 10ms and 15ms gives you!

I did some research since you mentioned GameMaker.
GameMaker allows you to specify the sleep margin, i.e. the time that we will be waiting using a busy loop, while the rest of the time, we will be sleeping (using Sleep or Win32 Waitable Timers).
I'm not sure if Fusion already does this, but here is an example of how this could be done (slightly simplified):

void sleep(double); // e.g. Waitable Timers
double get_time(); // e.g. QueryPerformanceCounter
void yield(); // e.g. SwitchToThread


void limit_fps(int target_fps)
{
    static double last_time = get_time();
    double current_time = get_time();
    double target_time = last_time + 1.0 / target_fps;
    double t = target_time - current_time;
    const double sleep_margin = 0.01; // 10ms 
    double sleep_time = t - sleep_margin;
    if (sleep_time > 0)
        sleep(sleep_time);
    while (true) {
        current_time = get_time();
        if (current_time >= target_time)
            break;
        yield();
    }
    last_time = current_time;
}

GameMaker doesn't seem to use yield() as in this example, but processes Win32 messages instead, which is probably about the same.
It's a tradeoff in terms of battery/performance, but it seems like most GameMaker developers use a sleep margin of 10ms.

[MENTION=12521]Julian82[/MENTION]: That's pretty interesting! Looks like I'll need to investigate this for myself.
Just to check, are you running the games that give you good frametime in fullscreen mode/with vsync? What games give you good frametime?
What about Freedom Planet (+ what Steam branch you are running the game on)?

Sorry if I'm barging in, but only had time to read the original post and some of the recent comments

I've seen the "microstutter" in AVGNA and Freedom Planet when running under the normal Fusion runtime on Windows.
Both these games have vsync enabled, and this also seems to be the core of the issue.
I'm pretty sure this is related to
1) Fusion deciding to frameskip because the blocking vsync call is causing the runtime to think there isn't enough time to render the next frame
2) Fusion deciding to idle sleep after/before vsync, causing the next frame to miss the vsync deadline
3) the fact that these games use UFS.
It's pretty difficult to debug, so I can understand why Yves & friends would have trouble diagnosing it.

I use a different heuristic when vsync is enabled.
Initially, we don't sleep between frames at all. However, if the target framerate undershoots/overshoots, we disable vsync and use an FPS limiter.
Also, when going fullscreen, we update the device to display at the target framerate (usually 60Hz), but we still use the heuristic in case the user has odd graphics settings.

Whoever is maintaining the Windows runtime could experiment with a heuristic like this, since it's worked well for us!
Obviously, the device can't be set to use 60Hz with UFS, since it uses a borderless fullscreen mode, but maybe some savvy extension developer can extend UFS with this option

Just extract it to any location, and run fuse.exe.
Press F5 to open the shortcut menu.

I actually explained the behaviour of background images on a Facebook post, copy+pasted here:

If we are talking about HWA and iOS, then Fusion does a full bake of the collision mask, but draws each background object every frame (unless they are out of view).
It does not bake their appearance, only their colmask. It has to rebake the complete collision map if you paste new items or move any background objects, which is quite expensive.
It also has to Z-reorder both background and dynamic sprites when you scroll.

About tiled quick backdrops, Fusion will not use a shader for tiling, so you are going to get a quad for each tile.
This is quite expensive if you use very small tiles. It will cull any tiles not in sight, though.

The Flash, Java (?) and Android (?) exporters don't bake a full collision map, but does a test against each object rectangle, and if it intersects, a collision test (rect + col).
They also draw each object every frame.

If we are talking about Chowdren, it can use 3 different strategies:

1)
Draw all background objects every frame, handle collisions using rect + col.
This is the default, and used for 90% of the games I'm porting. It's quite simple and memory-efficient.
Unless you're pasting a *lot* of stuff, you're not going to be GPU or CPU bound anyway with a good broadphase.

2)
Bake background viewport with an added border.
When moving outside a certain threshold, rebake the viewport.
Handle collisions by rect + col.
This is good if your background is not very dynamic, like in Not a Hero.
.
3)
Draw all background objects individually, but bake whole collision map, like Fusion.
This is being used for... well, a game I can't mention

------

Basically, Fusion won't actually "paste" the image into any buffer or anything, it will just create a sprite which will have to be rendered every frame.
Also, doing collision tests on Android against pasted images is quite expensive if you have a lot of items.

If possible, try and prerender the image that you need in external software, and load them in as .png.
You'd want to reduce the number of draw calls as much as possible, basically.

Just a small tool to manage MMF2 and F2.5 clipboard data.

Download: Please login to see this link.

Example:

Please login to see this picture.

Licensed under the GPL. No support/warranty/whatever.

Wine wrappers are a decent solution to the porting problem in my experience. Some people frown upon wrappers, but for low-end games, there's no reason not to consider them. I don't see the wrapper size as a problem.

Just be aware that the D3D implementation in Wine can be a bit slow, especially with shaders.

The Steam overlay simply injects into the process, drawing with the Direct3D context that Fusion uses.
For the borders, Fusion positions/resizes the display surface so it appears the window has borders (but the display surface doesn't contain them).
There is no workaround to this unless Fusion is changed. I think Fusion has done this since forever, so I think Yves may be hesitant to change it.

On HWA, the two are 100% identical in terms of speed. The semi-transparency value just has another internal representation.
Always use alpha-blending, as it has a much better range.

They have an active thread on Please login to see this link.. Apparently, their server couldn't handle the load, so they made a Please login to see this link. instead

Quote from Volnaiskra

Might multithreading be a source of untapped potential for future versions of Fusion?

It would be very hard for Fusion to reason about parallelism, at least for events.
Users expect events to happen sequentially, and you would need some very complicated dependency analysis to figure out how to split the events into separate jobs.
Systems like physics and rendering are much easier to parallelize, but in the case of Fusion, those account for very little of the total runtime.
Events account for 90% of the total runtime on desktop, so those are the real bottleneck.

The following can be done to optimize those more:
1) Merge similar event groups, where the user was trying to describe a branch, e.g.

If alterable string of Object A == "active"
If alterable value of Object A == 1
    Set position X of Object A to 5


If alterable string of Object A == "active"
If alterable value of Object A == 0
    Set position X of Object A to 4

What the user was really trying to describe was this:

If alterable string of Object A == "active"
    If alterable value of Object A == 1
        Set position X of Object A to 5
    If alterable value of Object A == 0
        Set position X of Object A to 4

Fusion does not have this optimization. I would be surprised if F3 won't have some way to describe this explicitly
2) Move to native code
3) Optimize for the statistically likely cases/branches. Yves worked a lot on this for build 284 for globals, alterables and flags.
4) Optimize cache usage. Objects use a lot of pointers internally in Fusion, so for e.g. every alterable read, 1 level of indirection needs to be followed. This could be optimized to 0.

Sorry for the performance rant, but I hope that gave some insight into the "real" opportunities for runtime developers.

I think Chris Branch proposed a more open-source approach to extensions during CC12. It's a shame that never came to fruition.
It would definitely be ideal with an Unreal-like approach, where anyone buying a license for Fusion also gets GitHub access to the source. That has worked very well for them, judging by the number of external pull requests they get every day.

Quote from Yves

The performance issue with loop names was already fixed in 2.5, except in the Loop Index function that was apparently forgotten (this one is fixed in the next build).

I see! I suppose you do some caching of the loops with static names, and for dynamic names, you fall back to the old method?
For dynamic names, you could generate a perfect hash function using something like gperf.

A limit was probably introduced since doing a string comparison for the loop name is an expensive operation, especially since it's done a lot of times each frame.
Yves mentioned it's fixed in the next build though, so now you just need to wait

UltimateWalrus:
Since you have access to the window handle in Fusion, it should be possible I guess? SDL2 is not doing anything super complicated.

SDL2 is excellent. There's really no reason not to use it now that it's zlib-licensed.
Valve has made a big push for it, so on Steam, you get a lot of things for free (like controller configuration).
GLFW/SFML are good, but they are definitely not as mature as SDL2. Go for SDL2