FrankenGraphics

So i thought i should make this project a bit more public/official - there has been a lot of questions lately if these graphics are for a game, and yes it is. It's been going reaaally slow all the way since 2016 when i had no idea what i was doing. I might still work on it in 2026, but hopefully not, now that i know the ropes a bit and what i want. In any case, it's a slow burner. I've only recently had a fit of inspiration to work on new tilesets for it, but it comes and goes. I'm going to give it a proper name probably last of all, but for now let's call it Project Borscht. It is my favourite soup and has a fitting colour. It's going to be a spiritual successor to classic CV trilogy. CV3 was my first own game (along with barker bill's trick shooting but who remembers that game) and i've been drawing inspired levels since that day... well, with pause in the teens and early 20s when it was more interesting to waste time Vampire fiction stuck with me throughout all my life. So this is sort of a personal exploration of what could have been for the nes, but never were. I also want it to be mostly free of the compromises that commercial game studios struggle with. I don't mind it taking forever to complete. As long as creative decisions don't get compromised. There is a story written out, but i keep making changes to it. I'm trying to do everything myself. We'll see how that goes. Some music, prior final mixing: https://frankengraphics.files.wordpress.com/2018/05/frankengraphics_secrettitle_16.mp3 https://frankengraphics.files.wordpress.com/2019/09/frankengfx-track27.mp3 https://frankengraphics.files.wordpress.com/2019/03/frankengfx-rat-smell.mp3 https://frankengraphics.files.wordpress.com/2019/03/frankengfx-horn-and-hoof.mp3 Downhill edge-of-forest level: 50% done graveyard scene - just got the outlines for the mausoleum done. The black and blue tiles help me figure out where clouds and other far structures will go. And the old stuff which you've problably seen 1000 times: I think this scene tileset needs to be updated to match a little bit better. but there's very little tilespace left to do it in. I mean this works but i have half a mind to update the foreground especially. If you look closely, you see that most of the tiles are just recycled from the bald mountain.. which is sort of jarring in the style castlevania 3 graphics can be jarring, in retrospective. I'm thinking, though.. i need to use mmc3 or something similar to pull this off anyway. So i might as well swap out the tile bank at the scroll split to bring in something new. That should probably work. Prisoners' tower from the same area. This is easier to update, because there's a fair bit of vacant tile space left in this set. I think there will be stairs, where stairs make sense. Before i thought i could do a proper platformer, i sort of experimented with all kinds of styles in the same theme and background story. For fun, here's some old screens that might make it into something eventually, but not quite this project. Maybe a spinoff sometime most likely (not too likely given time) to become something on its own. Isometry is super hard on the NES. Not least because of the attribute clashes. maybe something from this scene gets recycled, but i think i've grown a lot since 2016 and can do better now.

Yeah, ultimately it was the demo that convinced me this is something i want to support. Apart the "charming" theme. Sometimes, all it takes is a clever design idea, and the rest will somehow become more like sprinkle on top. I also found the admission that it's still in need of some programming efforts honest and commendable.

People really need to work on their nesmaker HUD:s. Nothing says "unfinished" more than those hud corner graphics. I would put it more mildly otherwise, but this game says it is finished.. that comes through to me as not caring enough, which would be fine with hobbyism. but once you go kickstarter, you go commercial. Then i expect effort to match the backing.

Just found this on kickstarter It looks funny and cute and the central platforming mechanic ties well into the theme. I liked the quirky melody, and the inventive underlying level design idea. The graphics got their own charming identity, except the HUD & font which presently are shake n bake from the nesmaker tutorials. Hopefully that gets bit of love between now and then, but the game looks well thought out otherwise. I'm grabbing a digital copy (headsup - the shipping reached a new hallmark of expensive, despite the creator being uk based and i live in europe). Edit: forgot the link. here it is

Just happened to stumble across this on kickstarter. The painter of the "Power Blade" box art is doing a new version of the same. He's also showing some photographs which he based the art on. Thought some here might enjoy it.

This example is equivalent to 4 DEX. If someone reading this is using an upwards-counting OAMBuffer cleanout routine, it should be: lda #$ff sta $200,x axs #$fc ;equivalent to +4 each iteration since AXS means X = (A && X) - # Edit: if the assembler you're using doesn't support any undocumented opcodes, then .db $CB will do the trick.

Not that you'll ever use this unless you're crazy about doing signed math (and then, the usage is probably still rare..), but this is similar to the bit-skip trick in the OP. You can synthesize a set overflow instruction by BIT addr, where the addr must point to an rts instruction or a value of #$60. Note how the 6502 instruction set has a clear overflow instruction (clv), but not a set overflow (sev) instruction? For some reason, setting the overflow flag is depending on a low transition to the SO pin (maybe some math help processor was supposed to interact with it or maybe it was thought of as a way to poll for requests), but most computers, the NES/FC included, leave it unconnected or tied to a constant. To recap, overflow yields a positive if a clc adc or sec sbc is out of signed range, ie outside -128 to 127.

One argument against 4x4 meta-meta-tiling: it pretty much squares the time it takes to make a level, because manually looking up and placing meta-metatiles (and the metatiles within) consumes a lot of time, despite your best efforts to organize them (and the organization always end up half done because you want to be practical and move quickly). Additionally, often you find yourself in a situation where you absolutely need to modify a tile, or a metatile. Now you need to make sure the meta-metas placed on your screens look and function okay. Often, they will not. then you need to solve those problems as well. It seems convenient at first when you populate the first handful of screens, but is best suited if the metas and meta-metas are defined for small levels or divided-up stages. The more screens you add using the same meta library, the slower your process making them will be. If you write an editor that will handle the sorting and metatile making for you, you can save a lot of time - up until you hit the hard limit of how many you can make. then it will become a puzzle solving excercise.

it's too early for that! we just started talking seriously about a commercial campaign, but there's a lot i feel we should do before getting there

I should be careful not spilling the beans on exactly what we hope to achieve with the stars for this particular screen just yet, but my general method for sprite placement on screens like this is this I usually to draw them free-hand in photoshop on top of the NESST-made background layer, then create so-called "slices" with the slice tool (it's originally an old web design tool meant to export assets to adobe dreamweaver); each 8x8 pixels, or 8x16 if we're in that ppu mode. The slices serve two purposes - i can stitch them together into a character table, and by examining their metadata i get their x & y positions and internal drawing priorities. I use these positions to type down a raw PPU OAM table, which is simply fed to the PPU and there you got it. There are usually some human errors on my end which i debug with mesen, which has a sophisticated sprite checker tool. Here's an example from a half baked tutorial i once typed up. Any pixels outside the slices get ignored. This way i can optimize sprite usage vs fluid free-hand drawing.

Demo splash screen! 75% done. I've got half a mind to move the copyright notice to pre-title card, which would free up some resources, but even here i've got 30 tiles and 1 colour to spare on the bg layer. The star field will be drawn on the sprite layer, which is currently only used for a few details on the logo

Project Blue has gotten the "oh, a mega man hack" a quite a bit too. And yes, "is it made in nesmaker" is an even more common question. From where i come, the answer "no" is in plain sight. It's in how it sounds, looks and plays - you see the absence of similar traits instantaneously. If you could trace something, it'd be the smb1-like physics and controls, which it was modelled after. But i think people are just associating the theme of "cartoony style + sci fi + platforming + shooting" to the first thing they can, which would be mega man both in the case of project blue and battle kid. Similarily, i believe the Haunted Halloween games were even more absurdly assumed to be a river city ransom hack at some point, where the only similarity is that it is a scrolling brawler. The nes maker assumption becoming more and more common is probably simply because that's another "only point of reference" for a growing number of people, just like hacks are for some other. I believe there's this perception that developing nes games isn't possible or at least viable (but, depending on where you come from, you may be aware that rom hacking is, or that you think nesmaker made making new games for the nes possible in the first place).

This was the thing i was trying to remember! So yeah, if you forget <, you will accidentally write or load from normal RAM space instead of zero page. Done consequently, it results in slow code, because the address to fetch it is two bytes long instead of one. Occasionally forgotten, it results in bugs. Nevermind my previous blabber about taking two bytes in storage; this is not the case. Another good reason. I like using @ (cheap local label) , -, and + (relative lables). Makes namespace conflicts and typos (esp. with upper/lowercase labels) less common.

I've only used the more advanced features of ca65 macros when i tried (and failed halfway) trying to translate Garth's FORTH layer. The problem i couldn't solve had to do an assumption of direct control over the program counter, which is not how ca65 + ld65 works. This was something i just couldn't figure out how to solve in another way, so the macros aren't to blame. But it maybe speaks a bit that it can be a little intimidating to get familiar with all of the things you can do? But, is there a significant difference in how it handles macros at the level asm6 or nesasm3 is able to use macros? ie, make a macro, pass some parameters, no .ifblank directives etc.

As a side note, i started out with ophis (yet another assembler) but quickly changed to asm6 and then ca65 when i realized it wasn't used much.

My oversall reservation with nesasm3 is that i feel the syntax a bit messy to read and write. Also - Without having used it much, it seems to me like i could cause a lot of human errors, sometimes without it telling me there's a problem, which can be time consuming. That said, it's is probably a matter of getting used to it, and the differences between asm6 and nesasm3 are fairly small. But, for example, it conflates (local) symbols/labels with dotted directives, and global symbols with caps:ed directives. Not only does it make the code harder to follow, that means everything that is not identified as a directive is instead treated as a label, which seems something i would run into a lot. example: .incbin is a directive, but .mylabel is a local label. So if i make a typo, say .incbim, it is treated as a label which could potentially go unnoticed. this particular case would probably throw me an error because .incbin should be followed by whitespace and an argument (path), but you get my drift. INCBIM, another typo, would be treated as a global label. The .bank directive seems unintuitive to me, since banks are fixed to 8kB whereas most mappers use 16 or 32kB banking. I could probably figure it out but meh. Banking is a set and forget thing with ca65 right at the mapper config step. a nice thing nesasm3 has got going for it is the -raw commandline option, which strips the game from its header which is kind of useful for when flashing your binary onto a cartridge. That's a step less than in asm6 or ca65 where you need to use .ifdef to achieve the same conveniently; or commenting out an .include to the header, whichever suits your taste. It's a pretty minimal thing, but still. I remember reading somewhere that it was pretty easy to hog two bytes of memory instead of one with an easy-to-make syntax mistake in nesasm3, but i don't remember exactly what was the cause. EDIT: all this seems very scary but honestly, it's just like gauauu said. the difference in your workflow is going to be fairly small. It's probably best to write a few code blocks in each style and decide for yourself.

I use ca65 and asm6 for different reasons: asm6 for small, easy-to-manage projects ca65 for everything else. Coming in fresh at a time when both asm6 and nesasm3 were available, asm6 simply felt like it was a bit easier. Also, reading the NN tutorials but having to type it out in asm6 syntax was a great excercise i can recommend. ca65, in the end, because for me there's less memory management to do throughout a project; and fewer human errors when i hit assemble. The initial config setup which may seem scary at first will pay you back with interest. It can do a lot of stuff. I'm not even sure how to use half of its many features, but if i'd take the time to read up on something i suspect i might find useful, it has the best documentation around. Also lots of people willing to help you if you have questions. *If* you want to port or your game or part of its codebase to another 65xx system at some point, it helps to have all of your codebase written in the syntax of ca65 since it is suitable for several other target platforms; not least the commodore 64. There is a bit of ecology/history to the asm6/nesasm3 divide. If you were frequenting NintendoAge, you were encouraged to use nesasm3 many of its user had stayed and familiarized themselves with the assmebler NN was written for. If you were on NESdev people would instead recommend asm6. (or ca65). So i think it's fair to say the new divide is nesasm is going to be recommended if you're on VGS, and asm6 if you're on nesdev, as far as lightweight assemblers go.

In a sequel, you expect it to have similar features and "feel" (people even start having objections when they are different; see the retrospect shade on castlevania 2 and zelda 2 popularized by avgn) - meaning it makes a lot of sense to reuse a fair share of of the engine. There is a market for content in that format and feel. The answer to the question, at least as far as i'm concerned with any game i'm involved with, is what i wrote in that same post: "I probably wouldn't want to use the same engine for a bunch of very disparate game designs, though. That's where you start to dilute the quality." Whether people notice the similarity or not on a cognitive level, my worry is people would not find my games as entertaining, because they've felt that "feel" before. SO, even if i were to reuse the engine yet again for a differently envisioned game, i would make sure to put time into making it feel like a fresh new experience. This process is the same for nesmaker as any other engine. There is a difference though in you're up for some pretty heavy redesign work if the engine has seen a lot of use, vs an engine that has been used just once. Also, if you take lizard and assemble it, you have not made a new game just yet - at this point, you have made a copy of lizard. So even in this case, you're up for a months of redesign. again, the deciding factor becomes time/effort. No, it's not a guarantee the NES game will come out good. But it is pretty much a requisite.

This is just common business sense, i think. If you got a good engine, why not make a sequel or derivative to get more out of your efforts? Why not at least reuse the undercarriage (non- or low-formative maintenance routines at the very least) for a new engine? Nobody's complaining that castlevania 3 is using an improved castlevania 1 engine, because it got heaps upon heaps of good game and level design added to it. Everybody loved battle kid 2 for the same reasons. A lot of people probably wish for a BK3. I probably wouldn't want to use the same engine for a bunch of very disparate game designs, though. That's where you start to dillute the quality.

I'd like to address some of these points. 1. Early homebrews blazed the trail. Just making an NES game demo however short or regardless design qualities pre-2007 was a feat. There was still little precedence in the first half of the 2010:s to use as a point of reference. Much thanks to the NESdev compo which has promoted devs to strive for making better and better games, and with the ongoing trend that some of the upper crop in the results of those compos then go on to be further developed into full-featured games that can compare to historical game releases, we're also seeing duos and trios where each member has at least one specialization team up to make it happen. With bigger and better games coming out, of course the gaming audiences' expectations of NES homebrew increases. We need to do better each time. Which is good, but demanding. that's just how it is. 2. The deciding factor that make both scenarios true is spent time. If you make a game worthwile someones' time and money, you're likely spending time and effort that would equal *at least* months of office time. Likely more. Some of that can be covered for spending weekends or late nights after children go to sleep and whatnot, but you're also likely to spend time on your game you'd, economically speaking, be better of salary working, contracting or freelancing. That difference in revenue for your worked time is a cost post in your budget. A game with lots of non-repeated content is therefore likely to be a costly affair for the homebrewer. The very definition of a cash grab, however, is to get somebody to pay you without you putting in hours of effort, usually resulting in a subpar product. Id' like to classify it a (premeditated, i'd probably add, not sure) exploitation of cashing in on expectations that the resulting product cannot meet. Or there could be overconfidence in the merits of your work, meaning you launch commercially way too early, leading to the same effect. On a tangent: In freelancing, we have a triangle of service qualities. there are 3 corners to it: high delivery quality, short turnaround time, and low cost. As a client, you typically get to choose 2. A similar theory could be applied to homebrew: High quality product, short development cycle, low cost of production. Again, you only get to choose 2, at most. There's the possibility of a disconnect between use value and market/perceived value, though. 4. This point is as true as always. However, it has gotten easier to release something that maybe should just be a demo rom for peer review over at nesdev or something. Everyone has to make that judgement call for themselves, but at least from a homebrew consumers' point of view it is not "special" anymore (however the experience may be special to you as a developer) to have something working and running on the NES in of itself. The significance of that is lost because we've made progress, together, beyond that point, which i think can only be be a good thing. tl;dr of it all: good games take time to make. cash grabs do not.

This, so much. For a niche hobby like NES development, you can pretty much count on landing in minus for almost every release, if you factor in the work as a cost. It's a for-loss venture you do because you really want to, not because there is money in it. Just the plugins for the video project is 200 usd in yearly subscription. Then there's the cost of other studio tools. Which is not so bad when you split it across a lot of projects including revenue:able freelance stuff, but for most homebrew campaigns, this is not an option. Maybe more indicative of the marketing costs: i was able to schedule 9 days of salary-work that month; the rest of my days was spent on campaigning. I really enjoyed staying in touch with all the fantastic people coming to support us, and acquiring some new skills along the way, but i felt i could have used even more time to make it as good as i wanted it to. Then, the game has been been in development for ~3 years on donnys side and ~2 and 1/2 years on mine. Not even remotely full-time of course, but suffice it to say i wouldn't have been able to keep working on more than NES project unless i had arranged my lifestyle accordingly by living in a collective and cutting my fixed expenses down to almost half, which affords me to take time off from a full-month work schedule.

This. The early hacks, demos and original homebrew games might have been modest, but they were driving the scene forwards. they helped fill in gaps in the life-essential documentation, espablish detailed knowhow, channels of communication, and an end user base for nes homebrew. PartyTimeHXLNT says it best. She also talks about the importance of welcoming new people to the scene and the resources. Timecode jumps straight to how homebrew scenes mature, but the whole talk is fantastic.

The "used tools too" in this case is having a canvas, a piece of charcoal, a brush, and and a palette to put colours on. But you have to find the motif. You have to do the first initial sketch. You have to find out what works for the composition in your mind. Getting those first initial strokes out on the canvas is the hardest part, but the reward is a personal expression will come easier in the end, because there's a wider field of personal variance. While you can theoretically do a lot of things with NESmaker, it's main appeal is having a bunch of canvases with the charcoal lines defined for you. You can negotiate them or even ignore them, hypothetically, but that's the best analogy i can think of. An unofficial mission statement for NESmaker could be: "make nes development more available by factoring out the hard part". And that's amazing. It also opens up to being able to develop certain types of games in shorter time, which could sometimes even be appealing to NESdev veterans if they gave it a chance. Just remember that in nes development, you're always trading something for something. This is why the focus on tools is disorienting. The thing that really matters is: engines, drivers, libraries. Probably in that order. The thing about engines is, it's a lot more formative on a limited system where just about every feature engine thrives at the expense of another feature. You can make just about whichever game you want in unity. You can't in an NES engine. Every engine is super distinct, and that's the charm.

Yes indeed! Part of the Project Blue stretch goal of including a NES music album from various projects was actually to put a bit of a fire under my own butt and finish some of my almost-done songs for HALCYON... so, they're coming soon!

in addition to what scrobin said, let's not forget what environment we had when NESmaker launched on KS. There were some legitimate concerns worrying about an increase in low-effort/shovelware that would make life harder for people who put in a lot of time and effort into their projects to get noticed - maybe even deteriorating what little homebrew awareness there was. Turns out, the market for homebrew is NOT that fragile. We're seeing a consistent upward trend of more and more people discovering commercial homebrew on their radar and enjoying it. Just look at backer numbers for excellent games like Lizard, and look at backer numbers now. If Lizard was announced today, you'd see a very different backer figure. A lot of it probably has to do with the efforts of high quality homebrews and high quality campaigns like NEScape, Twin Dragons, Nebs n Debs and Micro Mages. But it wouldn't surprise me at all if NESmaker added a considerable chunk to that awareness cloud as well. All there is to it is a bit of raised stakes - when you can make a the legend of zelda-quality grade game in half a year, all that means is that you need to shape up in order to stand out. That can only be a good thing.