OFFICIAL 5.0 SUGGESTION THREAD!

Chasersgaming · Mar 28, 2019

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.
[/quote]

Thanks!

Oh and is there any chance of possible allowing building/paint tiles in an 8 by 8 meta tile way instead of the 16x16 in the future. You would save so much more graphic space as a result I think, currently I’m using a 2 CHR banks and 2 Screen banks with lots of duplications in them using 16x16, and I can only use 1 per screen, using 8x8 would reduce this to 1 CHR bank, allowing for more tiles to be used on one screen, also would this reduce bytes, possible making making way for space for like bank switching, vertical and horizontal scrolling and what ever else that a function may take up more memory. I don’t know, just thought I’d throw that in there whilst I was here.

Goaterby · Mar 28, 2019

An option to have a project utilize 8x8 metatiles instead of 16x16 would open up lots of doors, even if it significantly reduces the overall map space.

RadJunk · Mar 28, 2019

Lots of good ideas!

I'll address some of them.

Anything that you guys might be tossing up as ENGINE improvements (different scrolling! parallaxing! Four player support! Fix this engine feature that is buggy! More modules!) are a whole other conversation. The default underlying engine ostensibly could even take a step BACKWARDS in functionality, while synching up with something a bit more ubiquitous and stable. But the more stable and user friendly we make it, the more YOU can manipulate it in ways (I point to Kevin Skeen's sprite hud or Dale Coop's 2 player engine or Mugi's two way scrolling as examples).

What we're really talking about is the TOOL, and what the front end is capable of.

One thing that seems to be brought up a lot is 8px asset definitions. I can say with certainty that by default, this one will probably never natively be a thing. NESmaker's output is strategically managed and regulated. Screens always spit out the same amount of data. This solves what is probably the single biggest headache for you to have to contend with (bank switching and management craziness). After MUCH time on it, considering that the smallest unit of measure that can really be changed as far as color is a 16x16 unit (that is as fine as you can get it), and our engine uses 16x16 collision blocks (which fit evenly into 8 bit space), 16x16 metatiles are an obvious outgrowth of that, and cut the number of values needed to represent a screen into 1/4. Almost all games use some sort of compression algorithm. That's about as simple as it can get, but that's one way we save space to have as many screens as that can exist. And if you look at the primary NES games...Mario, Zelda, Metroid, Megaman, Castlevania...they all use 16x16px tiles for this exact reason.

But there are some graphical improvements that we DO plan to make.

I appreciate all the suggestions.

Mugi · Mar 28, 2019

I really dont think the 8x8 is THAT important (although it would be cool to have some way to atleast have an option to use them maybe with examples) but the bigger issue at the moment is that the way the chr's are split combined with the 16x16 tile system is just too restrictive as a combination (which is why i instantly broke it

) i really REALLY REALLY hope that the whole matter of being unable to manage hud/path tilespace as normal assets will be addressed because it will be a huge boost in terms of what can be pulled off in terms of graphical fidelity within the limitations of the tool and the engine. (especially when combined with kevin's sprite hud for those who dont want to / know how to make their own sprite huds.)

that said, i do see some reasons for why it was done the way it is, i believe SSchr's (screentiles) were propably meant to be an area allocated for replaceable animated tiles (the tile animator that got removed from the tool loaded screen tiles), and well, maintiles are main tiles, and paths are paths. it's just that it only works for games designed in a certain way, which again is a limitation the tool as a multipurpose game making software should not have. Same goes with the splitting of sprite palettes too, it works, but it works for certain designs and not others.
as a generic tool, the choice should be left for the user, not the software's creator.

TheNew8bitHeroes said:
or Mugi's two way scrolling as examples.

jorotroids core is propably something that should be mentioned more than mine, although they both do the job. (my scroll engine is not public code at this point in time.)

RadJunk · Mar 29, 2019

The other part of it, though, is bit space to provide references for the loader to know what to load where. Every screen needs bytes that populate variables at screen load time to know exactly what to load where. This takes up space.

So then, we start to get into the tug of war...”well, I want to have 8 warps on my screen!”...”I don’t need any warps, but i need paths from three different banks!”...”i want no paths at all, why can’t I just have 6 ‘screen specific tiesets?!”...”Get rid of the screen specific tilesets so i can use that area for lowecase letters!”...”i don’t need text all all because I use the sprite hud, but I need more tiles!”...etc etc etc.

These are incredibly easy to concept out in a tool where the result doesn’t have soul crushing memory limits. But in that case, even making these sorts of defines and the ripple effects they have throught the rest of the engine is brutal. There’s nothing wrong with the idea - it’s a good one. But there is a LOT more to it in how the tool and engine work in tandem. Our goal was to provide a multi purpose vanilla solution.

But yes, we are working on things. But just wanted to express why that’s not as easy or logical in context as it might otherwise sound.

Mugi · Mar 29, 2019

im aware fo this, but as said, the assets already work, they just dont display (well they display garbage) and cannot be created within the tool
i made an external program that allows me to create .nmasset files that have tile coordinates of hud/path tiles, and these work in nesmaker just fine. the issue is literally that they cannot be made, not that they use too much memory or anything of the sort. those tiles are already loaded in, but unless you use them to draw paths, they cannot be used. Why not just let people draw 16x16 metatiles from them ? same with hud.

i would literally be happy to just have the tool be able to actually display the asset, even if it could not create them (i dont really understand why it doesnt even, because the .nmasset file stores a piece of the chr file as a bitmap, and even if you set it correctly, nesmaker just refuses to display it.) The other suggestion i made was to add a toggle button to have the screenpainter not display the paths so that they show up normally as assets.

see the screenshot.

currently metatiles created in the path space look like this in the screen painter, and im assuming what happens here is simply the program being programmed to draw the paths to show up procedurally depending on their placement (my tiles change appearance when i place them next to eachother as they attempt to "path" themselves.) this has literally no effect on the game or the engine (pathing code has been disabled) so the issue is only that they cannot be managed in the UI.

it has nothing to do with the engine at this point so the whole argument of memory management does not apply. simply making it possible to load hudtiles.bmp or pathtiles.bmp to the asset creator and allowing users to make metatiles off them solves this, no engine modifications needed.

the above screen looks like this in-game:

and the asset bmp's look like this

furthermore, this is how it looks in the rom through ppuviewer:

as usch, this is no more than something the UI doesn't display correctly, because it is hardcoded to display the paths as paths. which leads us back to my request of making it possible to display path tiles without them doing the "pathing" process.

i am extremely adamant on getting a solution for this, because the screen painter of nesmaker is by far it's most valuable asset for me, and is alone far worth the software's price in gold. Its completely irreplaceable as a tool and makes design work so much faster it's not even funny. However as it currently stands, its limitations are forcing me to ignore it as using it without being able to see half of your graphics completely destroys its usability.

as an ending note, yes this is an advanced usage of the engine in a non-intended way, but i would like to point out that im far from being the only person to do this. Im just more vocal about ti than most people

dale_coop · Mar 29, 2019

(already said that somewhere but...) I love that Mugi's idea.
Maybe a project option for that (display path tiles without them doing the "pathing" process and same for the hud tilesets).

Something that could be usefull for the future: a NESMaker Preferences window for all the general/default UI/projects settings...

MistSonata · Mar 29, 2019

I think Mugi has a good point. The screen painting tool is easily the most valuable part of NESmaker, and while the tool itself seems to want to be open enough to be fully customizable, the screen painting tool itself seems to be very rigidly confined to only work the way the base modules handle graphics and leave no room for modules that handle graphics code differently.

I'm not saying that the underlying game engine itself has to be able to handle these contingencies in the game engine, in fact I'm kind of saying the opposite. Why not just open the screen painting tool on the TOOL side to be more customizable in how to display graphics and how to export the graphic data, and let the end user worry about how it's going to work in the code? Let the user customize how big metatiles are, how paths work, how big screen data size is, etc and then let them figure out all the memory and coding issues in their own custom module. I feel like this, more than any other feature, would make NESmaker way better to work with. Instead of having to wrestle the screen data away from the tool, the tool could have an option to just get out of the way as best it can.

Basically, don't worry about how you're going to make tool features like this work in the game's engine. Just have the tool export the screen data and then let US worry about how it's going to work.

Mugi · Mar 29, 2019

oh definitely. I am not expecting any ENGINE changes to be made to cater to this. This is specifically something i wish the TOOL would be able to do, and just leave the code management of it for the user.

BinaryLab · Mar 29, 2019

During the contest I tried two thing that didn't pan out in the end (probably because, you know, time). I would be happy just to know if you guys are planning these for the near future, or not.

1) Screen transitions: a minimal option for fade-in/fade-out the pallets would be more than enough. Sometimes the transitions can get very glitchy and distracting. If we want to get fancy, we could do the slow-scroll mode used in Mega Man or Metroid.

