Fullscreen on 320x240 Game--Please Help!

Hi!

I'm making a game in 320x240 resolution. As probably discussed to death around here already, this is not possible because modern machines do not support fullscreen in resolutions below 640x480. Okay.

After extensive research on google and this site, I've identified a few attempts at a solution:

• The most obvious workaround is simply emulating 320x240 in 640x480 resolution with 200% zoom. This is not an optimal solution as it fucks up layer scrolling of layers with 0% scrollrates and allows for "subpixel" graphics on things rendered post-zoom (like particles).

• There is a way to emulate fullscreenedness by stripping the game of its window borders (apparently called "captions"), setting window to be "always-on-top", and maximizing window. This seemed to be the ideal solution, until I realized that the game looks extremely distorted on monitors of a certain resolution.

• I've attempted setting window size to 640x480 via event and THEN fullscreening the game. I no longer get an error, but the game automatically changes to 640x480 resolution upon fullscreening. To be honest, this is a pretty silly attempt and I didn't expect it to work at all. :p

So is there any hope left for me? I don't care about keeping aspect ratios or a little blurriness. I just need a true 320x240 game that can run in fullscreen. I've read past topics on this. I just want to see if there's been a new development or if anyone has new ideas (or if I'm just missing something really obvious, which is a possibility as I am new to Construct!).

Edit: The second method would work (assuming that there aren't some other hidden problems) if the contents of the window would scale smoothly instead of with nearest-neighbor distortions when the window is resized. Is this possible?

Editx2: Another possible workaround would be running the game in 640x480, saving a 320x240 chunk of the screen to buffer, and then drawing it 2x onto the screen in real-time, but it doesn't look like Construct is capable of doing something like that...

"- The most obvious workaround is simply emulating 320x240 in 640x480 resolution with 200% zoom. This is not an optimal solution as it fucks up layer scrolling of layers with 0% scrollrates and allows for "subpixel" graphics on things rendered post-zoom (like particles)."

Unfortunately that's the best you're gonna get. I've been messing with this for a long time.

To work around the 0% scrollrate issue, you'll have to position your objects relative to scrollx, scrolly. If you're using Ashley's fullscreen w/ aspect ratio example, then they must be relative to the UI_Origin or

(scrollx+barL.width)+n

(scrolly+barT.width)+n

If you really don't care about blurriness on certain PCs or maintaining aspect ratio, you can try the built-in fullscreen or maybe the window object.

Actually, I've developed a method that works wonders without using zoom and supporting 3 different aspect ratios (4:3, 16:9, 16:10).

I'll see if I can come up with an example, but it IS a bit complicated. However, I've not had any problems with it at all.

If you don't feel like waiting for me to come up with an example you can see how I accomplished it by checking the cap file for my RPG game here:

http://www.scirra.com/forum/action-rpg-demo_topic45431.html

It should be under the "MainMenu" event sheet, in its own group called "Window and Aspect Ratio Settings". You'll need a SysInfo object and a Window object to use my method. You'll also want to check the "start of layout" actions below the "Array Initialize" group, as those use an automatic detection of the screen size to come up with a default aspect ratio. I also have the Project Settings set to have Menu, Caption, Resizing, Minimize, Maximize, and Fullscreen all disabled.

It's probably a bit more complicated than it needs to be, but it works great for me. I have no issues with scroll rates and only have to compensate for having additional aspect ratios.

I just put up an example on how to do an easy to set up retro style fullscreen in the Tutorials forum.

http://www.scirra.com/forum/topic47220_post295684.html#295684

Hope it helps you out!

"- The most obvious workaround is simply emulating 320x240 in 640x480 resolution with 200% zoom. This is not an optimal solution as it fucks up layer scrolling of layers with 0% scrollrates and allows for "subpixel" graphics on things rendered post-zoom (like particles)."

Unfortunately that's the best you're gonna get. I've been messing with this for a long time.

To work around the 0% scrollrate issue, you'll have to position your objects relative to scrollx, scrolly. If you're using Ashley's fullscreen w/ aspect ratio example, then they must be relative to the UI_Origin or

(scrollx+barL.width)+n

(scrolly+barT.width)+n

If you really don't care about blurriness on certain PCs or maintaining aspect ratio, you can try the built-in fullscreen or maybe the window object.

Yeah, I've read your posts in an older related topic that came up in a search. Construct is a total majesty in pretty much every other aspect so far, so it really is a pain to have to come up with workarounds for something as seemingly simple as screen modes.

To be honest, zooming will probably be my very last resort. I'm still pretty new to Construct, so all of these workarounds seem a little overwhelming, not to mention the "sub-pixel" thing being a bit of a turn-off.

If I want to use the built-in fullscreen, all I have to do is get the game to at least 640x480... but then again, that's the challenging part, isn't it? ;)

I just put up an example on how to do an easy to set up retro style fullscreen in the Tutorials forum.

http://www.scirra.com/forum/topic47220_post295684.html#295684

Hope it helps you out!

Thank you for the tutorial, though you may notice that this is the same solution that I considered in the second bullet point of my original post. :P

It does seem like the best method so far, even if it's a "fake" fullscreen. The "fake" part bothers me a little, as I'm afraid that graphics from external programs (like instant messengers) will pop through the game screen during gameplay as the windows 7 start icon sometimes does, ruining the effect altogether. The other concern is the distortion that happens on certain screens--I'll comment on your tutorial topic.

