Jump to content


Photo

Pixel Perfect Resizing


  • Please log in to reply
69 replies to this topic

#1 9_6

9_6

    Guest

  • GMC Member
  • 3627 posts

Posted 22 December 2008 - 05:33 PM

Posted Image

This is for everyone who makes a low-res game and is annoyed by that blur that happens if you size up the screen or gets graphical glitches if they use tiles and use the viewport to size up the view.

LINK
MIRROR

IMPORTANT!
  • ALWAYS MAKE THIS OPTIONAL. ALWAYS!
    Apparently not all computers handle surfaces with no problems and even if they usually do, if the video memory is messed up, it'll glitch until the computer is being restarted.
    Don't look at me I have no idea why that is the case, it's a game maker related problem I have no explanation for. See this post.
    It's alright though, it only takes one script call to switch it on and off. But make sure you actually use it in the options somewhere in your game!
    The resizing is on by default, to switch it off simply call "scr_toggle_resize();" after initializing it, before going to the menu room (that your game undoubtedly has, right? Right?)
  • Don't activate"Use synchronization to avoid tearing" if you use this! It'll tremendously slow the game down!
    Once again, game maker related issue that I have no clue why it happens.
  • Also due to the view being resetted, the native gm object following won't work. You have to make your own system for view handling.
  • I'm not entirely sure about it but I think gm-native transitions won't work propperly with this either.
  • If you get a black screen, that's probably because of your game deactivating the screen controlling instance.
    Call:
    instance_activate_object(global.screencontroller);
    right after de-activating all instances to solve that.
    That should always keep the controller object activated, regardless of what sprite or position it has.

How to use the scripts:

scr_resize_init(w,h): Initializes the system.
Call it when your game starts.
w: view width, h: view height.

scr_resize_init_gm7(w,h): If you use gamemaker 7 or 8, use this script to initialize the system because gm7+ handles surfaces differently.

scr_room_goto_resize(room,w,h,wport,hport): Always use this instead of room_goto and use it at least once so the system has an effect!
wport: width of the screen hport: height of the screen room: room to go to.
wport and hport are how big you want the screen to be, not how big the view is so you want to make it bigger than width and height to increase the size of the view.

scr_toggle_resize(w,h): Toggles the resizing.
Always call scr_room_goto_resize() directly after that for it to have an effect.
Otherwise the view won't resize which can lead to your game being displayed in the top left corner of the much larger screen.

scr_texture_set_interpolation(interpolation): Use this instead of texture_set_interpolation()!
Sets 'interpolate colors between pixels' without blurring the resized surface.
It's off by default because usually hard pixels is what you want if you use this.

-----------------

The next few scripts are specifically for while-loops that freeze the game and do some drawing within them (pause menus and such).
If your game doesn't do that, you won't need them.

scr_screen_redraw(): Completely replaces screen_redraw()!
It draws the stretched surface to the screen or acts like the normal 'screen_redraw' if the system isn't active.

scr_resize_start_drawing()/scr_resize_stop_drawing(): For drawing when the game is frozen by a while loop (paused).
Use scr_screen_redraw() BEFORE calling scr_resize_start_drawing(), IF you use it to redraw the screen because everything between start and stop will be drawn to the surface to stretch it properly.
If you redraw the screen within that, it cancels that effect and your game suddenly becomes a tiny speck in the top left corner of the screen.
Call scr_resize_start_drawing(), draw the stuff, then call scr_resize_stop_drawing().
Keep in mind that this does NOT replace screen_refresh(), you still have to call that afterwards to update the screen.


Hope this helps someone.

Edited by 9_6, 26 September 2010 - 04:16 PM.

  • 2

#2 Anon

Anon

    GMC Member

  • GMC Member
  • 447 posts

Posted 24 December 2008 - 07:15 PM

Nifty.
I used it to replace the built in full screen function, and it works perfectly.
Only thing that would be better is commenting on your code, and saying which each function does.

Cool!
Anon
  • 0

#3 9_6

9_6

    Guest

  • GMC Member
  • 3627 posts

Posted 25 December 2008 - 06:49 PM

Update. See first post.
  • 0

#4 Fede-lasse

Fede-lasse

    AI Programmer

  • GMC Member
  • 2009 posts
  • Version:Unknown

Posted 26 December 2008 - 06:42 PM

Any screenshots?
  • 0

Call me Fede.


#5 9_6

9_6

    Guest

  • GMC Member
  • 3627 posts

Posted 26 December 2008 - 06:53 PM

You know this is no game but I added a 'screenshot' anyway so you can see what this is all about with one look.

Edited by 9_6, 26 December 2008 - 06:55 PM.

  • 0

#6 XpressO

XpressO

    GMC Member

  • New Member
  • 184 posts

Posted 28 December 2008 - 12:32 AM

This is very nice but wouldn't it be easier using views?
  • 0

#7 9_6

9_6

    Guest

  • GMC Member
  • 3627 posts

Posted 28 December 2008 - 01:10 PM

This is very nice but wouldn't it be easier using views?

Do you really think I wrote that sort of complicated stuff without being aware of viewports?
It even does resize the viewport to enlarge the window at some point! (and then sizes it back down to let the surface do the job)
I even mentioned viewports and their flaws in the first post!
It would be so much easier if it would be as simple as abusing the viewports but gamemaker is a total ***** with those because if you simply size up the viewport:

-tiles might be drawn with graphical errors (depends on the graphics card)
-primitives and circles are drawn in the high resolution which makes them stick out in a bad way
-it sometimes looks weird because of different sized pixels

The only way to get flawless resizing is through an upsized surface and this is why I wrote this system!

Edited by 9_6, 28 December 2008 - 01:17 PM.

  • 0

#8 edmunn

edmunn

    GMC Member

  • New Member
  • 1298 posts

Posted 05 January 2009 - 01:37 PM

