Jump to content


Dreamsequence

Member Since 17 Feb 2011
Offline Last Active May 08 2013 09:21 PM

Posts I've Made

In Topic: Automatic Resolution Adjuster

11 December 2012 - 04:41 AM



This method holds a few flaws, as stated on the OP, you must re-execute the code everytime the room changes, and if you dont do that everything gets reseted.
It is possible to change the views propierties at runtime, without need to use room_set_view(), wich is a bit of a clumsy function, since it changes the propierties of the room at startup and the only part we really need to change there is the views propierties.

The way I do it is pretty much the same calculation, but made on a Step event, so whenever you rotate the screen you get the view adjusted automatically with no need to reset the room or whatever; I use view_wport and view_wview constants, they give better and simpler results and you only have to specify them on the room you are on:

if os_type == os_android || os_type == os_ios {
    display_w = display_get_width();
    display_h = display_get_height();
    aspect_ratio = display_h/display_w;
    if (display_w > display_h) {
        aspect_ratio = display_w/display_h;
    }
    view_wview[0] = 768*aspect_ratio;
    view_wport[0] = view_wview[0];
}
// On this example, the view width will be scaled to match the
// screen's aspect ratio, while the height will remain the same (768px)
// Notice how the view ports change too to match the screen resolution!

The calculations and manners may change depending on the needs, but the method of applying the view sizes remains. I use this method on all of my alredy published games and prototypes :)/>


0.o Ooh, that's an interesting alternate.. I'll have to play with that later. Thanks for sharing!



This seems pretty useful! (Was looking for something to do this) my question is what if you have something draw on the screen at a specific location like using view_wport and hport then add numbers like if I don't want it at wport (0,0) instead i'd do something like view_wport + 300 (for example) now when this changes the resolution if mines set to be at 1920x1080 and they got down to 640x480 (for example) would that put the draw in the wrong spot?

You will have to make adjustments to make those elements draw correctly again. Personally, I like to have interface elements set only a handful of pixels off the edge of the screen, so when the resolution is changed lower, they're not too intrusive. But if you have, say, a text box popping in 300 pixels off the right of the screen and suddenly your screen goes from 1920 wide to 640 wide, you're going to have a gap spanning half the screen and that text box will probably be cut off by quite a lot.

Using things like view_hview/2 (centered vertically) or view_wview*0.75 (3/4 of the way to the right) will always draw that element in the same relative spot no matter what your resolution is. When you add and subtract, that's where things can get a little messed up. In some cases, you may want to either scale up/down elements or even make multiple versions of them for specific screen size ranges. view_wport and view_hport should work about the same, I think.

In Topic: My Gamemaker (steam) keeps closing

26 November 2012 - 04:17 AM

Gamemaker keeps on closing by itself. This started after one play through where I kept getting skulls. After that , I didnt get any skulls but my program keeps on closing down.

Is this a known bug that is going to get fix? or do i have to do a install-reinstall . Im not sure how to do that on a Steam application so someone could please help me?

Im running v 1.1.676 .

I only recently upgraded from Free Edition to Professional + HTML , if that helps.


Is this happening when you test play your game? I'm getting a crash every time I run my game as well... GM:Studio crashes but the runner keeps going just fine.

In Topic: Retro CRT distortion effect using RGB shifting

04 October 2012 - 11:19 PM


-snip-

Maybe some of the functions this uses are deprecated in GMS? I dunno, I've only tried in GM8.1 and it worked like a charm by copy-pasting the code that was there into some sort of constants object.

I thought that might be the case, but I went through the whole thing and it looks solid. Nothing seems to have disappeared from GM Studio.

Maybe since I've dug through it enough, I could give it a try myself, just recreating the RGB shifting from scratch to see if I can get it to work. Can it be done without surfaces, perhaps? Because this seems like it needs to all happen in the draw event, after all sprites draw but before the UI draws. (in my case, anyway) And GM isn't supposed to be able to mess with surfaces in the draw event.

In Topic: Latest Studio update broke new sound engine

03 October 2012 - 09:10 AM


Ever since I downloaded the newest GM: Studio update (1.1.469) the new sound engine has been wonking out on me. It was working perfectly before, playing dozens of sound effects just fine. But now, it's really acting up. Sound effects are going randomly in an out of sounding muffled and quiet, they seem to be only coming out of one speaker now, and there's just no explanation for why. When I export an executable, it continues to fail in the exact same way on my laptop, so I'm fairly sure it's not this specific machine.
Is anyone else experiencing this problem? Or something similar?



Not sure if this will help, but I read it on another post...

All new functions, for the new engine are preceded by "audio_". The legacy, or old functions are preceded by "sound_". If you wish to use the new engine, make sure it's checked under global game settings.

[x] Use new Audio Engine
// Example: audio_play_sound(sound,priority,loop);

[ ] Use new Audio Engine
// Example: sound_play(sound);

I actually already made this mistake in the last update, so I'm good on that front. Only one sound engine can be in use, so if you have the new one turned on, the old sound engine sounds simply won't play, and vice versa if it's off.
Unfortunately, that's not the issue I'm having. The sounds still do play (in the new engine, not the old one) but they're messing up a lot.

Seems like I'm not the only one. I saw a bug report that sounds... similar to this in the bug tracker, and it looks like they have it fixed for the next update. By the sound of it, it's hopefully just a matter of waiting until that next update for sounds to start working again. I guess the new engine has some unexpected bugs to work out.

In Topic: Retro CRT distortion effect using RGB shifting

03 October 2012 - 05:44 AM

I'm trying to implement this in my GM: Studio game... interestingly despite many attempts to fix it, it simply doesn't work, in more ways than one.

It always draws the screen black. I've tried numerous different combinations of cutting out the screen target changing bits of the script and setting them in Step events and moving the background sprite generation elsewhere, activating and deactivating stuff... it always turns the whole game screen black. :| I've even tried stuff like changing from drawing the screen as a background to drawing it as a sprite. No dice.

Also, it slows my game to a crawl. Ordinarily it registers an average 800+ FPS, but when I put this in (no matter what I do to try and speed it up) it dives down to 8-12 FPS. This is just the RGB shift effect, too.

I've gone through it line by line and changed so much that it should work. It just doesn't. And I know my game is running at 720p so drawing sprites the size of the game screen isn't something I want to play with too much, but I do that for my lighting system and it runs just fine.


Honestly, I'm stumped. This isn't an effect I -need- but I really wanted to do chromatic aberration in place of screen shaking for my game, and this is how it's done. (well, the simplified version of it anyway)