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...wscedwin2011-12-17 07:45:38

"- 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.

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.TL222011-12-17 16:03:59

[QUOTE=Tokinsom] "- 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.[/QUOTE]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? ;)

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

Hope it helps you out![/QUOTE]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. :Pwscedwin2011-12-17 22:59:03

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! 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...wscedwin2011-12-18 08:31:58

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. :Pwscedwin2011-12-18 09:15:39