OFFICIAL 5.0 SUGGESTION THREAD!

[codingkid01]

5) Different scrolling styles, continuous ( basically mario style scrolling) and fixed (zelda style where the screen stops and then scrolls to the next one.
6) Vertical and diagonal scrolling (diagonal like in smb3)

 

[Raftronaut]

My other suggestions are for the pixel editor. First, I find I keep discovering errors in my pixel art, which is admittedly
my own fault, but due to the fact the pixel editor defaults to the pencil, while opening and closing CHR files
I'll accidentally click on the frame and leave a black pencil dot. I'll only notice these errors when I spot them in my game,
But they could be avoided altogether if nesmaker would allow you to choose your defaul tool in pixel editor. Or setting it to
the selection tool would be a huge improvement for me personally in reducing those accidents.

Second, is in regards to mirroring or tile rotation. I understand the nes cannot rotate or to flip background tiles, but the ability
to copy an 8x8 tile, rotate it or mirror it and paste it in a blank 8x8 area would be very helpful.
Rather than having to redraw the tiles in a different position one by one

 

[RadJunk]

@CodingKing - those are engine issues. Not likely to see us create a diagonal scrolling (8 way scrolling) solution...we'd have to rip apart to much of the code to get it to work (massive memory hog), though a lot of infrastructure is there for someone else to do that very thing. Scrolling on the NES is one of the most challenging things to get right. Adding front end support makes it exponentially more difficult!

@Raftronaut - you can flip in the pixel editor now with H or V when you have an area selected! I'll see about rotating.

 

[Kasumi]

@ Kasumi - good ideas, as expected I think I intentionally forced people into sprite 0 learning because of that exact reason...so when they resized the HUD, and it broke THEN, or didn't have any graphics loaded, they'd have to learn why. But I do see the point. And maybe the solution for starting module is that "none" is still some sort of functional base.

Imagine if, when they resized the HUD, the program moved sprite zero too.

When it breaks, they'll always have to learn why, but you can keep it from breaking in lots of ways without them learning. And while you've said not to mention engine things, it's even possible to keep sprite zero from totally freezing the game, even if it never hits. (Which I'd be on the fence about suggesting doing, because it's one thing that can make what is a problem look like it's not one. But on the other hand, it can catch a mistake at runtime in an otherwise robust game.)

"none" doesn't need to be functional. It can be removed from the list, or it can be not the default and both are easier than making it functional and solve the problem.

 

[RadJunk]

@Kasumi - right...you're seeing some of the catch 22s here. Sure, you could resize the hud, and move sprite zero. But what if they don't have a corner graphic for their hud, and want to use a different background graphic (like Mario, with the coin in the middle-center)? Resizing the hud won't automatically move that background graphic, which means that repositioning the sprite 0 automatically to "the new bottom" would be problematic as it would never see a hit, since the background graphic did not move, but the sprite did. These are exactly the sort of WYSIWYG concepts that keep me up at night pondering about ways to best handle.

Appreciate all your input, as always

 

[Kasumi]

There's no catch. If the user does absolutely anything with absolutely any graphic, and absolutely any resize, and absolutely any HUD size the program can place the sprite on the lowest opaque pixel of the HUD by default. (And if there are no opaque pixels at all, the program can detect this too.) (It can still freeze if the sprite itself is transparent, and an index for the monster tiles is chosen since those are variable, but using a monster index can be warned about too.) Going even further, if there's not an opaque pixel in the bottom row of tiles, that can be warned about. (Because they probably want scrolling to stop for that row of tiles if they resized their hud that way.) Any catch you can think of, well, make the program catch it if possible. I believe it is possible here. I believe it is worth doing here. I'd rather have someone ask why their HUD looks different than why their game freezes.

An advanced user can turn off this default. I'm vocal on this point primarily because it freezes the game. Most other mistakes don't do this. (Except a speed of zero makes the game appear frozen, which is why I also mentioned that.)

The tool could help a lot more with this, even if it's not these specific things. Another suggestion is to give a warning about CPU usage if the HUD is low. (I'm not sure how low it should be to trigger the warning. Maybe 120 pixels.) You could also display how much CPU the wait for the HUD will use at all times. I'll try to think of more UI things the program could help with. I think you'll save yourself a decent amount of support time with changes of this sort.

 

[RadJunk]

All not bad ideas, though it still seems like even with those warnings, understanding of what sprite 0 is and how it works would be necessary to understand the warning or know how to fix it. I think, though, that there absolutely could be a warning if sprite 0 has no tile under it. Maybe if that warning occurs, it does just skip the sprite zero check. That's easy enough - even something as simple as it forcing the "use sprite zero" flag to uncheck on compile if that error occurs. That might be at least a way to handle it.

 

[chronicleroflegends]

I think this would be with the tool and not the engine but here are my suggestions:

There are some things in the tool which are still not 'hooked up' that cause a bit of a headache when you don't realize at first they are not functional.

Specifically: Text end actions after the default included ones. You CAN customize them, but they do not seem to actually link up and cause compilation errors. I had to replace one of the already existing text actions to get my custom code working.

Also the Enemy Hurt reactions. They exist in the interface but they don't actually do anything.

I am sure there are other things as well, but the things that exist in the interface but don't actually work yet would be my vote.

 

[saturdayxiii]

Hey, I just noticed that the Facebook thread was actually a link to here. wopps.

