It is currently Mon Jul 15, 2019 7:43 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 5 posts ] 
Author Message
PostPosted: Wed May 29, 2019 10:45 pm 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 2303
Location: Fukuoka, Japan
Danilo of JoyMasher (Oniken, Odallus) released ~2 weeks ago a small tribute to a movie he love, John Wick, for #screenshotsaturday, in a form of a fake nes game video (original tweet).

Since the concept was interesting, I decided to try to port it, since it's a very small 1 level thing. After receiving some adapted assets based on the limitation of the nes and testing how it would work in my current engine, I have a very early prototype of it that I shared yesterday a video on twitter (as a reply instead of a new post by accident ^^;;; link here) .

Since it's a nes game it makes sense to share it on nesdev so for now I will share an animated gif of the current look of it.

Attachment:
john5.gif
john5.gif [ 708.49 KiB | Viewed 2645 times ]

My time is limited, as always, so I don't know when I will finish it but once I have something stable I will start to share a rom of it. For now, only the running assets have been inserted and the rest is a glitch fest so it not usable yet :lol: the artifcats is where I load the palette since the tribute used more colors than the nes allows, same thing for background chr data, so I have to switch midframe a few things here and there. It's not in in hblank yet since my goal yesterday was to have a sample video to share and hopefully bring a smile to Danilo ;)


Top
 Profile  
 
PostPosted: Sat Jun 01, 2019 8:24 pm 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 2303
Location: Fukuoka, Japan
Sorry for the double post, I think I will ask the question here since it shows one part of the symptom in the screenshot.

For this quick project, the source uses more color than the nes can display at the same time. For this, I'm changing mid-frame the palette to try to reproduce as much as possible the same color that was used (if not, then the complete stage color needs to be adapted for the limitation).

It looks quite close to the original but you can see that artifacts are shown since I didn't time the code yet (it was a quick hack to make a video on the subject and all colors are changed 1 one shot at 2 points, status bar, 3 of them, and middle of screen, 4 of them).

When changing color mid-frame, it affect the address of the ppu since you change the address to the palette and you have to go back to the original address. I tried it in to change 1 color per hblank and it reduced the trailing artifacts but it caused the data shown the be not what I expected. I will need to take a screenshot later to show what I'm talking about but is it possible that if for 3 colors, 3 rasters, just resetting the address is maybe not enough? Is it possible the fine scroll must be re-adjusted, if not, it will not show what expected on that raster?


Top
 Profile  
 
PostPosted: Sat Jun 01, 2019 8:49 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11375
Location: Rio de Janeiro - Brazil
Like I always say, mid-screen palette changes are notoriously hard to pull off on the NES. You need at least one blank line when doing it, because one hblank simply doesn't give you enough time to 1) disable rendering; 2) set the palette address; 3) write the new color; 4) restore the scroll; 5) re-enable rendering. But even with rendering disabled, the PPU will render the color pointed by the VRAM address register, so in order to avoid visual glitches you have to change colors only during hblank, meaning you need several blank lines in order to update several colors. And during those blank lines, you can't display sprites either, which really limits where on the screen you can do it without disrupting gameplay.

And don't forget that disabling rendering mid-frame can corrupt OAM once rendering is eventually re-enabled (I personally can never remember the rules for avoiding this problem - what I remember is that you have to disable rendering as close to the end of the scanline as possible, but still before hblank starts).

I'm of the opinion that changing the palette mid-frame has waaaaaay too many catches to be feasible, so I basically don't consider this a viable technique on the NES. Whenever I'm designing something for the console, mid-frame palette changes are never on the table. I know that this doesn't help you with your project, so sorry for that, but I wanted to point out the specific reasons why this is hard to achieve so you can keep in mind all the issues you need to overcome when thinking of a solution.

BTW, have you tested this on hardware? Are the glitches the same or does something behave differently?


Top
 Profile  
 
PostPosted: Sat Jun 01, 2019 11:33 pm 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 2303
Location: Fukuoka, Japan
This project is a "holiday" to my current one I'm working on, allowing me to test and experiment things that I would usually not do with my current code base. I hope it will help me find new ideas to my current code block I have.

The goal is to try to get as close that I can from the original with the current assets and color is one of the many issue with it :lol: If I can't do it then:

- colors will have to be reduced in some way
- only one part of color may be updated (between status bar/ main game)
- leave the glitches as-is and say that was not possible without glitches

So success/failure is different in this project since it's a tentative re-creation of what Danilo's did. If it fails then oh well, it fails and will figure out something.

As for testing on hardware, I just made that quick port based on my current engine and it proved that it's possible to adapt it to something else, which is good, so I didn't test it yet. I guess I should try it soon.

As for the sprites, I wasn't aware of that so that may become a reason that I will have to drop it in the end, if it glitches too much :lol: For glitching OAM, wasn't aware of that too so I should be careful then.

Thanks for your feedback, that will help me on trying to port it as close as I can to the original material.


Top
 Profile  
 
PostPosted: Sun Jun 02, 2019 12:39 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11375
Location: Rio de Janeiro - Brazil
Banshaku wrote:
The goal is to try to get as close that I can from the original with the current assets and color is one of the many issue with it :lol:

I guess that the parallax in the buildings was the first thing to go!

Quote:
So success/failure is different in this project since it's a tentative re-creation of what Danilo's did. If it fails then oh well, it fails and will figure out something.

Well, he obviously didn't care for the actual limitations of the system when making that, he just went with the typical "NES feel" pixel artists seem to love so much (which is basically "4-color areas", but everything else is game), so it's no surprise that the conversion process isn't exactly going smoothly.

Quote:
As for testing on hardware, I just made that quick port based on my current engine and it proved that it's possible to adapt it to something else, which is good, so I didn't test it yet. I guess I should try it soon.

These things that mess with the PPU during rendering are always problematic, and emulated with varying levels of accuracy, so it's best to check on hardware ASAP so you don't end up making decisions based on misleading test results.

Quote:
As for the sprites, I wasn't aware of that so that may become a reason that I will have to drop it in the end, if it glitches too much :lol:

Yeah, the PPU is always processing sprites and backgrounds in parallel, and it evaluates sprites one scanline in advance, so if you interrupt that evaluation, at the very least you'll end up with no sprites for one scanline.

Quote:
For glitching OAM, wasn't aware of that too so I should be careful then.

The type of RAM used for OAM is DRAM (Dynamic RAM), which needs to be refreshed (read and written back) constantly or it loses its contents, and turning rendering off can interrupt the refresh process that the PPU is constantly doing, so when you enable rendering again this process resumes and may end up writing back values to the wrong memory positions. This is particularly nasty because it can even corrupt sprites on the *next* frame, if you happen to disable rendering near the end of the frame for some extra VRAM access time, even if you do an OAM DMA during vblank, since the corruption happens when rendering resumes, which's after the DMA, in the beginning of the next frame.

Anyway, feel free to keep trying to come up with something usable, I was just pointing some of the things you have to look out for.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group