Fantastic idea, and great execution.
  • 0

Posted Image
Please PM / Email your suggestions!

15.4" Apple MacBook Pro Late 08', 2.8 GHz Intel Core 2 Duo, 4GB RAM, SSD
Mac OS X Lion


:)

#9 TheMyst

TheMyst

    GMC Member

  • New Member
  • 166 posts

Posted 08 January 2009 - 05:14 PM

fffffffffffffffffffffffffffffffffffffffff, the links are broken! Think you can fix them mate? I could get alot of use out of these.

Edited by TheMyst, 08 January 2009 - 05:57 PM.

  • 0
Level Editor Example: Use/Abuse as you wish.
My PC (recently upgraded): Asus P5Q SE2 Mainboard, Core 2 Quad @ 2.33 (will overclock), 4GB OCZ RAM, Onboard Sound by VIA Technologies, nVIDIA BFG 9800GTX.
My old stuff is going on Craigslist: EVGA 650i Ultra Mainboard, 2GB Ram, 2.33 Core 2 Duo (OC'd to 3.0), nVIDIA 8600 GT.
Copy and paste this into your signature if you DON'T GIVE A #$@% about religion, but nonetheless are annoyed by people who wear it like a badge.

#10 9_6

9_6

    Guest

  • GMC Member
  • 3627 posts

Posted 11 January 2009 - 10:11 AM

Since 64D deciced to die permanently and willhostforfood works again but ate my files, I've re-uploaded it to willhostforfood.
First link should work now. THe second will too... some day.
  • 0

#11 Schtauffen

Schtauffen

    GMC Member

  • New Member
  • 80 posts

Posted 13 January 2009 - 12:33 AM

Very nice 9_6 :(
  • 0

#12 toopz

toopz

    Spriter

  • New Member
  • 782 posts
  • Version:GM:Studio

Posted 13 January 2009 - 04:41 PM

This is awesome man. Pixel perfect, and it solves a weird glitch I've been getting from GM trying to scale games up on Vista. I'll be using this for sure.
  • 0

#13 9_6

9_6

    Guest

  • GMC Member
  • 3627 posts

Posted 13 January 2009 - 05:09 PM

Thanks.
A thing I've recently discovered is that -because it overwrites the view settings- gms native object following doesn't work if you set it to follow a certain object in the room editor.
Unfortunately there's nothing I can do about this because there seems to be no way to retrieve the view settings from rooms you're currently not in.
  • 0

#14 toopz

toopz

    Spriter

  • New Member
  • 782 posts
  • Version:GM:Studio

Posted 13 January 2009 - 07:32 PM

Yeah, I noticed that as well. I may have noticed a tile glitch when changing between rooms, but that may just because my game has become a huge beast code-wise, and I haven't gotten it all meshed together yet. I'll probably mess with it some more later today, and see if I can't find a way around those problems for me.
  • 0

#15 9_6

9_6

    Guest

  • GMC Member
  • 3627 posts

Posted 13 January 2009 - 10:32 PM

I may have noticed a tile glitch when changing between rooms

Wait what?
That's not supposed to happen. That's actually the whole purpose of this system.
How did it look? Did you just use tiles placed in the room editor?
Does the same happen when not resized? Screenshot of the glitch?
  • 0

#16 toopz

toopz

    Spriter

  • New Member
  • 782 posts
  • Version:GM:Studio

Posted 14 January 2009 - 05:54 AM

I was seeing lines between tiles. That said it was doing numerous strange things, such as scaling down instead of up when I changed rooms. I think it either has to do with me not changing room_goto() in all of it's previous uses, or persistence. I left it persistent, so it may not have the init stuff in the new rooms. Or it may be doubling up with other ones, since I forgot to create some code to destroy one when there's more than one. Come to think of it...that's probably why it scales down. I'll let you know sometime tomorrow how it goes when I try to fix it.
  • 0

#17 toopz

toopz

    Spriter

  • New Member
  • 782 posts
  • Version:GM:Studio

Posted 17 January 2009 - 06:05 AM

I finally got this to work (seemingly) perfectly with my game. It took a while for me to get certain things working, like changing all of my room_goto()'s to scr_room_goto_resize(), but I finally did. It also took me a while to figure out how to set the view to follow my player via the script; at first I was under the impression that this broke gm's native view handling.

Don't worry about the tile glitches, they were my fault. I found out in another random little test of mine that it was actually one of my rooms causing the glitch. Said room could not be modified by the room_set functions, which was causing the ports and other things to wig out whenever it attempted to. The solution in that case was to recreate the room.

Now that I got it fully working, this thing is amazing. I'll definitely be using this now!
  • 0

#18 Drewdelz

Drewdelz

    GMC Member

  • GMC Member
  • 1056 posts

Posted 25 January 2009 - 07:45 AM

EDIT: Had some problems, then realized I forgot to toggle the scaling... lmao Works now.

Thanks for the script, saved my game from an annoying glitch on some graphic cards that drew a gray grid between in-game tiles.
Good job. :D

Edited by Drewdelz, 25 January 2009 - 08:33 AM.

  • 0

#19 Drewdelz

Drewdelz

    GMC Member

  • GMC Member
  • 1056 posts

Posted 11 February 2009 - 03:51 AM

I seem to be getting a weird error when switching rooms. :/
For some reason, it randomly decides to not 2x scale certain rooms when switching to them. It seems completely random, and I can't predict a pattern with the error.

And no, I'm not using room_goto, so I have no idea why it's doing this. . .

Any ideas?
  • 0

#20 9_6

9_6

    Guest

  • GMC Member
  • 3627 posts

Posted 11 February 2009 - 06:08 PM

Well I have no idea.
Maybe you could pm me the source so I can see what you're doing?
  • 0

#21 Drewdelz

Drewdelz

    GMC Member

  • GMC Member
  • 1056 posts

Posted 14 February 2009 - 08:06 AM

nvm, I'm an idiot. I didn't realize you had to call "scr_toggle_resize(w,h)" everytime you transfered rooms. lol
Why not just have it the room_goto script then? I mod'd it into it myself now, since I want it resized at all times.
  • 0

#22 9_6

9_6

    Guest

  • GMC Member
  • 3627 posts

Posted 14 February 2009 - 07:23 PM

you don't need toggle resize all the time!
You must be doing something wrong, you only call the toggle script if you want to -as the name says- toggle the resizing and call scr_room_goto right after it to have an effect.
You must be calling the toggle script somewhere else if calling it again 'fixed' the problem.
  • 0

#23 Drewdelz

Drewdelz

    GMC Member

  • GMC Member
  • 1056 posts

Posted 15 February 2009 - 10:11 AM

you don't need toggle resize all the time!
You must be doing something wrong, you only call the toggle script if you want to -as the name says- toggle the resizing and call scr_room_goto right after it to have an effect.
You must be calling the toggle script somewhere else if calling it again 'fixed' the problem.


Oh.
I don't really see how, but I guess that must be what's going on. O.o

Oh well, as long as it works.
  • 0

#24 Magdiel

Magdiel

    GMC Member

  • New Member
  • 161 posts

Posted 02 March 2009 - 04:01 PM

This is really useful =D
  • 0
Join the Magitude Games' Forum at:
http://magitude.forumotion.com
Check out my youtube channel =D
http://www.youtube.com/user/TheMagdiel
Keep track of my new game's, Time Stopper, progress by clicking HERE
Proud supporter of DjrelliK's perfect open-source smb3 clone!

#25 necKro23

necKro23

    GMC Member

  • New Member
  • 2 posts

Posted 05 June 2009 - 04:02 AM

Am I the only one having huge problems with this script? Neither the example GM6 file nor trying to implement the script in my own program is working properly at all (under GM7).

With the example, running it without changing anything shows the sample graphic at 1:1 size in the corner of a larger window. Toggling resize just makes the window the same size as the graphic. If I set the game to run fullscreen, toggling resize does fill the screen with the graphic, but it's blurry.

Putting it in my own program, it seemingly doesn't have any effect at all (GM interpolates the screen as usual).

Can someone shed some light on this?
  • 0

#26 UltimateWalrus

UltimateWalrus

    GMC Member

  • New Member
  • 2 posts

Posted 27 June 2009 - 01:54 AM

Am I the only one having huge problems with this script? Neither the example GM6 file nor trying to implement the script in my own program is working properly at all (under GM7).

With the example, running it without changing anything shows the sample graphic at 1:1 size in the corner of a larger window. Toggling resize just makes the window the same size as the graphic. If I set the game to run fullscreen, toggling resize does fill the screen with the graphic, but it's blurry.

Putting it in my own program, it seemingly doesn't have any effect at all (GM interpolates the screen as usual).

Can someone shed some light on this?


I think you have to go into the "Create" script and change scr_resize_init to scr_resize_init_gm7.
  • 0

#27 UltimateWalrus

UltimateWalrus

    GMC Member

  • New Member
  • 2 posts

Posted 27 June 2009 - 02:29 AM

This is awesome! You are awesome! Thanks a bunch!

I'm glad I'm not the only one who notices that Game Maker's full-screen mode looks like crap.
  • 0

#28 deformed thought

deformed thought

    GMC Member

  • GMC Member
  • 133 posts
  • Version:GM7

Posted 17 August 2009 - 06:39 PM

all it seems to do is resize the room...
  • 0

#29 Yal

Yal

    Obviously not Tsuka

  • Global Moderators
  • 10931 posts
  • Version:GM:Studio

Posted 13 November 2009 - 10:59 AM

I'll download this to make Gun-Princess work better on those graphic cards too many people seem to get nowadays (got tipped off about your solution by Head Removalist)... one question, wouldn't setting the monitor size, drawing region size, and view size to the same values, avoid this problem? At least, I think it works on electron beam based screens, but for flat and liquid crystal ones, I can't tell. This guy in my topic said something about bilinear upscaling, but I don't know what that is (english's my second language).

Anyway, I'll try download this. It seems very quite complicated to implement / adapt (the game I will use it for is a huge project; it has already near 200 rooms. I researched how to make a stage editor just to minimize the .exe size by having external rooms, but it's always more work changing stuff you've made before than just append something new)... so I'm asking, is there a simplier soloution (like the one I suggested, resizing the monitor to match the view) that would be easier to implement, but have a con (in this case, changing the monitor resolution - the actual method - would count as one, since windows open while playing would be resized by the swap) that might put people off?
  • 0

- The above is my personal opinion and in no way representative of Yoyogames or the GMC, except when explicitly stated -

 

Open this spoiler for my games:

Spoiler

Some useful game engines: (all completely free to use, even commercially, as long as you replace all included graphics / music first).
SisterEngine RPG Engine - - YaruFPS 3D Collision Engine -- YaruPlatEngine Platform Engine

New user? Can't draw but want to look unique? You can request a new avatar in this thread!


#30 9_6

9_6

    Guest

  • GMC Member
  • 3627 posts

Posted 17 November 2009 - 03:47 PM

Sure, you can also scale up the viewport for the same-ish effect but it'll glitch out and look completely messed up on some computers and vector drawings like draw_line will work in another, higher, actual screen resolution which looks out of place so it's not really a reliable solution.
The only other option is to mess with the resolution.
Now while this gets the job done pretty well, gamemaker likes to mess with more than just the the resolution, it also resizes windows, re-positions desktop icons and all that fun little stuff which is pretty painful for most people.
On top of that, if the game crashes, the computer is also stuck in the set resolution and you have to change it manually.
You have a lot of fun doing that when the resolution has been set to something like 320x240 so this is pretty much a no-go.

I wish there was a simpler method that works reliably, believe me I searched, but it looks like this issue is regarded as such a minor thing that not even gamemaker 8 will finally come with a native fix for this...

Edited by 9_6, 17 November 2009 - 03:55 PM.

  • 0

#31 Yal

Yal

    Obviously not Tsuka

  • Global Moderators
  • 10931 posts
  • Version:GM:Studio

Posted 18 November 2009 - 06:46 AM

OK... Well, the game I care about has the option to resize the screen, so I guess I don't have to implement this to let people have the choice of pixel perfect graphics.
  • 0

- The above is my personal opinion and in no way representative of Yoyogames or the GMC, except when explicitly stated -

 

Open this spoiler for my games:

Spoiler

Some useful game engines: (all completely free to use, even commercially, as long as you replace all included graphics / music first).
SisterEngine RPG Engine - - YaruFPS 3D Collision Engine -- YaruPlatEngine Platform Engine

New user? Can't draw but want to look unique? You can request a new avatar in this thread!


#32 9_6

9_6

    Guest

  • GMC Member
  • 3627 posts

Posted 18 November 2009 - 08:18 AM

Well if you think gun princess is supposed to look like this:
Posted Image
for some people then no, you don't need this.
(Also what on earth are you doing to draw textboxes? My computer nearly froze when I kept the game open and switched focus to photoshop to paste and crop the image. Is that some crazy do-while loop with no sleep() used to let the cpu breathe?)

Edited by 9_6, 18 November 2009 - 08:31 AM.

  • 0

#33 Yal

Yal

    Obviously not Tsuka

  • Global Moderators
  • 10931 posts
  • Version:GM:Studio

Posted 18 November 2009 - 12:03 PM

Well if you think gun princess is supposed to look like this:
Posted Image
for some people then no, you don't need this.
(Also what on earth are you doing to draw textboxes? My computer nearly froze when I kept the game open and switched focus to photoshop to paste and crop the image. Is that some crazy do-while loop with no sleep() used to let the cpu breathe?)

That's what I originally used, but somebody gave me the advice to use "screen_wait_vsync()" instead of sleep() when I asked what would be better. (So I use screen_wait_vsync() for the CPU breath right now...) I guess that was wrong? Also, I'm using keyboard_check_direct() to see wether the key is pressed/released, since keyboard_check() won't notice a change in a key's state in the same step (like in a do-while loop) and thus would make the only way of interrupting the game pulling out the plug. Guess how I know.

As for the grapical issue, yes, that's the problem. Did you take that screenshot with a 320x240 resolution? If so, then I have to use your solution since mine evidently does not solve the problem.

How does the tiles behave if you switch windowed mode on, by the way? Right, I've used a drawing region of 640x240 for the 320x240 view (bad habit), so the lines might still be there... I gotta change that. (Also, that should solve the problem with the vector based parts in the HUD being too thin.)
  • 0

- The above is my personal opinion and in no way representative of Yoyogames or the GMC, except when explicitly stated -

 

Open this spoiler for my games:

Spoiler

Some useful game engines: (all completely free to use, even commercially, as long as you replace all included graphics / music first).
SisterEngine RPG Engine - - YaruFPS 3D Collision Engine -- YaruPlatEngine Platform Engine

New user? Can't draw but want to look unique? You can request a new avatar in this thread!


#34 9_6

9_6

    Guest

  • GMC Member
  • 3627 posts

Posted 18 November 2009 - 01:56 PM

That's what I originally used, but somebody gave me the advice to use "screen_wait_vsync()" instead of sleep() when I asked what would be better. (So I use screen_wait_vsync() for the CPU breath right now...) I guess that was wrong? Also, I'm using keyboard_check_direct() to see wether the key is pressed/released, since keyboard_check() won't notice a change in a key's state in the same step (like in a do-while loop) and thus would make the only way of interrupting the game pulling out the plug. Guess how I know.

This doesn't belong here and I don't really know which is better but I've always used sleep() and never had any problems with it.
Sleep is a fixed value while vsync waits for hardware signals and maybe the vsync method screws up when the game has no focus? I don't know.
Try doing something else when a textbox is open. Click outside of the windowed games window and observe what happens.
At that point my only option was to kill the game process.

How does the tiles behave if you switch windowed mode on, by the way? Right, I've used a drawing region of 640x240 for the 320x240 view (bad habit), so the lines might still be there... I gotta change that. (Also, that should solve the problem with the vector based parts in the HUD being too thin.)

I didn't change the resolution (I don't like that for reasons already mentioned) and the screenshot was taken in windowed mode but it looked the same in full screen.
Also, notice how the text has another resolution than anything else?
That's both issues I mentioned some people like me get when simply blowing up viewports to enlarge the window without blur right there and is pretty much the entire reason I sat down and made this system.

Edited by 9_6, 18 November 2009 - 02:04 PM.

  • 0

#35 Ace

Ace

    GMC Member

  • GMC Member
  • 372 posts

Posted 26 November 2009 - 05:57 PM

I know this is an old topic but my gfx card does this too. Though there's one problem with your fix I'm still unsure of. How would you stop the camera from leaving the room as it seems to do here?

I put a fix in the obj_event so that it wouldn't do such a thing. I'd also need it to work for multiple views, but I'm unfamiliar with surfaces so I don't know if it would work as is even if I added "view_current" to the code. :)

if view_xview<0 then view_xview=0;
if view_yview<0 then view_yview=0;
if view_xview+view_wview>room_width then view_xview=room_width-view_wview;
if view_yview+view_hview>room_height then view_yview=room_height-view_hview;

Btw, this topic should be stickied!!!

This problem is a nightmare for any decent developer putting real effort into their graphics! I tried everything, but to no avail. I didn't think it was possible to fix this developer side. So thanks for your fix, dude! I really appreciate it!


EDIT:
Well, my code worked... until I resized it to tiny with the 'T' key. Unfortunately, when it's small, it doesn't recognize the limits of the room with my code. How would I be able to fix this?

If you could, would you update your scripts/example to include that code so the functionality wouldn't be any different to the real gamemaker's behavior, even when it's small?

Edited by Ace, 26 November 2009 - 06:36 PM.

  • 0
Posted Image Posted Image Online Fighting & Roleplay Game

ZERO ENGINE
Posted Image

#36 Yal

Yal

    Obviously not Tsuka

  • Global Moderators
  • 10931 posts
  • Version:GM:Studio

Posted 27 November 2009 - 06:49 AM

Hmm...

I've actually tried implementing this system, 9_6; but it gave me so much trouble I had to rip it out again to get the game to work properly again.

  • After exporting, importing, and applying script calls where I figured they should be, and starting up the game, I received "variable unknown error" for wport, hport and interpol. Later I got simliar errors for width and height.
  • Implementing the systems cut the framerate in half (and, well, since it draws everything in the room once more each step I understand why) even in rooms one screen large...
  • At some rooms, like the title screen or the game over room, the screen jitters one pixel right-down every second step, then back left-up again the next one. While you might think an effect like this is suitable for e.g. a pause script, I would rather not have it at all.
  • The scripts are poorly commented as in "explaining what they do and how". It's a common error, but if it's going to become a (replacement for) native fix one day it needs to be easy to understand. As well, the lack of reasons WHY you must use e.g. scr_room_goto_resize() made me skip copying that script (after all all of my rooms have the same viewport size), as well as a few others. Also, telling people what a piece of code does enables them to write their own solutions that might be better suited for their needs. As well, not knowing exactly what the code would do and why it should be done in a certain way made it a pain to debug-check and resize for my purposes.

I'd actually like to flam you a bit for the many hours of annoyance I've recieved from your code, but I'm too mature and it wouldn't do this problem any good.
  • 0

- The above is my personal opinion and in no way representative of Yoyogames or the GMC, except when explicitly stated -

 

Open this spoiler for my games:

Spoiler

Some useful game engines: (all completely free to use, even commercially, as long as you replace all included graphics / music first).
SisterEngine RPG Engine - - YaruFPS 3D Collision Engine -- YaruPlatEngine Platform Engine

New user? Can't draw but want to look unique? You can request a new avatar in this thread!


#37 9_6

9_6

    Guest

  • GMC Member
  • 3627 posts

Posted 27 November 2009 - 09:20 AM

I'm sorry but downright cutting the framerate in half is not supposed to happen. At least not with games at a resolution that low.
It doesn't draw everything twice, it draws everything on a surface which then gets stretched and drawn.
Did you by chance use vsync like I tell you not to do in a huge warning before everything else in my first post?
Cause that's the only thing which -for some reason- slows things down that much and there is absolutely nothing I can do about it except telling you not to enable it.

If width, height interpol etc are unknown variables, you forgot to initialize the system with one of the init scripts.

I have no idea what you tried to do and if you've possibly implemented it wrongly somehow, you didn't provide any details after all and I can only extrapolate so much from the result itself. Only that you had trouble.
Sorry but how am I supposed to help you that way.

The jittering isn't supposed to happen at all. Once again I have no idea what you actually tried to do and thus can't do anything help you or even guess what went wrong.

All I can say is that I designed it -to my best knowledge- in a way so it is easily addable to a finished game that doesn't do anything with surfaces and keeps the views normal. From what I can remember at least, it has been almost a year since I looked into it the last time after all but I had no trouble getting back into it just now, just using the comments so I don't know how you can say it is poorly commented.

I have documented what every single script does, where to use it and how to use it in short easy to understand instructions.
Some scripts are so short, if you want to know how exactly things work, just look at the few lines of code but it's not like you ever actually need to to get it to work.

--------------


Well, my code worked... until I resized it to tiny with the 'T' key. Unfortunately, when it's small, it doesn't recognize the limits of the room with my code. How would I be able to fix this?

If you could, would you update your scripts/example to include that code so the functionality wouldn't be any different to the real gamemaker's behavior, even when it's small?

That code always worked for me.
Anyway, view handling is supposed to happen in the game already.
I just slapped that on for demonstration purposes and want to keep anything that doesn't have to do with the actual system, which is about screen resizing and not view handling after all, as basic and simple as possible so people don't confuse it with something they need to add to their game. Sorry.
Be happy the view moves at all :)

