How do I most efficiently control each pixel of my display?

0 favourites
  • 6 posts
From the Asset Store
Vintage steam pixels for your UI! 125 unique assets in a single pack!
  • So here's the thing... I've recently been learning 6502 Assembly for NES programming, which then led me to learning about how emulators work, which has NOW led me to wondering if its possible to make a bare bones NES emulator using C3... I can load a rom just fine. I can parse it and disassemble it just fine. I can read and interpret the CHR data just fine. However... There doesn't seem to be any way I can emulate the creation of a frame of graphics, 60 times a second.

    I've tried the DrawingCanvas, but its too slow... I've tried 256x240 stationary single pixel sprites pre-loaded with the NES palettes colors as frames... also too slow... I've also tried using the TileMap plugin (which is comparable in performance to the sprites) and the best FPS I can manage is ~30 fps, which is 50% of what I need to have a playable emulator...

    Is this simply an impossible task for C3? I know emulators tend to be more resource hoggy than they'd seem given all the work they need to do, but if C3 can natively draw entire screen's worth of graphics at 60 fps, at a much higher screen res... then why can't I?

    Also... if I can't even do randomized noise at 60 fps, then there's no way I can evaluate the NES's 3 graphics layers to determine which pixel to show (or to show the BG color instead)

    Any input would be greatly appreciated

    Thanks

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Oh, and I also tried the SetColor shader on the sprites (without changing their frames) and that was the slowest at about 10 fps (For some reason I thought the shader might be faster, but alas)

  • Best performance so far appears to be using 256x240 single pixel TiledBackground objects, with the palette as the image, using X and Y offset to change the displayed pixel, however that's ~35 fps on my PC and ~45 on my phone when using remote preview... still not viable I'm afraid :(

  • That is for sure an interesting project. I don't think drawing pixel by pixel on sprites is gonna work out.

    Have you looked into this example project?

    editor.construct.net

  • Modern graphics hardware cannot efficiently handle "set pixel" type operations. Sending data from the CPU to the GPU is a pretty slow, and normally things like textures are all pre-loaded in advance and re-used across frames so as much as possible remains on the GPU without needing to send much data (other than draw calls). IIRC even video playback is often handled on-GPU so the resulting pixel data is decompressed on the GPU rather than sent to the GPU.

    Probably the most efficient you can achieve is to fill an ImageData in JavaScript and display it in a Drawing Canvas with the loadImagePixelData() method. The example WackyToaster linked to is a good demo of that.

  • This is running at a solid 60 fps on my PC. Thanks so much for this!! I'll keep everyone posted as to how this project comes along!!

    This is actually a potential component of a larger project that I've already started that also happens to involve:

    - a graphics editor

    - a text editor

    - a sound editor using the third party WebMIDI plugin (which is excellent and would love to see bundled as a standard plugin someday)

    I won't say more yet, though this may have already given it away... Either way, I'll keep everyone posted!

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)