FrankenGraphics

I think it's just seems even more arbitrary because the poor choice of words ("tools"). Let's say i got khans' blessing to use "the incident" as an engine base for a turn based adventures of lolo-inspired game. I think people would be delighted to know that fact, and it would also be pretty formative to the new expression. You would on the other hand have a hard time discerning whether i used photoshop, aseprite, yy-chr or nesst or the built in NESmaker tile editor for the graphics creation. Likewise, you can't really discern if someone used nesasm, asm6 or ca65 for an assembler. But yeah, i've decided i'm team "free will by author" on this.

So basically.. It's useful and potentially benign, but also like the star of david or pink triangle. Used of free will, it becomes a symbol of pride, identity and positive exposure. Enforced, it becomes malign, because it's used as an instrument to help degradation and discrimination and reduces you to a symbol. Does that sum it up? The comparison is blunt and not quite on point, because you can't escape your personal and bodily identity in the eyes of others as an ethnic, sexual or religious minority, for example. I do not seek to trivialize this issue through my comparison.

I guess i must be a bit naive, because i fail to see how Dimension shifts' origins would make it any less attractive... nobody cares as far as quality is concerned if a game is made with game maker, as long as it looks and plays great, right? Just look at the AM2R fangame - it took the crown from big N and they know it. The official remake that came later had poor sales, and at the same time the bootleg market is distributing am2r because there is a continuing demand for this cease-and-desist:ed game.

An idea. If the purpose really is to categorize titles as engine flips or shovelware or likely to never be finished, maybe a thread completely separate to the issue of listing games in general could be used by collectors and consumers to help make wise consumer choices... homebrew is a jungle, and it's pricey to put something on cartridge, have it shipped, maybe with customs fees etc, only to find out it was not what it said on the tin. Or, like is the case with some kickstarter/crowdfunding campaigns, that some games simply fizzle out of existence. There are usually tell tale signs that a game developer might not be experienced enough to actually bring a nes game out, but it can't hurt with consumers actually having a platform for being a bit critical. It just needs to be kept classy and mature, and avoid unnecessary toxicity. Edit: And yes, i'd rather show my support for homebrew projects i really like, ground-up or engine based, rather than talking some project down. Let's not use this idea to step on someone trying out a new hobby or just wanting to do a show and tell.

You're absolutely right. Apologies on my part!

I've done things from the ground up, (most of which isn't fit to see release). I've collaborated with others who have written their codebase from the ground up. And i have made a nesmaker game called Garbage Hunter. It doesn't concern me one bit if people label garbage hunter as a nesmaker made game, because it is. For all the modifications i did to the source; both undercarriage and chassi, it's still identifiable as a nesmaker engine game through and through. I'm also not comfortable with releasing it to the public because it could use another half year of polish to work more as an adventure and less as a 2-minute arcade experience, but that's on me, not the engine. I'm not denying the nesmaker label has been used, is used and will be used to disqualify the work of people, just like a game maker game or appstore app might suffer the same fate, but that's on each individuals' prerogative to put value into that classification. the classification itself is not carrying that value - the scene is - and it will vary from individual to individual. I'm also not fully convinced of either side, but i am convinced of this: It is useful information to know that Dikki painguin in: TKO forthe third reich was made with/based on bob rosts' nbasic, seen as an engine. Not only is it nerdly pleasurable to compare this to other nbasic made games and try to spot similarities and differences, but it also helped me orient myself way back when and try nbasic out for myself because i felt inspired by it. If i hadn't found that info and made a first hello world and get the gratification of seeing it "come alive", i might never have maintained interest in the scene enough to start lurking the nesdev forums, and i might never have started being creative for the platform in the first place. I'm only here in the scene because someone classified it and pointed me in the right direction. Nesmaker today is what nbasic was in the early 00s, although more well-featured and with a larger install base. It has forever changed the installbase of asm6, which affects your concerns for when writing new tutorials, for one thing. It is safe to assume asm6 has superceded nesasm as an entry level assembler and it makes more sense to write your tutorials for the latter today. It also makes my life more convenient as a homebrewer. I've maybe answered the question in PM:s and on forums if Project Blue is a nesmaker more times than i care to count. Same goes with people asking if it is a megaman hack. I get it, they're just curious and can't possibly have all the specialized knowledge at hand to make a call for themselves. At first, i tried to be nuanced and detailed about this (much like in my post where i described how nesmaker can be used as an assets tool), but that generally just leads to people not reading what is actually said. So now i simply tend to reply "no", however dissatisfactory that answer is.

