4.5 Bug List

TurtleRescueNES

Active member
Maybe this can be absorbed into a master bug list thread, but wanted to share a couple of odd behaviors here.

1) Compiled game does not use the background color (0 color) from the screen palette, rather the player palette. So if you design your screen to use black as the 0 color, but have your sprite's 0 color to blue, the compiled game will use blue.

2) Tile drawing, at at least using the two mains no HUD, doesn't work when you use the higher numbered tilesets, like the ones that would have been in the third bank in 4.1.5. When trying to paint with tiles from the second main tileset, it uses the wrong tiles, usually from the other first tileset.
 

Craigery

Active member
When using a double main tile layout, in some instances it doesn't read the second main tile set when you try to paint on your screen, it will instead use only 1 of the tile sets. It has something to do with using tile set 05-17 in the second slot.
 

RadJunk

Administrator
Staff member
@Jsherman - #1 is not a bug. ALL background tiles (0 values) will be the same, and generally, they'll be the same as the last "zero" value that is loaded. So...if your game loads tiles pals first, then sprites, you'll end up with the sprite 0 color. So that's an expected behavior.

However, #2 is troublesome! I will look into that with Josh. Have you tried, btw, to run the game? Does it use the wrong tiles? Or does the ROM create the correct tiles while the tool shows the wrong ones?
 

Jonny

Well-known member
I don't know if this is a bug or just a missing script but if I try to use the new Tile Layout feature with anything that includes HALF paths or NORMAL-NO HUD, I get a completely transparent colour background. I had it working at one point, maybe when I was using 4.5.1 not 4.5.2 ?
 

fluidImages

New member
TheNew8bitHeroes said:
@Jsherman - #1 is not a bug. ALL background tiles (0 values) will be the same, and generally, they'll be the same as the last "zero" value that is loaded. So...if your game loads tiles pals first, then sprites, you'll end up with the sprite 0 color. So that's an expected behavior.

I am having a similar experience - but certainly could be doing something wrong, and I am not sure where you load or tell it to load things in a specific order.

I have a simple game using the following pallet settings:
zero is 1B
one is 29
two is 19
three is 09

(four shades of green)

I have just painted the screen - nothing else on it...
but when I run it.. the background is black - not the 1b. (which is what I would expect)

Sean
 

fluidImages

New member
fluidImages said:
TheNew8bitHeroes said:
@Jsherman - #1 is not a bug. ALL background tiles (0 values) will be the same, and generally, they'll be the same as the last "zero" value that is loaded. So...if your game loads tiles pals first, then sprites, you'll end up with the sprite 0 color. So that's an expected behavior.

I am having a similar experience - but certainly could be doing something wrong, and I am not sure where you load or tell it to load things in a specific order.

I have a simple game using the following pallet settings:
zero is 1B
one is 29
two is 19
three is 09

(four shades of green)

I have just painted the screen - nothing else on it...
but when I run it.. the background is black - not the 1b. (which is what I would expect)

Sean

It does not appear to have this functionality in 4.1.5 - and functions as expected.
 

Jonny

Well-known member
jsherman said:
2) Tile drawing, at at least using the two mains no HUD, doesn't work when you use the higher numbered tilesets, like the ones that would have been in the third bank in 4.1.5. When trying to paint with tiles from the second main tileset, it uses the wrong tiles, usually from the other first tileset.

I got this too but I was trying to use a main tileset from bank1 and screen tiles from bank2. I made sure I was using from the same bank but I didn't try using exclusively tilesets from higher banks. I would have just continued my game with 4.1 but the added tiles were too tempting lol, I just can't seem to get it to work even if I'm using sets from the first bank. Just a blank screen, as explained above.

I think I'll just work through the new tutorials and my graphics until its out of beta because I can't be sure its not something stupid that im doing wrong. Doesn't seem like anyones getting the same problem of blank screen when using tilesets in the same bank, or maybe not many people have tried the new tile layouts yet.
 

fluidImages

New member
I was able to get it to work as I wanted by just flipping colors 0 and 3.

It did behave differently than the early build - but did not take long to modify to function properly.
 

dale_coop

Moderator
Staff member
fluidImages said:
I was able to get it to work as I wanted by just flipping colors 0 and 3.

It did behave differently than the early build - but did not take long to modify to function properly.

This is a topic about the 4.5 version.
If you are using the 4.1.5, it's a complete different version. Doesn't work the same way, don't use the same core engine and don't have the same bugs and issues.

Make sure to always specify the version you are using when you have issue.
 

fluidImages

New member
Dale,

This is about 4.5. However, just to ensure that I was performing something that I expected, I also tested the behavior in a version where I knew the expected result to validate it.

Sean
 

fluidImages

New member
Are paths not implemented in 4.5 in the compile? I have a path that looks wonderful in the editor - however after the compile, it just shows the top portion of the path every section.

Sean
 

mouse spirit