Also this has been strictly designed for 1 single view only.
I have no idea how it acts with multiple views or how to make it work with more than one whatsoever since I never needed more and am not really familiar with multiple views at all.

Edited by 9_6, 27 November 2009 - 10:04 AM.

  • 0

#38 Yal

Yal

    Obviously not Tsuka

  • Global Moderators
  • 10931 posts
  • Version:GM:Studio

Posted 30 November 2009 - 12:17 PM

Right, if I give more details: (all of these are in the past tense, BTW, I won't use the solution until I'm sure it works)

In the Creation code of the very first room I call the :( init script (which also creates the screencontroller object and an instance of it). The first time I started the game with the script, the script being exactly as in your example file, it gave me errors about nonexist variables. Eventually I had to replace all of the variables with the values I wanted them to be; seeing as the whole game has the same screen resolution all the time.

As well, making sure the viewcontroller isn't deactivated was harder than it should be. The init script should also create a 1x1, non transparent sprite, give it to the screencontroller, and make the object invisible. People knowing less GML than me are prone to get more problems than having to change the scipt and run the game three times.

The jittering appeared, for some reason, in the very first room the first time it was visited only. It always appeared in the game over room, which only has an object drawing transparent text... at least that's what I think could cause the interference. In the main gameplay, the jittering appeared randomly (at least I'm clueless what caused it the times it appeared) but sometimes didn't appear (jay!). After setting wport and hport to the same size as width and height it worked, but it gave an unpleasant outline of whatever was drawn on the internal surface the last time something was drawn on it (like when calling screen_refresh()) to the viewport.

