Untitled adventure game, Milestone 1: Scrolling and tools.

Hi.

I've been working on-and-off since the spring on a little zelda-like adventure game. I thought id share what i have so far, maybe that will start a discussion, maybe not at all.

I've mostly been working on the foundations of the engine and tools. I have zero gameplay element, that will come next. Everything you see if obviously a placeholder (my character is a litteral crash test dummy to make this extra clear). I am not an artist in the slightest. I eventually hope to reach a point where I have enough of a game to partner up with a real artist to make this look real nice.

So here is what i've got so far. I'll cover some of the details of each in this post:

• 4-way scrolling (100% artefact free)
• basic assets (metasprites/tiles, animations, levels, etc.)
• basic editor
• small scripting language

Before i start rambling on, thanks to everyone who answered my questions. Thanks to Sour for Mesen, aka the greatest development tool, after visual studio.

4 way scrolling

Using vertical mirroring and assuming an overscan of 8px on the top and bottom of the screen, that leaves us with 16px to hide all of the attributes defects. This mean that if we are pixel-perfect, we can get really nice 4-way scrolling without using any special mapper (I use an MMC3)

Here is it running in a small C# version of the game I use for debugging. I use black bars to hide the overscan. When I switch to the debugging mode, there is 2 sets of red lines, one with the overscan and one without. Notice how all the artefacts are kept outside of the visible area. Note that the red/yellow squares are kept on screen for a few milliseconds, i'm not updating that many tiles.



Same thing, in Mesen.



It is a small level but it has been tested on huge maps and supports up to 8 screens on each axis (assuming you have the ROM/RAM to hold the data).

If you are planning to reproduce this, I *highly* advise that you create yourself a reference version in a language that is more "flexible" than ASM. The final ASM version is about 2000 lines of codes (including the code to prime the screen initially, and render some background animations). There are some nasty edge cases to handle, especially when it comes to stitching the attributes of the top and bottom rows, and on edges of name/att tables. Doing this directly in assembly would have been very time-consumming.

Basic assets

Here is a quick overview of all my asset types.



Here is what each of them are:

• Animation: A series of keyframe, each of them being a Metasprite.
• AnimationSet: A bunch of animation together. This both represents a 1KB switchable bank of CHR ROM and the PRG ROM data for the keyframes.
• BackgroundAnimation: Allows animating the background.
• Bank: Represents an switchable 8KB bank of PRG ROM. You can dump assets in there as long as you dont go over 8KB. Right now only 8 are displayed because I have so little content. Ultimately all 64 might be there.
• Level: More of a "room" than a level really. Comes with things litle triggers and scripts. More on that later.
• Metasprite: Bunch of sprites stuck together.
• MetaTile: a 4x4 grid of sprites. So my metatiles are 16x16.
• MetaTileSet: a bunch of MetaTiles togheter. This both represents a 2KB switchable bank of CHR ROM and the PRG ROM data.
• Palette: Duh
• Sprite: Duh

More gameplay-related assets will be added in the future, this like text, dialog, music, etc.

Basic editor

If you every worked in the game industry, you know how tools are much more important than whatever fancy tech you may have. That's why engines like Unreal are so popular. Their tech is by no mean outstanding, but their toolsets are super flexible and allows artists to have total control over their content. So I decided to spend some times on tools.

The tools handles all the packing in CHR ROM, updates everything automatically. You can safely delete stuff without worrying about your level being completely messed up. It works pretty well.

While you *can* paint sprites and stuff in my tools, there is no way I am going to be able to compete with Photoshop. So I added support for copy and pasting images from external applications. It automatically creates sprites, assigns palettes, detects flips, etc. Here it is in action. Notice how it detects that the hat is a flipped version of the same sprite and how it matches the rest of the body to existing sprints.



You can also compile and launch the game from the level editor:



When you export the data from the editor, you simply need to include a couple of ".inc" file in your code and you are ready to go.

Scripting

My game will not be 100% systemic. By this I mean I want to be able to create unique moments like in Zelda games. Things like:

• You enter a room, the music changes, a big bad guy appear, you kill him, them a chest appear in the corner, etc.
• In a room you have 3 switches on the wall, if you dont press them in the right order, a monster appear, if you solve the puzzle, a door opens.

So i added a little scripting language (it is BASIC-inspired, the first language I learned as a kid). It compiles to some bytecode i made up. It supports a bunch of stuff (loops, arrays, complex math expressions and conditions, etc.) and can also make calls to "engine functions" which are implemented in ASM.

