NESpix - Tileset/Pixel Art Editor

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

Cool, the UI is well designed. I got some graphics corruption in the title screen after creating a simple picture.

Thanks, I fixed it!

This is truly beautiful! Thank you.

THx you i know im well designed!

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.

I saw this one coming.

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.

Is there something I should have improved about my own project?

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.

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.

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.

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.

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


Great idea, that would be awesome to see!

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:

And another one:


How are you handling Vblank/NMI tasks?
If there's anything else you'd like to know, please point me to it.

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.)

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.