Now, there's a few things you could do to improve readability:
str="Use multiline;
strings();
Which makes them easier to read();
"
object_event_add()
And I still don't get exactly what the screencontroller do. I get that it will draw stuff on a surface then place the surface on the screen, but I'm clueless what the user defined events do and when they are called since they're called from the other scripts. You also haven't given reasons for why you should do stuff, it's like Always use scr_screen_redraw() before calling this! instead of Always use scr_screen_redraw() before calling this script, otherwise the viewport will be turned upside-down and the framerate will drop to 3. If you get what I mean.
Adding some lines like //Redraws surface like screen_redraw() would do in the space between two lines would improve readability.

You should also give some in-depth explaination in the language you're born with (which I assume it isn't english) so that people at least could google translate/babelfish it.

qEdit:
And I'm 100% sure I'm not using screen_wait_vsync() anywhere in the code. It is a coincidence, but I removed it from a script just a few days before I tried to implement your solution.

Edited by Yal, 30 November 2009 - 12:20 PM.

  • 0

- The above is my personal opinion and in no way representative of Yoyogames or the GMC, except when explicitly stated -

 

Open this spoiler for my games:

Spoiler

Some useful game engines: (all completely free to use, even commercially, as long as you replace all included graphics / music first).
SisterEngine RPG Engine - - YaruFPS 3D Collision Engine -- YaruPlatEngine Platform Engine

