7 replies to this topic

[Dreamsequence]

Well, got the script to work! Levels are generating! But now I'm having issues on Android, from what I can tell, because the runner there puts the game files in a .zip compressed file and it won't read.

This one is pretty open-ended since I'll be building the whole game to work around the system I create here, but I want to have levels where each 32x32 tile is generated from the color of one pixel in the corresponding position in an image file, likely a .bmp.

The game I am working on is a auto-scrolling 2D space shooter. The trick I'm going for here is that the whole game takes place in one room in GM with a static view, with objects and backgrounds all moving at a constant speed toward the left of the screen. As you progress through the level, it loads scenery and objects just offscreen to the right, and once something passes off the screen on the left it's deleted.
Because of this, I need a good visual way to make levels. Hence the image-based levels. Doing this would allow me to easily adjust level length, contents and more in whatever image program I choose to use, and store that data in fairly small file sizes. I can specify what each color means, and for each different level type I would have a script that reads every pixel and generates objects based on their color.

I think the best way to do this would be to have a script read each pixel horizontally like you would read text: left to right, top to bottom. That script would generate a text file as it goes, placing letters and symbols to correspond to the color.

That's as far as I get, because I couldn't find a function in GM to check for the color of an individual pixel. Is there any way to do this, even if it requires drawing the bitmap on the screen and reading from that? I found a couple threads using the search function, but they were both half a decade old, and they weren't much help.

One last thing, I'm building this game for iOS and Android, which means using Game Maker Studio, so .DLLs won't be any use here.

Edited by Dreamsequence, 24 May 2012 - 05:16 AM.

[kelson]

this code should do what you want it to do but it will be vary slow because the draw_getpixel function is slow.

for (w=1; !w>sprite_width; w+=1;)
{
for (h=1; !h>sprite_height; h+=1;)
{
color=draw_getpixel(x+w,y+h)

switch color
{
case blue:
{
}
case red:
{
}
case green:
{
}
}
}
}

[Dreamsequence]

this code should do what you want it to do but it will be vary slow because the draw_getpixel function is slow.

for (w=1; !w>sprite_width; w+=1;)
{
for (h=1; !h>sprite_height; h+=1;)
{
color=draw_getpixel(x+w,y+h)

switch color
{
case blue:
{
}
case red:
{
}
case green:
{
}
}
}
}

I'm not sure what the last part is about, but thanks for pointing out that function! I have no clue why my searches in the help file never brought it up, but I just checked and it should work fine.

Well, as long as I can cover up the pixels so the player can't see them. That might be an issue, but only if this function is VERY slow. As long as GM can handle doing it a few times per step, I can draw the map on the loading screen at the start of the loading process, grab the colors from a row or column or two, and draw the loading screen graphics over it before it draws the screen. Ideally that means the player wouldn't get to see the whole level's map before the level started. Once the data is transferred from colors on the bitmap to text in a file, using that to generate the level should be much easier.

[icuurd12b42]

do it directly from the file or here, I fill a ds_grid from a bmp file

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

further down is a link to another topic where the code was changed to read the bmp is sections, like for load on demand...

[Dreamsequence]

do it directly from the file or here, I fill a ds_grid from a bmp file

http://gmc.yoyogames.com/index.php?showtopic=488086

further down is a link to another topic where the code was changed to read the bmp is sections, like for load on demand...

Thanks for the help!
And sorry to necropost, but I wanted to update on this...
I have gotten this script running, with a few alterations (mainly just changed it so it creates the ds_grid when it loads rather than having it created beforehand. Shouldn't be an issue since this script only happens when loading a new level) on Windows runner but it's giving me fits on Android. I think I know what's going wrong, though.
The issue seems to be that for the Android runner, it places the game and data in a .zip file. I put my level .bmp in the "included files" for the game and it does indeed open the file on Android just fine, but I fear the compression is making it impossible to read the file properly.

It seems like my best bet is to have the level files copy over outside the game's directory, but I'm not sure how to accomplish that. Any ideas?

[icuurd12b42]

No, android file access is unknown territory. I'm surprised though if you say you can open the file, it should be in it's original bmp format...

[Dreamsequence]

No, android file access is unknown territory. I'm surprised though if you say you can open the file, it should be in it's original bmp format...

Hm... I think this is going to take some looking into then...

I wish I knew how Android's directories worked. There doesn't seem to be the usual expected C:\\"" like with PCs in there. In fact, the directories appear to use only / and all the searching I've done with Google hasn't shown there to be any sort of root directory.. just /mnt/sdcard/...

I'm trying my damnedest to get the phone to recognize the image file exists, but I'm kind of going at it blind here. The only time I didn't get the error "File does not exist" (error message is from your script rather than GM) was when I used working_directory + "leveldebug1.bmp" and I get a GM error message saying "Error reading byte." followed by one from the script, "File is not a .bmp"... So, I know it found the file, at least. Craziest thing is, it seems when I tried plugging working_directory as draw_text to see for myself what it would bring up, all it says is "assets"... which seems to suggest the root directory of what GM:S is able to access is ONLY files within that .zip. If I could simply find a way to have this thing find the file outside of a compressed .zip I could know if it's the platform that's the issue or the compression, as I believed.

Worst case scenario, I think, I have to take out the .bmp reader from my game and create a separate application I use to decode .bmps into text files, then just have my game load the text files directly into the ds_grid. It would mean I couldn't make a level editor, though that was a shaky goal to begin with.

Maybe I could open a thread on the Android section of the Studio forum and see if any mods have an idea what's going on here.

Edited by Dreamsequence, 24 May 2012 - 08:15 AM.

[icuurd12b42]

I suggest you ask the the android section yes.