nesdev.com
https://forums.nesdev.com/

Graphics editor for NES
https://forums.nesdev.com/viewtopic.php?f=22&t=9119
Page 3 of 3

Author:  tepples [ Thu Sep 13, 2012 12:29 pm ]
Post subject:  Re: Graphics editor for NES

I've released version 0.04. Get it
Changes:
  • Left+B+Select at the title screen erases the saved data in case garbage was present.
  • Tile editor: Pen color indicator (at lower right) and tile edge marks (on the border) are drawn in the same color as the status bar text, fixing contrast with light backgrounds (requested by Kasumi).
  • Map editor: Press Start for the map tools menu.
  • Map tools: Zoom in on the map and edit tiles in the order they appear in the map.
  • Map tools: View with constant tiles to see attribute assignments (requested by rane).
  • Map tools: Change the screen tint (requested by Kasumi).
  • savtool: Complete overhaul of image converter.
  • savtool: Extract a palette from a .sav as a 32-digit hex code.
  • savtool: Convert a color PNG with a specified palette (based on a request by tokumaru).
  • savtool: Remap a PNG to use a specific tile sheet.
  • savtool: Combine .nam and .chr into .sav or vice versa.
  • sample_savs: Cleaned up pm a bit.
  • sample_savs: RPG_village has better tree highlights and some figures.

And again, I'm taking suggestions for what to add in the next version:
  1. Use swap operations instead of copy operations to preserve unused tiles when moving used tiles to the top
  2. Copy and paste rectangular areas of map
  3. Something that you're about to describe after trying the new features in 0.04

I really want to get it to the point where I can include more than the four sample_savs that I currently include.

Author:  tepples [ Thu Sep 20, 2012 1:00 pm ]
Post subject:  Re: Graphics editor for NES

Has anyone had a chance to try the new savtool or in-map tile editing?

Author:  Kasumi [ Thu Sep 20, 2012 4:00 pm ]
Post subject:  Re: Graphics editor for NES

I haven't ever tried any of the included python scripts, because messing with python has always been a hassle for me. I have tried the in map tile editing and it's very, very cool.

Author:  tepples [ Thu Sep 20, 2012 6:52 pm ]
Post subject:  Re: Graphics editor for NES

What hassles have you run into when getting Python to work? Perhaps I could walk you through installing Python. Or what alternative to Python should I have been using?

Author:  tokumaru [ Thu Sep 20, 2012 8:38 pm ]
Post subject:  Re: Graphics editor for NES

I managed to run Python programs with a portable version of Python, that way I don't need to modify my system in any way.

Author:  tepples [ Fri Sep 28, 2012 2:34 pm ]
Post subject:  Re: Graphics editor for NES

Is there anything else that you especially want to see done in 0.05 other than copy and paste?

Author:  zzo38 [ Fri Sep 28, 2012 10:18 pm ]
Post subject:  Re: Graphics editor for NES

Other ideas (you might not use):
  • Allow the use of keyboard and mouse (optionally; standard controllers would still work too).
  • Tapedump save mode.
  • Turbo File save/load.
  • Data recorder save/load.

Author:  tepples [ Sat Sep 29, 2012 6:03 pm ]
Post subject:  Re: Graphics editor for NES

And I've released 0.05. Get it
  • Map editor: Removed duplicate binary-to-decimal converter.
  • Map editor: Made some UI code reusable by other map tools.
  • Map tools: Added copy and paste (requested by Kasumi).
  • Tile editor: Moved everything up 8 pixels to make room for another line of text in the status bar.
  • Tile editor: Displays count of unused tiles.
  • Tile editor: When zoomed in on a map with unused tiles, Start toggles allocation of a fresh unused tile when drawing onto a tile used more than once.

I can see how a Super NES Mouse in port 2 might be used: left button = A, right button = B, and movement generates up, down, left, or right actions for every eight mickeys. But I don't see how a keyboard would help. Nor can I test with a data recorder.

EDIT: Also attached

Attachments:
editor-0.05.zip [81.62 KiB]
Downloaded 21 times