New user? Can't draw but want to look unique? You can request a new avatar in this thread!


#39 9_6

9_6

    Guest

  • GMC Member
  • 3627 posts

Posted 30 November 2009 - 07:11 PM

Right, if I give more details: (all of these are in the past tense, BTW, I won't use the solution until I'm sure it works)

In the Creation code of the very first room I call the :( init script (which also creates the screencontroller object and an instance of it). The first time I started the game with the script, the script being exactly as in your example file, it gave me errors about nonexist variables. Eventually I had to replace all of the variables with the values I wanted them to be; seeing as the whole game has the same screen resolution all the time.

I have no idea why that would happen whatsoever.
The variables get initialized in the script right before anything can complain about them being amiss and they are only needed in the init script anyway and even if you would have had a global variable called 'global.screencontroller' in the game already, the init script alone should just do nothing at all in this case.

If you however get that error from the script that switches rooms, that probably means you have a variable 'global.screencontroller' somewhere which would explain the errors.
In fact, that is the only explanation I would have right now.

As well, making sure the viewcontroller isn't deactivated was harder than it should be. The init script should also create a 1x1, non transparent sprite, give it to the screencontroller, and make the object invisible. People knowing less GML than me are prone to get more problems than having to change the scipt and run the game three times.

Brute-force activating the object like I suggest it in the first post in the warning should be a more reliable solution to that and shouldn't require the object to have a sprite at all.
Maybe I should make that into a script and tell everyone who deactivates stuff to call it right after that, otherwise the screen stays black.

The jittering appeared, for some reason, in the very first room the first time it was visited only. It always appeared in the game over room, which only has an object drawing transparent text... at least that's what I think could cause the interference. In the main gameplay, the jittering appeared randomly (at least I'm clueless what caused it the times it appeared) but sometimes didn't appear (jay!). After setting wport and hport to the same size as width and height it worked, but it gave an unpleasant outline of whatever was drawn on the internal surface the last time something was drawn on it (like when calling screen_refresh()) to the viewport.

