A question about HUGE levels

If you don't want to build a level editor (for dynamic loading of assets in one frame), then your idea seems to be reasonable. You'll need to copy/paste your whole code (and debug it) in every single frame though (which will most likely cause big trouble in larger projects). You can use global events to avoid this (but it seems to be buggy at points, so most devs don't do it).

There are a lot of good performance discussion threads in the forum. When it comes to level building you've to watch CPU load (storing and moving tile positions). In my experience up to 3000 tiles can be handeled quite well using an average CPU, but I won't go much higher. On the other hand there is RAM count (2 GB limit, avoid big textures, avoid alpha cannels when not needed, be save and stay lower than 1GB). Summary: Using tiles 32 * 32 to 512 * 512 like you suggest is perfectly fine, I do this too and got the best results with it.

Fusion's renderer is not the best for doing native HD60, so scaling up is generally recommended if your artstyle allows it. I would take a resolution that can be scaled integer only to 1920*1080 as this is the most common resolution on PC. You could use 640*360 instead of 640*480. Scaling pixel art with floating point values can look very ugly and cause texture artefacts (subtle lines), espcecially when scrolling. There are possibilities to get dynamic pixel perfect resolution adaption working in Fusion, but it's a bit compolicated. I've an example in this thread (and also Ultimate Walrus, which I have not checked): Please login to see this link.

In general using backdrops is slightly better (Fusion will have to allocate more memory for every active object with it's values and possibilities of alteration). On the other hand actives are much more flexible of course - so it depends. If you want to create everything prebaked, then you should probably use the backdrops. If you use actives uncheck "fine detection" whenever possible (use block shapes for almost everything).

In my opinion, the belief that Fusion can't handle 1080p is a myth. My game is set at 1080p, and I get 50-140fps, depending on situation on my main PC. On my gaming laptop, I get only a little bit less. On my old PC (which contained some low-end graphics card...can't remember what it was, but it was fanless, so that should give you an idea of how powerful it was), it was still very playable unless I went too heavy on shaders.

The only reason it even dips into sup-optimal framerates like 50fps is because for the past couple of years I've absolutely crammed it with eye candy without much care for optimisation: some 3000 objects, particles, shaders, multiple large background artworks (4096x1024, 2048x1024, etc). And the framerate is set to 120fps in-engine, which means that the code has to run twice as fast as in the average Fusion game. I'm currently in the process of optimising it, and there'll probably be some areas where I step the craziness back a little (eg. some of those background images can definitely be shrunk and scaled). I'm quietly confident that I'll be able to get it to the state where it runs at 60fps+ on anything loosely resembling a gaming PC (and for everyone else, I'll include graphics options to disable the big performance culprits - I know what most of them are).

So I find it hard to believe that the average MFA, which probably isn't as heavily stressed as my unoptimised one, would have trouble running at 1080p. Of course, it's straightforward to test this out. Build an MFA which resembles a game scenario (eg. a bunch of large actives, lots of duplicated little actives, a dozen or so moving bouncing balls, and move the camera with arrow keys), run it at 1080p, and see what happens. Most likely it'll be fine, and you might not even need safety goggles.

I will say that if your game style is pixelart, then it probably doesn't matter if you go small - you may as well go small and scale up, as long as you follow Julian's advice to get crisp pixels. But if you're not doing pixel art, then your game is going to look pretty terrible when it's scaled up. And it won't just be scaled up to 1080p. Plenty of people nowadays have 1440p or 4K screens, and these will only be more common in a year or more(?) when your game is released. I myself now have a 1440p screen, and I don't much like how fuzzy my 1080p game looks on it. It's ok, and it certainly passes, but if it was being scaled up from 640*360, it'd all be over.

I guess another key point is to decide what your target market is. When we're talking about resolution increases, we're generally talking about GPU performance. Making your game at a larger resolution will force the GPU to push way more pixels per frame, though it won't be likely to affect the CPU too much. So I guess the question is: is your target audience primarily PC Gamers? Or just regular folks who might want to occasionally play a retro game on their dell laptop? If it's the former, then they all have dedicated graphics cards, and going 1080p isn't likely to cause issues. If it's the latter, then most of them have weak GPUs built directly onto the CPU, and they may struggle.

Having written all this, I just realised that I've assumed you're targeting PC. If you're actually targeting mobile, then you'll definitely need to be more careful with GPU usage, and 640*360 may be for you.

Quote from Edel

Thanks for your advice. Yes you're right about 640*360. Not sure how i got to 640x480. I'm thinking I might need something a bit higher like 960x540.

