[SOLVED!] Low-resolution games and fullscreen

Can it be done? ? ?

I've been messing around with CC as of late for fun, and because I've always been fond of the program.

However, rescaling a low-res project to an adequate resolution with varying aspect rations has always been one of the sticking points. It sidetracked one of my projects in the past because I didn't feel like redrawing the sprites at higher resolution (lazy, I know).

I have here two example caps following two different methods at resizing and rescaling.

The first uses Ashley's method of using several global variables, zoom parameters, and black bars to sort of cheat letterbox scaling into the application. While the zoom does make the resolution look nice, it does not scroll to the player, rendering it useless. Is there something I missed here?

http://www.mediafire.com/download/cjn1a ... ttempt.cap

This .cap file attempts to use some of the rescaling methods found in tl22's very complex Action-RPG .cap file. I am most sure I am missing something here. The only event that seems to trigger anything is the one where the window size is changed to GetScreenWidth x GetScreenHeight.

While it at the very least stretches things without producing artifacts, it is obviously not ideal. tl22's cap file scales nicely enough, though everything is left blurry because I assume the zoom features can't entirely display the optimal resolution without bugging out.

http://www.mediafire.com/download/bsmz8 ... mpt_v2.cap

I know there aren't many CC users in the wild (the result of some negative marketing? <img src="{SMILIES_PATH}/icon_e_wink.gif" alt=";)" title="Wink"> ), but I'd love to hear some input or advice. Or, ideally, .cap files that do this even better! <img src="{SMILIES_PATH}/icon_cool.gif" alt="8-)" title="Cool">

Other examples I am aware of include a project tulamide worked on that was a water-based puzzle game (that I couldn't get quite to run properly in-game), and a few other minor examples that while stretch without producing artifacts, nonetheless don't do the job optimally.

Oh god I'm having flashbacks already. All I can say is do not use Ashley's method in the first link. I worked on a game for ~7 months using that and it was such a pain. It's been years but off the top of my head your viewport and parallaxing is completely warped, HUD's / Pause menu objects have to be created and placed entirely with code (and might still shake when scrolling regardless of event order), everything moves on sub-pixels, performance takes a hit, and so on.

I don't think proper fullscreen was ever figured out in CC. Makes me wonder how Konjak handled it in The Iconoclasts.

""I know there aren't many CC users in the wild (the result of some negative marketing? )""

No because it's a busted, buggy, antiquated and inferior product XD;

It makes me wonder what made Ashley's example "work" vs. the many others (myself included, lol) that attempted to emulate it.

I don't think proper fullscreen was ever figured out in CC. Makes me wonder how Konjak handled it in The Iconoclasts.

That would be the "holy grail" of .cap files, I think

At the very least, I suppose it might be better for me to focus on other aspects than bang my head against a wall. If I find potential solutions I'll post relevant links in the thread.

Alright I got your holy grail.

http://kayin.moe/c1res.cap

This is how it works in Brave Earth. The big trick here is figuring out how handle parallax because for some nonsensical reason, Construct does not calculate that from the center of the screen (I dunno if C2 does this in the not-stupid way, but w/e). Some notes on how this works...

Make your layout big and unbounded. If it's not bigger than the resolution the game is running at the camera gives up on life.

The formula for handling parallax would have to be repeated for different object classes. I kept it to scrolling backgrounds for simplicity. You'd need to make another family to do sprites... which... isn't really a big deal. And you can use this fine with tiles in the gameplay plane and background plane without shit moving around weird.

The higher resolution, the less FPS you get at a rate that doesn't QUITE line up with what you'd expect. For most games you won't even notice though. Kinda an issue in BEP

If you get shimmering with scrolling (Especially if you're like me and end up using a complicated, smoother camera) not related to vsync issues, scroll to your camera's floored X and Y.

I really don't recommend 150 and 250 zooms. 300% onward, 50% zooms become less obvious. Not perfect, but good enough for Shovelknight to run at 1080p.

Besides for weird performance issues in BEP on lower power hardware (in which case, the game can be ran at 320x240 full screened to get max performance), this is the best solution I think you're gonna find.

The only cons here is you get a lot of subpixeling which, depending on how much you care, may or may not be a problem. I don't care about sub pixel positions too much myself, but if you resize an object it will 'break' resolution' in a way it wouldn't at 100% zoom.

You can also use high quality, high res art for the sidebars (and maybe punch out a viewport with the erase effect) and it will show at max resolution which is pretty nice, so you can do stuff like this http://static.gamespot.com/uploads/scal ... 30_004.jpg

Fascinating!

I am in awe of your math skills.

The resize function is quite formidable. If I understand what's going on:

1) First, the global CurrentW and CurrentH are set to the resolution (in this case, 320x240)

2) Afterwards, a check is made to see if they are different than the DisplayWidth and DisplayHeight, and if so,

3) You set up the X and Y of the "Red" family bars using some seriously complicated math that calculates the position of the bars by having the current width and height subtracted from the base width and height(obviously it's more complicated than that though), and

4) finally, a zoom is applied that judges the difference between the base width and height and the new current width and height and zooms accordingly. Very elegant and flexible.

I wonder how the formula handles all four bars and their respective positions (unless you sort of eyeballed it?). And more importantly, how you figured all of that out! Again, I am very impressed.

[quote:27c3kc47]The formula for handling parallax would have to be repeated for different object classes. I kept it to scrolling backgrounds for simplicity. You'd need to make another family to do sprites... which... isn't really a big deal.

Do you mean the formula for the resize function?

[quote:27c3kc47]You can also use high quality, high res art for the sidebars (and maybe punch out a viewport with the erase effect) and it will show at max resolution which is pretty nice, so you can do stuff like this

Funnily enough, I was thinking about this the other night, and came up with the pseudo solution to just have a window like the image above, except native to the application and not hard-coded in - similar to what you find in old Japanese computer games.

I'm not good at math, I'm just stubborn. I don't even remember how I eventually figured it out, but being able to preserve parallax was really important to my project. I kinda went back to figuring out the math a number of times before it clicked. It turned out being simpler than I expected, really, so someone with a better intuitive understanding of math could have figured it out way fast. But yeah, you pretty much got it. Just plug that big long formula in resize into a different family to use on sprites and you can have all your background elements behave with different scrolling (as you assumed correctly.

also yeah PC games seemed to love doing big illustrative frames around games. Always a very distinctive feature.