No idea what might have caused this.
Maybe it had to do with you manually setting variables like you stated before.
I had that too and it drove me nuts because it made no sense, setting wport to width-1 and doing the same to hport mysteriously solved it.

Now, there's a few things you could do to improve readability:

str="Use multiline;
strings();
Which makes them easier to read();
"
object_event_add()

THIS
is a good idea. I wasn't even aware you can write strings like that.
I'll look into changing that.

And I still don't get exactly what the screencontroller do. I get that it will draw stuff on a surface then place the surface on the screen, but I'm clueless what the user defined events do and when they are called since they're called from the other scripts. You also haven't given reasons for why you should do stuff, it's like Always use scr_screen_redraw() before calling this! instead of Always use scr_screen_redraw() before calling this script, otherwise the viewport will be turned upside-down and the framerate will drop to 3. If you get what I mean.
Adding some lines like //Redraws surface like screen_redraw() would do in the space between two lines would improve readability.

The user events are basically just the screen refreshing but because gamemaker6 decided to be a total ***** at a point that makes no sense whatsoever, it needs to handle screen refreshing in a different way when the game is frozen as opposed to gm7 where the normal script always gets the same result.
I moved that into the user events because it is easier to have 2 different init script versions and calling the user events from the other scripts than having to juggle around 2 different versions of each script that needs to refresh the screen.

Considering your other point, I don't see why I should explain "Always use this instead of screen_redraw();". It fully replaces that function.
Why? Because the system needs it. If you don't, stuff messes up. It's simple like that.
There's no need to combine functions either, they always fully replace the gm native ones and if they don't, I explicitely state that they don't (like in "scr_resize_stop_drawing" which does not do the job of screen_refresh).
I also don't see where you got the example "Always use scr_screen_redraw() before calling this!" from, I've just searched through all scripts.
There are some scripts like "scr_resize_start_drawing" that require things to be done in a certain order. I don't see how lengthy explanations of why you should do this would help.

You also just say 'Do not touch the hot plate, you'll burn yourself.' to a kid as a short, easy to understand statement instead of explaining the various states of burns in a lengthy explanation.
It'll find out why it shouldn't, if it does anyway but it knows it should not.

I also didn't feel like doing things wrong on purpose just to document what happens if you use the system wrongly and I think I do properly state how to use it correctly.
If it's well hidden trap holes like the vsync thing, well, I made a big red warning about that in the first post.