Yeah, that resolution can still be handeled pretty well, but you've to be a bit more careful, especially if you plan to use pixel shaders. Like Volnaiskra said, Fusion can handle HD too, but if you go for it, test early and test often. My performance target is usually 60FPS on an i3 with integrated graphics. I run Outbuddies in 960x450 too (at least as an option) and I get 80 - 120 FPS with this resolution on my i3, depending on how much code and shaders are going on.

That's so true about older games not being pixelated. A friend of mine is an electronics wiz, and his hobby is building DIY arcade screens out of old TVs, but with obsessive attention to visual and electronic authenticity. He looks for very specific types of discarded TVs (German 1990s SCART CRTs, certain models only), then tinkers in their guts, rewiring things and adding features, until he has the most authentic arcade-style look possible. He then runs MAME games on them.

I never cared much for pixelart or retro games until I saw him run some 90s games on one of his machines. It's absolutely chalk and cheese compared to anything you can see on a modern monitor. As soon as I saw it, it transported me to 20 years ago - I had totally forgotten how radically different the screens of yesteryear looked. Those games glowed. And I don't just mean figuratively. Every pixel literally glowed, so much that it bled heavily into the surrounding pixels. This gave the whole screen an almost phosphorescent type of luminescence which is simply impossible to get on any modern hardware. And it was very difficult to discern individual pixels from each other, as they all vibrated and bled so much. Instead, each pixel combined with the others to create an impressionistic whole that was greater than the sum of its parts. Artistically speaking, it was practically a different medium to computer graphics today.

My friend even explained to me how many of the classic 90s games would take advantage of this pixel-bleeding phenomenon to create a homebrew form of antialiasing: they would put particular combinations and patterns of pixels into their designs, knowing that the brighter ones would overwhelm the darker ones and help soften the edges of the design. When you see some of those graphics today on a monitor, they look wrong. Not just sub-optimal, but actually wrong, since there are pixels being used in them that simply don't make visual sense when you see them 'naked' rather than filtered through the idiosyncrasies of an old CRT. It's certainly ironic how attached many contemporary game designers are to pixelated graphics, considering how resolutely (and skillfully) the masters of the past struggled against them!

Quote

So if you are making your game in 1080 and the player does not have a 1080 display will the game not run? Or does Fusion run in a windowed mode?

I'm not sure, though it'll be easy enough to test. Just make an MFA with a resolution of 5000x3000, run it, and see what happens. Much will depend on what settings you choose in the MFA's window properties (change resolution mode, keep screen ratio, resize display to fill window size, etc.)

Untick "Heading When Maximised", and ensure "change resolution mode" is unticked.
Tick "maximized on boot up", "resize display to fill window size", and "fit inside (black bars)".

