fenyxofshadows

Okay. I was working on a game, and the clickable plane isn't always at 0. I want to use Yourself's scripts, but they only work for z=0 and I can't figure out how to make them work for variable z.

Help........ -________________________________________________-

For those who don't have them yet, this is what Yourself's Convert_2D script looks like. It converts an onscreen position to a 3D position.

screenx = 2 * argument0 / view_wview[argument5] - 1;
screeny = 1 - 2 * argument1 / view_hview[argument5];
mX = dX + ( uX * screeny ) + ( vX * screenx );
mY = dY + ( uY * screeny ) + ( vY * screenx );
mZ = dZ + ( uZ * screeny ) + ( vZ * screenx );

if ( mZ != 0 )
   {
    x_3d = argument2 - argument4 * mX / mZ;
    y_3d = argument3 - argument4 * mY / mZ;
   }
else
   {
    x_3d = argument2 - argument4 * mX;
    y_3d = argument3 - argument4 * mY;
   }

The problem is, it converts only at z=0. I can't figure out what needs to be changed to make it an arbitrary z.

http://gmc.yoyogames...howtopic=554334

This discussion is basically nitpicking about the definition of a religion. But, by the arguments shown, people seem to believe that belief in a god constitutes religion. There are atheist religions though. People also seem to believe that belief in a god is all you need for religion. This doesn't make sense, as a religion needs a well defined set of beliefs and traditions, and more importantly, it needs followers. Theism, like atheism, does not fit this.

I personally believe that atheism and theism are definitions of one's beliefs, but they aren't focused enough to be religions by themselves.

To ask the question of whether atheism (or theism) is a religion is a fallacy.

Discuss, or don't. I'm merely making this topic to act as a sort of corollary to the previous topic.