I may look into writing a plugin or something that does this for you without workarounds if I decide that it's worth it (and if I can figure it out!), though I'm a little reluctant to look at code since the reason I moved to Construct from building my own engine in the first place is because I was sick of programming. :P

Well you can set the window to always be on top, so popups like messengers shouldn't be an issue. Theoretically of course. Haven't tested it myself, but I also only have the window be set on top once.

Also, the distortion should be accounted for in my example because it uses a combination of window resizing and display resolution resizing. In my example I just use the 3 common ones of 4:3, 16:9 and 16:10. If you want to support all resolutions imaginable, well... good luck! <img src="smileys/smiley17.gif" border="0" align="middle" /> But yea, the methods I use can work for any aspect ratio, you just need to put a check for that specific aspect ratio if you want the resolution a specific size.

Yes, I've set the window to be always-on-top. While testing, I found that certain elements of the Windows 7 GUI shows through at times. I don't know why, and I can't seem to replicate it, but fact that it happened at all is a source of hesitance for me. I may try to identify the cause later.

Anyway, your tutorial file doesn't have any display resolution related events and visibly suffers from scaling distortions. I'm assuming that you just left that out for whatever reason, but I think that I understand what you meant to do. I suppose you could change the display resolution based on the screen size, but changing the actual content (viewspace) of the game based on the user's screensize seems a little suboptimal for me!

This is a good solution, but I'm not yet convinced that it's the best-possible solution for what I want to do. I've done a bit of screwing around in my test project file and I think that I'm ready to suggest another workaround for a true-320x240 and true-fullscreen mode. It's pretty much just like regular zooming, but without its esoteric (how does system zoom work anyway?) parallax-breaking properties and without allowing "post-zoom" rendered things like particles and gradients to disobey the 320x240 grid. As far as I can tell so far, it works perfectly. There may be some problems with memory... I don't know. I'll clobber together an exe later if anyone is interested.

On a side note, does MagiCam not work in fullscreen? I just get a frozen white screen if I switch to fullscreen view while using the plugin...

Why not just pre-upscale your graphics instead of messing around with zooming? If you want it fullscreen, the player won't notice anyway, and if they want to play windowed anyway it will be easier to see what's going on.

I considered that, and in fact, made half a game using that method back when I was working with another game engine. It is not an enjoyable process: working on the game starts to feel cumbersome and "hacky", not to mention that it allows for sub-pixel movement which, in my book, defeats the whole point of making a game in this so-dated-that-modern-cards-don't-support-it resolution.

I admit that it's not a very practical matter. Yes, the player probably won't notice or care if a sprite is off by half a pixel. I just have an obstinate love affair with genuine retro visuals in a game, so I'm not very willing to make any compromises on that front.

I'm also not one to try to lock a player into a fullscreen prison for no good reason. The nature of this particular project really calls for it, which is why I'm going through all this trouble in the first place. :P

<font size="2">Disregard this post, I'm an idiot. Need to pay attention to which Construct is talked about.</font>

Okay, as promised:

example exe

Arrow keys to move. Press Z to jump.

Instead of using the system zoom, which breaks a lot of stuff, I used a top-most "magnifying" layer to do it. There are no noticeable problems as far as I can see. I think that this is the solution I will go with.

And again, if anyone can tell me whether or not MagiCam works on fullscreen...

to prevent subpixel movement with double scaled graphics, and have them obey the grid, you can set positions to round(player.xy/2)*2.

but again... this is kinda hacky i feel you. it's not so much a construct problem as a 'problem' with modern machines. you can use the window plugin to up scale stuff but that works differently on some machines (hardware problem). Ive noticed it on my laptop scaling in a "blurry" way that becomes crisp if the system volume widget appears (wtf?), but other than the laptop (which has an integrated card), im pretty sure most hardware scales as expected.

EDIT: oh, and in your example you might want to set the camera to scroll only to round(player.x),round(player.y) so that you don't get the sub pixel scrolling you're seeing sometimes (apparent in the 'doubling' of the text)

Okay, as promised:

example exe

Arrow keys to move. Press Z to jump.

Instead of using the system zoom, which breaks a lot of stuff, I used a top-most "magnifying" layer to do it. There are no noticeable problems as far as I can see. I think that this is the solution I will go with.

And again, if anyone can tell me whether or not MagiCam works on fullscreen...

In my endless quest to find the solution the full screen issue in Construct I have even sunk so low as to revive a year old thread! <img src="smileys/smiley11.gif" border="0" align="middle">

But if there's any chance in figuring this out, I must take it. How did you go about doing this exactly? Your transition from windowed to full screen is perfect, and yet, for some reason, when I use the magnified layer in the way I assumed you did, it's very buggy and doesn't give a full view of what's there anymore, even the ground players stand on isn't visible...

I don't think that he'll answer (hasn't been on for 127 days). I haven't really used fullscreen; is it really that buggy?

At this point, I'll even take the narrowest of chances. :P

Yeah it's pretty tough to handle with certain features. For instance, most methods of full screen require some form of zooming, and if you zoom, you can say goodbye to parallax scrolling, and scrolling at any rate besides 100% on each layer. Which means the HUD is no longer as simple to implement, and pause screens may also be a problem.

I don't know, it's just so damn frustrating that a program which in all honesty has been so great would fall before something as basic as full screen. <img src="smileys/smiley6.gif" border="0" align="middle" />