This also allows me to prototypes functionality that I am still not sure how it is going to work. Here is an example of me using it to prototype a door opening and a room transition. As the character hit the trigger next to the keypad, it plays a background animation of a door opening (thus changing the collision) and the room transition is done by another trigger.



Please understand: NOBODY IN THEIR RIGHT MIND would use scripting to open a door and do a room transition like this if you are going to have 3 doors in every room. Of course you would want to make that code part of the engine. But is it good enough for a quick prototype? Absolutely.

The level has 3 types of objects that the script knows about: locators, routes and areas which are respectively 0D, 1D and 2D objects.

• Locators are simple points, simply to represent a coordinate
• Routes are paths, which will be used to assign path to AIs, for example.
• Areas are rectangles, which can be used as trigger (and other stuff later).

A script is assigned to a level. It can have global variables that are kept alive as long as you are in that level. The script can only react to specific events. I dont want any kind of scripting to run on every single frame. Right now the only 2 events I have are:

• on_level_init: Called after a level is loaded, but before it is rendered. This is where I will be spawning AIs, setting up the inital state of things like doors.
• on_trigger_touched: Called when the hero enters a trigger. The id of the trigger is passed as an argument.

More will be added as I go along.

Anyway, that's it for now. Hopefully I will keep working on it a have more to report.

-Mat

NES Maker look out! I'm impressed, good work!

Are you sure you didn't mean "milestone"? BTW, you can edit the title by editing the first post in a thread.

Oops. Fixed thanks!

That tool looks really elegant. Nicely done! Looking forward to see your progress with your game.

very impressive work, good job!

as soon as i finish up my current game i'm going to start work on a similar set of tools for the next several games i make.

Impressive work.

P.S. You may not be an artist, but your dummy looks good

I suppose I'll ask, have you plans to share these tools? I totally get it if you're not, just curious. No pressure.

The problem with the assumption that TVs will cleanly hide 8 scanlines at the top and at the bottom is that... they won't, you'll find all sorts of picture alignments out there. Also, PAL TVs will always show all 240 scanlines, or so I've been told. If you want true artifactless 4-way scrolling, you'll need tricks or 4-screen name table layout.

I understand. But compared to most games I play that attempt to do this kind of thing (SMB3 being a good example), I say this algorithm is far superior.

-Mat

When I release something (or get tired or coding it) ill totally dump the code somewhere.
In the meantime it is still too much of a WIP to release anything. It looks OK in animated GIFs, but it is not in a form that I feel comfortable releasing yet.

-Mat

Superior to SMB3 is an unfair comparison; it also has a status bar.

For free scrolling without a status bar he horizontal arrangement like this is just the standard method, and lots of games do it. (I was surprised that even the Mega Man series tends to stay horizontal for vertical scroll, even though its mapper could switch.)

I don't know... a glitch is a glitch, regardless of the edge of the screen where it manifests itself. If I had to pick an axis for scrolling glitches, I too would go with vertical mirroring and try to hide the glitches at the top and bottom of the screen. However, if my own CRT TVs are any indication, I definitely wouldn't succeed in hiding them. But still, in a game that primarily scrolls horizontally, that seems like the most sensible choice.

With the MMC3 at my disposal, I wouldn't think twice about using IRQs to mask the top and bottom 8 scanlines by disabling background rendering and using blank patterns for sprites, or vice versa.

EDIT: Just wanted to make it clear hat I'm not trying to be a dick or anything, I'm just pointing out that hiding stuff in the overscan unfortunately doesn't work as consistently/reliably (or at all, in PAL) as we'd like. You're doing something really cool, keep it up.

A lot of interesting things for the tools. Good work!

Wanted to do something similar (maybe not that advanced) a long time ago but time dried out. Will be interesting to see the final result.

I concur.

4 way scrolling on standard 2 screen PPU, I would use vertical mirroring and have tile changes at the top / bottom visible. The opposite of SMB3.

The best way to solve attribute glitches is to use 4 screen nametables

Shoutouts to my boy GTROM.

Yeah, I might blank the bottom scanline with IRQ for extra safety, that's very easy to do, i actually had it working at some point. Top rows were problematic iirc, or is that the other way around? One of them I can simply disable rendering, but the other needs a palette swap I think (a la Jurassic park). I cant remember exactly.

No offense taken! Haha.

Btw, I'm not saying what im doing is novel or original at all! While it is easy to conceptualize, the implementation is far from trivial and I do consider it a "feature" of my engine at this point.

-Mat

You can't do a palette swap at the top of the screen. Changing palettes requires turning rendering off, and you will get corruption of sprites.

Changing the palette near the bottom of the screen can work if there aren't any sprites below the change point.