This will scale the game to any resolution (even below the game's native resolution) and preserve the aspect ratio. However, there will be a small performance hit because it will be running in windowed fullscreen instead of exclusive fullscreen mode. However, this is more convenient if the user wants to alt-tab etc.

This method does not do integer scaling though, so you can have issues with shimmering when scrolling due to the non square pixels. To overcome this, you can use Ultimate Walrus's Ultimate Fullscreen Object and choose the perfect scaling(?) option which will only scale in integers. However, if you use this mode, you cannot downscale to a lower resolution than your games native resolution without using some workarounds (such as changing the game scale with the Ultimate Fullscreen object).

If you tick "change resolution mode" Fusion will try to change the user's actual resolution to your game's native resolution. I don't really like this option because unless your game's native resolution happens to match the native resolution of the user's own monitor, then their graphics card or monitor itself will have to do some scaling which will introduce its own scaling artifacts.

In short, the best method is using the Ultimate Fullscreen object where you will have full control over the scaling, and used in conjunction with an optional antialiasing shader, you can give the user complete options to customise the game's appearance to their liking.

Quote from salamanderpants

and is the way most games are made these days.

It really isn't. Unless you mean 'most indie games' or 'most retro games', in which case perhaps you're right (I wouldn't know - I've played many indie games, but not enough to get a sense of how widespread this is). But even if so, just because they do, doesn't mean they should. Exclusive Fullscreen games usually get better performance, better stability, and play nicer with multi-monitor setups.

Excellent info in the rest of your post, though. Very informative.

Quote from Volnaiskra

That's so true about older games not being pixelated. A friend of mine is an electronics wiz, and his hobby is building DIY arcade screens out of old TVs, but with obsessive attention to visual and electronic authenticity. He looks for very specific types of discarded TVs (German 1990s SCART CRTs, certain models only), then tinkers in their guts, rewiring things and adding features, until he has the most authentic arcade-style look possible. He then runs MAME games on them.

I never cared much for pixelart or retro games until I saw him run some 90s games on one of his machines. It's absolutely chalk and cheese compared to anything you can see on a modern monitor. As soon as I saw it, it transported me to 20 years ago - I had totally forgotten how radically different the screens of yesteryear looked. Those games glowed. And I don't just mean figuratively. Every pixel literally glowed, so much that it bled heavily into the surrounding pixels. This gave the whole screen an almost phosphorescent type of luminescence which is simply impossible to get on any modern hardware. And it was very difficult to discern individual pixels from each other, as they all vibrated and bled so much. Instead, each pixel combined with the others to create an impressionistic whole that was greater than the sum of its parts. Artistically speaking, it was practically a different medium to computer graphics today.

My friend even explained to me how many of the classic 90s games would take advantage of this pixel-bleeding phenomenon to create a homebrew form of antialiasing: they would put particular combinations and patterns of pixels into their designs, knowing that the brighter ones would overwhelm the darker ones and help soften the edges of the design. When you see some of those graphics today on a monitor, they look wrong. Not just sub-optimal, but actually wrong, since there are pixels being used in them that simply don't make visual sense when you see them 'naked' rather than filtered through the idiosyncrasies of an old CRT. It's certainly ironic how attached many contemporary game designers are to pixelated graphics, considering how resolutely (and skillfully) the masters of the past struggled against them!

wat an amazing post! took me right back to the days, i relate to this so much & is a constant frustration for me that i cant get that look in my games, wen pixels were like neon crystals, the whole screen looked like mosaic art from the future, & as u played those games with their big buttons & levers, u felt like u were piloting a 80s spaceship!

these days ppl hav so many different screen types with differing resolution monitors that its a pain, the old arcade days the were more 1 size fits all, the graphics wud still come thru even on the busted, half broken monitors lol.

i hope one day sumone makes a perfects 90s arcade arcade screen shader, that u just apply & BLING!!! its there!!! XD

Quote from Volnaiskra

It really isn't. Unless you mean 'most indie games' or 'most retro games', in which case perhaps you're right (I wouldn't know - I've played many indie games, but not enough to get a sense of how widespread this is). But even if so, just because they do, doesn't mean they should. Exclusive Fullscreen games usually get better performance, better stability, and play nicer with multi-monitor setups.

Excellent info in the rest of your post, though. Very informative.

Thanks for pointing this out. I have removed this part of my post.

Quote from Edel

So I'm testing things out and things are looking sharp. I have 9 512x512 backdrops making one of the smaller levels. Think of it like an architectural plan(walls of different lengths). Here is the problem: COLLISION!

I forgot about a little problem.... You can't seem to make backdrops invisible! At least there is no convenient checkbox that says 'visible' in the properties panel like with Active Backdrops. There is a 'Blend Coefficient' check box in the Backdrop properties panel. Set it to 255 and POOF! Invisible!

Setting the backdrop to Blend Coefficient 255 makes them invisible over the level tiles. Now all I do is clone the background for every wall I need in that level. It seems to work just fine. You just have to be careful because setting the Blend Coefficient to 255 makes the backdrops invisible in the Frame Editor as well.

Considering that everything is working perfect so far... Is this totally incorrect and terribly inefficient? By messing with the Blend setting did I turn these things into 'ticking alpha channel bombs of doom'? I ask because I'm always looking for best practices.

It sounds like it could affect performance, but I don't know. You could instead put the backdrops on another layer, and turn off that layer's visibility, then either put all your hitboxes on that new layer, or move them to the new layer temporarily when testing for collisions.

Not sure if this is best practice or not, but I always use Active objects for collision (and everything else - I never use backdrops). It certainly gives you more flexibility and keeps your options open. For one, it lets you untick "visible" of course, which is good since you can see them in the frame editor, as you mentioned.

I don't know a whole lot about backdrops, but I don't think they have many advantages, while they definitely have many disadvantages. The only advantage I know about is that they let you make ladders or jump-through platforms (solid when landing on them, non-solid when jumping through them from the bottom), which would be handy if you have those mechanics in your game. It's also handy that you can just do "is player overlapping background" and it will take care of all your various backdrops at once. But you can easily achieve something similar by using qualifiers on an Active: give all your various shapes of collision blocks a single qualifier ("physical objects" is an obvious one), and then you just have to test for "is player overlapping background".

Being able to use qualifiers gives you further options down the track. For example, you could add an additional qualifier to items that are sticky, or made of ice, or allow the player to hang from, etc. And being able to give your collision block alterable values may help down the track too: for example, if you want a fragile platform that keeps track of how many times the player touches it until it crumbles. And backdrops aren't exposed in the Event editors, so you can't scale them, move them, destroy them, etc.

By the way, if I understood you correctly, it sounds like you should be using duplicate, not clone, to copy those walls. Clone makes brand new unique copies of objects (requiring new RAM each time), whereas duplicate makes instances of objects.