NESpix - Tileset/Pixel Art Editor

NESpix - Tileset/Pixel Art Editor
by on (#128903)
Image Image

Exactly what the title says! Allows you to create 16x16-pixel tiles and arrange them for a quick preview.
You can easily extract saved graphics from your emulator's/flash cart's SRAM files using YY-CHR.

Download
NESpix 1.0.1
NESpix 1.0.1 source code
Re: NESpix - Tileset/Pixel Art Editor
by on (#128906)
Cool, the UI is well designed. I got some graphics corruption in the title screen after creating a simple picture.
Re: NESpix - Tileset/Pixel Art Editor
by on (#128924)
Thanks, I fixed it!
Re: NESpix - Tileset/Pixel Art Editor
by on (#128926)
This is truly beautiful! Thank you.
Re: NESpix - Tileset/Pixel Art Editor
by on (#128929)
thefox wrote:
Cool, the UI is well designed. I got some graphics corruption in the title screen after creating a simple picture.


THx you i know im well designed! :)

Miau, this sux, dont ever touch NES again or i will quillzzz you...
Re: NESpix - Tileset/Pixel Art Editor
by on (#128930)
ui wrote:
Miau, this sux, dont ever touch NES again or i will quillzzz you...

Aww, cyberbully, you! <3
Now make a nice tileset and post a screenshot.
Re: NESpix - Tileset/Pixel Art Editor
by on (#128931)
ui wrote:
thefox wrote:
Cool, the UI is well designed. I got some graphics corruption in the title screen after creating a simple picture.

THx you i know im well designed! :)

I saw this one coming. :)
Re: NESpix - Tileset/Pixel Art Editor
by on (#128943)
This looks great miau, nice work!

Additionally I think I may have finally found the motivation I needed to add WRAM dump/load support to my kazzo firmware.
Re: NESpix - Tileset/Pixel Art Editor
by on (#128944)
Is there something I should have improved about my own project?
Re: NESpix - Tileset/Pixel Art Editor
by on (#128954)
Generally I consider the your(tepples) Graphics editor to be the full screen power user tool with conversion scripts and tile reduction features, and has with plenty of advantages over NESpix, but here's where NESpix is better:
  • Editing pixels and map at metatile(16px^2) level
  • Everything in one screen
  • Palette editing doesn't have a range restriction (I understand why, but sometimes I want $2d and $3d)
  • UI elements that's easier on the eyes
  • Nice title screen

You might be able to easily add a switch for a 16*16 pixel mode, but getting multiple things on the same screen might be hard to do conceptually, technically, and without reducing the current set of features.
Re: NESpix - Tileset/Pixel Art Editor
by on (#128983)
I'd echo what 43110 said about the two tools. Tepples' editor is powerful and feature packed, and has a good manual to explain how to use it all. But frankly many of those features I don't personally want to always run with a NES tool. I'm sure if I devoted an hour or two to play around with Tepples' editor I would get the hang of it and have more appreciation for the features. But as it is right now it's hard to gain the motivation to learn it and test it out. That's where NESpix shines, the beauty and simplicity of the screen shots yanked at my nesdev heartstrings and I couldn't help but spend 5min of my lunch hour to go try it out.

The annoyance I find in drawing on the NES is mainly with pattern table creation. I don't care how accurate coloring/filters claim to be, you can't come close to the NES on a CRT. While I'm drawing pixels on a zoomed scale, I want to immediately see those pixels rendered on the normal scale. Even better, I want to see the tile I'm editing next to multiple other tiles at the same time, and being able to edit 4 tiles at a time is a beauty. I currently use NESST for all my NES drawing needs. The biggest annoyance I have with it is during PT editing, but it's great for NT/AT generation after the PT's have been created.

To top it off the user friendliness is spectacular. I think I could fairly easily teach my 6yr old daughter who's a wiz with the mario paint tile editor, to draw on the NES using this tool. All other NES drawing tools I'm aware of would be too complex.

So while NESpix is limited, it does the one thing I want to do on the NES with near perfection.

I'm thinking it would be awesome to be able to include NESpix and Tepples' editor on the next action53 release. The best way to overcome the lack of WRAM on the action53 cart would be to modify our mapper to support mapping the 'user flash' we talked about for the serial bootloader cable to the $6000-7FFF slot. The pattern table data could then be dumped with the serial bootloader and/or a cartridge dumper which supports our multi-mapper. Curious what you guys think about it's inclusion with Action53 volume2.

miau, would you be willing to share your source code? I'm sure I could modify the save routine to support flash writes instead of regular sram writes that are being done now.
Re: NESpix - Tileset/Pixel Art Editor
by on (#128985)
infiniteneslives wrote:
Curious what you guys think about it's inclusion with Action53 volume2.

I think it's a good idea. Including stuff like this and the serial bootloader could coax people into getting their feet wet with NES development. Which, with your suggestion about using Flash, immediately brings forth another idea: the graphics editor(s) could be used to edit graphics in some small game that is included in the cartridge.
Re: NESpix - Tileset/Pixel Art Editor
by on (#128990)
At least for my editor, SRAM would be needed because that's where the working copy of the picture is stored and modified. And the problem with just saving and restoring $6000-$7FFF is one of allocating slots to each game. It would be better as a separate project with adequate development and testing time.
Re: NESpix - Tileset/Pixel Art Editor
by on (#129003)
infiniteneslives wrote:
miau, would you be willing to share your source code? I'm sure I could modify the save routine to support flash writes instead of regular sram writes that are being done now.

I added a source code link to the first post. Be aware it needs lazy65 to compile. Actually, the only reason NESpix even came into existence is because I needed a small project to thoroughly test the tool.

You'll find saving in src/Editor/SaveSlots.z and loading in src/Title.z

thefox wrote:
the graphics editor(s) could be used to edit graphics in some small game that is included in the cartridge.

Great idea, that would be awesome to see!
Re: NESpix - Tileset/Pixel Art Editor
by on (#129023)
miau, I took a look at your source for any inspiration. I was wondering if you would be willing to explain your NMI routine's cmd priority/task queue system. What does it allow you to do? And/or, if you would be willing to explain the source with a bit more detail I would appreciate it. I have something I think is similar and would like to compare.
Re: NESpix - Tileset/Pixel Art Editor
by on (#129037)
Movax12 wrote:
miau, I took a look at your source for any inspiration. I was wondering if you would be willing to explain your NMI routine's cmd priority/task queue system. What does it allow you to do? And/or, if you would be willing to explain the source with a bit more detail I would appreciate it. I have something I think is similar and would like to compare.

Some parts of the vblank code are from when I originally started NES development so it's a bit awkward, but here is how it should work:

- have a stack with addresses of functions to jsr to during vblank ("vblank commands")
- push a command with Vblank.cmd.exec
- the stack pointer does not advance automatically, the same function gets called once everytime the ppu enters vblank until it calls Vblank.cmd.end
- Vblank.cmd.replace changes the address at the top of the stack, making the supplied address the next command to be executed and discarding the current one

...except that's not quite how it works?! There's a high priority version of Vblank.cmd.exec and I don't recall why it is even needed with the stack-based approach. At this point, I'd rather rewrite the whole thing properly than spend any more time looking at it, heh.
Also, I probably should have used a queue instead of a stack, that would have been more logical and intuitive. Then again, queues can be a bit fiddly to implement and a priority system could be costly cpu-wise.

In any case, here's a usage example for the current Vblank.cmd interface:
Code:
.proc letsDoSomethingOverMultipleVblanks ;can be called outside of vblank/NMI
    Vblank.cmd.exec firstVblank
    rts
firstVblank:
    ;do stuff
    Vblank.cmd.replace secondVblank
    rts
secondVblank:
    ;do other stuff
    Vblank.cmd.replace thirdVblank
    rts
thirdVblank:
    ;do other stuff
    jsr Vblank.cmd.end
    rts
.endproc

And another one:
Code:
.proc letsGonnaDoSomethingOverMultipleVblanksAgain ;can be called outside of vblank/NMI
    .bss
    counter: .res 1
    .code
    lda #32
    sta counter
    Vblank.cmd.exec vblank
    rts
vblank:
    ;do stuff once per vblank for 32 vblanks
    ;...like redrawing one row of the nametable per vblank
    dec counter
    bne @doNotEndYet
        jsr Vblank.cmd.end
    @doNotEndYet:
    rts
.endproc


How are you handling Vblank/NMI tasks?
If there's anything else you'd like to know, please point me to it.
Re: NESpix - Tileset/Pixel Art Editor
by on (#129044)
There are some similarities to how I do it, and you have given me some things to think about.
For me, I have a list of addresses to be accessed in NMI. To try to speed things up I store these addresses at $0100 and switch the stack pointer to point to these addresses when running these commands. Every RTS executes the next routine in the list (fast!). This makes it fairly quick to access anything that wants to run in vblank. The last address in the stack always must point to returnFromChain.

The parameter whichVectorList exists because I have three lists of routines to execute. (High priority PPU update routines, call always routines (even in missed frame), and routines that can be called at the end of NMI that don't need vblank time.)

Code:
privatefunc startChain, {whichVectorList a}
   
    ; save normal stack:
    tsx
    stx realStack
    ; transfer and save new temp stack:
    _ x := whichVectorList
    stx currentNMIstack
    txs
    rts ; load the CPU program counter with the first hooked vector.
endfunc

privatefunc returnFromChain
    ldx realStack
    txs
    return currentNMIstack
endfunc
Re: NESpix - Tileset/Pixel Art Editor
by on (#129108)
Well, that gives me things to think about.

Having multiple lists and using actual stack addresses is neat, I think I will adapt that for other projects.