You could point the top of the screen to an unused portion of the nametable, and have it all black, and then change the X and Y scroll at the 8th scanline, timed with an IRQ.

But, that's a lot of effort.

You might as well use 4 screen, if glitches must be eliminated.


Also, does MMC3 scanline counter work if rendering is disabled? Like for the top 8 scanlines? I thought it didn't.

Edit, the Konami VRC mapper IRQ uses CPU cycles to count, you could use that to time turning rendering on at scanline 8, and off at 231.

You're right, it doesn't.

Yes, it's definitely true, and there's a very simple reason for it: NTSC systems have 480 interlaced lines in the active area => 240 progressive lines, whereas PAL systems have 576 interlaced lines => 288 progressive lines. So assuming that the 240 non-black lines output by NES are centered on those 288 lines in the active area, there's a headroom of 24 lines at the top and the bottom of the picture. It'd be very rare to find a TV that has so much overscan.

Is it actually centred? I was under the impression that there was a bit more space on the bottom, but maybe I had just seen a poorly calibrated TV.

Also, I forgot to say to OP: this is cool. Looking forward to seeing more of your game.

I'm not sure. But even if it's not, it's definitely not so much off-center (from what I've seen) that overscan would become an issue.

Yeah, I'm not sure it's ever absolutely centered, but it's definitely "centered enough" that you always have very visible, thick black borders on both the top of the bottom of the screen, whenever you're playing any 50hz console on a PAL compatible TV/monitor.

Even modern consoles like PS1 and PS2 do nothing to accomodate for it, aside from a few games just offering an alternative 60hz mode (which is the best way out anyway)

A 16:9 PAL TV in "zoom" mode will display about .93*.75*288 = 200 lines. So if a game follows Nintendo's safe area guidelines for NTSC (224x192 title safe), everything important should remain visible in zoom on PAL, and the TV will cut off artifacts.

I was just curious if it was actually off-centre. It wasn't really a comment about overscan.

(Looking at some videos of people playing PAL NES with a camera pointed at the TV, it does look slightly above centre to me, but maybe not quite as significant as my memory/impression had been.)

I tried to answer that. So I'll keep it more simple: As far as I can tell it looks centered.

Yeah, between you and thefox I assumed it has to be "mostly" centred at least. I had seen one a while ago that looked off-centre to me, and I don't run into PAL NES and TVs very often, so ever since I'd had the idea that it was a bit more off centre than it seems to be normally, now that I'm looking at footage I can find.

I suppose knowing the actual scanline the picture starts on would be a nice addition to the wiki's knowledge, but at the same time it's not very critical information and I don't have the hardware to measure anyway.

The oscilloscope pictures that HardWareMan posted are good enough, at least for the UM6538 he had. Vsync is rows 0-2, upper blanking is rows 3-42, picture is rows 43-281, lower blanking is rows 282-311.

http://martin.hinner.info/vga/pal.html says that vertical timing is supposed to be: Vsync:0-2; upper blanking: 3-22; picture: 23-309; lower blanking: 310-312 ... so I guess pedantically the 6538's picture is 5-ish scanlines too high? (20 scanlines padding on top, 28 scanlines padding on bottom)

Don't know if 2C07 timing is exactly the same, but we do know they share the same 252x239 pixel picture.