Hm... I don't think web deving works too well as a comparison, and here is why i think that: -Yes, there is sometimes some snobbery (don't listen to them) going on in webdev circles about using divi or wix or wordpress templates vs build yourself a template for your site. -But even professional webdevs use these services regularly. Why? Because it is a very pragmatic outlook to be web deving. Even when there is an aesthetic dimension to it, the aesthetics are utilitarian in nature. Even an art-heavy service like wetransfer functions to promote the company as forward-thinking and provide the user with easy to digest newsbits while the file is uploading. Rarely, the webpage is the goal in of itself. It's just a tool to get income flowing, information in/out and customers happy. It can be, but rarely is, a cultural or entertainment product in of itself. It's "just" a vessel for actual content. -It also differs from game development in that what webdevs mostly do is layout work, with little to no actual programming. with html and css, you don't define the behaviour of the browser or the backend. It has more in common with typesetting and magazine layout. In other words, the creative possibilites are narrowed down to its primary functions: view/read content, submit user created content, and link together. And in this decade, generate vast amounts of personal user data for marketing purposes. Making a game, maybe even in general, and perhaps especially for a platform that was never intended to be programmed by its users in the first place - in fact, nintendo went to great lengths to discourage this by obscuring technical information, making the hardware design unnecessarily cryptic, and so on - entirely exists in the field of aesthetic expression, as long as we're looking at bedroom coders, homebrewers, chiptune composers, story writers and starving pixel artist bohemians ( ). tl;dr: a homebrew game is primarily an aethetic expression in which the creator(s) rarely expect to get compensated for their time. Most homebrews are being done at economic loss. Web pages are most often utilitarian in nature and are most often commissioned by for-profit or elsewise funded entities. There pretty much isn't an analogy for Photoshop within nesdev. We're talking about a giant studio tool that has been commercially developed by whole teams of payroll staff over decades and has a near market monopoly on digital photography development and raster graphics. It can do just about everything between heaven and earth when it comes to raster graphics, absolute or indexed and sometimes vector graphics, even including animation, but it can be a bit clunky with its overhead. The closest likeness to photoshop in programming would maybe be VSCode, which share all those traits and is similar for a nesdev homebrewer in that all the functionality to do whatever is there, but you probably won't need most of it. Still, you can manage your assisting python scripts along with your NES assembly code in the same convenient environment if you want to. It's also similar in that you're unlikely to use VSCode unless you also write enterprise level program blocks, and you're unlikely to use photoshop unless you're also working with graphics or photography at some level elsewhere. If you don't, there are more and better specialized tools with lower entry thresholds, such as asesprite, yy-chr, nesst, and so on. edit: gauauu just summarized what i meant to say in a single line, lol.

I would't frame that as "simply". Like you said, you hex edited closed software to make it do what you want. Yes, you can use external tools (all my graphics and special screens for garbage hunter were made in nesst) but it's also several steps slower at each import compared to just using a text editor and asm6 up straight, or nesicide. It's a perfectly acceptable tradeoff if you know a module will align fairly well with your overall design goal and thereby cut production time rather than add to it. At some point though, if you set out to make something very different from what is offered, a user in the crossroads of what route to choose might at least consider begin with a more open/free/modular tools because otherwise you might spend time debugging someone elses' code (which is generally way harder than debugging your own), hacking tools, negotiate interface obstructions, find workarounds, spending time clicking through dialogues and other things you won't even have to worry about outside NM but sort of must be there, more or less, for the benefit of entry level users. Your work with NESmaker is exceptional, and yes, it does really prove you can make very unexpected things while keeping your base in NM. But, i really think that for the average nesmaker user with more ambitions than experience, the future potential of NESmaker is getting more modules (or even whole new engines and accompanying plugins) out for use with it.