• Title: Maintaining aspect ratio on devices with vastly different screen sizes
• Description: An example / tutorial on how to maintain the aspect ratio of a game on many devices without separately compiling for each device
• GM Version: GM:Studio (Android (tested on Gingerbread), Windows (tested on 7), iOS (untested), and Mac (untested) modules)
• Registered: No, however to test it on Android or iOS requires Pro.
• File Type: .gmz
• File Size: 1670Kb (sorry it's so big, but i had to include a massive image to emphasize something)
• File Link: https://dl.dropbox.c...atioExample.gmz
• Required Extension: none
• Required DLL: none
• Tags: tutorial, example, aspect ratio, studio

Summary
First, before I say anything, this is not to be used with HTML5. This is meant for fullscreen games, and HTML5 is meant to be played outside of fullscreen.

Okay... When you are making a game for mobile devices, oftentimes the devices don't match in aspect ratio sizes (4:3 vs 16:9) or DPI (iOS Retina vs most things). This is to be expected, but it makes life a pain for a mobile developer, who either has to allow some devices to stretch the images strangely or not support some devices.

What I have done is devised a method to allow your games to be aspect ratio and DPI independent.

Note: This method is an imitation of something that already exists in the Windows and Mac modules. Under Global Game Settings, under the "Windows" and "Mac" tabs in the "Graphics" subtab, there is a setting called "Scaling". Click "Keep Aspect Ratio" (which is the default setting for fullscreen games in Windows and Mac). However, my method is meant to emulate this functionality on mobile devices that do not have this option at all.


First, we will need your first room to have two views (I used view[0] and view[1] for this). The settings of view[0] don't matter, but it must be visible when the room starts. The settings of view[1] do matter. View[0] (henceforth called the "border") scales to fit the full screen of the device, while view[1] (the "play area") scales to fit view[0] without losing its aspect ratio. The initial settings of view[1] determine the resolution (using "View in room" W and H) and the aspect ratio (using "Port on screen" W and H) of the play area. In the example, the play area is 800x600, with a matching aspect ratio.

Next, we need a controller object for the aspect ratios. Give it a very high depth (so it acts and draws first).

In its create event, put something like the following

///Initialize

//initialize variables
globalvar scale_multiplier;
scale_multiplier = 0;
first_run = 0;   //for the alarm
globalvar HEIGHT;
globalvar WIDTH;

//initialize window size
//get width and height of screen
HEIGHT = display_get_height();
WIDTH = display_get_width();
//make view 0 fit screen
view_hview[0] = HEIGHT;
view_wview[0] = WIDTH;
view_hport[0] = HEIGHT;
view_wport[0] = WIDTH;
//make window fit screen
window_set_size(WIDTH, HEIGHT);
window_set_fullscreen(true);

//set alarm to set the game window again
alarm[0] = 5;

As an explanation of what this does: It gets the total pixel count of the screen being used, then stretches the border view to fit it before the border has a chance to draw. This way, whatever is put on the screen is put on at the screen's full resolution, so everything is a 1:1 ratio relative to the screen. It then sets the window size to the proper size, and sets fullscreen (for desktops to demonstrate). It then sets an alarm for a test and the positioning of the game view.

When GM runs, the window is set to the size of bounding box of all of the views. This circumvents this by setting a view to be the largest that the screen can draw, and then manually setting the window size.


Next, we need to set the size of the game view, and position it correctly (the example positions it in the center of the screen).
Put something like this in alarm[0] event of the same controller object.

///Change the view[1] to fit the screen based on aspect ratio.

//get width and height of screen
test_height = HEIGHT
test_width = WIDTH
HEIGHT = display_get_height();
WIDTH = display_get_width();

//test the screen size to see if it A) changed, or B) hasn't been fully initialized
if ( ( HEIGHT != test_height ) or ( WIDTH != test_width ) or ( first_run == 0 ) )
   {
   first_run = 1;
   
   //make view fit screen
   view_hview[0] = HEIGHT;
   view_wview[0] = WIDTH;
   view_hport[0] = HEIGHT;
   view_wport[0] = WIDTH;
   //make window fit screen
   window_set_size(WIDTH, HEIGHT);
   window_set_fullscreen(true);
   //make view normal again

   //test the screen's aspect ratio relative to the play area's aspect ratio
   if ( ( HEIGHT / view_hport[1] ) <= ( WIDTH / view_wport[1] ) )
  	{
  	/*
    	if the height relative to the play area's height is smaller
    	than the width relative to the play area's width, then 
    	the multiplier for the screen is based on the height
    	this way, it stretches to fill the screen up to the height,
    	similar to the "Maintain Aspect Ratio" option in the
    	Windows module                                             	
  	*/
  	scale_multiplier = ( view_hport[0] ) / view_hport[1];
  	}
   else
  	{
  	/*
    	if not, it's based on width, again like the Maintain Aspect Ratio 
    	option in the Windows module.
  	*/
  	scale_multiplier = ( view_wport[0] ) / view_wport[1];
  	}
   
   //this actually changes the play area's size
   view_hport[1] = view_hport[1] * scale_multiplier;
   view_wport[1] = view_wport[1] * scale_multiplier;
  
   //this sets the position of the play area to the center of the screen
   if ( ( HEIGHT / view_hport[1] ) <= ( WIDTH / view_wport[1] ) )
  	{
  	view_xport[1] = ( WIDTH / 2 ) - ( view_wport[1] / 2 );
  	view_yport[1] = 0;
  	}
   else
  	{
  	view_xport[1] = 0;
  	view_yport[1] = ( HEIGHT / 2 ) - ( view_hport[1] / 2 );
  	}
   }
   
//run the test of the first few lines again in 5 steps. 
//if the screen size hasn't changed then nothing should happen
alarm[0] = 5;

I believe another explanation is in order. What this does is accomplish two tasks. It resets the border view size and the window size if the window resolution has changed somehow (for example, rotating a phone). It then tests the aspect of the game view relative to the aspect of the screen, and stretches the game view (or shrinks it as the case may be) to fit so that it is neither smaller than need be nor too big to fit the screen. It then positions the game view correctly. It runs the alarm again every 5 steps, but if the screen hasn't changed then nothing should happen as it would fail the test for everything to be repositioned.


There is a bug with this, however. Because this uses views, the border area shows part (or all) of the room at 1:1 resolution, and may even show objects! *shudders* This is neither good for your players nor your framerate!

So, to work around this, there are two things that must be done.

First, we need to cover up the room itself. The example does it by posting a massive picture in the top corner of the screen but only when the view being drawn is the border view.

if ( view_current == 0 )
   {
   draw_background( bg_bordertest, -1, -1 );
   }

This has a pleasing effect (note: this is not from my example).

However, objects may still draw on the border view. If they do, they will take up video resources even if they are covered by the border.

So, for all objects that are visible on the game view only, do this:

if ( view_current != 1 )  //this way we don't waste resources or have graphical errors
   {
   exit;
   }
draw_self();  //can be any draw code, really

The example has an example of this in the obj_player.



Hopefully, this will solve some problems with stretching without having to individually compile for each resolution, or do any other strange things like that.

Thank you for reading!

Split+Balance
Download: http://gamejolt.com/...oad/8871/10984/ (8.6 MB)
Type: Vertical scrolling shooter
Here's my GMC Jam 7 entry.

Devlog:

WIP Screens:

WIP .exe Downloads:

Okay, I converted a lot of static 3D draws to models and now half of them aren't drawing. Of those that are drawing, some don't have textures.


It's also missing the clouds that were there before too. I tried reducing the size of the cloud textures from 1024x1024 to 256x256 to have them hopefully appear, but with no luck.

As a more visual example of what I'm missing, here's my screen from before



Is this a bug with GameMaker 8.1, is it a bug with the number of polygons per draw, or is it just my computer derping?