The Prying Eye - Development Thread

[CutterCross]

Cool. So what shows in your screens 'Tileset Layout' now? Does it still have the same selectable presets or is that redundant now in your project? Can you still select other layouts within NM ?

The tileset layout in the UI itself is mostly useless, along with all the default BMP / CHR tilesets the tool exports for backgrounds (and now the GameObject tileset). It's used as a placeholder to keep most of the screens from looking completely unrecognizable, but I use tileset slots 2 and 3 of the exported tileset layout data for setting my HUD tiles, so the result is usually something like this for finished screens:



Game compiles and screens load just fine, since tileset slots 0 and 1 of the UI tileset layout window are just there to play nice with the tool, and the actual compressed background tilesets are handled under the hood and through each screens' Screen Info tab. The new secondary GameObject tilesets are also handled this way, but are uncompressed.

From the time I implemented tile compression, I completely reworked the CHR load system so that it's stuck to 1 specific tileset layout for backgrounds. Changing the layout in the UI does nothing. Altering the BMPs the tool uses for main background tilesets also does nothing, as their corresponding CHRs aren't included in the codebase anymore. Same now goes for the original GameObjects tileset.

 

[CutterCross]

I reworked the pause menu layout just a bit. I wasn't satisfied with how cluttered it felt, and I wanted to make it more visually appealing. So I pushed all of the information stuff more to the sides and gave the main graphic a bit more room to breathe. Also used the few tile slots I had remaining in my tileset to give it more of an actual background. This won't really sacrifice any of the actual information itself, and I think it's a much better layout overall.

 

[CutterCross]

Alright, so I've been working on this for the past few days. If you look at the screen banks for Prying Eye in NES Space Checker, you'll see that there is a lot of big gaps in the nametable data that could be better used. All of the nametables are stored as uncompressed 8x8 pixel tile data. So I decided to come up with a nametable compression system that could free up some of this wasted space.




Now I already use Tokumaru's CHR compression / decompression algorithm for storing CHR data, but there's a catch when it comes to using this same system for my nametable compression. Because the main gameplay areas (the actual environment the cursor moves in) iand the like are very detailed with very little horizontal tile redundancy, the data overhead required to keep track of possible redundant tiles for each row would outweigh any possible savings of the compression. (Also, the decompression itself is relatively slow.) So I had to chose a different approach that would work best for my game's setup.

I created my system based on how nearly every screen uses borders of some kind. I could have a piece of data for each screen that specified how many rows to wait until drawing the actual screen's specified nametable data, (IE write a number of certain rows of blank $00 tiles,) and a piece of data that specified how many rows of unique tiles to draw. Then, I could calculate how many rows of the screen are left to fill with blank $00 tiles. With this setup, I could reduce the size of each screen's nametable so that they don't include these borders anymore.

I ended up using a metarow system, where it specified groups of 2 rows at a time. This allowed me to store both the number of rows to "wait" and the number of unique rows to draw in a single byte. [2 nibbles]. To completely get rid of any additional overhead in each screen's data, I used the first tile of the nametable data itself to store this value, which would then be overwritten by a blank $00 tile when drawing to the screen. This solution also gave me the idea to try storing static screen information in the 1st row of each screen's nametable data to give myself more flexibility with no real additional cost.

Here's some examples of how the nametables are drawn now. On the left is the final game image, on the right is an example representation of how it would look like if I used a different tile index to fill the "blank" parts of the screen:



Gameplay screens like the Foyer also write the textbox border and initial text from separate tables, further reducing the amount of unique nametable data for each gameplay screen.



And this is the final result of each screen bank that currently holds nametable data:



[Bank $00 also holds some extra CHR graphics, which are about 2KB]

 

[9Panzer]

Damn cutter... this stuff is next level.

 

[CutterCross]

Damn cutter... this stuff is next level.

I'll likely implement a similar system to compress attribute table and collision table data. If there's one thing that describes this game's development, it's compression. Haha.

Honestly though, techniques like this are paramount if you're ever seriously considering creating something professional on the NES. It just comes with the territory. You'll slowly start to see how 512 KB is a HUGE amount of ROM for an NES game in retrospective, it's just that NESmaker by default can't give you that sort of control over how you allocate that ROM without sacrificing what makes it convenient to work with.

 

[Jonny]

Honestly though, techniques like this are paramount if you're ever seriously considering creating something professional on the NES.

I don't know about this, there are quite a few commercial games made using NM which I'm fairly certain didn't need any compression or data reallocation. There's a high chance I could be wrong about this but they don't appear to need anything this advanced.
Have I totally misinterpreted ?

 

[CutterCross]

I don't know about this, there are quite a few commercial games made using NM which I'm fairly certain didn't need any compression or data reallocation. There's a high chance I could be wrong about this but they don't appear to need anything this advanced.
Have I totally misinterpreted ?

I suppose I should rephrase that. Yes, there are NESmaker games that have gotten commercial releases that didn't use any extra data compression, and mostly worked off the base framework NESmaker provides. But there is a difference between those NESmaker releases and most commercial releases by the NESdev community and NES releases from the system's original lifespan. This is less specifically about compression and more about using the system and mapper hardware to your advantage.