I don't mean to be contrarian, but for the intents of my previous post; assuming nothing is what nesicide does. While both are IDE:s, their respective design philosphies rest on different use cases. In my experience, a small but still very significant amount of Game design is actually built into the GUI itself of NESmaker (not even counting its auto code generation at build time) and that's one big thing that sets it aside from nesicide, with both pros and cons that will depend on your goals. Then there's still the codebase... Even an empty module is a lot of assumed game design concepts and technical priorities. You still have the big common denominator of all modules in that empty module. And if you clean *it all* out and really start writing from scratch, i think it would really pay to make a thorough comparison which of these two IDE:s would be best for your (not meaning literally your DS, just any hypothetical) game project in the long run. Which is of course hard do do without experimentation because there is hardly any reviews of either, at least not without a lot of bias. But basically, you wouldn't need to hex edit nesicide to make it comply. The price you pay for that freedom is that assets creation like levels and screens are wholly external. On the other hand, if you mean to write a new module for others to use with nesmaker (like dale_coopers' 2 player module), i think it makes perfect sense because it provides more and more variety to the non-coding or light-coding end users. Edited to relate more to mugis reply with the hex editing stuff.

As a homebrew game designer and developer, i think it is interesting to know what tools people use and for what. A detailed list in each titles' own thread can prove valuable for comparing notes. For example, project blue used the following tools (skip if not interested) -NESICIDE - Project organizing and general IDE features. Donny swears by it; i've yet to give it a good chance. -CA65 - the assembler nesicide is a layer to. I also used it in of itself as a binary file splitter/merger/concatenator/maker for my graphics as a replacement for the command line tools linux users take for granted but us windows users lack. For example useful for me for moving text and hud tilesets from one 4k graphics table to another. -NP++ and Sublime Text - i edited assembly data tables for my graphics with these. I use both to separate what i'm working with at the moment. -Blarggs' NTSC artifact generator for checking what the graphics might look like on that (i live in a PAL region) -NESST - my single most important tool. i drew the backgrounds and sprites and animated my metasprites in it, made level prototypes, explored and analysed tile reuse efficiency with it. -Donny's custom level editing tool for PB. We couldn't have done the actual levels without it. -Photoshop. Some things just can't be done with NESST, like sprite overlays over backgrounds and animation timing previews. It is somewhat clunky though. -NESmaker. In some cases, it proved a quicker way to preview if my animation timings and metasprite compositions checked out right by making a little "faux game" with an animated object on screen. This saved me some time from not having to use photoshop to that end. -I-CHR by Kasumi. I used it for importing my sprite overlay work in photoshop into a tile format the NES actually can use. If you provide a palette reference so I-CHR knows how to index colors, it's great for this purpose. -RetroUSB PowerPak for testing on a PAL system. No emulator gets this right, and that's a fact i'd like to stress. -INL:s rom burning soft- and hardware to make an actual test and see if broke studios' PCB was compatible with our game and said tools. -mesen, nintaco, nintendulator and fceux. I think the key here is there's different ways to use nesmaker. In this case it was used as a tool among other tools, but not generating any assets that went into the game other than knowledge how to proceed using NESST. It might also be used as a tool to produce assets that might acutually go in a game written from the ground up. It may be used and modded so extensively the resulting game loses most or even all traits of the original engine. It might be used with a significant amount of modification but still be recognizable as a "nesmaker game" by someone with a bit of technical insight. Or it might make a game without a single line of code modified, which was original sale pitch. It seems to me, there's both a lot of nuance, and a wide array of possibilities here. Categories aren't very good at nuance. But they're good at structure. I find them helpful. Because since NESmaker (toolset, interfance and above all engine) does a lot of hard design choices for the user (which can be seen as both a pro and a con, depending on both user and context) is the most form-giving tool to date. Yes, you can do pretty much anything with NESmaker given you have enough motivation, time, and skill, though at some point, the GUI and/or the original codebase will inevitably be too tight a shell because no GUI can ever cater for every need. like i think might be the case with mugis' game? One point in the previous thread i got stuck on a bit.. I don't think i agree with comparing the NN tutorials to NESmaker and say it's equally a form-giving platform. For me there's three five basic categorizations. 1) stray example codes and tutorials. NN would fall into this category. As would joypad reading and warmup initialization examples on the nesdev wiki. You learn the basic ropes, but none of this is significantly formative for the game you are designing. It would take an expert time to disassemble or debug to figure out what method was used. Learning from or even copypasting that example code is a bit like knowing how a pawn moves on a chess board - it influences the game in the slightest possible way, because the examples are atomic. It's up to you to connect them and the combinations are infinite. We might not even have decided to use a chess board for our game yet! 2) Actual libraries. Like NESlib, or nesdougs' (derived?) mmc3 library. These provide you an easier, more human programmers' interface with the hardware in exchange for some restrictions, and those restrictions start to shape the game design in subtle ways if you know where to look. For example, if you're using NESlib, say goodbye to using colours #$2d and #$3d in conjunction with the fadein and fadeout routine, because these routines will en/decode these colours wrong. Now we might have decided we'll use an 8 by 8 square grid for our chess game, and maybe with two zone colours even. We haven't decided on the rules yet though. 3) Drivers. These are complex, monolithic blocks of code that function in a specific way towards a specific goal. In nes development, we benefit greatly from music drivers. It is fairly easy to figure out what game uses what engine by means of it features, even if composers can do their best to hide restrictions with creative tricks. There are still very distinctive things like exactly what it sounds like when an SFX cuts the music, how much the engine affects the general performance of the game, and so on. At this level, we're starting to see some classification of basic opening moves in a chess game, but they do not define all of the game alone either. I'm going to stop this chess analogy because it sucks, haha. But you get my point. 4) Whole engines. family BASIC, Bob rosts old nintendo BASIC engine, Mojon twins' engine (sorry, don't remember the name) and the different NESmaker modules would fall in this category. Now we're really narrowing down the design to a pragmatic but of course also limiting set of features. Through all these layers of platform building through steps 1-4, we've made a lot of hard design desicions along the way. 5) Engine specific IDE. There's only one of its kind to this date here, which is NESmaker. Neciside might be an IDE, but it virtually assumes nothing about the game meaning you need to figure everything out yourself, but on the other hand, no doors are closed. It's a tradeoff, and i want to stress i don't think you could say one is better than the other. It depends 100% on your use case. I might not agree with every decision about the NESmaker interface *personally*, like how it autogenerates some code (locks you out of editing some stuff), and how assets are managed, but it might just be right for somebody else with a different idea or a different goal. The point here is, the interface is another formative layer for the game design. My NESmaker project "Garbage Hunter" can attest to that. So why do i list these layers of distinctions? What gives? I think it's not just about the same relative ease somebody can hit "assemble" on the final NN tutorial and hit "assemble" in NESmaker, because what comes out of NN is barely a game even by early 80s standards. You still have all the technical design work in front of you. With NM, you have most of the tech stuff done with at your first hello world, and with it a lot of design decisions about your game. This is super helpful to newcomers, and i think that's the promise of NESmaker. But it also means NESmaker games start out very distinctive and with a low "make" threshold, meaning a lot of games start out seeing publicity and sharing that same distinctiveness. I remember when i saw "dungeons and doomknights" trailer, i thought "oh that must be one of the first nesmaker games to 'go public'". I don't know where that game is now except i saw a pretty cool looking dragon fight screenshot lately, but anyway. Most nesmaker games have a distinctive graphic style as well, which has a lot of variation within its own biosphere, but which you often can trace to the underlying metatile and path structure of the CHR RAM. I can't say i would know heads or tails if i looked at Nebs n Debs or Twin Dragons if they started out as NN tutorials or something else, though. And i'm not sure if i would be able to tell mugis' Dimension Shift had a NESmaker origin from a trailer either (sorry i haven't had the time to actually play it yet), because there is so much work done to make it distinct on its own terms. So yes, i think it's interesting to know what engine or tools a game was made with and see if i can trace its "DNA", because these things matter to me as a nerd. And NESmaker is probably the most significant change in the creative output and demographic of scene since shiru's NESlib (or zooming secretary that proved C was viable for some game designs). So there it is. I think it's useful, because it's simply put significant and, generally speaking, distinctive. Not because NESmaker games are somehow inherently "worse" from other NES games or anything. Does any of this make sense? I guess it depends on the intention of the use of the label more than anything, too. Edited lots of times to make myself less incoherent.

Thanks, everybody who joined us from here or old nintendoAge and backed Project Blue! Going to sink my teeth in the super hard mode tomorrow.

Classic! A lot of people seem to hold on to early versions of winamp and i understand them. So i want compatibility to be as broad as possible. I also like that style for nostalgic reasons.

Winamp is on version 5.x now! Though it's the same minimal bloat, straightforward application just as always

Only 17 hours left to go. Here's a good look at the international version cartridge! Made by Antoine/Broke Studio. (The US ones will be made by Joe/Memblers) Here's an update on our current stretch goal unlocks! A_Album.bmp

Me neither.. But because of the isometric perspective, we can at least always assume it is going to mask 2 pixels at a time on that line, which leaves us with two decisions per byte (since each pixel is 2 bits x 2 pixels = 1 nybble). So there can really only be 4 outcomes per byte; leave all intact, leave left intact, leave right intact, mask out all. Maybe that can be narrowed down depending on object position? a modulo operation should at least be able to filter out unnecessary decisions..? Somehow it feels like it is just comparing to a 1-bit masking table, though, and the table is offset with the object position.

No hard feelings at all, it was a very rewarding experience in of its own to work with you and develop some new skills on top of that Yeah it's a mystery to me as well. Like, i get that they're cascading metasprites to stream directly into memory so they take turns updating one each frame. But beyond that i'm at a loss. They must have some conditional nulling out pixel data as it is uploaded? Maybe in a buffer, idk.

Thanks for the opportunity to work on this awesome project! If things change, you know where to get me. Here's another room with a conceptual smooth light on/off transition effect.

The limited edition enamle pins stretch goal is a go! He're an updated overview

Thanks, everybody! What a warm welcome! ice man, here's a gif to illustrate the increased fidelity we were able to do when we could finally change mapper from the compo-approved CNROM to BNROM/GTROM Structurally, the level map format of the nesdev compo demo was: -256 tiles, -256 metatiles, -256 meta-metatiles across a total of 64 screens per map. Just one map. The full version has -256 tiles (with some optimizations removing letters for more graphics), -256 metatiles, -and a whopping 1024 meta-metatiles, across the same number of screens/rooms, increasing both level design fidelity and graphical detail. I think the # of palette animation sequences and maybe also the # of screen palettes per map was increased at this point in time, not least allowing for streaming water and light/dark room effects in the 3rd zone. The game supports 12 maps, which is divided across the three modes 4 for normal, 4 for hard, and 4 for custom. Normal and hard alters the difficulty by having changes done to a copy of the same room. Boss fights and several screens are heavily remixed. On other screens, we might have changed a platform, obstacle, or an enemy position or made a heart tricker to get to, and so on. the custom 4 maps are patchable by the user via a level editing tool for the pc we'll provide freely.

Hi! I'm Ellen, or preferably known as FrankenGraphics in homebrew circles. I make new NES games; not least together with excellent programmers such as toggle switch/Donny Phillips and Nathan Tolbert. In the rest of my spare time i jam in a band, watch roller derby (former rookie dropout), listen to new wave music, reads a lot of sci fi. I work with product and experience development, not least in the interactive or graphical department. Sometimes for public museums, sometimes for private enterprise. I also grow and sell hardy perennials. Currently active on KS with the new NES game Project Blue, Status: -development: done -funding: done (still live!) -quality control & difficulty fine tuning: active -manufacture: pending If you wanna connect with me on IG or Twitter, my handle is @frankenGraphics