Splaff

I'd like to use Game Maker's splash screen functions to show a short video logo at the beginning of my game, which is just a typical AVI file.
However, it seems that the functions for displaying video lock anything and everything to a 4:3 aspect ratio, despite the fact that the original
video is 16:9... I've looked through the documentation for something which would fix this, but the "scale" function just affects size, not ratio.

Can this actually be changed, or is this yet another Game Maker limitation? Are there any simple DLLs to get around this?

Hey all. I've been putting together a very simple platform engine in the last few hours
to use as a base for a game, but I've noticed a few confusing errors in the programming.
(For reference, the code was adapted from the Zool design in The Game Maker's Companion.)

The errors appear to come from a horizontal force being applied to the "air" state of the player
while the player is pushing against a surface in the same direction - if a key is held to press the
player against a wall while jumping, a strange bug occurs where the object leaps up a large
number of pixels instantaneously (as compared to the normal jump, which is far more smooth.)

The player also has a strange tendency to "snap" to corners it approaches - try jumping diagonally
into the corner of one of the "stairs" in the test level, and the player object suddenly jumps to align with it.
I've also seen it sliding down walls far more quickly than the standard speed, and for no apparent reason.

I believe that all of these problems are caused by the move_contact_all(direction,-1) statements which
I currently am using - as jumping and sliding would offset the direction, therefore making this unreliable.
Am I correct in thinking this? If so, what can I do to replace it?

Hey all, I've got a math question.

I'm building an orrery in Game Maker (those fancy solar system mechanisms with rotating planets and moons in concentric circles), and I'm using the
lengthdir functions to draw planets and etcetera at the proper distance while they rotate. By using different length arguments in lengthdir_x() and lengthdir_y(),
I can also make the appearance of an elliptical orbit, as if the orrery is being viewed from partially above (simulating perspective in 2D).




However, there's another problem. I'm also attempting to build the whole thing at a 45 degree tilt, meaning that the lengthdir functions themselves
will no longer suffice. I can't change the length arguments, either, as that would just change the shape of the orbit, not its pitch.




How could I achieve something like the diagram above? I'm essentially just trying to get angle-based x and y positions on the border of a tilted ellipse.

Hey all! I'm at the very beginning of creating what I hope is my first major project, and I've been running into a few walls in my thought.

The major problem, at the current moment, is resolution. This might not sound like much, but it's a serious issue, so please bear with me.

It may help if I describe my prototype a little further. I'm attempting to create a largely environmental and atmospheric puzzle game, where a large
majority of the game revolves around exploration and slowly getting to grips with the world. Anyone who's played Seiklus or Fez will know the idea.
Essentially, art, design, and detail will be a major part of the final appearance of the game, as well as the player's ability to appreciate the imagery.

So here's where the issue lies. I'm going for a style in which each room is designed cinematically - framed like a static shot that you can walk through, accessing
doors or other transportation in order to reach other rooms. Seiklus did something similar to this, but its camera was also able to move along a single axis in most rooms,
with the exception of a few "free camera" areas in the overworld. And Fez avoids this issue entirely, as the rooms have no borders other than water and open air, and the
rooms that do have borders have the stability of being designed for a single resolution: it's a console game, so the native resolution is globally the same.

With that said, here's something to look at: a resolution benchmark test. Please run it and take a screenshot of what you see with Print Screen. (It's force fullscreen for now.)
DON'T edit the image in any way: I'm running a test to see how well my test engine can correct itself to arbitrary resolutions. So keep the black borders, as there most likely will be some.
Upload it to a site like Filesmelt or Imgur, and then post the link to this thread - the more samples I have, the more reliable I know the engine is.

Introduction

Hey all. It's my first time posting here, but I've been coding with Game Maker on and off for a few years. I've recently played
both Minecraft and Terraria, and am interested in creating a sort of demake/rehashing of my own, using original code and gameplay,
as well as textures from the Painterly Pack (Minecraft). However, as I've begun to script the basics of blocks and lighting, a very
obvious problem has occurred to me: how to actually generate worlds of a formidable size, how to be able to iteratively load and save
these worlds in a fashion that doesn't make Game Maker go insane, and last but definitely not least, how to be able to write these
worlds to some sort of data array or image on the hard drive, as Game Maker doesn't store array data with its built-in save method.

As this is a gigantic topic and there are many points I want to hit on, I think it would be best to separate this up into different
sections for discussion: methods of generation and reading/utilizing the generated world data, sorting and saving that data into a
usable form, being able to load and discard the world data as needed while the player passes through the world, and being able to
completely and flawlessly save that data onto a rereadable file or image (from which the data could then be reloaded when the player
plays again.) I'll apologize in advance for how long this topic is, but this is a compilation of a few months of thought.

All the following methods are the solutions I've arrived at after all this time, but there are still massive gaps and serious flaws
which I hope the community at large will be able to piece together.



Generation SOLVED!

Like Terraria or Minecraft, all generation would be completely procedural and random. To clear up any confusion, this game is indeed
2D, so I'll be referencing Terraria more than Minecraft in this case. Terraria's style of generation is pretty easy to replicate (as
gathered from a minimap) - you have a top layer of grass combined with a thick layer of dirt, underneath which dirt becomes more
sparse and chunky (and stone becoming the most prevalent material). Caves, tunnels, and miscellaneous veins also start at this depth,
with the general trend of direction being downwards in diagonals, with smaller caverns caused by intersections. So that's well and good.