Just because something is commercially released does not mean it matches the same professional quality as its peers.

Most of the commercial NESmaker games I've seen are good in their own right, but most of them also shouldn't need 512 KB of ROM, flash memory, or 32KB of CHR-RAM, especially if the game is of a smaller scope. You can tell that limiting themselves to NESmaker's default framework limits their potential, and it otherwise shouldn't need to use a mapper like UNROM 512. That's not the case with ALL NESmaker projects, but it's common to see. Meanwhile, a game like Micro Mages pulls out all the stops while only taking up 40 KB. It's not just a great game, but a feat of NES engineering, being able to squeeze that amount of content into the same amount of ROM as Nintendo's simple [arguably primitive] black box games.

Basically, the more control you have over your game's framework, the more potential it has to be more professional.

 

[Jonny]

I understand and I agree that it makes for a more credible and professional product (mostly to other developers) if the cart hardware is used efficiently or at least to a level that doesn't seem completetely wasteful. On the other hand, I'd hope that finished games were judged on everything else first and its kinda what nesmakers of all abilities are stuck with.
The whole story behind Micro Mages screams quality and it's inspiring to see someone putting that level of detail and integrity into a much bigger project like TPE.

 

[CutterCross]

I didn't know whether or not I'd be able to pull this off given how packed my NMI is, but I did somehow:

View: https://www.youtube.com/watch?v=suRLvqpJdqQ


I got the base framework for split X/Y PPU scrolling using sprite-0 detection. This'll be nice for some neat effects down the road.

 

[CutterCross]

Split Vscroll effects are fun once you set them up correctly. Now I just have to fix this for every gameplay screen...



I'll probably tune this transition up later as well but it's a good start. Most of the work on it was just reworking my old scroll systems to get better flexibility out of these effects.

 

[Jonny]

Those fades are looking great. What would you tune? The speed or something? I've just noticed the windows you've added to the menu. Nice touch.

 

[CutterCross]

Those fades are looking great. What would you tune? The speed or something? I've just noticed the windows you've added to the menu. Nice touch.

Mainly the Hblank alignment and doing a similar transition for the pause menu itself. I'm not going to do this for EVERY transition, just in-and-out of the pause menu.

At this point I'm working on these effects for the learning experience rather than practicality, but I'll see what I can do with them as development progresses. Again, still working on the meat of the game, it's just that content creation for a project like this is really slow.

 

[CutterCross]

I finally got a decent system in place for distinguishing which sprites will follow the scrolling background and which ones will be completely independent. Also reworked how the engine handles its nametable focus for PPU window scrolling. That'll seriously come in handy later on.



In other news, more fancy transitions. Because I am never satisfied.

 

[Basty]

Whoah! That is most certainly something you don't see in the NES games.

 

[Jonny]

That's super fancy. Are you fading but scrolling at the same time? My brain can't process what's happening, I just know it looks cool.

 

[CutterCross]

That's super fancy. Are you fading but scrolling at the same time? My brain can't process what's happening, I just know it looks cool.

Yep. Fading + scrolling. The former gameplay screens use a sprite-0 hit to create a horizontal and vertical split so the textbox stays in place, and all the HUD graphics are just screen-independent sprites. Sprite-0 detection makes keeping track of sprite positions a whole lot more complicated haha.

 

[5kids2feed]

I implementing a proper input delay between screen transitions

Mind sharing the code for this? Been trying like crazy to figure this out as my character will be stuck in #$00 but moving the directing I’m holding for some reason between certain warps.

 

[mouse spirit]

I understand and I agree that it makes for a more credible and professional product (mostly to other developers) if the cart hardware is used efficiently or at least to a level that doesn't seem completetely wasteful. On the other hand, I'd hope that finished games were judged on everything else first and its kinda what nesmakers of all abilities are stuck with.
The whole story behind Micro Mages screams quality and it's inspiring to see someone putting that level of detail and integrity into a much bigger project like TPE.

This project does have a lot of features, and I believe cutter always goes the extra mile for his stuff. Technically awesome to be sure.
But to anyone skimming through here, please know that professional has never meant good. And like I think johnny was saying, a professional code/engine doesn't make a good game or product, But a good overall game does. Coding is only a fraction of a game, where art,sounds,level design, playability, creativity, new ideas, likeable/hateable characters,atmosphere,button scheme.
To widdle it down,graphics and code are "needed", but truly only part of the process. I've played some very unprofessional games in my life and enjoyed them a lot more than Most AAA or just "professional" games. And sometimes all the bells and whistles just can't make a big enough difference to a poorly made game overall.

 

[PasseGaming]

I don't know about that mouse, someone who has solid working knowledge of coding can go a long way, even without mind blowing graphics, music and new ideas.. As opposed to those with only a rudimentary understanding, who may have fantastic ideas, art and music but can't code to save their lives. It's defiantly a leg up in development if you understand what your doing, over the rest of the stuff.

 

[mouse spirit]

Touché . Possibly, a good balance is best.