(In contrast, 2C02 timing is Vsync:0-2 ; upper blanking: 3-16 ; picture: 17-259 ; lower blanking: 260-262. This is almost exactly compliant with NTSC, but provides 3 too many scanlines of upper blanking, so I guess it's pedantically 1.5 scanlines too low)

The IRQ counter won't work with rendering disabled, which is why I mentioned disabling only one layer (either sprites or background - as long as one of them is enabled, the PPU will function normally, and so should the scanline counter), and bankswitching blank patterns for the other. IIRC, Jurassic Park uses black (not blank - it has black in every palette!) patterns for both layers. Palette swaps mid-screen are notoriously hard to pull off on the NES, very few games did it.

Dang, this looks really cool!

I'm really liking the growth of tools for retro dev lately. (Even if those are just internal for now/indefinitely) Bit of competition for my thing, but I welcome it

Looking forward to seeing where you go with this!

This looks incredible. Definitely looks like it could replace nesmaker. Are you going to be selling it or is it free/open source?

Also, how do you make your guy go behind walls? I was impressed by that because I never could figure out a good way to do that on my own adventure game (The Legends of Owlia), so I just made it impossible. In Crystalis, they had to severely compromise the palette and have more than one shared color so that you could go behind a house using the background color as green but still have black outlines etc. It was kinda ugly.

My guess is maybe you have a character that always moves on an 8x8 grid and you can just cut him off? I cut off sprites for text boxes by nudging them a max of 4 pixels and then cutting them off at the sprite grid boundary, but never found a nice way to do the same just going behind walls etc.

Very cool stuff.

Thanks. Not planning to sell anything, I'm just having fun and learning. Will definitely put the code up somewhere at some point. Its just too messy now!

To hide the guy i simply have a flag for each metatile that says if it is a "foreground" tile. So I constantly look if the feet of the character are touching a foreground tile, if it is, i render him behind the background.

This look cool, but it has severe limitations.

Most obvious one is that your floor, at least near the areas where you character can be occluded, needs to be of a plain color (i.e. the background color, which is this ugly orange/pink color). So i have these little "brick" tiles on the floor, but I could NOT put one near the bottom wall, otherwise the guy would render behind the brick pattern.

Also, gameplay-wise, I can see how it could be frustrating to die because you were partially occluded and couldnt see what was going on... So for all these reasons I might not keep it. Or I might adapt my level design to mitigate the problems. We will see.

-Mat

The background doesn't necessarily have to be a plain color. If you have any sprite that matches either the background color or the shape of the background object, you can use what I call impossible triangle priority, a quirk of sprite priority on the NES. To put it short: If sprites' priority bits don't match their OAM order, the background wins.

When you hit a block in Super Mario Bros. 3 and a mushroom sprouts, you have three things mutually overlapping:

1. The block in the background
2. A solid black mask sprite, which is "behind" the block
3. The mushroom sprite, which is "in front of" the block but "behind" the mask sprite, hence the impossible triangle

The mask sprite appears before the mushroom in OAM, so it covers up the mushroom's pixels. But because the mask sprite has the priority bit turned on, any opaque pixels in the background replace the pixels of the mask sprite. Thus the mask sprite cuts a hole in all sprites behind it, allowing the background block to show through. Pillars in Mystery World Dizzy and The Curse of Possum Hollow use the same principle, as do tall pieces of furniture in RHDE: Furniture Fight.

See also:
PPU sprite priority and the entry of SMB3 in Tricky-to-emulate games

Wow, this is some cool stuff! I didnt know any of that. I will read the wiki. Thanks!

-Mat

I find this discussion fascinating.

What if you only had BG disabled for the top 8 lines, but sprites on, and you put 8 blank sprites at Y=0. The 8 Sprite limit makes it impossible for any other sprites to show up there.

I'm 90% sure the MMC3 IRQ would work, because it ticks the counter down on the sprite evaluation (I think).

Then rendering on till line 231, then another IRQ, then rendering off at the bottom.

Does anyone see any flaws with this plan?

Can't you just busy-wait with rendering disabled for the top 8 scanlines? Or would that also muck up the IRC counter?

I think it would work BUT keep in mind my background color is NOT black. Its that ugly pink/orange on the floor. So you wouldn't get black bars, you would get pink bars!

-Mat

I used this technique before, but since timing raster effects at the bottom of the screen without IRQs is pretty hard (if you scroll vertically, guaranteeing a sprite 0 hit is practically impossible), I just masked 16 scanlines at the top of the screen. In the NMI handler, I turned background rendering off, and placed 9 high-priority transparent sprites at the very top of the screen, and waited for the sprite overflow flag to get set. After that, I'd wait 16 scanlines with time code before turning background rendering back on. My main CRT back then used to hide 12 or so scanlines at the top, so there was very little blank space visible, which bothered me much less than scrolling artifacts.

Hey there - this is Joe from The New 8-bit Heroes / NESmaker. Just wanted to say...this is fantastic

Great tools, friend! Look forward to seeing what comes from them! We actually have a similar bit flip for hiding behind tiles this way...super cool to see it in yours too! And I'm jealous of how awesome your 4 way scrolling handles! Our scrolling is still pretty clunky to make the rest of the engine fit congruently.

Great work. Love to see the community building things like this.

Joe

Oh thanks!

Let me know if I can help with the scrolling. Its been kind of annoying to get it to work, maybe i can save you some time. But I doubt that is plug-an-play since its highly dependent on your data layout.

-Mat

Thanks, friend! Yeah, it's not that SCROLLING itself is an issue. Conceptually, we've already made it work fine. It's more that in an attempt for a extremely malleable code base with a consistent front end, it's been SUPER tricky to devise methods for it around that!

Would love to talk to you more about your project and what you're doing...I think it looks fantastic (and amazing art, too!!) Hit me up in an email if you'd like - joe@TheNew8bitHeroes.com