Well-known member
Firstly, thank you joe and anyone who helped for this update.Now on to things i noticed. Bugs or oversights n stuff that may be on purpose or because of a limitation, so please excuse
me if i am incorrect.I figure better said than not fixed if possible.

I noticed that the program holds on to clicks, specifically in the map screen.Meaning, i click once,move the mouse and whatever,but then click one more time and it enters the screen i chose.Feels like it may miss my second click half the time and so i noticed this happening alot.
I did noticed that copying and pasting a screen works better,but all around there is something strange about mouse clicks in general.

When i start the game,after my title screen, my character graphics are garbled for a few seconds then looks right(if i immediatley press start after my rom loads up at the start screen,its fine), also in the bottom right corner,one tilegraphic doesnt look right.Also my characters top right of his face is messed up,this only happens on my first stage screen and only 1 of 7 times upon entering the screen.The bottom right graphic happens 6 out of 7 times.I am using the FCEuX emulator.

My screen was not showing edits ingame.I did copy and paste it from another screen.Half of my edits show in game.Maybe it was just slow at adding my edits because
on the 5th export and test it worked.
I did make sure to save my rom and click off of stuff to maybe lock in my edits also, like i said just ended up working.


Still cant delete a Path Info path.

If i make a new asset, i cant tell it saves if the folder isnt expanded and so i keep hitting the button and create 10 of the same asset.Maybe it should then move to the newly made asset, maybe not so much a bug.

Can't see the rectangle i am drawing in HUD mode when grids are on.

Some buttons say OK and some say Close and some say Save but seem to be the same.Maybe just "save" would be less confusing.
Also close should be on every tab of project settings, not just the first one unless of course it only "saves" the first tab.

Sometimes palettes act funky between "work spaces". Like they don't match up untill i repick the same colors,even if i am looking at the colors i just saved in a palette, the sprite will show the "old colors".Like i said, untill i "re affirm "those colors. To be clear, the palette says one thing, the sprite shows another for the same exact palette and i am looking at both at the same time.Im not sure maybe i am mistaken.

The test and export button should probly not be near any other buttons...

I was pumped about this update, but i live in a cabin with no wifi.So i used my phone to download 4.5..No log in, no access code. Just downloaded on my phone and used an sd adapter to use on my laptop.Am i using a full version?
Fyi i did most certainly pay for 4.1.5.Just saying that it seemed like i just downloded it for free no problems.Maybe since the older version was on my laptop the program was instantly unlocked.Just thought i should mention it.

Also thank you to dale_coop, in general.

ps.Crabs are still unlocking my doors.Jk but for real. :evil:

Heres are pics of my graphic errors.One pic has zero errors to compare.
sdvfdsvsd.png
gamesacdfasf.png
gameasasf.png
gameasdasf.png
 

chronosv2

New member
I can confirm the strangeness with high-detail screens.
Apologies in advance for how this is written, I decided to do all my poking about while I was writing this so it was written over a period of time.

I've been quietly poking at 4.5 on my end (not quite ready to announce that I'm back yet) but the 8×8 tile screens also seem to exhibit this behavior with the 'Main & Screen × 3' tiles mode.
I've left Main set to Tileset00, Screen 1 is Tileset_Screen_28, Screen 2 and 3 are Tileset_Screen_29 (just for testing purposes, duplicating a tileset is obviously unnecessary).

Main draws just fine.
Screen 1 draws just fine.
Screen 2 draws Screen 1
Screen 3 draws Screen 1.
Looks like the Tile IDs don't match up, either: Tried to draw a blank tile with 0xBF and I see in the Tile ID indicator is 0x7F.
If I had to wager a guess I think the tile types with duplicates are pulling their Tile IDs from the first of the set when the tilesets are pulled from entries beyond a certain point.

In Main×2 it's Tileset06 and higher on Main Group 2.
In Main & Screen × 3 it seems to behave very oddly:
When the tiles start pulling from Group 1 depends entirely on what 2 and 3 are set to.
All I can say is to try and set Groups 2 and 3 to different values, then watch the tile IDs you start painting.