Trying to keep things to a simple framework, I began to create a method similar to this, and was able to produce similar results with a
little trickery. I decided that the generation - for now - would be entirely based upon minimaps. That is, the engine would first produce
an image with the drawing functions, and then with a liberal use of draw_getpixel() (feel free to shriek in terror now), arrange the pixels
of the image into a grid of block type data (0 being air, 1 being stone, etcetera). The program behind this was rather simple. First, the
background colour was disabled, so that anything drawn would remain on screen indefinitely. A single pixel of "grass" would start at the
left of the screen and pixel its way over to the right, moving up and down to simulate a surface terrain. Every step, the "grass" instance
would create a "dirt" underneath it. "dirt" would travel down for 20-25 blocks or so, and then create "stone", which would draw a line
from the bottom of "dirt" to the bottom of the screen. After all this was completed, tunnels and various dirt veins were added in on top
of the stone layer, creating a very simple - but navigable - Terraria-like underground.

Just look at that realism: 1 pixel = 1 in-game block

So now we have a minimap, but now we also have our first issues. For one, this minimap we've generated is only 512x512, which is far
smaller than the smallest Terraria world (4200x1200). While people may have a bit of fun spelunking in a world like this, they may
be a bit crestfallen at how quickly they reach the void at the bottom. Definitely not good.

Alright, then, why don't we just make this minimap bigger? Here's the overarching issue: You can't. You can't make a minimap larger than
the person's screen resolution, because this is all being drawn and then saved from their screen. You can't use views to "chunk" the data,
either, because views redraw the background colour - which would draw right over all the pixels you see. (Remember that the image you
see is the result of the TRACES of objects - NOT the objects themselves!) This is the greatest issue with the minimap. Imagine you had
a 1920x1200 monitor, but your friend only had a 1024x768 - he would be a little disheartened when he found out he could only generate
worlds a fourth the size of yours. And who would want a world size based on your screen resolution anyway? 1440 and 900 aren't exactly
the cleanest numbers for intervals of 16.



Reading the Generation SOLVED!


Ignoring all the obvious flaws in the minimap system, let's pretend it's created a satisfactory world for us and now we want to play around
in it. Now that we have some solid data, we can chunk it - say hello to everybody's favourite memory hog, draw_getpixel()! Because the only
residue of our data is the colours on our screen, we have to load data into a temporary method of storing it - in this case arrays - by converting
the colours that draw_getpixel() sees into usable data values. And thus we create our chunks - each chunk looks through its designated area of
X and Y with a hefty for-loop-inside-a-for-loop, converting colour into integers and storing it in its own personal array. Even though draw_getpixel()
is known as the devil of all CPU hogs, my mid-to-high end computer was able to chunk the 512x512 minimap in just 27 seconds. That's not bad,
but imagine something larger. If we consider our minimap as one block of 512x512, 32 of them could fit into a standard world size of 4096x2048.
And having to wait nearly 15 minutes for one's map to chunk is not exactly the most pleasant of experiences.



Summary SOLVED!


So there we have the first set of issues. How can we effectively create and store the data from a 4096x2048 world? That's nearly 8.5 million blocks of
data to be saved somehow, which Game Maker is definitely not capable of storing while the game is running. Could a minimap system be used, or are the
flaws so great that it would be impossible to base a working engine off this? Could a minimap be possible if the seeds for the map were first created
by the engine, and then the separate, smaller chunks were rendered by themselves based on that seed data? Does the necessary use of draw_getpixel()
cripple the whole idea in its entirety when the engine runs on a larger scale?

A beginning Terraria player explores a surface cave

Loading, Chunking, Saving, and Reloading SOLVED!


Now we come to our final - and arguably biggest - problem: the problem of storing the data in such a way that Game Maker can easily open it, edit it,
and close it - without it being a resource already in Game Maker. The two ways I see to do this are either by little images of the chunks (again, going
back to the minimap idea) or a hefty use of .ini files. However, I think that the images would be the favorable method here, as an .ini file containing
the amount of data a standard chunk could contain would both be very lengthy and very ridiculous. So if we use images, how could we import and export?
To get the data out of a minimap, we could simply take a screenshot of that part of the screen and save it to a .png, so that none of the colours are
distorted by compression (therefore corrupting the level data.) The chunk's minimap, when loaded, could even be displayed in the corner of the screen,
both for the game to edit and save the image and for the player as a guide. The only downside of using externally saved images is that they are easily
edited. While some users might restrain themselves to only using it for building structures, I'm sure others couldn't resist from turning an entire chunk
into a solid block of diamond ore - ruining the fun of the game.

So if that covers the external data handling, what about the internal? Of course, if we have chunks, we need to load them and unload them as the player
passes through them - and obviously, without the player noticing the next blocks popping in at the edge of the screen. So how do we get the chunks to
spawn their blocks and/or destroy them without lag spikes? Should the instances be deleted every time the player strays away from that chunk, or should
the instances stay spawned, but deactivate when they are out of range? Would a combination of chunking and deactivation cause issues when loading blocks?

A tech demo of what I've created so far - showing sand, dirt, mud, stone, and coloured lighting
Shapes were cut out of each blocked material to show each material's unique edge style

TL;DR Version

How can we generate a large-scale map efficiently? Minimaps? Chunks? World seeds? SOLVED!
How can that generated map be processed so that it can be used by the engine to create the playable world? SOLVED!
How can the processed data be stored in such a way that it can be loaded, used, and resaved on the fly? SOLVED!
How could chunks work dynamically in a game so that they are loaded and destroyed as needed? SOLVED!
How much of the world data would be stored externally, and in what fashion? SOLVED!
Is the scale of a 4096x2048 world so large that it is impossible for Game Maker to realistically handle? SOLVED!



This engine is pretty far along now, with the help of a few miracle-workers (dark_master4 in particular). I'm now fleshing it out to be more like an
actual game engine - having it render all the blocks seamlessly, how to determine where walls should be and where they shouldn't be, compiling textures
for the blocks and items, creating an inventory system, creating seasons and time of day, etcetera etcetera etcetera etcetera etcetera.