Author:  zzo38 [ Sat Sep 29, 2012 6:19 pm ]
Post subject:  Re: Graphics editor for NES

tepples wrote:
But I don't see how a keyboard would help.
I think a keyboard would help two things:
  • Shortcut of commands (so each command can be mapped to a separate key, instead of using menus).
  • Direct text entry onto nametables, you can type in and it make the text (or other tiles, if mapped this way).
But I don't really care much if you implement this or not (since I do not use this program); it is just suggestion.

Author:  Kasumi [ Sat Sep 29, 2012 10:38 pm ]
Post subject:  Re: Graphics editor for NES

Answering an old post: I'm not sure what I ended up trying with python before deciding the ends don't justify the means. But in this case, I must install python to try some scripts for this one program. Non portable is 15 meg, then install. One of the really cool things about NESdev is downloading for less than a second, and getting a totally cool program.
tepples wrote:
Or what alternative to Python should I have been using?

I like command line apps, but I realize that's certainly not worth the trouble for you if you want to be cross platform. (Indeed, another really cool thing about NESdev is it's pretty cross platform.) Lack of python isn't even something I'd mention if it hadn't been asked about, because I realize how stubborn I am about this sort of thing. I'll probably just write a PyxelEdit to editor program when I need some conversions.

Re: Tint bits. Any chance they could make their way to the palette editor? This way one could see their effect on the entire palette without closing it and reopening it to see every change.

Re: Copy/Paste. Because the block disappears as you're moving it quickly, sprites around it would be neat. Also, because if I copy a bunch of sky tiles to "blank" an area, when I'm moving around a map that's mostly sky I can't see where I am at all until I end up overlapping something.

Author:  JRoatch [ Sun Aug 03, 2014 2:54 pm ]
Post subject:  Re: Graphics editor for NES

If flash is at $6000-$7FFF, then where is the memory for holding the working copy of a document that exceeds 1280 bytes?

The A53 mapper has 32KiB bytes (4 banks) of CHR RAM, it may be a bit slow having to do round trip copies from PPU to CPU and back again, but there's the space to store stuff at.

Author:  tepples [ Thu Apr 21, 2016 8:10 am ]
Post subject:  Re: Graphics editor for NES

Tracking bug reports and feature requests from this topic:

  • savtool: Port to Python 3 Done
  • savtool: Accept true-color PNG files
  • savtool: Make sure the error message for too many tiles has the amount of tiles substituted in

The A53 mapper has 32K only if 32K is installed. That was intended for CNROM games, but every CNROM game included in a multicart so far has been mapper hacked to UNROM (along with fixes of stack overflows), so I haven't needed to use it quite yet.

I don't think I'll be able to share enough code between the present version, which has work RAM at $6000-$7FFF, and a version that uses bankswitched CHR RAM as work RAM to make them build from the same tree. If I do make a version that uses bankswitched CHR RAM as work RAM, would you prefer that the screen be turned off during operations using a lot of random access to work RAM, causing flicker? Or would you prefer that such operations be made dog-slow, as in Videomation?

Author:  JRoatch [ Thu Apr 21, 2016 9:38 am ]
Post subject:  Re: Graphics editor for NES

tepples wrote:
If I do make a version that uses bankswitched CHR RAM as work RAM, would you prefer that the screen be turned off during operations using a lot of random access to work RAM, causing flicker? Or would you prefer that such operations be made dog-slow, as in Videomation?

Copypaste commits and tile sorting would be fine with a blanked screen, and I would just omit the live preview of copypasting. Instead maybe try having 2 displayed bounding boxes, one for source and the other for destination, kind of like in the days before window compositing when a outlined box was showed when moving windows.

Moving in the zoomed tile preview is going to be tricky, as I think it should not blink. It might just be acceptable to leave it 3 times as slow (2 frames to load the tiles for each row, and 1 frame to draw them), but if there's enough RAM for a 6x5 tile window (480 bytes) then maybe the tile fetching part can happen in idle frames while the cursor is moving around.

Page 3 of 3 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/