Upon a little further testing (started to make a spreadsheet to test each value, which in hindsight might be crazy since there's 24389 combinations in 29×29×29) I may have a hypothesis. Are tileset IDs being checked for duplicates?
I started down the line:
Tried image IDs 0,0,0 and tried placing down the bottom left tile in each set (0x70, 0x90, 0xB0) and all three placed 0x70.
Changed image IDs to 0,0,1 and got 0x70, 0x70, 0xB0.
Changed image IDs to 0,0,2 and got the same.
Then decided to try 0,1,0 and got 0x70, 0x90, 0x70.
And then tried 0,1,1 and got 0x70, 0x90, 0x90.

So it feels like there's some duplicate checking that might be going on?
And maybe that duplicate checking is triggering on combinations with high tileset IDs?

Hopefully this helps track down that particular issue.
 

Rob Burrito

New member
i can't seem to get the autotext tile to trigger the screen within the tool.
in text edit, when the selected text is set to: End of text action/NPC is trigger, when testing the tile works, but after displaying the correct message it loads the first message registered (in this case from the first tutorial NPC text).
it does this even when day triggered text groups are updated too, so it's not just refreshing the autotext tile on the new screen.
guessing it's not triggering the screen state as intended, and something is telling it to display text #$00 at the end of text state.
*also if the first entry of text is set to 'NPC is trigger', the text box will loop indefinitely. so all it's doing when set to trigger is to display the first possible line of text again.
guessing it's something in Base 4_5/Game/Subroutines/doDrawText between lines 103-126, but not exactly sure where it's going wrong.
 

Craigery

Active member
TheNew8bitHeroes said:
However, #2 is troublesome! I will look into that with Josh. Have you tried, btw, to run the game? Does it use the wrong tiles? Or does the ROM create the correct tiles while the tool shows the wrong ones?

It doesn't display in the tool correctly or compile correctly. It will display what is in Main Tileset 1 regardless of which you dragged the tile from.

However, I just tried making an Asset then dragging that in displays properly, but ingame it is off.

uc
 

AllDarnDavey

Active member
TheNew8bitHeroes said:
@Jsherman - #1 is not a bug. ALL background tiles (0 values) will be the same, and generally, they'll be the same as the last "zero" value that is loaded. So...if your game loads tiles pals first, then sprites, you'll end up with the sprite 0 color. So that's an expected behavior.

I'm with the other guys on this one, I'm not sure this should be intended behavior. For one, it's not how the functionality worked in previous versions, and it's not how it previews when screen painting in 4.5 either.

We tend to think of NES games as having 2 layers, a background layer using 4 color palette sets (well 3 color and a single shared color), and a sprite layer using 3 color + transparent palette sets. But really, we have 3 layers. A layer that's a single solid color with no tile artwork (the clear color), the background layer with tiles consisting of palettes of 3 colors and an invisible 0 color letting that clear color through (this is why they all share that color, because it's technically not part of the background layer, but the layer behind it), and then the sprite layer which also uses palettes with 3 colors and a invisible 0 color letting layers behind it show through. If you ever used walk behind tiles, you'll notice it makes the player sprite go behind the background layer tiles, but not that shared clear color layer.

I guess it doesn't matter if the game grabs the clear color from background palettes or monster palettes, but it makes more sense if it comes from the set of background palettes. If I were making my own Super Mario type game and I had an above ground that I want a sky blue for the shared clear color, but when I go down a pipe I want black for the shared clear color, it would feel weird that I'd have to assign a different monster palette set for that switch, instead of that clear color coming from different background palettes.

I mean we have plenty of monster palettes to work with, so we could work that way, but not only is it different then before, but it feels less intuitive to load that clear color from monster palettes, most people already think of that clear color as part of the background tiles, no one thinks of it as part of objects. So unless there's a compelling reason for it (like it's easier to do fades or day/night transitions or something), I don't know why you'd change it.
 

dale_coop

Moderator
Staff member
AllDarnDavey said:
TheNew8bitHeroes said:
@Jsherman - #1 is not a bug. ALL background tiles (0 values) will be the same, and generally, they'll be the same as the last "zero" value that is loaded. So...if your game loads tiles pals first, then sprites, you'll end up with the sprite 0 color. So that's an expected behavior.

I'm with the other guys on this one, I'm not sure this should be intended behavior. For one, it's not how the functionality worked in previous versions, and it's not how it previews when screen painting in 4.5 either.

We tend to think of NES games as having 2 layers, a background layer using 4 color palette sets (well 3 color and a single shared color), and a sprite layer using 3 color + transparent palette sets. But really, we have 3 layers. A layer that's a single solid color with no tile artwork (the clear color), the background layer with tiles consisting of palettes of 3 colors and an invisible 0 color letting that clear color through (this is why they all share that color, because it's technically not part of the background layer, but the layer behind it), and then the sprite layer which also uses palettes with 3 colors and a invisible 0 color letting layers behind it show through. If you ever used walk behind tiles, you'll notice it makes the player sprite go behind the background layer tiles, but not that shared clear color layer.

I guess it doesn't matter if the game grabs the clear color from background palettes or monster palettes, but it makes more sense if it comes from the set of background palettes. If I were making my own Super Mario type game and I had an above ground that I want a sky blue for the shared clear color, but when I go down a pipe I want black for the shared clear color, it would feel weird that I'd have to assign a different monster palette set for that switch, instead of that clear color coming from different background palettes.

I mean we have plenty of monster palettes to work with, so we could work that way, but not only is it different then before, but it feels less intuitive to load that clear color from monster palettes, most people already think of that clear color as part of the background tiles, no one thinks of it as part of objects. So unless there's a compelling reason for it (like it's easier to do fades or day/night transitions or something), I don't know why you'd change it.


Here's a fix (or "another behavior") for that color 0 issue:
http://nesmakers.com/viewtopic.php?f=40&t=5474
 
Top Bottom