2) Demo player: a scripted play through to be used in the intro screen. I tried to implement a table that could be read by a pointer, with two bytes, one for inputs and the other for timer. When the time goes off, I would read the next value and call the appropriate action for that simulated input. It did work, somewhat. What do you think?

3) In-engine sprite priority control. For instance, I might want to draw my player before every other sprite on screen (after sprite 0, of course), or lastly, so it is always on top of the rest. Right now, it is not consistent. I noticed that in the overworld my player appears behind the other objects, while in my only 2 underworld screens the player is drawn above all the other sprites. Having only the "first or last" option in the object properties would go a long way.

BentPawGames · Mar 29, 2019

Having the proper pixel editor for editing paths while being able to see the path layout in preview would be amazing . Right now i edit paths by clicking the edit button on the paths screen but 1) it doesnt have any features including undo, and 2) it is buggy and sometimes starts undoing the stuff I draw seconds after I draw it

BentPawGames · Mar 30, 2019

One other thing that came to mind: Sometimes when making changes in the pixel editor, they can be really slow to update when you go to use it to create new assets (e.g., draw something in pixel editor, then go to the asset creator, and the changes do not appear. Sometimes it takes a few seconds. Sometimes loading and reloading several times seems to do the trick. Other times it just never appears and you have to restart the program).

