[ShadowBlitz16]

hey I'm trying to make a zelda game in gamemaker studio.
I am in the middle of setting up the tileset functionality and I was wondering how these games loaded sprites for link, items, npcs, and the overworld.
I have recently been playing the old LA on my gameboy and saw that you can screen warp by pressing select before the camera transitions to the next screen.
I tried it out and realised that doing this makes the game skip loading the tilesheet for enemies and overworld tiles.

so I was thinking does each screen have a different tileset it loads for overworld and npc tiles?
would it help with performance?
if so how would I program this functionality in gamemaker?

I realize most computers don't need this sort of optimization now days,
but gamemaker isn't the most optimized game engine and keeping this could add to the nostalgia of my game.

[VicVergil]

Well first there's the VRAM (video memory).
Each graphic is composed from smaller square-shaped puzzle pieces called tiles.
There's the bigger graphics, the backgrounds, and the smaller ones moving around the screen, the sprites.

Link / HUD tile data are loaded at all times.
Environment tiles, and NPC tiles in the case of towns, are loaded once* when entering a new area. (*: stuff like animated water may differ)
Enemy tiles and weapon tiles aren't all loaded at once, just the necessary ones at that instant.

Fonts, menu tiles, and cutscene graphics are not loaded at all unless absolutely necessary.
The whole font is loaded in the case of LA/FTFTBT, but in the case of OOA/OOT only the characters needed for the currently displayed sentence are.

If they didn't do this, the graphics simply wouldn't fit in the limited VRAM they had (which has doubled from the GB to the GBC).
So they only load what's necessary.
Even better, sometimes games have various lists of enemies and depending on these lists they determine what enemies to load. Each zone is tied to a specific "enemy set".

[tryphon]

I'm not a gamemaker specialist (just toyed with it some hours yesterday), but I highly doubt the lack of performances of GM lies here (actual machine "VRAM" is orders of magnitudes higher).

If by performance you mean game speed, then your problem more likely go with your coding. You use unefficient algorithm, either in your code, or, more likely, in GameMaker generated code. For example, collisions testing are usually slow in Gamemaker, because they are done pixel wise, which the old console didn't.

Two useful links : http://www.yoyogames.com/blog/2 and http://www.yoyogames.com/blog/32

[henke37]

Also, collision testing can be vastly optimized if you can limit the number of candidate colliders using some sort of spatial partitioning of your data structure.

[tryphon]

You mean things like quadtrees (for a 2D game) ? Do you know if some old-school games 8/16 bits era) used this kind of strategies ?

[henke37]

Yes, quad trees is one way of doing spatial partitioning. Not the only one tho. If you have a grid then you can partion using that directly. O(ln x) is still larger than O(1).

[ShadowBlitz16]

thankyou guys for all your input

however I am currently trying to program tiles in

I currently am creating a  1d array which could store a value in it
the tiles will be 8x8 width a array length of 0-255

however I don't know exactly how they worked and how to reimplement them in gamemaker

what values would the array hold?
how would I draw them on screen?

it would be nice if there was someone with knowledge of how the gameboy worked I could chat with on a irc or skype

Edit: another question I came up with is did the nes or gameboy support layered tiles? if so how did they do it?
did they just draw the payers one at a time in a for loop?

[njosro]

Quick tip if your aiming for optimizing: gamemaker's built-in ds_list is faster to use than 1D arrays you create yourself.

In game maker you should store the tiles with the built-in background resource which can be used as a tileset. The option is very easy and very optimized. Each "screen" you go to in the game can reference lookup values from a big ds_grid that you create (basically a speedy and powerful 2d array) which will contain the tiles that are to be drawn on the screen, cell by cell. I highly suggest having separate game maker background resources: one for small 8x8 tiles and another (or multiple others) for 16x16 normal sized tiles.

In the loop that initializes the tiles it can look something like this:

for (yy=0;yy<height;yy+=1) {
    for (xx=0;xx<width;xx+=1) {
        tile_add(background,<lookup from ds_grid>,<lookup from ds_grid>,16,16,xx,yy,<depth you want>)
    }
}

and when you're leaving the screen just do tile_layer_delete(<depth you wanted>) to free the video memory.

Depth just depends on the order of things drawn. The later something is drawn, the more "in front" it will be. Yes in a loop. Game maker will do a similar thing as the nes/game boy but with its own built-in depth system which is much easier to use.

[ShadowBlitz16]

Quick tip if your aiming for optimizing: gamemaker's built-in ds_list is faster to use than 1D arrays you create yourself.

In game maker you should store the tiles with the built-in background resource which can be used as a tileset. The option is very easy and very optimized. Each "screen" you go to in the game can reference lookup values from a big ds_grid that you create (basically a speedy and powerful 2d array) which will contain the tiles that are to be drawn on the screen, cell by cell. I highly suggest having separate game maker background resources: one for small 8x8 tiles and another (or multiple others) for 16x16 normal sized tiles.

In the loop that initializes the tiles it can look something like this:

for (yy=0;yy<height;yy+=1) {
    for (xx=0;xx<width;xx+=1) {
        tile_add(background,<lookup from ds_grid>,<lookup from ds_grid>,16,16,xx,yy,<depth you want>)
    }
}

and when you're leaving the screen just do tile_layer_delete(<depth you wanted>) to free the video memory.

Depth just depends on the order of things drawn. The later something is drawn, the more "in front" it will be. Yes in a loop. Game maker will do a similar thing as the nes/game boy but with its own built-in depth system which is much easier to use.

I was trying to avoid using data structs
where would I create the ds_list and the two ds_grids?
in the initialization of the tiles?

also does it need to be a grid? I was trying to keep the feeling of the 1 dimensional lookup style of the nes

[FCandChill]

Comment removed because reasons...

[tryphon]

That's a fallacious well-known argument : well-written Python can be faster than bad-written C.

The thing is it's much easier to write good Python than good C.

That said, I'm a huge Python fan (C too, tbh) and Python is fast enough to handle a Zelda game. You could even use pygame for it (just avoid 32 bits surfaces, stay with 24 bits + a transparent color). And if pygame isn't enough, you can always try PyOpenGL.

But even with an easy language like Python, it'll be much more work than with GameMaker (but much more rewarding, and as already said, you'll have complete control).

[ShadowBlitz16]

You could always code your own game in C++ or some other high level language. It gives you more control over your game ... but also requires you to be a very good coder. The MOTHER4 fan project is being made with python which can run faster than C programs despite what other people say.

I was trying to learn python and pygame however I need constant help since I have no idea where to start
I was trying to make a tile and palette system however I couldn't figure it out

Edit: also does the nes or gameboy support tiles or graphics that are not 8x8 or 16x16 and dis it possible to offset tiles like hud elements by pixels?

[tryphon]

I was trying to learn python and pygame however I need constant help since I have no idea where to start
I was trying to make a tile and palette system however I couldn't figure it out

You don't need to make a palette system if you program it in Python. Try to find a project on pygame.org that looks like what you want to achieve, understand the source and modify it. I'd say it's the easiest way.

[ShadowBlitz16]

You don't need to make a palette system if you program it in Python. Try to find a project on pygame.org that looks like what you want to achieve, understand the source and modify it. I'd say it's the easiest way.

I don't really feel like recoloring all my sprites and coding all the colors in for different states
I feel a palette system would help alot with reducing things like this