Recently I had need for a tool that would allow me to create a tileset and nametable from a BMP file, and edit some other things. I've found few solutions which weren't fully worked for me by various reasons (NSA, p8nes), so I quickly made this Windows tool for my needs. Maybe it could be useful for someone else, so I release it to the public.
It allows to import graphics from 16-color BMP file, edit and create nametables, attributes, palettes, and tile graphics. It has the features I've needed only. I may fix bugs and add some small features by request, but I don't have big plans on this tool.
The tool is released into Public Domain, completely with source code, so you can use it any way you want. The source is not much help, though, because it is in Borland Turbo C++ Express, which is no more available for free, and is not portable, but anyway.
Download
Cool! I'll be giving this a try.
Couple of things immediately:
+ A really handy feature which I've never seen in one of these editors before is the ability to 'paint' attributes/palettes on the nametable. Really nice
- I tried to load a .chr file that I'd made in YYCHR but your program wouldn't load it because it says a .chr file must be 4096 bytes. How come? The one created in YYCHR is only 2048 and looking at your tileset window you only have space for 256 tiles (same as YYCHR) so I'd have thought the resulting .chr file would be 2048, the same as YYCHR?
Edit to add: ah, it seems that the YYCHR files are actually 8192 bytes - I never realised that before. I guess it saves out a 4k CHR/4K SPR file? In that case, your tool is correct
I can add support for 8K CHRs in form of selectable 'pages', if you need it.
I tend to work on 4k files anyway (CHR and SPR separate), I just never realised that YYCHR creates an 8K file by default.
I loaded up the CHR file for my latest project and messed around editing the nametable. I really like it, especially the inclusion of RLE. That's a really nice touch. Going to have a play importing BMPs because that sounds cool.
One quick thing that would be nice is if you could make the CHR editor open if you double-click a tile in the tile set (of course, it should open with the tile you click
)
Great work Shiru. I'm going to have a look at the source too. I'd love to be able to port it to OSX (I'm using it via a VM at the moment, same as YYCHR so it's not a problem really)
As for new feature, if you have the time and inclination to do so;
+ more editing functions for the nametable such as copy/paste/cut would be really handy I think
+ more advanced editing would be the ability to insert/delete a row/column in the nametable (when I need to do this with YYCHR I end up just loading the nametable into a hex editor
)
Good work.
Couple of bugs / feature requests:
- when I imported a BMP the surfaces weren't re-painted until I pressed a button (Show grid)
- maybe change the grid so that it displays 16x16 (attrib areas) with solid lines and subdivides that to 8x8 with dotted lines (or equivalent)
I was going to say the same about the grid (16 x 16) but I'd also suggest drawing all the grid lines in dots. Your tool seems to suffer the same problem as YYCHR in that it uses one of the palette colours to draw the grid so depending on what you're putting on the nametable, the grid lines can be 'invisible'.
Actually, I select a constrast color to the $3f00 color for the grid. Seems this does not work well enough.
Ok, I'll add/fix the requested things soon.
It doesn't work well if you make a simple contrast from a colour's negative. You know that the negative of 50% grey is 50% grey, right?
As you can see, by default the color in the tool is exactly 50% grey, and you can see the grid.
Please note that my webhosting does not work by sundays by some reason, so the screenshot could be not available. The download should be available anyway, it is on separate FTP server.
Shiru: how easy is it to implement the ability to double-click a .CHR file and have NESST open with that file? Currently it doesn't work - NESST opens but with no file loaded.
I've made most of the requests except the >4K CHRs supports.
This includes double-click on a tile in the tileset to open CHR editor, *.chr association support, opening all the files of the same name (requested by me, very handy), copy-paste functions for the nametable, improved grid, and maybe something else.
Download link is the same.
Cool!
I'll check it out right now.
Great tool!
It will help a lot with static screens and automates duplicate tiles
+ Grid is much better
+ Love the nametable editing stuff
+ Association of .pal with .chr is really good, it doesn't seem to work if you double-click a .chr file from Windows though?
Could you also have it remember the last folder/path you accessed so that when you reopen the program you don't have to navigate from the folder where NESST resides?
Thanks Shiru
Changed double-click opening to load all the files (like Open) instead of just *.chr; added remembering of the current directory between the sessions.
Brilliant - many thanks Shiru
Works great Shiru, I didn't think about associating the nametable with the .chr file too so that was a nice surprise
If you're still interested in more ideas?
Some of the drawing modes in YYCHR are actually quite handy: the line tool and the rectangle tool especially. Also the ability to remap colours in YYCHR comes in really handy sometimes. Not that I think you necessarily need to make a copy of YYCHR but I think you've got the beginnings of a really great tool here.
My workflow for any platform involves GraphicsGale as the main graphics editor, I make all the graphics in it as 16 or 256 color bitmaps (it allows to reassign color numbers etc), and a converter, mostly command-line. Often I have just a set of BMP files in a project, and building script converts them into binaries or asm/h files. So this tool was supposed to be used as a converter mostly, however not automatic (because it is not so easy in case with NES).
I can add some more features if they are really needed (to exclude a tool from a toolchain, maybe). I'm not too familiar with the YYCHR, however, so I need better explaination of needed features. These line and rectangle drawing - they should work in the tileset window (2x fixed zoom) or in the CHR editor (if so, isn't it overkil to have such tools for 8x8 image)?
Ah I see.
I tend to just work in YYCHR because it's fast and easy so I guess I'm just giving you ideas that would make me use NESST instead
If you're still up for adding features though, the rectangle and line tools work in the tile editor. I find them handy - actually I use the rectangle tool almost all the time as you can do single pixels, lines or rectangles with it. You could probably forget about the line tool.
Oh and colour fill in the tile editor too
Rectangle only allow to draw straight lines, arbitrary lines aren't needed then?
Isn't it could be rather difficult to use these tools with 2x zoom only? You barely can target to the exact pixel with this zoom. If I'll add more zoom levels, I'll have to add scroll bars to the tile set, probably, and also if there will be ability to draw in the tileset and zoom like 16x, CHR editor window will be redundant.
For now, I can't clearly imagine how it could look and which changes are necessary.
I don't know how much time you want to spend on this Shiru or how much you'd be happy moving away from what it was originally but personally I would lose the CHR window and do the tile editing in the tileset itself (with zoom and scroll, as you say). Then it would be easier for you to draw graphics that are made of more than one tile etc.
I usually just copy-paste into YY-CHR, basically just using it as a character converter from the clipboard.
I don't want to spend too much time on it, it is just a little tool for rather specific tasks, but I can spend few days on it.
I'm afraid that zoom+scroll could be not enough. For example, with 16x zoom (as in CHR Editor window) you only be able to see 16x16 area, and with 8x (smaller zooms aren't comfortable to edit the graphics, I think) only 32x32. Is it enough? You also will need to press a key or a button to switch between the tile select and tile drawing modes, or use some shift key to select a tile (increases chances of accidental graphics change).
Shiru wrote:
I don't want to spend too much time on it, it is just a little tool for rather specific tasks, but I can spend few days on it.
I'm afraid that zoom+scroll could be not enough. For example, with 16x zoom (as in CHR Editor window) you only be able to see 16x16 area, and with 8x (smaller zooms aren't comfortable to edit the graphics, I think) only 32x32. Is it enough? You also will need to press a key or a button to switch between the tile select and tile drawing modes, or use some shift key to select a tile (increases chances of accidental graphics change).
Yes, that's what YYCHR does. Depending on your zoom level you can only draw on 1 x 1, 2 x 2, 4 x 4, 8 x 8 etc. But then YYCHR does have a tileset (that you can always see 256 tiles) and an tile editing box - YYCHR has it's nametable editor in a different window but I prefer your approach of having the nametable in the main window.
Let me have a think about it a bit more before I ask you to make such big changes - I wouldn't want to waste your time if it turns out to be a bad idea.
I really like it! BUT.....forcing the character file to be 4K? I can't use it. :'(
Please understand that simple 'I can't use it' does not help me much. If you detail why you need >4K, how you use it, and how you see it's support in the tool, it could help.
Meanwhile, another small feature I've needed is added, download link is the same.
Shiru,
Would it be easy to implement a "export tile numbers" function?
You would select part of the nametable (using shift and drag) and then select the export function and either binary data be exported row by row of the selected area, or even better, export hex numbers (or .byte/.db?)
So if you selected an area 4 rows x 4 columns, the export will result in a file that looks like ;
.BYTE $00,$00,$00,$00
.BYTE $01,$02,$03,$04
.BYTE $00,$00,$00,$00
.BYTE $01,$02,$03,$04
(the $xx numbers are just made up as an example)
I'd love this function. It comes in really handy if you're trying to design partial nametables that you might overlay in your code. Best example would be for menu boxes etc
Okay, Here's two reason.
4K ROM's are a waste and just adding 4K to that (Like every NES game ever released) lets you do alot more with graphics and backgrounds.
8K is the minimum standard. Even the simplest NROM games use 8KB graphics. (Searching for games under 16KB in size yields one result, galaxian clone that uses 8KB PRG and 8KB CHR, still too much)
neilbaldwin, yes, it should be easy. I could make a function which will puts the data as .db's into the Windows clipboard, it is ok, or you need file export?
3gengames, you giving me not the information I need. Of course I know that the CHR ROM banks are 8K. I use NESASM, which allows me to include arbitrary set of data in a bank. So I just incbin two 4K *.chr files to fill a CHR ROM bank, and there is no waste, you just have two *.chr files instead of one. I assume that more than one page on a screen is a rare case (requires tricks to switch pages mid-screen), and I don't plan to support these cases, that's why 4K files.
I don't know about you, but I think most others have all their graphics in one file. I hope I am not sounding mean, it's just that I'd bet most graphic files aren't split up. :/
3gengames wrote:
I think most others have all their graphics in one file.
Concentration Room is NROM-128. Its 8 KiB CHR ROM is made of three sprite sheets: 128x88 for the title screen graphics and ASCII font, 128x40 for opponent mugshots, and 128x128 for gameplay.
Ok, there was other part of my question: how do you see >4K files support in the tool?
3gengames: Actually the PPU splits the 8kB in half anyways. 4kB is 256 tiles, so one set for background, one set for sprites. With the more advanced CHR-ROM switching on some mappers, it makes sense to split it into even smaller files.
I use CHR-RAM, but starting out with 4kB.
Shiru wrote:
neilbaldwin, yes, it should be easy. I could make a function which will puts the data as .db's into the Windows clipboard, it is ok, or you need file export?
Clipboard would be fine - thanks!
Shiru, you can just load the (X)KB file in, divide that by four, and then have a tale selectable. Then any ROM size will work and you can change and edit any nametable without loading any new files. It's up to you to add it, but I think that would be a great addition!
I could definitely use it then. And you can bet your life I would.
I think supporting more than 4K would just be confusing... people WILL try to use tiles from more than one bank simultaneously. I would skip that feature. It's not like splitting a file in half is hard.
But who is going to use this that would attempt that? It's alot easier to select ROM bank X then going CTRL+O, find the right graphics file, load it up, and do that 10 times for different screens.
Oh well, it's your call, thats the only thing I would change though.
thefox wrote:
I think supporting more than 4K would just be confusing... people WILL try to use tiles from more than one bank simultaneously.
Put a
slider widget next to the pattern table to select a 4 KiB bank, and I don't see how it would confuse. As the user moves the slider, the user sees that all the tiles in the nametable view change at once.
The problem with this whole CHR thing is that everything that has been said so far still doesn't work for all cases. Mappers like the MMC3 can make each 1KB chunk come from anywhere in a 256KB CHR file. You could even use the slider approach, but you'd need 4 sliders.
CHR-RAM would be tricky to handle (unless you are making very basic use of it), so it might be a good idea to just expect the user to make a 4KB file with the combination of tiles he intends to use for that screen, instead of loading the actual CHR data that is included in the ROM (which could even be compressed).
I've added the feature with copying parts of the nametable into the clipboard as set of .db's. It is in the Nametable menu.
I had thoughts of how to support non-4K *.chr files. As I understand, we have just four common cases: 1K, 2K, 4K, 8K.
For 8K we can have two banks, only one visible at a time, and two buttons select which part is visible. BMP import would only fill up current part of the 8K. There should be functions to save 8K or current 4K, probably just filter items in the save dialog, or maybe Nametable menu items.
For 1K and 2K, I think it could be loaded starting from the currently selected tile in current 4K part (with any offset), and with ability to save 1K or 2K file starting from the cursor.
Is that would be enough?
Thanks Shiru!
If you're looking for other little feature to add
In CHR editor:
+ shift CHR up/down/left/right
+ flip CHR horizontally/vertically
+ colour fill tool
No pressure though, they would just be the icing on the cake.
Great job
OK I don't understand the guys complaining that it "only" supports 4KB of CHR, since this is what the NES uses.
However, I'd rather have support for smaller files, and expand them to 4KB with blank tiles... maybe you'd want to make screens that doesn't use ALL the 256 available tiles.
Bregalad wrote:
OK I don't understand the guys complaining that it "only" supports 4KB of CHR, since this is what the NES uses.
The NES uses 8 KiB, but only 4 KiB at a time. The PPU has built-in bankswitching ($2000.D4). Mappers use more than that, again 4 KiB at a time. In my opinion, at a minimum, a nametable editor should support 4 KiB banks, which will cover CNROM, GNROM, Color Dreams, and S*ROM CHR banking. In fact, I just realized that I need to improve my Python-based nametable editor to support this (and sub-4 KiB files).
Awesome, shiru! I can't wait to get on this.
Thanks so much. -downloads new version which I hope has it!-
New version is uploaded, download link is the same. Now it supports 1K, 2K and 8K in a way I've described above. It also has additional CHR editor features - scroll, mirroring, and fill.
Please be careful, these changes were relatively major, so maybe some bugs were introduced. I.e. backup your files before overwrite them with tool, just in case.
Epic. I'll try it after school.
Great stuff Shiru.
I spotted a little bug - if you press V to vertically flip a CHR, colours 01 and 02 are swapped.
My mistake, I made the vertical flip as it was a single bitplane. Fixed, the file is updated.
Shiru, I can't thank you enough for all your effort with this tool. I've now abandoned YYCHR completely and NESST is really, really nice to work with , as well as allowing me to make edits and changes to my graphics really, really quickly.
It's this kind of attitude that I really love about the NES community
I can't abandon YYChr for it's more features like copy and paste, but otherwise, I am going to use this all the time now! Thanks so much, I agree. Great tool.
I'm working with it right now actually. ^_^
I've added minimal undo feature, just one step, but it could be very useful sometimes (when you accidentally fill something or put a tile in wrong location). The file is updated.
@neilbaldwin, the fact that my tool got your attention is already really great honor for me, because you are one of the people who contributed to rising of my interest in NES games, game development, and chip music.
Shiru: would it be possible to add copy/cut/paste to the tileset window? I was thinking you could hold shift and draw a selection box (like in the nametable) then perform operations on the selection?
Bug: "Apply tiles" and "Grid" buttons are grouped/exclusive (only one of them can be down).
@neilbaldwin, it is definitely possible, but will take some time to implement.
I've fixed the bug thefox reported, the file is updated.
Copy/paste for tile groups in the Tileset window is added, it works the same way as nametable copy (Shift+mouse drag to select).
I thought of something else last night (because I'd been doing some tidying/reorganising of my project CHR file).
How about a function that processes the loaded CHR/nametable in the same way you import a BMP file?
What I mean is that the function will scan the CHR file for repeats/redundant CHRs, remove the repeats and 'defrag' the CHR file (move everything to the start of the CHR file) then 'remap' the loaded nametable accordingly.
Not sure how it would work exactly but I think it would be quite a nice 'clean up' function. You'd end up with a 'compacted' CHR file with empty tiles at the end (instead of all over the place as my CHR files seems to end up
)
I figured you're probably already doing a lot of the work in the Import BMP function.
Not a big problem, just an idea
Added CHR optimization, it is in the Patterns menu.
Ha ha, great work Shiru!
Can I just ask for a small tweak? Could you make it so that you can perform a rectangular selection (shift plus left-click drag) and then the selection gets excluded from optimizing? It would be handy for when your CHR file has a specific structure (for example, I have two sets of alphanumeric tiles in my CHR file and I'd like to keep them in the same place in the CHR file).
This one was a bit tricky, but added it too (version number is not changed, just updated the file).
Fantastic!
(Oh, I noticed that the colour-swapping bug that I mentioned when you vertically flip a chr occurs also when you shift a chr downwards with the cursor keys)
Fixed the bug, but I can't update the file right now because my website is down. I'll upload it when it will be available again.
Edit: website works, the file is updated.
I have been lurking around these forums for a while already, but I just registered for an account to thank Shiru for this great tool.
In a community that I am part of, there is a small competition going on recently, that you take a classic adventure game, make sprites and mock-up screens of it, as though the game is made by a different developer on another system. It is a coincidence that NESST was released at the same time and so I decided to give it a go.
This is what I did:
And, the ROM (with source):
http://www.mediafire.com/?saqov494ymhbq74
This is also my first "working" Famicom ROM.
(As I'm not really going to do any more work on it, I think this post does not belong to the Homebrew section or a thread of its own; I just cut in to say thanks.)
Great tool Shiru. I don't know if you are still taking feature requests, but here are some features I'd like:
Pattern/CHR:
-saving/loading of .CHR files of variable size <4k. I use CHR-RAM and I group my tiles/sprites into variable-sized chr blocks. For example, a single enemy sprite with all animation frames would have its own .chr file. I'd like to be able to drag a box around some tiles and save only those tiles to a .CHR file. Likewise I'd like to be able to load these .CHR files. For example if I have a .CHR file that holds 18 tiles, opening the file would load those 18 tiles into the editor starting from the currently selected tile in the tileset.
-use CTRL+click to add individual tiles to the selection. Shift-drag can only make a perfect rectangle selection. I'd like to be able to add stray tiles to that selection (for saving).
-a command to toggle the tiles to and from 8x16 sprite format. TileMolester calls this "row-interleaved". 8x16 sprites are vertical, but they must be stored horizontally (top half $00, bottom half $01 for example). It would be nice to be able to draw the sprites as they appear in-game (vertical), and then press a button to remap them to how the NES expects them to be stored:
Code:
|----|----|
| A | B |
|----|----|
| C | D |
|----|----|
becomes:
|----|----|----|----|
| A | C | B | D |
|----|----|----|----|
-ability to edit more than one 8x8 tile at a time. Maybe have the CHR editor be the size of the current rectangle selection?
Palettes:
-hovering over a palette will display help text at the bottom telling you which color is which. Right now it is ambiguous which of the 4 colors in a palette are color 0, 1, 2 or 3.
I see two problems in these requests: non-rectangular selection would require complete redo of selection code and change look of the selection as well; ability to edit more that one tile at a time was discussed above in this thread, it is not decided yet if it would be comfortable.
Other requested features are relatively minor, I'll add them a little later.
MetalSlime wrote:
-a command to toggle the tiles to and from 8x16 sprite format. TileMolester calls this "row-interleaved". 8x16 sprites are vertical, but they must be stored horizontally (top half $00, bottom half $01 for example).
-ability to edit more than one 8x8 tile at a time. Maybe have the CHR editor be the size of the current rectangle selection?
Why don't you simply use YY-CHR? It can display tiles in several different layouts (including 8x16). As I understand it, this is still primarily a nametable editor, and feature creep is to be avoided.
Btw, I would love to see a proper sprite/animation editor (a separate tool) if anybody is up to the task.
Something where you can load a CHR file, build animation frames out of the tiles and export to some (maybe customizable) format. It could also import and optimize (remove duplicate tiles etc) a image file (with all of the frames), generating the CHR data and sprite layout data.
thefox wrote:
MetalSlime wrote:
-a command to toggle the tiles to and from 8x16 sprite format. TileMolester calls this "row-interleaved". 8x16 sprites are vertical, but they must be stored horizontally (top half $00, bottom half $01 for example).
-ability to edit more than one 8x8 tile at a time. Maybe have the CHR editor be the size of the current rectangle selection?
Why don't you simply use YY-CHR? It can display tiles in several different layouts (including 8x16). As I understand it, this is still primarily a nametable editor, and feature creep is to be avoided.
Btw, I would love to see a proper sprite/animation editor (a separate tool) if anybody is up to the task.
Something where you can load a CHR file, build animation frames out of the tiles and export to some (maybe customizable) format. It could also import and optimize (remove duplicate tiles etc) a image file (with all of the frames), generating the CHR data and sprite layout data.
The sprite/animation tool is what I was trying to create here:
http://nesdev.com/bbs/viewtopic.php?t=6177
Suggestions on output formats are wellcome
Wave wrote:
Suggestions on output formats are wellcome
Output formats should be as customizable as possible. In the case of sprite definitions, there are a few things I consider important:
1. the possibility to define an origin point for each frame, so that all coordinates are relative to that point;
2. selection between grid-based or sprite-based frames. The second option is good for complex frames which are not perfect rectangles or make use of sprite layering;
3. the option to select which fields are exported, and in which order. The selectable fields are things like: X and Y dimensions, X and Y offsets, tile index, attributes (palette, priority and flipping), number of sprites used, things like that.
IMO, this is one of those things that are hard to make right, like level editors. Every programmer has their own way of working, and it's hard to make a tool that will fit all.
Wave wrote:
The sprite/animation tool is what I was trying to create here:
http://nesdev.com/bbs/viewtopic.php?t=6177Suggestions on output formats are wellcome
The GUI seriously needs an overhaul.
But I don't want to stray this thread any further off topic.
One more tiny feature request:
-Have the nametable grid show attribute borders. The grid is crowded already, but you could make just the corners of attribute blocks look a little different. Or have a separate attribute grid that could be turned off and on like the other grids. Today I was trying to find an optimal place to draw a text box to the screen and I had to strain my eyes a bit and touch the screen with my fingers to find a place where the corners of the textbox would line up right with the attributes.
The grid currently shows both tiles and attribute blocks (2x2 tiles), do you need it to show the attribute bytes as well (4x4 tiles)?
Shiru wrote:
The grid currently shows both tiles and attribute blocks (2x2 tiles), do you need it to show the attribute bytes as well (4x4 tiles)?
Yes, that's what I meant. A grid that shows the 4x4 attribute bytes.
I've updated the tool to v1.3. Download link is the same.
New features are most of suggested earlier plus few bugfixes. Some of these are:
- V and Ctrl+V in the CHR editor were conflicting
- Load CHRs of any size of multiple of 16 (below 4K, of course)
- Palettes reorganized and has text hint for colors and entries
- Separate grids for tiles, attributes, blocks
- Forced extension for CHR save (previously it was possible to save something without extension)
- RLE packer had a bug, last attribute byte was always lost
- You can use Caps Lock to keep selection mode on
- You can select random tiles in the tileset using Ctrl and left/right click
- You can copy random selected tiles as sequence of tiles
- You can save selected tiles into a file
- If you trying to overwrite a CHR file, and it has different size, a warning shown
- Interleaving/deinterleaving of CHR data (for 8x16 sprites)
- Now you can see parts of neighborn tiles in the CHR editor and move to them by clicking on the edges (not as good as could be, but makes editing a bit easier)
Very good, I especially like these improvements:
- Palettes reorganized and has text hint for colors and entries
- Now you can see parts of neighborn tiles in the CHR editor...
although I personally liked the "smallness" of the old CHR editor.
Minor fixes, the file is updated.
I'd missed the latest updates. Nice work Shiru.
I cannot tell you how much time this saved me while doing the interface for PR8.
Thanks a lot Shiru. This latest update should make graphics-editing and exporting much easier for me.
NES Screen Tool v1.31. Some minor fixes and new features:
- You can switch color codes in CHR data and in the palettes
- You can add an offset to range of tiles
- Del key to delete selection
- Shift+C for Nametable/Put selected block to clipboard
- H and V (flip tile) works in main window too
- You can see how many entries of a tile in the nametable
- When you open a file with double click, current directory now changes to this file
- Some other fixes
looks good, thanks
For my own use, I re-typed the controls as I thought they were getting a bit too confusing (a lot of controls now!). Then I thought other people might find it as easier reference so I'm pasting it here.
Code:
Nametable Controls
------------------
Put current tile into nametable - left-click mouse
Set current tile from nametable - right-click mouse
Make selection - hold Shift or press Caps Lock then drag with left button
Cancel selection - right-click
Copy tile/selection - Ctrl+C
Paste tile/selection - Ctrl+V
Cut tile/selection - Ctrl+X
Fill selection with current tile - Ctrl+F
Copy selection to clipboard as text - Shift+C
Rotate nametable without attributes - cursor keys
Rotate nametable with attributes - Ctrl + cursor keys
Tileset Controls
----------------
Set current tile - left-click mouse button
Open tile in CHR editor - double-click (left) mouse button
Make selection - hold Shift or press Caps Lock then drag with left button
Cancel selection - right-click
Copy tile/selection - Ctrl+C
Paste tile/selection - Ctrl+V
Cut tile/selection - Ctrl+X
Non-rectangular multiple select - Ctrl+left-click, ctrl+right-click to de-select
Note : if you copy a non-rectangular group, it will be pasted as a linear sequence of tiles.
You can also save selected tiles into a separate file.
Palette Controls
----------------
Select current color/palette - left-click mouse button in palettes
Assign color to palette/color - left-click mouse button in colors
CHR Editor Controls
-------------------
Set pixel - left-click mouse button
Set current color to pixel color - right-click mouse button
Fill an area with current color - Ctrl+left-click mouse button
Scroll pixels in tile - cursor keys
Horizontal flip/mirror - H
Vertical flip/mirror - V
Made a little mock-up thingy for a puzzle game idea that's been going through my head:
Cool program.
EDIT: Redid some tiles (
previous version)
Recently I've read on this forum that color $0D could bring troubles on some TV sets. CUrrently there is no colors $0E,$0F in NESSt. I think this have to be fixed, but can't decide how exactly.
Should I use full palette, i.e. add two more columns? Or maybe leave it as is, but when graphics loads, change all blacks to $0D automatically, and when it saved, change $0D to normal black?
Shiru wrote:
Or maybe leave it as is, but when graphics loads, change all blacks to $0D automatically, and when it saved, change $0D to normal black?
Makes most sense to me. Having 8 more blacks doesn't add any value to the user.
Shiru wrote:
Recently I've read on this forum that color $0D could bring troubles on some TV sets. CUrrently there is no colors $0E,$0F in NESSt.
$1D is the same voltage as $0E and $0F.
I have doubts that it makes sense to have 8 extra blacks too, that's why I asked.
$1D is available in NESSt, but $0D too, so someone could use it having no idea it could case problems, so it have to be fixed anyway.
I think the point of using $0F instead of $1D in an NES program is that it won't become $0D in a palette fade routine.
Ok, I did autofix which replaces all the blacks to $0f. File is updated.
Edit: I added color emphasis and monochrome mode display too. I guess it works, although not sure if it accurate or correct, so tell me if something wrong.
Another update, it is now possible to import CHR from 24K and 40K NES ROM files.
Could you possibly add the ability to load an external 192-byte palette file (not the 16 NES values, but the actual RGB values)? The one you included has some pretty glaring inaccuracies: $2C and $3C are almost identical, $3D has a pinkish hue, $x8 is way too orange, and $29 is way too bright.
Aside from that, this is an excellent program!
Loadable external palette is there from very first versions.
readme.txt wrote:
You can place nes.pal file (192 bytes) in the program directory, if you want to tweak the colors of the NES palette.
I know that default palette is not ideal, but every emulator has its own palette, and there is like 1000 different palettes (really!), so I decided to allow to load any palette and not bother about default one too much.
Oh, jeez, I totally missed that. Sorry! ._.
Minor fix, the program didn't opened custom palette when called with double click from other directory. Version number haven't changed.
Update, now you can export current tileset or nametable as BMP. Could be useful if you want to just draw authentic NES graphics and not to use it in an actual NES project, or to mockup something with full featured graphics editor.
There were two updates. Few minor fixes, and now you can create metasprte definitions for programs, currently as a C array only.
Is it just me, or does applying tiles no longer work?
It works if you press down 'Apply tile' button.
Shiru wrote:
It works if you press down 'Apply tile' button.
I actually just figured it out. I accidentally hit the CAPSLOCK button on my netbooks tiny keyboard. Apparently it works the same as the shift key.
Yes, it is very useful when you rearrange nametable and need to use shift all the time.
Shiru wrote:
Yes, it is very useful when you rearrange nametable and need to use shift all the time.
I agree, it is a very useful feature now that I know it exists.
Thank you for this tool Shiru! I can finally copy/paste in my photoshop pixel art verbatim (via graphics gale)... something i couldn't do in yy-chr.
Shiru, thank you so much for this tool! For some reason, I still can't figure out how to copy/paste from MSPaint, or export (it keeps telling me my bitmap needs to be 4 or 8 bpp). Anyway, I know that's user error, I just can't figure it out. The real reason I was writing, was just to say thanks. This tool is really helpful, way easier than TLP and YYCHR combined!
Currently you can only import uncompressed BMP files. They should be exactly 256x240, with 16 or 256 colors (i.e. palettized).
Thank you for making NESst. It works fine in Wine on Xubuntu 11.10. Now I have a bit of a feature request:
I'm working on a multicart that will include several homebrew NROM games. (LM, LM, and ZS are among them.) One way I can save space in the multicart is to compress the tile data, and the compression ratio improves if I blank out tiles that I know are unused. A lot of games seem to have some sort of repetitive 'X' marks in unused areas of CHR ROM, which compress well using some codecs but poorly with others.
Currently I can Import from an NES cartridge image. I'd like an option on the Export menu to save my changes to the CHR data back to the cartridge image.
And a minor bug report:
When CHR banks A and B are active, the "Interleave" and "Deinterleave" options affect only bank A's data, not bank B's, even if I have bank B visible.
The CHR import is currently NROM only. Is it enough to have import/export for NROM only, or you need this for larger files (this would require to add a way to select a bank in the file)?
For now, NROM only is fine.
I overdone it and added import/export for NES files of any size. Some other minor features and bugfixes are done as well. The file is updated.
I'll try the new version later, but what is the mode that you can click characters on the left AND right side and it doesn't let you place any more blocks on the screen? I've had it happen on my older version, but I'll try this one soon too. It happens anywhere from start up to even a few minutes of use in, it's weird.
I don't really understand the question. At the startup, placing tiles and attirbutes to the nametable is disabled. You have to enable it with the buttons Apply tiles, Apply palettes.
Yes, but there's times where even when those are activated (and disabled and re-enabled doesn't work) when you click the nametable, it selects the tile on the right and doesn't allow you to replace it from then on out on my version. I can't determine what causes it, it seems random at times, but sometimes I think it's when you select a tile on the right too maybe. I'll test more later as I never tried to make it do it, it just happens.
Hmm, never happened for me. You can select tile on the right by clicking right mouse button on the nametable, so maybe in this case your left click is counted as right click by some reason?
I envisioned the following work flow:
- Import .nes ROM in NESst
- Export tilesets A and B
- Scribble on them in a paint program
- Import tilesets into NESst
- Save CHR data back to .nes ROM
When I export tileset as image from NESst under Wine 1.3.28, it comes out as a 24-bit BMP. But when I reimport the 24-bit bitmap into NESst, NESst tells me it can import only 4- or 8-bit BMP. Why doesn't NESst save a 4-bit BMP in the first place? Or does it save a 4-bit BMP under genuine Windows?
tepples wrote:
I envisioned the following work flow:
- Import .nes ROM in NESst
- Export tilesets A and B
- Scribble on them in a paint program
- Import tilesets into NESst
- Save CHR data back to .nes ROM
When I export tileset as image from NESst under Wine 1.3.28, it comes out as a 24-bit BMP. But when I reimport the 24-bit bitmap into NESst, NESst tells me it can import only 4- or 8-bit BMP. Why doesn't NESst save a 4-bit BMP in the first place? Or does it save a 4-bit BMP under genuine Windows?
You prefer PNG? I added a PNG exporter of CHR-ROM banks to NESICIDE for someone on #nesdev that wanted it. I could add an importer...then I'd be in the Costanza "import/export" business.
NESst saves 24-bit BMPs because it was easier to do that way. It draws graphics as 24-bit because besides the graphics itself there are extra things like selection rectangle, grids, etc.
I can make export 4-bit, it would only require some additional code.
The export is now 4-bit, and you can import back previously exported tileset. The file is updated.
Thank you for working with me on this. I just tried it out, and there appears to be a bit of a problem: If I import a 128x128 pixel tileset image while bank B is showing, the import goes to bank A anyway.
Another feature request: Can I get a minimize button?
Fixed the import problem, also added Swap banks just in case.
Regarding the minimize button, what exactly you mean? There is standart minimize button for main program window.
I'm not seeing a minimize button at the right side of the title bar of the main program window. All I see is close. It might just be a Wine problem.
It is, probably - because the button is (and always was) there, and it works. Maximize button is disabled, though.
Thank you for putting this new feature in so fast.
Would someone be willing to walk me through how to include this in a .asm file to show up as say, a title screen, once I've designed one using this application?
Dan
Read more nerdy nights over and over until you understand at least PPU interaction, because you should be able to pretty much do that once you get to there. Don't look too far ahead.
muffins wrote:
Would someone be willing to walk me through how to include this in a .asm file to show up as say, a title screen, once I've designed one using this application?
Dan
Save the CHR data to a file. Then there is an option in one of the menus to save the nametable, attribute, and palette data to clipboard. Then using your own code, or borrowing some from existing tutorials (aka nerdy nights) replace the background and attribute data with the data copied from nesst.
Nerdy Nights 6 deals with backgrounds, but I agree with 3Gen, you should really go through all the others first just to get a basic understanding. Week six has already dealt with reading controllers, displaying sprites, palettes, and a lot of really important stuff you need to know before continuing on.
Thanks guys! I guess I should have been a little more specific with what I was having trouble with. I have been through those tutorials a few times and have created a functional pong game (without audio or title screen...that's the stuff I'm working on now
) but what I was curious about was how to dump the information from the Screen Tool to a file, and then access it in the PRG ROM. I've written a loop that can fill a screen with tiles (32 x 30) to create a background if I have explicitly written out the data, for example:
Code:
.db $25, $25, $26, $25, $27 ; and so on...
but I didn't want to go through the painful process of designing a title screen in NES Screen Tool, then go tile by tile and hand code each of those tile numbers in myself, but rather have the program dump that data into a file that I could access via a loop. I see the "Save nametable and attributes" option that you mentioned, WhatULive4, but I don't know how to access the data in a .nam file because the Nerdy Nights tutorials give no background on that type of stuff.
Put the files generated by NES Screen Tool in the same folder as your source code, and replace the .db statements with .incbin (some assemblers do it differently, but it's usually .incbin "file.nam"). This includes a binary file at that point in the ROM, which is the same as if you typed a bunch of .db statements.
Just what I was looking for. Thanks Tokumaru!
You'll want to select the whole image or just part of the image if you want using the shift key. Then in the nametable menu, select the "copy block to clipboard" option.
One feature I'd love to see is for attributes to be properly calculated when importing a .bmp, as it is a bit tedious that you have to correct the attributes manually even if the .bmp has been drawn with this in mind. Of course, that presents a problem that if the rules of the attributes are not enforced in the bmp data, but I think just getting the color from the upper-left 16x16 block would be sufficient, and just let the user deal with the case where (s)he neglected the attribute rules in the original file.
Also, it'd be nice if there was some sort of "project" file for saving loading all of your data at once, instead of having to save nametable, tiles, and palette separately. I guess just saving all of this into one .zip/.tar archive (which is what OpenOffice's format or the Android .APK format really is) might be the simplest way to implement this.
'Save all' is may be useful, but I certainly don't want to make zip/tar thing. Why there is no 'Save all' yet: it wasn't really needed in (many) actual projects, since they tend to have one tileset, few palettes, and many nametables. I.e. situation 'one tileset-one palette-one nametable' is not common.
Added colors and attributes import. It consider colors 0..3 as related to palette 0, 4..7 to palette 1 etc, checks the most often used colors in an attribute position and sets corresponding attribute. So it is able to import back previously exported BMPs with colors and attributes, or another image that was created considering this limitiations.
There is also primitive Save all function now, it calls all the save dialogs (Save CHR, Nametable with attributes, Palette).
Shiru wrote:
Added colors and attributes import. It consider colors 0..3 as related to palette 0, 4..7 to palette 1 etc, checks the most often used colors in an attribute position and sets corresponding attribute. So it is able to import back previously exported BMPs with colors and attributes, or another image that was created considering this limitiations.
Thanks! This one is really helpful! :)
Quote:
There is also primitive Save all function now, it calls all the save dialogs (Save CHR, Nametable with attributes, Palette).
Hmm... this one currently requires you to type in the filename separately for each type of data it is about to save... so it's only slightly less teious than having to go through it manually :P
I do understand your arguments against a "save everything"-feature, but I see it more as a "save your current state for working on it later" function. Even if your final data you'll use in a game will most likely be carefully sorted into different .chr, nametables, palettes etc, without a simple 1-1 relation, the common case while playing around in the tool will be to want to save everything you're currently working on easily for later reloading, which is where I think this feature would be very convenient.
If 'Save all' will put first entered filename (CHR) into two next save dialogs (nametable, palette), would this help?
I'll think about 'save state' thing, I guess it not only needs to save all currently loaded data, but also current paths and state of buttons (grid etc).
I think I found a bug. Don't know if it has been reported earlier since I didn't have the patience to read through the entire thread!
I was splitting some of my CHR-banks into smaller chunks, and I usually do this by selecting 1kB of data and using "Save selection", but if I did this when I had selected data in bank B it saved the corresponding data from bank A instead.
Yes, it was a bug.
The program is updated, added the requested 'save states', also tile 90 degree fliiping, few small bugs fixed, and documentation is improved.
Loving this tool Shiru!
Minor feature change requests for your next release:
-Is there some way to see what name table mode I'm in visually? I always just end up assuming I'm in select mode and undo the undesired modifications if I'm wrong. Kind of annoying. I avoid looking at my keyboard like the plague so the caps lock light doesn't help.
-Could the draw/select nametable hotkey be switched to something besides caps lock? Tab perhaps, or hold spacebar while selecting? This becomes excessively annoying especially when using a man's text editor like Vim as a neighboring dev tool. I start destroying my code if I forget I left the caps lock on from my last nametable modification.
As a discussion:
I see there is talk of larger than NROM support. I'm no where close to being able to make use of this with a game. But I imagine it would be a huge benefit to supporting bank switching for animations and such. I guess you can do similar effects by just using A and B nametables back and going back and forth. Then just manually stitch your banks together properly. Wouldn't work so great for more than two banks of animation. Down the road once I set up some hardware with swappable attribute and name tables I may request support for more than one attribute table or different attribute table limitations. But now I'm really getting ahead of myself
I'll think about remapping the key (how about the Scroll Lock?) and indication, although I don't really get the problem with Caps LED - it is like 30 cm from the window on my PC, and I have no problem to see if it on or off without looking at it directly.
'More than NROM' support is already there, but I don't plan to make animation functions, as the tool certainly wasn't designed for such things. I only had thoughts about fast switch between many nametable files, to make multiple screen edit faster.
Well my keyboard is on a sliding tray so the top portion of my keyboard where the lights are isn't visible 9 times out of 10. My other keyboard doesn't even have lights, probably to conserve power since it's wireless. And the keyboard I'm currently using doesn't have scroll lock and numlock is also out of the question...
I understand why it might be easier to check caps/scroll lock mode. I guess my biggest bother is the fact that my current mode while using your app also affects the mode of every other app I'm currently using on my computer. I NEVER use caps lock so it's difficult to remember to turn it on and off all the time. It become detrimental in Vi when hjkl are used to move the cursor and HJKL modify my code in undesirable ways.
I'm down for holding a key while I select things similar to excel.
Well... so hold the key - any Shift, and forget the Caps Lock. No changes required then.
I certainly don't want to support keyboards that have no Lock keys, because these keys are standart, and widely used.
Awesome! works for me
This tool is pretty useful, thanks for your work!
I just have a question: Is there any way to take a shift-selected block from the tileset and apply it as a block to the nametable? I wasn't able to find any other way of transfering tiles from the tileset to the nametable apart of doing it one by one.
Thanks!
Currently there is no such way. I thought to do it, it won't take much time, but I'm not sure about the logic. Is it OK that operations with copy/pasting graphics will change copy/paste buffer of nametable too? Or a separate key to paste selection from graphics into tileset without change of the buffer is a better idea?
I think that instead of copy-pasting between buffers, when you click on the nametable with apply tiles enabled it should apply tiles according to the selection on the tileset. In the case you have selected only one tile, it would behave like now, but if you have selected a block (and it also could work with discrete selections) all the selected tiles are inserted at the point you click on the nametable. It would work as some kind of "brush".
Does it make sense?
Great idea, implemented. The file is updated.
That was fast!
Thanks a lot!
Major update. Now it have built-in metasprite editor. You can create complex metasprites with non-regular grid aligned sprites, various palettes, horizontal and vertical flips. Beware the bugs and inconveniences, though, as currently I don't have time to make another NES game and test the new editor capabilities in real workflow.
A minor problem with metasprite code generation reported by thefox in another thread is fixed, please redownload.
I've wished for direct support for using $0F in the palette selection as Black, but use of $0D and $1D is there instead, and we've proven that in any TV using signals, using palettes $0D, $1D, $0E, $1E, $2E, $3E, is not recommended, I am not sure about $1F,$2F,$3F,
Maybe you can turn them blacks to $0F by default, but make a toggle that gives them a warning about TVs not supporting some colors that are Pure Black if re-enabled, Benefiting the Use of $0F on any NES games created!.
I don't quite get what you are talking about. There is only $0f for black in the editor, it automatically replaces $0d etc to $0f. You simply can't select $0d in the editor, by the exact reason that it would cause problems.
Oh, Did not notice, Sorry!
That was what I wanted!
Minor update. Copy, paste, and flip for metasprites, mouse keys in the metatile editor are reassigned: RMB to move sprites, LMB just to select a sprite, LMB+Ctrl to change the origin of coordinates. Import BMP as a nametable now allows to use images of arbitrary size, not larger than 256x240.
The save to clipboard option seems broken for me. (Windows 7)
All of these options or only some of them? I don't have Windows 7 around to check if the code works there at al.
At the very least the nametable ones (Both copy as C and as ASM)
edit: after a quick test, the metasprite one works. So just the nametable ones it seems.
Hm. They use mostly the same code, but I'll check it out anyway, maybe there is some difference.
Jeroen, did you try to use the nametable functions when a selection is set? They only work with a selection. Other that this, I don't see anything special in the code in both nametables and metasprites cases.
I've attached a bmp that I made in gimp. It should be only one tile. Somehow the rightmost edge tiles miss the 8th pixel.
I am running nesst under wine.
Chose 'do not save color space information' when exporting from gimp.
I wonder if it's only on my end. I had trouble copying to clippboard, too. But didn't try pasting into another windows app under wine.
Thanks for the work you have done, anyways.
p.s Had to rename the bmp extension.
The file you have provided does not contain any graphics at all, it is all-solid color. Did a few exports to test, don't see this problem, no missing pixels.
And you got just a single tile? The image was supposes to be all one color, and be one tile. I just ran another test, this time in virtualbox with the windows clone reactos, still happens that I get two tiles. If I have the full layout, the whole right side tiles have a transparent color 1 pixel horizontal stripe. I don't know why. it had been working fine. Not to much up your thread, but just noting this in case it pops up again.
Oh, I get what do you mean, the two tiles after import, not export. OK, I'll investigate what happens there.
It was an import bug introduced in the last version. Fixed.
Say I have some text in my nametable, using font tiles at $00-$2F, and then realize I want my font tiles at $30-5F instead. So I move the tiles from $00-$2F to $30-$5F, and I have to retype all my text again. A simple button somewhere for enabling the nametable to update itself to use new tile numbers as the tileset is changed would be neat. Or maybe this feature already exists, and I overlooked it?
Other than that, this tool is fantastic. It, and discovering the .incbin command (that I'd been looking for but didn't find until this Friday) has led to more progress in my quest to make my own NES game than I've seen since I signed up on these boards. Keep up the good work, and thanks!
There is no such feature yet, but I'm considering to add it for a while now. Think I'll make an update soon.
For now you can use the Nametable/Add offset feature, it helps to renumber tiles in the nametable in situations of this kind.
Ah. Yeah, that works too. Thanks again!
Just passing by to say that your tool is the best out there. Seriously, NES Screen Tool + YY-CHR = unbeatable duo. The only reason I'm programming my own level editor on XNA is because I would like to not have to write all trigger zones and sprite placements by hand. God bless you for your tool!
A questions I want to ask that was in mind a lot, but a little nervous of receptions.
Is this needed/required as the only way to create certain graphics, like background such as stages, game-over, victory, and title screen? Or coding is also an optional, but this is most recommanded?
NES Screen tool makes it easier to draw a screen for the NES, or set of screens.
To actually display on a NES, you will still need a little bit of program, but it's a task that could easily be done using cc65.
caramelpuffpuff it is just a very nice tool for making NES screens. The nicest, actually.
It's not "needed"; there are lots of ways to make an NES screen. For example, some people just type nametables out as hex numbers in the assembly code. Shiru's tool is really convenient though, since it already obeys all the NES rules.
RainyHero, so is this tool, "universal-usage" or "exclusive-usage", which is only use for certain games only, like SMB3 tools? And is this tool usable to everything I'd use it on, like title screen, background, game-over, stages, selection, etc? Or it has limitations/more than I said?
It can be used on any screen, but some things related to nametables (such as collision or heavy compression) are best done with specialized tools.
Is nametable the "entire group" of sprites and graphics and backgrounds? Or the is term is different?
"pattern table" is the term for the group of small 8x8 pixel pictures that are combined to make sprites and backgrounds.
Name table is the term for the list of numbers that say what pattern table pattern is drawn where in the background.
A background consists of three parts of video memory: the pattern table ($0000-$0FFF), the nametable ($2000-$23FF), and the palette ($3F00-$3F0F). The pattern table is the 256 tiles, the nametable is a 32x30-tile map plus a 16x15-area coloration map that tells which part of the palette each 2x2 block of tiles uses. Sprites use OAM (a separate memory space) and typically use the other pattern table ($1000-$1FFF).
Oooooooooooooh. So nametable it's a file-code to organize on what sprites and background it appears and what does not.
Could you add export for nametable as .asm text file with .byt/.db instructions? I've found out that easiest method to put nametable into memory is to divide it into 6 "segments", each of 5 rows so we can load it each by 160 bytes with 6 loops, like this:
Code:
loop:
lda face,y
sta PPUDATA
iny
sty $A1
lda $A1
cmp #160
bne loop
ldy #00
loop2:
lda face2,y
sta PPUDATA
iny
sty $A1
lda $A1
cmp #160
bne loop2
ldy #00
;snip for rest of loops as they are largely same
To do that, I need to put symbols (labels) every 5 rows of nametable, so I need text output (hex numbers) instead of binary (.nam files).
You could split the binary file yourself using python/whatever other languages you know, or just add 160 to the pointer each time in 6502.
You can copy a whole nametable from one label with (d),Y addressing mode. Load a pointer into two adjacent zero page locations, increase Y after each byte, and when Y wraps, increase the high byte of the pointer.
It is already possible, sans nametable attributes - just select the whole nametable, then Nametable/Put selection to clipboard as ASM.
Also, you can normally define labels as an absolute address or an expression, so you probably can just do something like
Code:
part1
part2=part1+160
part3=part2+160
...
incbin "nametable.bin"
tepples wrote:
You can copy a whole nametable from one label with (d),Y addressing mode. Load a pointer into two adjacent zero page locations, increase Y after each byte, and when Y wraps, increase the high byte of the pointer.
Yeah, but my way is easier (and until it makes game too slow I'll keep it)
@Shiru: Thanks, will try that!
darkhog wrote:
Code:
;snip for rest of loops as they are largely same
And this is when you should use macros. On ca65, you can even use macros to generate the labels Shiru was talking about.
thefox wrote:
darkhog wrote:
Code:
;snip for rest of loops as they are largely same
And this is when you should use macros. On ca65, you can even use macros to generate the labels Shiru was talking about.
Shutup, I'm still learning
.
Anyway, I suppose I'll eventually convert it into macro as I am big fan of code reuse, but first I want to make something that works. Then I will learn how to do it properly, but so it'd still be working.
I am not 100% if qbradq will finish the tool that he mentioned one time, so can you please support Nintendo's RLE format for PPU data as seen in the Black Box and Mario series, qbradq and Orbit2002 uses this as well:
http://forums.nesdev.com/viewtopic.php?f=5&t=10676It will be more complete after that.
This is more of a linux / wine issue than related to this tool so sorry if it is a bit off topic. I had a hell of a time getting NES screen tool to work on WINE as the drive mappings weren't configuring correctly. It took me a couple of hours to figure out. Doing this (NOTE THIS WILL REMOVE YOUR WINE FOLDER) :
Quote:
sudo rm -rvf ~/.wine
Then re opening NST in WINE, downloaded a couple of things and then it worked fine! Might help someone out in the future.
lazerbeat wrote:
This is more of a linux / wine issue than related to this tool so sorry if it is a bit off topic. I had a hell of a time getting NES screen tool to work on WINE as the drive mappings weren't configuring correctly. It took me a couple of hours to figure out. Doing this :
Quote:
sudo rm -rvf ~/.wine
Then re opening NST in WINE, downloaded a couple of things and then it worked fine! Might help someone out in the future.
Whoa! Hold up there - while this probably worked for you, don't let anyone go blindly copying that. There could be things a Wine user might care about in there they might not know about. That completely nukes your Wine folder!
mv ~/.wine ~/WineBackup would be a safer recommendation, at the risk of filling up your homedir with random crap.
I wish I knew how to trigger wine to ask the "Do you want to install Gecko? How about Mono?" dialog, after you already had an install.
mikejmoffitt wrote:
Whoa! Hold up there - while this probably worked for you, don't let anyone go blindly copying that. There could be things a Wine user might care about in there they might not know about. That completely nukes your Wine folder!
Sorry, that is a good point. I literally only use wine for a couple of NES utilities so it is very low risk for me. I updated the OP with that disclaimer.
So, I'm trying to figure out the Metasprite format the program outputs with no luck. Could someone please explain to me how it is formatted, and why it is a huge file?
Punch wrote:
So, I'm trying to figure out the Metasprite format the program outputs with no luck. Could someone please explain to me how it is formatted, and why it is a huge file?
My quick notes from a while back:
myself wrote:
msp file format:
originX: byte
originY: byte
after this comes 256 metasprite definitions. each metasprite definition takes 256 bytes
so the total size of the file is 256*256+2 =~ 64KB
yCoord: .byte (note: subtract origin to get the value shown in NST)
tile: .byte
attribs: .byte
xCoord: .byte
if the yCoord is $FF, the sprite is not visible.
I'm requesting a feature for Nes Screen Tool:
At the very bottom left of the screen, under the nametable, where it shows the ppu address offset. Could you please make the offset clickable, so the base nametable becomes adjusted? So it can show $4xx/$8xx/$cxx too?
Iknow it's fairly easy to calculate the differance mentally, but it's slowing me down when I have to remember 4 different numbers ( base high byte, low byte, tile number, run length count of tile if sequential.
I was about to take a peek in the source code to see if I could hack it in; but my c is rusty.
I adore NESst, using it daily at the moment! Would a "clear nametable" function like the "clear" function for the .chr files be possible?
This tool is wonderful. But saving CHR can be confusing if one doesn't pay a lot of attention and it looks like a bug, although it isn't. It's more of a usability issue. I loaded two 4kb CHR to each bank, and I selected the "Save CHR" function, but it automatically had 4kb selected as file size. It is very easy to miss that you can change to 8kb. Why doesn't it automatically select the appropriate size?
I just keep the two 4 kB CHR files separate in my project. One for each pattern table.
lazerbeat wrote:
I adore NESst, using it daily at the moment! Would a "clear nametable" function like the "clear" function for the .chr files be possible?
Select tile to clear with, hold shift, select whole screen, press CTRL+F to fill selection.
I've been wondering this for a while, so I'm just going to ask, how feasible would it be to add zoom functionality to the NES Screen Tool Metasprite tool.
I don't know if there's something different about my setup or what, but I don't see how one could do pixel perfect placement of tiles at pixel resolution.
darryl.revok wrote:
I've been wondering this for a while, so I'm just going to ask, how feasible would it be to add zoom functionality to the NES Screen Tool Metasprite tool.
Yeah, that would be nice. For the time being, you can use Windows Magnifier to work around the issue.
thefox wrote:
Windows Magnifier
I forgot that this exists!!! Thanks for the reminder. I haven't used this thing in years, but i often find myself squinting close to the screen because I want to count pixels.
I actually reduce the resolution of my screen to 1024*768 every time I have to use Nes Screen Tool for "zooming".
I draw a sample picture with windows xp paint.
I used only 7 colors and the picture is 256 x 240 :
I saved it 16 color bmp (4bit)
Then I import it to nes screen tool (Import --> BMP file as nametable) :
Why does it mess up the colors?
Do I have to clean it up manually?
NES Screen Tool doesn't use the picture itself to make the background palettes for NES.
NES Screen Tool uses the palette inside the image file.
The palette of the image you uploaded is seen on the left, above.
Every 4 colors are supposed to correspond with an NES background palette. The palettes there are impossible to make your image (there's not even a universal color), so NES Screen Tool doesn't do well.
I set up the palette properly (white is universal):
And this is the imported result with no changes/cleanup:
Note that the tree bark got the same color as the sun. This is because NES Screen Tool tries to find the closest match in the actual NES palette to the palette in the image. The closest match for those two different colors ended up being the same color. But you can just change that palette color since it is still separate:
You need to use an image editor with actual palette control to set up the palettes.
Graphics Gale is a program that will let you do this for free.
Here's the image you uploaded with a fixed palette:
Attachment:
nametable_test3.bmp [ 61.05 KiB | Viewed 4004 times ]
Kasumi wrote:
The palette of the image you uploaded is seen on the left, above.
What is the name of this software?
That was
Aseprite.
As stated in the post,
Graphics Gale is another option which is free for this if you're not into buying or compiling Aseprite. The free, older version of Aseprite will let you do it, but it's not as convenient in that one as Graphics Gale.
I swapped (drag and drop) and replace (ctrl + drag and drop) the palettes.
But as you can see the whole colors are messed up!
If you shift click and drag, you can move the colors around without destroying the image.
Thank you it works now
What is the rule to arrange those colors?
Do I have to visually check out the adjacent colors and put them in one group?
Is there any tutorial on how to covert a picture to tileset, name table + attribute, palette?
I'm not sure I understand the question.
It's the NES background palettes, arranged as they would be on the NES.
Index 0, 4, 8, and 12 are the universal color (color 0). Index 1, 5, 9, and 13 are color 1 for each of the four palettes. Index 2, 6, 10, and 14 are color 2. Index 3, 7, 11, 15 are color 3.
Index 0, 1, 2, and 3 are palette 0. Index 4, 5, 6, and 7 are palette 1. Etc.
On NES, each 16x16 pixel (2x2 tile) region can use the four colors from any one palette. Colors 0 must be the same color in all four palettes. If you draw an image where there's 5 colors in a 16x16 pixel region, or one that uses 4 colors that don't match any of the given palettes, it's not going to work.
I chose white as the universal color because it's the most common (or at least overlaps with more than the green), and worked out which palettes were needed by the image from there. But you can arrange your palette however you like, so long as it doesn't break the above rules. Ideally you draw with the palette restrictions in mind, rather than drawing an image, and then trying to constrain it to palettes.
Edit: I guess the last line was edited in or I missed it. I don't know of a tutorial (or software) to get an arbitrary picture broken down into tiles with decent guessed palette info. I was working on something like that, but it will require more time that I do not have at the moment.
There is an alternative approach, where you literally just give the converter a 256x240 pixel PNG image plus a 32-character hex string representing the NES palette that you want to use. However, it requires installation of a Python interpreter as well as use of the command prompt.* This "savtool", as I call it, is bundled with my
graphics editor for NES.
Or do you require that it be point and click and in the form of a single EXE for the Microsoft Windows operating system? If so, let me know, and I may put it on my list of things to make for the community once
The Curse of Possum Hollow wraps.
* I prefer the command line for data conversion tools like these because it allows me to script the conversion in a makefile, so that when I edit the original PNG image, Make can detect the changes and re-run the conversion.
I think we need a tool that let people design their picture inside of it and then generate chr.bin name.bin and palette.bin
FARID wrote:
I think we need a tool that let people design their picture inside of it and then generate chr.bin name.bin and palette.bin
I bet that 90% of the tools were written because people were unsatisfied with the current tools. NES screen tool can be used to do what you want, just slowly.
I've recently looked at the source code of NES screen tool, thinking about changing things, or adding functions, but it's entirely uncommented... so I don't know if I can even convert it to a form that I can compile, let alone add features to.
FARID wrote:
I think we need a tool that let people design their picture inside of it
I find it futile to implement drawing tools from scratch. Most artists are already used to advanced drawing programs, with things like layers, transparency (for onion skinning), animation, and so on. Implementing all of these things from scratch is not at all trivial, especially if you want to convince artists to switch over from whatever it is they're already used to. Few programmers would be capable (or willing) to implement something as versatile as Photoshop or GIMP inside their little tile editors.
A customized graphic drawing software for NES can help the designer to stay within the limitations while drawing the picture.
Designing the graphic with modern softwares and then converting it to use with NES gives me really headache.
I bet nes designers used such a customized software back then.
FARID wrote:
I bet nes designers used such a customized software back then.
Yes, and the early games look really blocky and flat because of all the limitations of the drawing process that was used back then. Pattern tables, name tables, palettes and such are aspects of the distribution format, and editing directly under those constraints can be very limiting for artists. I know I often break the rules of NES graphics, doing things such as using more colors than allowed to color code parts of the drawing before applying the final colors and effects. An editor that only allowed 4 colors per tile taken from 25 colors distributed in 8 palettes would never let me work like this. Sometimes we break the rules temporarily as part of the creation/cleanup process, meaning that the restrictions imposed by the hardware should not be applied/enforced until the very last step. This might not be clear to people who are not artists, but not everyone works exclusively with the delivery format.
This is similar to questioning why an illustrator uses brushes, transparency and vector tools when the final product he must deliver is just an array of RGB pixels. Sure, he could just open MS Paint and draw the entire picture pixel by pixel, but it'll take much longer and the result will hardly be as good. It's much better to let artists choose their own limitations during the creation process, and just create the final product by exporting/converting.
Nowadays we have very advanced tools to do things, and trying to mimic the way things were done in the 80's does NOT make your retro games any better. Back then they often used crude assemblers, that only supported tiny labels, no macros, and so on. Why would anyone choose to work under those limitations nowadays, when we have much better tools?
I'm not saying that everyone should draw their NES graphics in Photoshop or GIMP... in fact, I personally think that's overkill. But every artist already has their own workflow, and telling them to drop that in favour of the quirks of a tiny little editor will hardly give the best results. That's why I think it's better to focus on the conversion process and optimization of the distribution data, rather than pointlessly trying to offer good drawing tools, which may not be easy to do, and will hardly please artists anyway.
Kasumi wrote:
Ideally you draw with the palette restrictions in mind, rather than drawing an image, and then trying to constrain it to palettes.
tokumaru wrote:
It's much better to let artists choose their own limitations during the creation process, and just create the final product by exporting/converting.
So which suggestion should I take?
tokumaru wrote:
early games look really blocky and flat
Nekketsu series had impressive graphics :
More here :
Nekketsu! Street Basket BG RipLet's find out how did they make those complex backgrounds.
FARID wrote:
Kasumi wrote:
Ideally you draw with the palette restrictions in mind, rather than drawing an image, and then trying to constrain it to palettes.
tokumaru wrote:
It's much better to let artists choose their own limitations during the creation process, and just create the final product by exporting/converting.
So which suggestion should I take?
These advices are not mutually exclusive. You definitely should draw with the restrictions in mind. Using unrestricted software doesn't mean drawing photorealistic images expecting them to convert well to NES specs. One thing you can do, for example, is enable a 16x16 pixel grid in Photoshop (or whatever software) when drawing backgrounds, so you can easily tell if you're respecting the attribute limitations, but you'll still have layers (for keeping trees, bushes, etc. separate in case you need to move them later), transparency (for onion skinning of background animations, for example), and whatever other features you find useful as an artist. In photoshop you can also use smart objects for tiles, metatiles, or repeated elements in general, meaning that changing 1 instance will automatically affect all others. When you're done, you can export the final image for conversion, but still keep the editable (layered) version for future tweaks that might be needed.
What route you'll take will depend on how you like to work as an artist. Most artists already have an established workflow, and they'll definitely be more productive if they can maintain that workflow. If they're targeting an specific console, they should definitely keep the limitations in mind, knowing that the final result should strictly conform to them, or deal with any degradation introduced by automated conversion. If you're new to this, doesn't have a workflow, and just want to plot pixels, then by all means, draw all your graphics in YY-CHR or something, where you'll be constrained to tiles and palettes all the way.
Quote:
Let's find out how did they make those complex backgrounds.
I'm pretty sure that the artist is more important than the tools. A good artist will make do with the crappiest of tools, but not even the best software in the world will improve the work of a bad artist. Hunting down the obsolete computer and floppy disk with the software they used to make the Nekketsu games will NOT instantly allow you to draw the same kind of graphics (just like using the same assembler used for SMB3 will not instantly allow you to create an engine as good as that game's), but if you study the graphics well and really understand what makes them any good, you'll probably be able to create similar art no matter the software. Most artists will prefer to use their tools of choice though, in order to achieve the best possible result in the smallest amount of time.
tokumaru wrote:
I'm pretty sure that the artist is more important than the tools. A good artist will make do with the crappiest of tools, but not even the best software in the world will improve the work of a bad artist.
I agree with you, but those who follow Nerdy Nights nes programming tutorials (including I myself) are not professional graphic designers, and for making a hobby nes game they will not hire professional graphic designers. A customized graphic software for NES games can help these kind of people to make their own simple graphic without struggling to use heavy graphic softwares.
Sometimes they do.
The main thing that makes those nekketsu screens so nice is the shared palette entries, which help to hide the attribute grid. That's not a technical feature, it is a creatively made decision about use of color. Having better graphics editors won't help someone the way you're looking for.
Knowing NES graphics restrictions, studying some basics of color theory, illustration and design--and being able to analyze how professional game graphics are successful or could be more successful in those areas will help more. For example, gesture drawing exercises can help greatly in sprite work when it comes time to represent bodily motions at such a low resolution and in so few frames. Also, being willing to separate one's self from local color is a common growth art students usually go through and can greatly help when working with such limited palettes, and when one gets to 16-bit color, knowing how to use saturation (and in particular the lack of it) to your advantage can help tremendously.
The image editing software is irrelevant. I use Photoshop, yy-chr, graph paper, and NESst. Once you learn the restrictions, self-imposing them is no problem. I think everyone has a different workflow (and comparing them in a thread may be enlightening. I've compared my own to a few others, notably Alp and Grimlock via email conversations.)
Tools that automate features are the most helpful, NESst's importing for example. I'd like a tool that analyzes similar tiles by similarity and frequency, and it looks like one's in the works in the thread currently below.
EDIT: typos
M_Tee wrote:
The image editing software is irrelevant. ... Once you learn the restrictions, self-imposing them is no problem.
I agree with this.
NES Screen Tool is
great for learning how NES backgrounds work, but it's not a very good editor. Loading backgrounds from NES games you want to learn from in it, like FARID is doing there, is also a really good way to learn.
Mostly I work with GIMP. I don't use indexed colours when working, because I like to use transparent layers to guide things or draw on top of reference, etc. Instead of indexed colours, I just have an NES palette open in the colour selector, and more of then than that I just use the eyedropper tool to grab colours from nearby in the image instead (really quick and easy to switch tools with the keyboard once you know the shortcuts). The most important tool is just a 16x16 grid, which generally makes it very easy to see what colours I can put where.
After I'm done working there, I'll migrate the stuff over to an NES specific tool like NES Screen Tool or something else to actually assemble the data. Maybe I'd make some minor tweaks from there, but in general I want to do any major work in a proper art program like GIMP or Aseprite, etc.
rainwarrior wrote:
I don't use indexed colours when working, because I like to use transparent layers to guide things or draw on top of reference, etc.
That's exactly what I mean. While drawing, there are many reasons not to abide by the restrictions of the target platform. I for example like to work on a huge canvas with "snapshots" of the progress of each sprite I draw, and that'd be impossible with only 256 tiles. Another thing I often use is layered sprites, which AFAIK isn't possible in dedicated editors. Layers and transparency are great for drawing pixels over reference images (say, a higher resolution pencil drawing you scanned), or for animating (looking at past and future frames to draw inbetweens). Layers can also help with "rigged" characters, for which you can create different animation frames simply by moving the independent body parts (each one being a different layer). The possibilities are endless as long as the tools are there.
Quote:
Instead of indexed colours, I just have an NES palette open in the colour selector, and more of then than that I just use the eyedropper tool to grab colours from nearby in the image instead
Same here.
Quote:
The most important tool is just a 16x16 grid, which generally makes it very easy to see what colours I can put where.
Yes. Most programs will allow you to freely customize the grid, some even allowing subdivisions, so you could have a 16x16 grid with 8x8s inside them, allowing you to always see the boundaries of tiles and attributes. It should also be possible to use non-square grids, such as 8x16 for tall sprites.
You definitely should be familiar with the limitations of the platform you're making graphics for, but having your tools enforce those limitations all the way is too restricting, and far from ideal for experienced artists.
I think there is some kind of error in NES Screen Tool 2. 04 and I should report it.
When I save screens and then I get them in my test roms, I always lack the color attributes of the lower right corner, and default the 0 palette.
It looks like Embarcadero Starter is $0. Someone here might be able to compile the source code...
https://www.embarcadero.com/products/cb ... -download/I bet this is an "off by one" error.
It's much more likely that problem is in the ROM itself. A lot of people have been using NES Screen Tool for quite a while, so you'd think that that type of a bug would've been caught before.
I never got around to posting about it because I had kind of assumed user error on my part as well, but I've had this same thing happen before. I can't recall all the details off the top of my head, sadly.
thefox wrote:
It's much more likely that problem is in the ROM itself. A lot of people have been using NES Screen Tool for quite a while, so you'd think that that type of a bug would've been caught before.
Well, maybe no one had noticed before.
I have tested on two different rom types (NROM and UNROM), simply loading a stating screen, and the error appears in both.
Diskover wrote:
thefox wrote:
It's much more likely that problem is in the ROM itself. A lot of people have been using NES Screen Tool for quite a while, so you'd think that that type of a bug would've been caught before.
Well, maybe no one had noticed before.
I have tested on two different rom types (NROM and UNROM), simply loading a stating screen, and the error appears in both.
Does the attribute error show up when you load the nametable file back into NES Screen Tool? If not, then the file
can't be probably isn't faulty. If yes, then NST obviously has a bug.
thefox wrote:
Does the attribute error show up when you load the nametable file back into NES Screen Tool? If not, then the file can't be faulty. If yes, then NST obviously has a bug.
When I load the nametable in NES Screen Tool 2.04, it looks fine. When I load the nametable created with NST in a rom, it is when the error appears.
Anyway, that NST looks good, is not guaranteeing us anything, so the test is not worth anything.
I suggest that there is an error in NST when saving the attributes of the nametables.
In fact, as you can see, another user has something like this.
freem wrote:
I never got around to posting about it because I had kind of assumed user error on my part as well, but I've had this same thing happen before. I can't recall all the details off the top of my head, sadly.
Diskover wrote:
Anyway, that NST looks good, is not guaranteeing us anything, so the test is not worth anything.
I suggest that there is an error in NST when saving the attributes of the nametables.
It doesn't
guarantee anything, but if it's able to save and load the data without corruption, it does show that at least it's able to save (and restore) the information in the file in some form. It should be fairly easy to examine the data in a hex editor to figure out what, if anything, is going wrong (look at the last bytes of the nametable file).
Are you using RLE? Maybe the problem is in the vram_unrle function?
na_th_an wrote:
Are you using RLE? Maybe the problem is in the vram_unrle function?
Both Shiru and dougeff, which are practically the same.
Code:
_UnRLE:
tay
stx <RLE_HIGH
lda #0
sta <RLE_LOW
lda (RLE_LOW),y
sta <RLE_TAG
iny
bne @1
inc <RLE_HIGH
@1:
lda (RLE_LOW),y
iny
bne @11
inc <RLE_HIGH
@11:
cmp <RLE_TAG
beq @2
sta $2007
sta <RLE_BYTE
bne @1
@2:
lda (RLE_LOW),y
beq @4
iny
bne @21
inc <RLE_HIGH
@21:
tax
lda <RLE_BYTE
@3:
sta $2007
dex
bne @3
beq @1
@4:
rts
I can confirm that the bug exists. But not in the asm. The tool itself is (sometimes) omitting the last byte of the attribute table, when writing an RLE. It's always the last byte. And it seems to happen if the last byte is different from the previous byte.
I made 4 different nametables (different only in the last attribute table byte). And, 3 of the RLE's were identical (and missing the final byte). The other one only included it because it was part of the 'repeat' from a previous byte.
So this is likely a problem in the RLE encoder, then? I'm surprised it took this long for a bug like this to be noticed, considering how long NST has been around.
I suppose the to down-rightmost attribute cells tend to be the same in most cases?
BTW, you can easily hand edit the RLE to fix this....
The first byte of the RLE = the special 'repeat' code.
0x01,0x00,0x01,0xfe =
0x01, get special code
0x00, print 0 on screen
0x01, 0xfe, and then repeat that '0' 0xfe more times
The RLE ends when repeats are zero...
0x01,0x00, repeat the last byte zero times = exit
I was getting this as the last bytes of 3 RLE's
0x0f,0x01,0x06,0x01,0x00 =
0x0f, print 0x0f on screen
0x01, 0x06 repeat that '0x0f' 6 more times
(missing byte)
0x01,0x00 exit
Insert the last attribute byte there, before the 0x01,0x00
0x0f,0x01,0x06,0x03,0x01,0x00 (version 1 should have been this)
0x0f,0x01,0x06,0x07,0x01,0x00 (version 2 should have been this)
0x0f,0x01,0x06,0x0b,0x01,0x00 (version 3 should have been this)
0x0f,0x01,0x07,0x01,0x00 (version 4 was this, with 0x0f repeated 7 more times)
[on a side note, NES ST changes the value of the 'special' byte, so it can be any value 0-ff, but it will always be the first byte of the RLE. It's called 'RLE_TAG' in the asm.]
dougeff wrote:
[on a side note, NES ST changes the value of the 'special' byte, so it can be any value 0-ff, but it will always be the first byte of the RLE. It's called 'RLE_TAG' in the asm.]
It makes sense to try and minimize the expansion by using the least common tile index to trigger RLE sequences... Hopefully there'll even be a tile that's never used.
The encoder probably buffers a byte before deciding whether it's uncompressed data or the beginning of a run, something it'll only know after looking at next byte, but doesn't have a special case for when there's no next byte to make the decision, so the buffered value gets forgotten. Just guessing.
One workaround is to save the uncompressed nametable as your "source" and compress it during the build process.
So, someone emailed Shiru, right?
tokumaru wrote:
So this is likely a problem in the RLE encoder, then? I'm surprised it took this long for a bug like this to be noticed, considering how long NST has been around.
Maybe no one gave it importance or the tool is not being used as much as we thought.
I'm almost at the end of the development of my homebrew and I'm in that phase of fixing bugs. I've been observing that failure with the colors of the corner from the beginning, but I did not give it importance until yesterday I was given to investigate.
tepples wrote:
One workaround is to save the uncompressed nametable as your "source" and compress it during the build process.
How can I compress while composing? How do I write that?
tokumaru wrote:
So this is likely a problem in the RLE encoder, then? I'm surprised it took this long for a bug like this to be noticed, considering how long NST has been around.
The latest version introduced some new bugs (especially to do with saving and loading NSS files), that have been outstanding for 2 years now.
I personally have used NESST a lot, but I've never touched its RLE feature before. (I have also been using version 2.03 much more than 2.04 because of the save/load bugs.)
Edit: the ZIP on his website has finally been updated! There's a version 2.3 now.calima wrote:
So, someone emailed Shiru, right?
It could be you!
Diskover wrote:
tepples wrote:
One workaround is to save the uncompressed nametable as your "source" and compress it during the build process.
How can I compress while composing? How do I write that?
In general, you'd use a command-line program that turns an uncompressed nametable into a compressed nametable, and have your source depend on the compressed nametable, and have each compressed nametable depend on the corresponding uncompressed nametable.
The details of how to express that depend on what you're using to build your program. Do you use
makefiles? Batch files for CMD, Bash, or PowerShell?
Tup? It also depends to a lesser extent on what assembler you're using, in particular whether it uses object files linked together later (e.g. ca65/ld65) or expects other source files to be added with an include command (e.g. ASM6). For example, if you're using a makefile and object files, it might look like this:
Code:
# Tell how to compress nametables
obj/nes/%.nam.pb53: screens/%.nam
tools/pb53.py $< $@
# Rebuild title.o every time a compressed nametable changes
obj/nes/title.o: obj/nes/title.nam.pb53
Is this the PB53 you (tepples) were talking about?
viewtopic.php?f=22&t=13686
There are several RLE-like formats. PB53 is just the one I used in the Action 53 menu and RHDE.
I (and Diskover, I think) am asking for a specific link to specific code. Is this the code you referenced?
Yes, the PB53 mentioned in the PBJ topic is the PB53 I was referring to, which is the same as
the PB53 described on the wiki. No, PB53 is not identical to PBJ, but PB53's primary compression mode (unary RLE) is reused in PBJ.
Assuming that you are using ca65, GNU Make, and Python (if not, see the README for
my NROM project template for how to install them), all needed code is in the Git repository for
RHDE.
rainwarrior wrote:
calima wrote:
So, someone emailed Shiru, right?
It could be you!
Totally, except I don't use NESST
Folks, Shiru doesn't come here any longer, someone using this mail him.
It would appear the program's been updated recently... latest version is now v2.3, with custom nametable size support. I haven't gotten around to testing if the attribute bug has been fixed, however.
My version here is 2.04, and according to the NTFS data it was last modified Jan. 29, 2015. It doesn't have the RLE attribute bug as far as I can tell.
I'll stay on this version for now
Apparently Shiru uploaded a version 2.3 about 4 days ago.
In the readme changelog there's a 2.1 released a year ago, and 2.2 / 2.21 released a month ago.
For some strange reason I've never seen these versions... I downloaded the ZIP many times, including just 2 weeks ago and that zip still says version 2.04... except it's actually a version from early 2015, and not the version of 2.04 I was used to? I think shiru had maybe been updating it sometimes but forgetting to update the ZIP file on his website, and in some cases forgetting to update the version number or readme file??? This is really bizarre.
Anyhow, new version is out, I guess!!!
I don't know if Shiru still catch up here, but thank you for the update !!
rainwarrior wrote:
Apparently Shiru uploaded a version 2.3 about 4 days ago.
In the readme changelog there's a 2.1 released a year ago, and 2.2 / 2.21 released a month ago.
For some strange reason I've never seen these versions... I downloaded the ZIP many times, including just 2 weeks ago and that zip still says version 2.04... except it's actually a version from early 2015, and not the version of 2.04 I was used to? I think shiru had maybe been updating it sometimes but forgetting to update the ZIP file on his website, and in some cases forgetting to update the version number or readme file??? This is really bizarre.
Anyhow, new version is out, I guess!!!
That was to comment: before I downloaded the zip again and I found a version 2.3 with new features and with the bug fixed, when before had always put the 2.04
Have you updated it and said nothing? Can be.
Somehow I missed rainwarrior's post...
But I saw on Shiru's facebook (Alex Semenov (Shiru)) page that he updated the Screen Tool. 2.3...with
"Basic map editor for large scrollable maps" and "new lossy import feature".
I really never go on Facebook anymore... and only happened upon this post by chance.
I'll have to check it out.
There doesn't seem to be an easy way to set the Map Size. The readme says it can be...
"from 4x4 to 4096x4096" but doesn't say how. The only references in the source code to
"nameTableWidth =" and "nameTableHeight=" are during Opening a map file, and setting a default of 32x30.
??
Edit...you have to click..."Nametable/New Nametable or map" to get the larger (or smaller) map.
dougeff wrote:
Somehow I missed rainwarrior's post...
But I saw on Shiru's facebook (Alex Semenov (Shiru)) page that he updated the Screen Tool. 2.3...with
"Basic map editor for large scrollable maps" and "new lossy import feature".
I really never go on Facebook anymore... and only happened upon this post by chance.
I'll have to check it out.
Can we do scrolling levels in screentool now? I've been looking for something like this.
Nice, did he update his RLE asm code to handle scrolling maps or is it the user's responsibility to account for it?
hawken wrote:
Can we do scrolling levels in screentool now? I've been looking for something like this.
Oh, cool. Yes it does. Scrolling seems to be only with cursor keys. Still only shows a single screen, not an expanded view.
Bug? In Wine so that might cause an issue, but when drawing a stroke of tiles past the edge of the view has some problems when the view edge isn't at the nametable edge.
Top and bottom edges get an alert box saying "Scan line index out of range.".
Left and right edges wrap around the view so the stroke continues from the opposite edge but that part doesn't get saved to the nametable so it disappears when the nametable is scrolled.
surt wrote:
hawken wrote:
Can we do scrolling levels in screentool now? I've been looking for something like this.
Oh, cool. Yes it does.
Enjoying this so far! I can finally make levels in NESst
Have requested a resize function on his facebook.
Punch wrote:
Nice, did he update his RLE asm code to handle scrolling maps or is it the user's responsibility to account for it?
If you choose a user defined Nametable size, you can only save as .map. which is uncompressed.
NOTE TO ALL: Shiru fixed the RLE encoder bug (for regular sized nametables).
See code differences in source code...
Old:
Code:
for(i=0;i<size;i++)
{
if(src[i]!=sym||len==255||i==size-1)
{
if(src[i]==sym&&i==size-1) len++;
if(len) dst[pp++]=sym;
if(len>1)
{
if(len==2)
{
dst[pp++]=sym;
}
else
{
dst[pp++]=tag;
dst[pp++]=len-1;
}
}
sym=src[i];
len=1;
}
else
{
len++;
}
}
New:
Code:
for(i=0;i<size;++i)
{
sym=src[i];
if(sym_prev!=sym||len>=255||i==size-1)
{
if(len>1)
{
if(len==2)
{
dst[ptr++]=sym_prev;
}
else
{
dst[ptr++]=tag;
dst[ptr++]=len-1;
}
}
dst[ptr++]=sym;
sym_prev=sym;
len=1;
}
else
{
++len;
}
}
The current palette set doesn't show the real colors.
Is there anyway to change the display colors?
FARID wrote:
The current palette set doesn't show the real colors.
Is there anyway to change the display colors?
You can edit the palette, by loading the exe in a hex editor and searching for the palette array.
dougeff wrote:
You can edit the palette, by loading the exe in a hex editor and searching for the palette array.
Awesome!
Thanks
It seems that Shiru has re-updated
NES Screen Tool to version 2.32v2.32 03.08.17 - Sprite duplication, group flip, four palette slots, tile density sort, and more
Density sorting - That's interesting! The first use i see is finding tiles with low and/or similar content and test if one is redundant.
But in my mind, this sort of thing could maybe also be a useful/effective preconditioner prior to RLE compression (sorting by optimal lengths of runs are obviously even better, but it can't hurt that 0 heavy content is packed in one end).
This tool is indispensable for my work on Wizard of Wor. Absolutely amazing. Hats off to Shiru for his work on this!
-Thom
I found a bug ...but it's seeded by photoshop. There could be a way to proof NESST, though. Description and workaround below:
Sometimes -in photoshop at least-, when saving images as indexed bitmaps, it silently stores multiple entries of the exact same colour.
NESST will read this as separate colour entries during import and try to 1) squash colour depth, resulting in scrambled/lossy patterns, and 2)
come up with multiple subpalettes to cover.
If you ever find that NESST scrambles your bitmaps/patterns, even though you've been careful to just store 4 indexed colours, here's a workaround:
1. Photoshop > file > export > save for web (legacy)
2. Select GIF. Select either selective or adaptive indexing. This will merge any dupes and solve the problem. There's a bonus feature to this, too.*
3. Save. Open. Re-save as bmp.
4. NESST imports will now work.
It seems the bug originates from using the colour swatch, if the colours of the swatch were picked with the eyedropper tool in another project window, but i haven't tested it extensively.
As for proofing NESST, checking for identical colour entries in index and ignoring the excess entries should work.
========
*As a bonus, the indexing mode will sort your colour entries. Adaptive mode puts the most used colour first, which is usually the bg colour, so that's good for NESST imports.
No need to save to GIF and re-save as BMP, you can convert your images to indexed color prior to saving, and work on them that way, using a fixed palette, without running the risk of using the wrong colors by accident.
You can go to image -> mode -> indexed color to palletize your image, using similar controls to those found in the "save for web" dialog.
That's true. I was working in indexed mode already - Admittedly, it allowed for 12 colours when i first swapped to it, which gave plenty of room for the bug to manifest itself (NESST detected 6 colours + the bg colour, where only 4 were unique). Normally AFAIK in PS, if you allow for more colours than what is used, those excess colours will be discarded when saving, but this is apparently not the case if dupe entries somehow manage to sneak in.
In the save for web dialogue you have a better view of exactly what colours are stored and in what order, which was how i detected what it was that NESST didn't like. But swapping back to rgb and then to indexed once again is quicker, like you said.
I think that if you click on the "forced" drop-down and then on "custom" you can see the color table Photoshop generated for you, and you can manipulate it too.
The thing I think this tool is missing is the possibility of doing MetaTiles for the backgrounds
Shouldn't that be the job of a dedicated map/level editor? Not that i would complain if nesst was expanded in this direction. Just as long as it still would let me reference nametable cells to patterns without forcing the use of metatiles.
Maybe derive a list of metatiles based on the current content of the nametable; ignoring any duplicates? More elaborately, that list could in turn be used internally to feed into a 'stamp' type of tool.
FrankenGraphics wrote:
Maybe derive a list of metatiles based on the current content of the nametable; ignoring any duplicates? More elaborately, that list could in turn be used internally to feed into a 'stamp' type of tool.
That would be great
Hey shiru, i was wondering if you could look into this?
-As of some recent version, NESST saves .chr files as 8kB by default. This causes inconvenience further down the pipe as 95% of the time, the other 4kB is just an empty fill. I was wondering if you could make it so that unless theres some actual content other than a fill on the "B" set, a 4kB file would be defaulted?
The current workaround for this is either
-saving each file separately rather than all three/four at once; which gives the option to set filesize for chr files.
-cut the superfluous 4kB:s in a hex editor
-use ca65 and pass a 4kB range for the .incbin directive (not an option in other assemblers).
-use powershell or bash to cut it in half
So there are options, but adds a step to the process and a bit of required vigilance compared to earlier NESST versions. If an 8kb file gets in by mistake and breaks a boundary, ca65 users will get a warning, asm6 users will see the file assemble silently but it won't run properly.
You are probably going to have to contact him (email) directly.
If I could add a feature, it would be to allow the import graphics lossy to reduce the tile count to a variable # of tiles. Currently it stops removing tiles when it gets to 256, but the save as RLE function doesn't work unless you have at least 1 unused tile, so 255 would make more sense. And I can see situations where I would want to set it to...say 128, maybe.
I'll try that! thanks
dougeff wrote:
Currently it stops removing tiles when it gets to 256, but the save as RLE function doesn't work unless you have at least 1 unused tile, so 255 would make more sense.
For this purpose, i think it is ok to decide for yourself which tile is most redundant, though? Especially with the help of the frequency and density sorter tools that were added in the last version.
My current work-around solution is to insert alphanumeric characters into the blank area of the original image, then import lossy, and then edit out the alphanumeric tiles, leaving them unused. Takes me very little time.
FrankenGraphics wrote:
Hey shiru, i was wondering if you could look into this?
-As of some recent version, NESST saves .chr files as 8kB by default. This causes inconvenience further down the pipe as 95% of the time, the other 4kB is just an empty fill. I was wondering if you could make it so that unless theres some actual content other than a fill on the "B" set, a 4kB file would be defaulted?
The current workaround for this is either
-saving each file separately rather than all three/four at once; which gives the option to set filesize for chr files.
-cut the superfluous 4kB:s in a hex editor
-use ca65 and pass a 4kB range for the .incbin directive (not an option in other assemblers).
-use powershell or bash to cut it in half
So there are options, but adds a step to the process and a bit of required vigilance compared to earlier NESST versions. If an 8kb file gets in by mistake and breaks a boundary, ca65 users will get a warning, asm6 users will see the file assemble silently but it won't run properly.
Am I misunderstanding your request or are we using different versions of NESst?
It looks to me like 4k is default with other options available:
When you All > Save, it saves an 8kB chr file with no options. (But used to save an 4kB file, no options in earlier versions).
When you Chr > Save, it saves your latest used option, + gives you options.
Ah, that'd explain why I hadn't noticed. My workflow doesn't typically have me saving all.
Quote:
Load CHR file with size of 1K, 2K, 4K, 8K, or other size of multiple of 16.
Regardless of this I'm still getting "Wrong file size" error from loading a file of 32k in size.
EDIT: This seems to happen with 16k files as well. This is weird since both of tese are in a multiple of 16.
Attachment:
robin.jpg [ 155.92 KiB | Viewed 8192 times ]
Is it possible to make such special screens with NES Screen Tool.
How?
i don't see anything special about it? Some colours reappear across two subpalettes to make attribute transitions more fluid.
Pattern based graphics editing takes a bit of time getting used to, but NESST is perfectly suited for the job.
Without having the game, i'd assume "press start" and "camerica" is on the sprite layer. A quick glance makes it look like the camerica logo is within 64 pixels.
So you need to make some metasprites and export them as OAM data for your NES program to layer.
SusiKette wrote:
Quote:
Load CHR file with size of 1K, 2K, 4K, 8K, or other size of multiple of 16.
Regardless of this I'm still getting "Wrong file size" error from loading a file of 32k in size.
EDIT: This seems to happen with 16k files as well. This is weird since both of tese are in a multiple of 16.
Did you get it working, susikette? One thing i noticed the other day is that NESST will crop sizes of nametabledata/map files if you open files via the "all" menu. Maps need to be loaded via the "nametable" menu.
Buherman wrote:
Attachment:
robin.jpg
Is it possible to make such special screens with NES Screen Tool.
How?
With patience
FrankenGraphics wrote:
i don't see anything special about it?
...
i'd assume "press start" and "camerica" is on the sprite layer. A quick glance makes it look like the camerica logo is within 64 pixels.
You couldn't actually do this in NESST because the screen is split into two halves to make use of twice as much CHR. (Also, there are three sprites as FrankenGraphics suggests.)
Probably possible to make something similar by simplifying a few details, especially that big tree, but as-is it's not something NESST by itself would handle.
By the way, if there's a background screen you want to transfer from FCEUX to NESST, you can go to the Debug > Hex Editor, and then in there File > Dump to file > PPU Memory. The resulting data can be split up into CHR ($0000-1FFF) nametable ($2000-23FF, or one of the other 3) and palette ($3F00-3F0F) and you can load those into NESST.
...though if you just want to learn how it's made, FCEUX's nametable viewer and PPU viewer are a pretty good start just by themselves. (Mesen and Nintendulator have similar tools for inspection too.)
rainwarior wrote:
FrankenGraphics wrote:
i don't see anything special about it?
...
i'd assume "press start" and "camerica" is on the sprite layer. A quick glance makes it look like the camerica logo is within 64 pixels.
You couldn't actually do this in NESST because the screen is split into two halves to make use of twice as much CHR. (Also, there are three sprites as FrankenGraphics suggests.)
Probably possible to make something similar
about phen375 by simplifying a few details, especially that big tree, but as-is it's not something NESST by itself would handle.
By the way, if there's a background screen you want to transfer from FCEUX to NESST, you can go to the Debug > Hex Editor, and then in there File > Dump to file > PPU Memory. The resulting data can be split up into CHR ($0000-1FFF) nametable ($2000-23FF, or one of the other 3) and palette ($3F00-3F0F) and you can load those into NESST.
...though if you just want to learn how it's made, FCEUX's nametable viewer and PPU viewer are a pretty good start just by themselves. (Mesen and Nintendulator have similar tools for inspection too.)
An extremely convenient component which I've never found in one of these editors previously is the capacity to 'paint' traits/palettes on the nametable. Extremely decent
The title screen to Super Robin Hood actually uses sprites as well as background tiles. Use of sprites means you have some additional colours (overall) available to you. Everything is background tiles except for the CodeMasters logo, the Camerica logo, and the "Press Start" text, which are sprites.
Good looking graphics on the NES are done often by the graphics artist understanding the
NES attribute table design/limitation and knowing how to design a screen that has things appropriately placed to work well with it. Once you learn about it and start to see it (visually) in games, it's hard to unsee.