TakuikaNinja · Mar 31, 2019

(Not sure if it's mentioned here yet...)
I don't have the software, but I've heard NESMaker bugs out when you try to preview music imported via asm(using the GGsound converter).
It would be very nice to see that fixed.

Mossy · Mar 31, 2019

Number one thing i want to see would DEFINITELY be 8x8 Tiles and game objects.

n8bit · Apr 1, 2019

TakuikaNinja said:
(Not sure if it's mentioned here yet...)
I don't have the software, but I've heard NESMaker bugs out when you try to preview music imported via asm(using the GGsound converter).
It would be very nice to see that fixed.

Here is the details on the error you get when trying to play/click on music or sounds imported from famitracker/GGSound converted asm files...

Code:

See the end of this message for details on invoking 
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: index
   at System.ThrowHelper.ThrowArgumentOutOfRangeException(ExceptionArgument argument, ExceptionResource resource)
   at MysticSearchesTool.SongPlayerControl.Init(Int32 soundID, Boolean isSong)
   at MysticSearchesTool.MysticSearchToolMainDialog.HandleSongNode(TreeNode node)
   at MysticSearchesTool.MysticSearchToolMainDialog.tvProjectTree_AfterSelect(Object sender, TreeViewEventArgs e)
   at System.Windows.Forms.TreeView.OnAfterSelect(TreeViewEventArgs e)
   at System.Windows.Forms.TreeView.TvnSelected(NMTREEVIEW* nmtv)
   at System.Windows.Forms.TreeView.WmNotify(Message& m)
   at System.Windows.Forms.TreeView.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Loaded Assemblies **************
mscorlib
    Assembly Version: 4.0.0.0
    Win32 Version: 4.7.3362.0 built by: NET472REL1LAST_C
    CodeBase: file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/mscorlib.dll
----------------------------------------
NESMaker
    Assembly Version: 1.0.0.0
    Win32 Version: 1.0.0.0
    CodeBase: file:///C:/NESmaker_4_1_0_GOOD/NESMaker.exe
----------------------------------------
System.Windows.Forms
    Assembly Version: 4.0.0.0
    Win32 Version: 4.7.3324.0 built by: NET472REL1LAST_C
    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System
    Assembly Version: 4.0.0.0
    Win32 Version: 4.7.3362.0 built by: NET472REL1LAST_C
    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
    Assembly Version: 4.0.0.0
    Win32 Version: 4.7.3056.0 built by: NET472REL1
    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
NesMakerPluginBase
    Assembly Version: 1.0.0.0
    Win32 Version: 1.0.0.0
    CodeBase: file:///C:/NESmaker_4_1_0_GOOD/NesMakerPluginBase.DLL
----------------------------------------
System.Xml.Linq
    Assembly Version: 4.0.0.0
    Win32 Version: 4.7.3056.0 built by: NET472REL1
    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Xml.Linq/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.Linq.dll
----------------------------------------
System.Core
    Assembly Version: 4.0.0.0
    Win32 Version: 4.7.3362.0 built by: NET472REL1LAST_C
    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll
----------------------------------------
System.Xml
    Assembly Version: 4.0.0.0
    Win32 Version: 4.7.3056.0 built by: NET472REL1
    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------
System.Configuration
    Assembly Version: 4.0.0.0
    Win32 Version: 4.7.3056.0 built by: NET472REL1
    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
----------------------------------------
System.ComponentModel.Composition
    Assembly Version: 4.0.0.0
    Win32 Version: 4.7.3056.0
    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.ComponentModel.Composition/v4.0_4.0.0.0__b77a5c561934e089/System.ComponentModel.Composition.dll
----------------------------------------
IcarusHUDInterface
    Assembly Version: 1.0.0.0
    Win32 Version: 1.0.0.0
    CodeBase: file:///C:/NESMAKER_4_1_0_GOOD/PLUGINS/ICARUSHUDINTERFACE.DLL
----------------------------------------
UtilityPlugin
    Assembly Version: 1.0.0.0
    Win32 Version: 1.0.0.0
    CodeBase: file:///C:/NESMAKER_4_1_0_GOOD/PLUGINS/UTILITYPLUGIN.DLL
----------------------------------------
NAudio
    Assembly Version: 1.8.4.0
    Win32 Version: 1.8.4.0
    CodeBase: file:///C:/NESmaker_4_1_0_GOOD/NAudio.DLL
----------------------------------------
System.Net.Http
    Assembly Version: 4.0.0.0
    Win32 Version: 4.7.3056.0 built by: NET472REL1
    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Net.Http/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Net.Http.dll
----------------------------------------
MetadataViewProxies_814bd141-ae7f-4349-ac48-c82abf15c473
    Assembly Version: 0.0.0.0
    Win32 Version: 4.7.3056.0
    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.ComponentModel.Composition/v4.0_4.0.0.0__b77a5c561934e089/System.ComponentModel.Composition.dll
----------------------------------------
Accessibility
    Assembly Version: 4.0.0.0
    Win32 Version: 4.7.3056.0 built by: NET472REL1
    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/Accessibility/v4.0_4.0.0.0__b03f5f7f11d50a3a/Accessibility.dll
----------------------------------------
FastColoredTextBox
    Assembly Version: 2.16.21.0
    Win32 Version: 2.16.21.0
    CodeBase: file:///C:/NESmaker_4_1_0_GOOD/FastColoredTextBox.DLL
----------------------------------------

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

<configuration>
    <system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.

Mugi · Apr 1, 2019

oh yeah, in addition to what i listed earlier, one more thing reagarding the graphics that would be really neat to have and would also contribute to the flexibility of the tool itself.

please make the CHR building dynamic based on the contents of the graphicsAssets folder instead of being hardcoded to the current default setup.
i've added several CHR files to the engine and i keep BMP's of them in the folder for my own mental sanity, but nesmaker does not compile them during game building, and instead they have to be manually compiled into CHR files and placed
in their appropriate folders to work. It's not really hard because nesmaker already contains a hefty "export CHR file" button, but making the tool automatically create chr's of all the bmp's inside the graphicassets folder would just save extra steps
for people who are modifying the graphics layouts of the engine.

RadJunk · Apr 2, 2019

Noting every suggestion. As explained in previous responses...all great ideas. Some trickier than others. Some, already in motion. Some, simply impossible within the thing that we're doing. But we are hearing all of you

dale_coop · Apr 2, 2019

Ok, Can I add another one (an easy one):

In the "Input Editor", when you want to remove some scripts your assigned (by mistake, the wrong ones), would be great to have the multi-selection ( multi-select -> right-click -> remove -> happy dale

)
(And maybe same in the "Scripts > input scripts")

illuzio571 · Apr 3, 2019

As a colorblind person, this would help me immensely:

Changing the names on the Color Picker. Currently, they use names that I don't recognize as colors at all (like Olive or Magenta) simply because I can't tell the difference between some of them.

Would it be possible to either:
A. Change the names fully just by default (some people may not like that the colors aren't as accurate)
B. Change them when a colorblind mode is turned on somewhere, be it on the Color Picker itself (just a checkbox) or in the settings.

The names for colors I would suggest were given to me by my girlfriend who understands my colorblindness very well (Deuteranopia)

x0 = Grey
x1 = Blue
x2 = Blue / Purple
x3 = Purple
x4 = Purple / Pink
x5 = Pink
x6 = Red
x7 = Orange
x8 = Yellow
x9 = Yellow / Green
xA = Green
xB = Green / Teal
xC = Teal

This really helps as it makes it more of a written down gradient. The palette itself is already a visible gradient, but as a colorblind person I can't tell you where a green is versus a red versus a yellow.

dale_coop · Apr 3, 2019

illuzio571 said:
As a colorblind person, this would help me immensely:

Changing the names on the Color Picker. Currently, they use names that I don't recognize as colors at all (like Olive or Magenta) simply because I can't tell the difference between some of them.

Would it be possible to either:
A. Change the names fully just by default (some people may not like that the colors aren't as accurate)
B. Change them when a colorblind mode is turned on somewhere, be it on the Color Picker itself (just a checkbox) or in the settings.

The names for colors I would suggest were given to me by my girlfriend who understands my colorblindness very well (Deuteranopia)

x0 = Grey
x1 = Blue
x2 = Blue / Purple
x3 = Purple
x4 = Purple / Pink
x5 = Pink
x6 = Red
x7 = Orange
x8 = Yellow
x9 = Yellow / Green
xA = Green
xB = Green / Teal
xC = Teal

This really helps as it makes it more of a written down gradient. The palette itself is already a visible gradient, but as a colorblind person I can't tell you where a green is versus a red versus a yellow.

This is already customtizable... just open the "GraphicAssetList.xml" in a notepad and around the end of the file, you will see the colors names... just change it like you want

OFFICIAL 5.0 SUGGESTION THREAD!

New member

Member

Administrator

Member

Administrator

Member

Moderator

Moderator

Member

New member

Member

Member

Active member

New member

Member

Member

Administrator

Moderator

New member

Moderator