Anyway, more zooming options on the overworld/underworld map would be appreciated. For me the full screen is still too small and the "big map" is too big. Big map also scrolls to the top left every time I click on a screen. So I have to leave Big Map if I want to edit more than the first couple columns of the first couple rows.

 

[acoostix]

I'm really sorry if this is a duplicate request.

What I would love to see is to have the tool reworked for a team environment. Right now it is relatively easy for an artist and sound person to work independently, but the person doing level design also has to be responsible for like... everything else.

It would be super cool if there were separate date files / project files for level design, for game objects, etc.... so that you could have multiple team members working on the same project with source control. A version of this may be possible already, but not from what I can see (to be fair, I didn't look to hard, just know that there is one project file that seems to store the games "guts".)

Honestly - tool is great, this is just somethign that would be really useful to me.

 

[mongolianmisfit]

I would like to see decimal increments for things like gravity, etc. I would think this is possible, no?

 

[MistSonata]

I discussed this with Josh a while ago, but I'd like to post it here too just in case...

I'd like to see a feature for advanced users where you can make graphic assets with custom defined hex values. Basically instead of being represented in the tool by graphics you've loaded into your game from whatever bank, they'd just be displayed as the hex number that will be put into that screen's data (maybe lock it off in a "show advanced options" thing so beginners won't mess with it?). Right now, the way the tool outputs screen data, it can only export little more than 1/8th of the available hex values, and if you want to use something like a custom path system, or place a 16x16 graphic from the HUD/Path tiles on your screen, you have to manually decouple that screen's data from the compiled output and edit it manually in a text editor.

It doesn't need to be fancy, I just want to be able to create an asset that will output "$A3" in whatever space I paint it in, if that makes sense.

I would like to see decimal increments for things like gravity, etc. I would think this is possible, no?

You would think that you could do decimals in hexadecimal, but I'm afraid that's not how it works. More granularity in settings such as gravity would be nice, but it often takes more programming space to process, so you can't exactly do it for everything.

 

[dale_coop]

For the GRAVITY settings... you have two user constants: GRAVITY_HI and GRAVITY_LO
You could say that GRAVITY_HI is your gravity units and "GRAVITY_LO" is the for the decimals...
You go can go very precisely with those.

 

[Retrobuster]

I'm really sorry if this is a duplicate request.

What I would love to see is to have the tool reworked for a team environment. Right now it is relatively easy for an artist and sound person to work independently, but the person doing level design also has to be responsible for like... everything else.

It would be super cool if there were separate date files / project files for level design, for game objects, etc.... so that you could have multiple team members working on the same project with source control. A version of this may be possible already, but not from what I can see (to be fair, I didn't look to hard, just know that there is one project file that seems to store the games "guts".)

Honestly - tool is great, this is just somethign that would be really useful to me.

I haven't attempted this myself so not sure how efficient it would be, but you can export zips of all kinds of individual parts - like monsters, pallettes, game objects, the overworld/underworld maps, assets, etc so IN THEORY, one person could work on designing the map while another person is working on the game objects. Then they export those in their separate zips and one person just imports that stuff into a '"master" project. So it's KIND OF like what you're saying, I think.

 

[digit2600]

Oooh.. can you guys fix that 8 key, it corrupts collision tables..

 

[Pauldalyjr]

Angled collisions. Would work great for stairs, ramps, etc.

 

[Chasersgaming]

I would like to see the colour attributions be decided in the room screen, not define it all prior to room placement. Like create the room using the tiles sets in the RBG values, then like placing a tile, place the colour attribution information. Much more easier and more user friendly I think. Just my thoughts.

 

[mongolianmisfit]

Parallax and screen shake as built in options would be amazing.

 

[AllDarnDavey]

I'd like to see more modules and 20 min project videos. Maybe improved 2 way and/or vertical scrolling options. A module that lets you switch between vertical and horizontal 2 way scrolling metriod style would rock. Perhaps maybe, a module that lets you exit the left side of the screen and warp in from the right side pac-man or kid ikarus style.

Animated tiles, animated palettes, palette fading.

A way to paint collision values.

An option to use the path tiles as another set of normal tiles.

The ability to make custom metatiles from 8x8 sections (like for objects) would be nice, or at the very least let us start a 16x16 meta tile square from an odd offset so we can design 16x16 metatiles that overlap CHR data.

It would be nice if objects and monsters shared a pool of 4 palettes instead of 2 separate palette sets. Normally having the player and enemies share a palette would save you palette space, now that would just be a waste with 2 duplicate palettes loaded.

It would be nice if I could export and import individual palettes to a txt file instead of only copy and pasting or exporting all palettes.

Some quality of life improvements like some duplicate ways to access some features. Right now you can only paint paths or override background pallets with a keyboard shortcut, and while they work great, if you don't know about them you'd have no idea they exist, having those also exist in a button, drop down menu, or right click option would be nice. For instance I had no idea the Pixel Editor let you flip a selection horizontal or vertically with the H or V key until I read it a few minutes ago (I must have missed that video).

 

[dale_coop]

I would like to see the colour attributions be decided in the room screen, not define it all prior to room placement. Like create the room using the tiles sets in the RBG values, then like placing a tile, place the colour attribution information. Much more easier and more user friendly I think. Just my thoughts.

You can use the Q, W, E and R key shortcuts for that
And if you want paint with collision data only (not drawing the graphics of a selected tile), use the 7 key... (easier than the right click thing).

Never use the 8... it’s bad.