You should also give some in-depth explaination in the language you're born with (which I assume it isn't english) so that people at least could google translate/babelfish it.

What's wrong with my english?
Everyone who uses game maker should be able to understand english.

Ist automatisch uebersetztes Deutsch wirklich genauso gut versteandlich wie Englisch von jemandem, der die Sprache kennt und die Saetze von vornherein Englisch formuliert?
Wenn nicht, warum sollte ich dann meine Zeit verschwenden indem ich alles doppelt schreibe in einer Sprache, die hier sowieso kaum jemand spricht?
Das erscheint mir recht kontraproduktiv.

I also have no idea how to go 'in-depth' with the documentation.
You see what it does, you know how to use it, what more do you need?
You don't need to comprehend the source code, that's for me. You also do not see the source code of extensions or libraries.
You being able to view and edit it is in fact just a bonus. You're not encouraged to do that but you have the possibility.

So if you get an error, come to me immediately and I'll try to help, no problem (unless I'm busy at that time).
If you however proceed to manipulate the scripts which kinda solves the problem but leads to even more errors which you then waste hours on to fix, don't blame me.

Also if you can't get it to work at all, you can even give me the source and I'll take my time to look into the matter myself (and don't worry, I don't care about 'stealing' anything since I'd have no use for other peoples code, graphics or sounds anyway).

Edited by 9_6, 30 November 2009 - 07:42 PM.

  • 0

#40 Yal

Yal

    Obviously not Tsuka

  • Global Moderators
  • 10931 posts
  • Version:GM:Studio

Posted 01 December 2009 - 11:33 AM

If you however get that error from the script that switches rooms, that probably means you have a variable 'global.screencontroller' somewhere which would explain the errors.
In fact, that is the only explanation I would have right now.

First of all, I tried being clever by changing each and every "screencontroller" (using the Search Replace option) in every script into something completely different, just for being sure no clashes would occur. And since I never encountered a "unknown object" or so error, I take that didn't affect anything. What disturbs me is that the event where the Unknown Variable error occured was the first event actions where set to in the init script. The create event of the screenscontroller object, right? So for some reason it seems like GM blatantly ignores the fact that all of these five variables are set to values! That is very annoying. Of course, it isn't your fault either.


Considering your other point, I don't see why I should explain "Always use this instead of screen_redraw();". It fully replaces that function.
Why? Because the system needs it. If you don't, stuff messes up. It's simple like that.
There's no need to combine functions either, they always fully replace the gm native ones and if they don't, I explicitely state that they don't (like in "scr_resize_stop_drawing" which does not do the job of screen_refresh).
I also don't see where you got the example "Always use scr_screen_redraw() before calling this!" from, I've just searched through all scripts.
There are some scripts like "scr_resize_start_drawing" that require things to be done in a certain order. I don't see how lengthy explanations of why you should do this would help.

You also just say 'Do not touch the hot plate, you'll burn yourself.' to a kid as a short, easy to understand statement instead of explaining the various states of burns in a lengthy explanation.
It'll find out why it shouldn't, if it does anyway but it knows it should not.

I also didn't feel like doing things wrong on purpose just to document what happens if you use the system wrongly and I think I do properly state how to use it correctly.
If it's well hidden trap holes like the vsync thing, well, I made a big red warning about that in the first post.

I'm not suggesting that you should use things in the wrong way to see what happens, but if you either made a mistake and stumbled upon some kind of consequence (like the vsync() problem) or know that something will happen if the code is used in the wrong way (like, calling a script with the argument 0 instead of the id of an instance (always larger than 1000000) would make a loop having to loop trough 1000000 indexes extra, which takes some time), it would be nice if you wrote that.

"If you don't, stuff messes up." might of course be enough of a disclaimer, but it's nice if you tell how stuff might mess up, if you get what I mean. An explanation like that will answer a very important question: "Does [stuff that currently mess up] mess up because I use this code in a wrong way, or is there a problem with the code itself?" Usually, knowing what isn't the reason to a problem makes tracking down what is the reason much more simple.
  • 0

- The above is my personal opinion and in no way representative of Yoyogames or the GMC, except when explicitly stated -

 

Open this spoiler for my games:

Spoiler

Some useful game engines: (all completely free to use, even commercially, as long as you replace all included graphics / music first).
SisterEngine RPG Engine - - YaruFPS 3D Collision Engine -- YaruPlatEngine Platform Engine

New user? Can't draw but want to look unique? You can request a new avatar in this thread!


#41 9_6

9_6

    Guest

  • GMC Member
  • 3627 posts

Posted 02 December 2009 - 12:46 PM

Okay I have just played a gm game that makes extensive use of effects that, I assume, eat up tons of surfaces.

Then I started my game that uses resizing and got graphics glitches all over it (after activating the resizing) that weren't ever there before.
The only way to resolve that was to restart my computer.
This is directly related to that game and reproduceable, maybe it has something to do with how game maker handles surfaces or there is some permanent memory leak in that game or it just completely wrecks your video memory, I have no clue whatsoever.
Anyway if your game looks like this:
Posted Image
for no apparent reason, restart your computer.
This is also why you always ALWAYS make the resizing optional since the game displayed normally without it.

I am in 'glitch mode' for a while right now, getting the same errors consistently, about to restart my computer to see if that fixes it. (Edit: yep, that fixed it.)
However I have play tested that game with the resizing activated countless times and never ever got that error before so I'm fairly sure the resizing would never cause that sort of problem by itself.

You said you had experienced some graphical glitching before, was that it?
I've also updated the first post, made everything more readable and explained stuff a bit more. Is that better?

Edited by 9_6, 02 December 2009 - 02:13 PM.

  • 0

#42 PHL

PHL

    GMC Member

  • GMC Member
  • 189 posts

Posted 10 January 2010 - 03:12 PM

Well I have no idea.
Maybe you could pm me the source so I can see what you're doing?


Is this thing a DLL ? I use Game Maker 5 so a GEX cannot be useful to me.
  • 0
See and/or buy my art online at tamajongphilip.imagekind.com. Video games need graphic artwork of some kind.

PHL's Free Game Ideas - www.phl-freegameideas.webs.com

On the Internet you can buy PHL's Air Flying game at http://store.indieci...lsairflyinggame . (Friday 19th October 2012.)

#43 9_6

9_6

    Guest

  • GMC Member
  • 3627 posts

Posted 11 January 2010 - 07:39 PM

Well I have no idea.
Maybe you could pm me the source so I can see what you're doing?


Is this thing a DLL ? I use Game Maker 5 so a GEX cannot be useful to me.

It is neither a dll nor an extension nor compatible with gm5.
  • 0

#44 SolvedSnake

SolvedSnake

    GMC Member

  • New Member
  • 21 posts

Posted 04 April 2010 - 02:06 PM

9_6, you are my new favorite guy! <_<
  • 0

#45 PHL

PHL

    GMC Member

  • GMC Member
  • 189 posts

Posted 06 April 2010 - 07:54 PM

Hello
Pixel Perfect Resize sounds good but it seems not to be for Game Maker 5.
How can I get the same thing for GM 5 ? Would you make it?
Thank you.
PHL
  • 0
See and/or buy my art online at tamajongphilip.imagekind.com. Video games need graphic artwork of some kind.

PHL's Free Game Ideas - www.phl-freegameideas.webs.com

On the Internet you can buy PHL's Air Flying game at http://store.indieci...lsairflyinggame . (Friday 19th October 2012.)

#46 True Valhalla

True Valhalla

    ಠ_ಠ

  • GMC Member
  • 5277 posts
  • Version:Unknown

Posted 29 June 2010 - 10:39 AM

Guess this means it isn't liking my computer:

Posted Image

Pity, really wanted to use this.
  • 0

book_forum.png


#47 decroded

decroded

    GMC Member

  • GMC Member
  • 584 posts
  • Version:GM8

Posted 25 September 2010 - 03:53 AM

Hi I'm trying to implement your system and everything works except when I have persistent rooms.
When the previous room is persistent and I go back to it, it causes the window to show at 1:1 scale instead of 2:1 scale.
The pixels inside are 2:1 scale still so it cuts out most of the view too.
The problem is in fullscreen too.
I have tried all the different room, view settings etc and tested as best I can but I'm not having any luck.

I modified your example here with 3 rooms.
N=next room
B=prev room

The 2nd room is persistent, notice that coming back from 3rd room to 2nd room has the problem?
Any workaround please or am I doing something wrong?

UPDATE:
Excuse a noob's ignorance, but using one line
window_set_region_scale(2,true);
gives me the same result without any problems with persistent rooms.
My game doesn't have loads of stuff happening on screen yet but I play tested a few levels and it stayed solid 60fps the whole time (except during room transition) and looked perfect in windowed or full screen.
I'm sure there's a reason but please can you tell me why I shouldn't just use that method?
Is there some kind of compatability issue or performance hit with more complex games?

Edited by decroded, 25 September 2010 - 08:36 AM.

  • 0
Don't forget to +1 if I have helped you ========>

#48 9_6

9_6

    Guest

  • GMC Member
  • 3627 posts

Posted 26 September 2010 - 12:38 PM

Oh dear, it has been forever since I looked into that code the last time.
I'll try to identify the problem later.

UPDATE:
Excuse a noob's ignorance, but using one line

window_set_region_scale(2,true);
gives me the same result without any problems with persistent rooms.
My game doesn't have loads of stuff happening on screen yet but I play tested a few levels and it stayed solid 60fps the whole time (except during room transition) and looked perfect in windowed or full screen.
I'm sure there's a reason but please can you tell me why I shouldn't just use that method?
Is there some kind of compatability issue or performance hit with more complex games?

Draw circles and lines while scaling up that way and you get mixed resolutions which look awkward.
Also just blowing the viewport up can lead to graphical glitches, for example if you use tiles some people get 1 pixel wide lines of black.
It's a pain and honestly, I wish your method would just work flawlessly, like it should, but it doesn't.

Edited by 9_6, 26 September 2010 - 12:40 PM.

  • 0

#49 decroded

decroded

    GMC Member

  • GMC Member
  • 584 posts
  • Version:GM8

Posted 26 September 2010 - 01:10 PM

Oh dear, it has been forever since I looked into that code the last time.
I'll try to identify the problem later.

Thanks. I was going to have a look but I'm still trying to define a view in GML without using room properties (please help here if you can!).

Draw circles and lines while scaling up that way and you get mixed resolutions which look awkward.
Also just blowing the viewport up can lead to graphical glitches, for example if you use tiles some people get 1 pixel wide lines of black.
It's a pain and honestly, I wish your method would just work flawlessly, like it should, but it doesn't.

Circles and lines work fine as per this part of a screenshot from my WIP.
I'm sure there are some other issues I will run into though and will need to switch to your system so I would rather do it your way.

Cheers.
  • 0
Don't forget to +1 if I have helped you ========>

#50 caiys

caiys

    GMC Member

  • GMC Member
  • 90 posts
  • Version:GM:Studio

Posted 26 September 2010 - 06:44 PM

I seem to be having a problem trying to get this to work in my game (the example file works fine). I add all of the scripts, create a MM_Contoller object which is placed in the initial room and in its create event add the following code:

scr_resize_init_gm7(396,216);
scr_room_goto_resize(Main,396,216,396*2,216*2);

The screen correctly scales up to double the room size but the screen goes black and freezes so I have to use the Task Manager to close it.

I use an instance_deactivate_all pause script but that's only in a completely different room in an object that doesn't appear in the initial room. I'm also not using any while loops at all.
  • 0

 





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users