Next topic

[FroggestSpirit]

I'd like to make a gameboy emulator in Enigma, and to do so, i'd have to be processing graphics each frame. Normally the graphics are part of the memory, and get mapped to the screen as such. I'd basically like to take an array that is 1 byte, and a length of 64, to make an 8x8 tile that can be mapped anywhere on the screen. Even if it might not run at full speed, it'd still be a start, and idk if 3D would make this easier by making it a texture as opposed to a tile. Anyone know how I'd go about this?

[TheExDeus]

If you know how the data looks, then why cannot you do it via tile_add or even draw_sprite_part? I didn't quite understand what is indie that 1byte. And why 1 byte has length of 64.

[FroggestSpirit]

Basically, a tile for gameboy is 8x8 pixels. I guess the array for this could be any size in reality, and for gameboy, it's actually 2 bits per pixel, and the palette data is elsewhere. I don't know how fast 3D can be done, but I could manually draw each frame with either pixels to the screen, or colored verticie triangles (they would overlap in a way to look like squares). more or less, itd be an array, and based on the value, the pixel in that tile would change. Could enigma comfortably draw either 25,000 pixels to the screen, or 25,000 triangles per frame?

[TheExDeus]

But how does the data look? Because if they are "tiles", then can't you just load them as tiles? Save them as images and load them in ENIGMA. Then draw via regular drawing functions.

The speed of course purely depends on hardware. On my 660ti I can draw 30k sprites with 250FPS. And it of course can handle 25k triangles. If you use a model it can handle hundreds of thousands. Speed depends more on what you want to do and how you do it. There are usually many ways to optimize something.

[FroggestSpirit]

the array would basically be like:
pixel[0,0]=1;
pixel[1,0]=0;
pixel[2,0]=3;
...
pixel[7,2]=2;
and so on

the numbers would represent the colors that are defined in the palette. I could have the array store them as rgb values if it works better, but the graphics need to be generated during runtime, so they can't really be saved and loaded.

[TheExDeus]

You can generate them at runtime too. Like use surfaces. Draw the tile on it and create a sprite from it. It would work because the tiles are not animated. Another way would be to make sprites consisting of those indexes (so it's a sprite with pixel values 1,0,3,2 etc.) and then color them with palette using a shader in runtime.

[FroggestSpirit]

right now, i'm using this:
for(int i=0; i<144; i++){
   for(int j=0; j<160; j++){
      draw_set_color(make_color_rgb(i+80,j,128));
      draw_point(i,j);
   }
}
I got this running at about 60fps, which is ideal, however, when the actual emulation code is in place, and it reads colors from an array instead, it might slow down. Is there a better way to do this?

[TheExDeus]

I already told you - use a surface so you would only have to do it once. If you only have to draw 144*160 (which I guess is gameboy resolution) then it's possible even that code will suffice. Try coding the emulator and then see if you get framerate issues. If this runs at 60fps (try set_synchronization(false) and room speed 9999 to see how much you can really get) then there is no reason to do optimizations now.