Mugi

i hae no idea what im doing but it's been fun so far so it's all fun and games, hehe.

no sweat really, though im obviously overly defensive of the project as i have poured my heart and soul into it every day for the past year either way, I suppose I'll just have to deal with it since my project is indeed a pioneer of the whole process of "breaking out of nesmaker" in a way. there are multiple projects, such as soko banana that have been worked through nesmaker and contain a lot of handwritten assembly to go with them, but i believe dimension shift is truly the first and currently only game that fully evolved outside of nesmaker and now simply uses it as a tool in the toolchain instead of building around it.

since this whole mess started because of my project, i have now added a post in the Dimension Shift project thread detailing the development process of the game, along with tools used, and a reason for why i do not wish for this game to be classified as a nesmaker game. Feel free to ask questions in that thread if there are any.

i will add this information to the first post too but as we've been talking about development transparency in multiple threads here recently, here's a quick insight for the development tools used on dimension shift. compiler: ASM6F (fork of ASM6 with support for unofficial instructions, which are heavily used in the code.) graphics: pen & paper scetches scanned and edited for NES / Shiru's NES Screen Tool / nesmaker's BMP2CHR converter / Paint Shop Pro 5 / Optpix ImageStudio for PS2 graphics development. World building: done using nesmaker's screen painting tool, which generates 16x16 metatiles from a chr and allows WYSIWYG screen painting, while generating NT/AT on the fly. Additionally, menus, cutscenes and any other special types of screens are directly drawn using Shiru's Screen Tool, and the resulting CHR/NT/AT are converted using our in-house NTAT conversion tool into our own proprietary nametable format. Audio: Composed entirely in Famitracker, and imported into the game by converting a Famitracker .txt into assembly using GGsound's own conversion tool, which is then included into the assembly source. Sound Driver: Gradual Games' GGSound (as included by default in nesmaker) code writing: notepad++ / nesmakers internal script editor Project management: nesmaker's internal project save format which we mail back & forth with FIX94 in an attempt to keep our source synchronized (lol.) the base game engine of the game is indeed nesmaker 4.1.4 scrolling platformer core, with roughly the following added to it (excuse me beforehand for minor inaccuracies, it's been a long ride) - memory management completely redone - chr ram bankswitching functionailty. - chr management / loading rewritten from scratch - chr compression added - standalone "menu engine" with it's own tile load/input/everything else routines - standalone "cutscene engine" based on the menu engine's code - DMC IRQ based software scanline counter - scrolling has been rewritten from the ground up, including tile load handlers and everything else related. - custom scripting support for per-stage based unique functionality in the game - new metasprite draw routine. - partially rewritten collision engine - partially rewritten physics engine. we had a brief discussion about this with FIX94 earlier today and from what we concluded, here's what is left from the vanilla engine written by Joe Granato; - entity (object) handling system (nonfunctional- not compatible with our scrolling code.) - portions of physics engine we saw no need to rewrite as they do the job. - portions of the collision engine remain unchanged at this stage (pending rewrite/modifications due to it's heaviness) - input handling there are stray pieces of code left in the game that are literally pointless to rewrite, such as input handling, which can quite literally just be copypasted from nesdev wiki, or rewritten in 5 minutes. Also a large portion of the original engine's structure has been kept intact, the way routines load and how the main assembly is laid out largely remains unchanged while the code inside it has been rewritten. a large portion of nesmaker engine's filenames and folder structures for the source code also remain unchanged, additions excluded. as the game is still highly in progress, there are things that have yet to be looked into, such as rewriting the object/entity system, and doing heavy rework/fullrewrite of the collision engine. nesmaker's 6-point collision engine, while slightly buggy, is generally fairly robust. it's problem is that it is EXTREMELY HEAVY. as such, we are more than likely gonna take the axe on it with a heavy hand at a later date once we start implementing objects and projectiles. i hope this clarifies a little, feel free to ask questions. EDIT: for why i dislike having people label this game as a nesmaker game, is as follows: current project compatibility with nesmaker is propably roughly 30% or so. the project can be loaded and saved in nesmaker with following limitations. UI functionality for; - managing hud: crashes nesmaker - managing RAM: has no effect on source code, includes have been removed. - managing graphics banks/CHR files: has no effect on source code, includes have been removed, and dummy asstets are used in order to prevent nesmaker from crashing. - "path" management: nonfuctional, assembly code completely removed, crashes nesmaker. - game objects: in most part, nonfunctional. Player object's parameters can be changed, but graphical modifications have no effect on source code, the real compressed graphic is manually worked and a dummy graphic is displayed in nesmaker. - monsters, monster graphics and monster parameters: 100% nonfunctional, loads dummy assets, no effect on source code - text/text groups: crashes nesmaker. text box and text storing routines completely removed from the source code - special screens: no effect on source code, loads dummy assets. still functional: - input handling: including assemblies connected to presses of buttons functions and is used. - palette management: still functions although, most palette changes actually happen in-code - audio import: importing a GGsound .asm file through nesmaker's UI currently functions in the screen painter mode, a chr file can currently be loaded, metatiles created and screens/NT/AT generated, however, most functionality related to defining screen attributes (special flags, audio, monsters, trigger status) is non-functional. we have also changed the way nesmaker handles the screens as a 256 screens long "corridor". instead our screen load routine handles the world as a 16x16 screens grid which endlessly loops itself in both vertical and horizontal axis.

the soundtrack is actually pending a full rework soon(ish) digit took a break from composing for the game due to real life commitments and as such the audio assets of the game currently are more or less first drafs made. the idea is to basically "start from scratch"

oh it's.... conveyoring allright

not quite PB level but its getting there

FIX94, my developing partner is a long time nes/nintendo guru, and also an author of his own nes emulator, FIXNES. add to that, while this is my first actual game development project, i am practically romhacker for life, and aside actual programming experience, I've amassed a wide range of snippet information regarding little things such as this. We are well secured in our knowledge of what should and should not be done. going back to nesmaker enough, i just felt like mentioning that nesmaker's current versions do not have a palette fader as an UI function either. a fade routine that is broken and incompatible with the nesmaker engine is included in the assemblies, but using it requires one to rewrtite the entire palette handling assembly, and a lot of the fade routine itself. (this routine is mostlikely a leftover of an earlier engine version, used to make trollburner, and propably used on some early development versions of mystic searches.)

the fade thing is one reason for it yes. my game takes excessive use of the color 2D and also does so in conjunction with palette fading. I've had a long discussion about this matter with Joe and while he said he has zero plans to ever make that color available to use through nesmaker UI** he's been more than understanding with my frustration with it. now, the color can be taken to use simply by exporting a palette (copied to clipboard) changing the palette entry, and then importing it back. the problem with this in nesmaker, especially if you use the in-tool screen painter, is that this color is also not displayed (it displays as white.) i believe i talked him over to making it correctly display in the subsequent versions, even though it will still not be available from the UI. and for those wondering, Dimensionshift's palette fading routine has been sanitized to deal with 0D.

more or less. I always wanted to make a shatterhand 2, and when i finally decided to make a game that is not blantantly violating it's copyrights, the whole design of the game literally started from that fact. It needs a stage select..... Like shatterhand. we all know that shatterhand is the best nes game, and you can disagree, but then you are wrong Thanks. There really is no intricate secret involved in getting away from nesmaker's limitations. One just stops using it. I could rant about the tool and it's uses for all eternity really, but I kinda already did in the other thread so I'll just leave it at that. and yeah, the biggest dealbreaker for me with it was that it did not allow me to do some things i knew full well that the nes is capable of doing. On a system as limited as the NES, indtroducing further limitations, while necessary in the case of an UI tool, is a terrible idea. ironically enough, the thing that really tipped me over is the fact that the palette entry #$2D was removed from the color selector.

by "simply outsourced" i meant, Use shiru's screen tool instead of nesmaker. i didn't outsource it, i bruteforced it to bend to my will. xD and yeah, using external tools like screentool is slower because you have to do the whole juggle with the data as opposed to how drawing in nesmaker literally edits the NT's in realtime and that's that. but as such it's not any slower than making a game without nesmaker to begin with. as far as the future of nesmaker goes, we will have to come back to that once the fabled 5.0 version is out.

well, first time using it for anything more than hiding dickbutts into random internet memes. also my first time working with nes' color restrictions etc. the few pixel art things i've drawn in my life prior to this project have all been 256 or in some cases of small images 16 colors, with no grid / palette restriction in usage. I've received critique regarding some of my stage designs in the game repeatedly regarding the fact that my reuse of foreground assets as background assets makes it sometimes really hard to see where you can and cant stand in the game, and it's a fair critique really... It's been a long and tedious learning curve to design gameplay screens for a NES game and while my graphical style is generally very well regarded (which I really appreciate btw!) the whole platform visibility matter is just one of the many things i consider to be my big shortcomings in NES graphics work. Edit: I added a small video clip to the first post that I recorded yesterday after finally getting the weapon draw code to work. since then, i finished the dynamic weapon hitbox code today, so the hitboxes are a bit more accurate than they are on the video. the hitboxes also only generate when the actual hit happens, not when the button is pressed, that caused, for example the item crates in the video to break before the weapon actually hit them.

again, the whole part of nesmaker that is baked into the tools design (such as the way it sorts chr files and simply will not let you change that.) well, dimension shift changed that. What is the direct result of this action is that you will have to do like you would do in any other enviroment, you design your screens outside of the IDE. now, Dimensionshift is able to still use nesmaker's screenpainter because we removed it's restriction to display full 128x128 pixel chr files. the normal nesmaker screen painter splits the chr into 4 parts; 6 rows of "Main Tiles" 2 rows of "screen tiles" 4 rows of "path tiles" 4 rows of "hud tiles" a normal level tileset consists of one main tiles, and one screen tiles. For the sake of simplicity, lets ignore the path functionality for now. the path and the hud tiles are essentially locket assets, and you can define a tileset, and in addition to that, without doing full chr reloading, you can define one screentiles per screen or per scrolling area if you use the scrolling. nesmakers UI is locked into not allowing you to mess with this categorization. So what we did, is changed the tool so that it now thinks a "Main tiles" is 128x128 pixels in size and the assembly itself has been completely written from scratch to deal with chr ram etc. resulting in the fact that i can now load full chr's into the screenpainter and use them as i wish. the moral of the story here is that while i simply brutedorced nesmaker to do what i want it to do, the point is that it can simply be outsoruced from the tool. using nesmaker as an IDE to make a game, doesnt mean you have to use nesmaker to draw screens. I do a lot of the screens of DS with shiru's screen tool. it all boils down to how one wishes to use the tools provided, and the limitations that come with them.

it's a digitized picture made out a combination of a drawing I made and a photograph I used in conjunction to get a more realistic feeling for the sky. the title screen girl image is also a digitized image I drew, scanned, and then converted to play nice with the NES. while I'm quite pleased with how the currently implemented graphics look, it is worth a mention that at this point in time, literally everything aside the character sprite design and the title screen are WIP and subject to change. edit: i cant spell

i believe the point Joe was trying to make with his comparison of NN and NESmaker was that like he said himself, you CAN load an empty module into nesmaker. which then does not assumen a single anything about your game. Yet the example code is still there. to your empty module, you CAN load a routine to read a controller. Yes, it comes with modules that lock you in ways, and do A LOT of the dirty work for you (a full, albeit simple, in some ways game engine.) but you can also get nesmaker, and start from literally nothing but code examples that are bundled with it. as far as my case goes... dont tell this to Joe but I had to go and take a Hex editor to nesmaker already to make it do some things it doesnt normally do, because that's how much different the codebase is now, it quite literally does not even load into nesmaker without throwing hissy fits about a lot of things, including the fact that we compress our CHR's and we set them up completely differently than nesmaker's default chr allocation is set-up. I also have the added excitement of having the UI crash on me if i click on certain elements on it, such as the object handling as such, im still learning the ropes here, and nesmaker is a fairly secure enviroment for taking one's first steps, so im not willing to completely ditch it just yet.

Hey all. Due to the (un)popular demand, I decided to dedicate a thread for this project too, so here we go. Dimension Shift is a platformer I'm making together with FIX94, an extremely talented Assembly programmer and programmer in general. the game itself is designed and illustrated by myself, along with programming work split between myself and FIX94, who more focuses on engine programming, while I dabble in feature programming (honestly, we both just do whatever, but I suck, and he doesn't so...) all the audio in the game is composed using famitracker by Jeremy Sebastiano (aka. Digit2600) The project started as my personal test to see how hard can it be to make a nes game, so I bought nesmaker and started putting things together. FIX joined me after he saw my first test rom of the game and was "dissappointed that all my efforts go to waste because the game engine is so limited" so he poked at it until we turned nesmaker's engine into a bi-directional scrolling platformer. that rom was submitted to the nesmaker's byte-off competion where it fetched best pixel art award, and gave us the needed motivation to do the move over... fast forward 9 months, the whole game engine has been redone, more graphics designed, the story fleshed out and we are at this day (november 15th 2019 at the the time of writing.) i've learned quite a bit of how to bend the NES to my will. (FIX is just happy he has to rewrite less of the things i wrote to make something that doesnt waste 99999999 cpu cycles lol.) this is a mapper 30 rom, and the engine currently features cool things such as; - 4directional scrolling with automatic scroll correction and dynamic scroll locking per screen (H only, V-only, Free movement) - full chr ram bankswitching - makeshift scanline counter (mapper 30 doesnt have this feature, so DMC IRQ is used for midframe screen splits) - separate "cutscene engine" with full upper and lowercase text printing. Capable of drawing 1024 unique tiles + text font per screen - parallax scrolling and of course the usual things needed for a game, such as funky physics yadda yadda. the project is going forwards somewhat smoothly, we are currently missing an entity handling system and a good pile of stage design. all the basic mechanics of the game are in various states of working order, physics, wall climbing, attacking, hud, money, health etc etc. the latest big addition was the completion of the weapon metasprite system that allowed implementing multiple weapons that all have their disdinct characteristics. different damage, different attack speed, different hitboxes. and so on and so on. the gameplay style is rather faithful to shatterhand where i draw a lot of inspiration from. the game will feature 7 playable stages including the really short intro stage, a stage selection screen, an array of obtainable weapons, ability to revisit stages, fancy boss fights, flashrom save/load feature, and propably a lot more that I just forgot to type here. I really dont want to say anything about when this game will be completed, but it will be eventually done, in one form or another. this my first time doing pixel art and my first time programming a game and my first time programming in 6502 so be gentle. few screenshots below.

thanks for the interest but im not sure there's much point in making a thread about it. what would i put there ?

you're making webpages on nesmaker ? amazing!

i am having this too, although, i simply let it shift since im using a modified theme on my windows that turns it dark, and also alters the text color. this has caused several websites that do not specifically define a text color (they use a windows default) to appear as dark. generally the solution to this is to define the text color in the site's css to always have it be the same, but sounds like its' not the case here.

the difference here is that apparently somehow solegoose thinks that nesmaker writes my code instead of me. im fine if im being scoffed at because X or Y has better functionality for writing text, but yeah. it is true that you can load a module into this editor, that comes packed with things, some of which you still see on the list in my picture. in the case of this particular project, the defaults i havent cleaned out yet, are either empty, or not included in mainasm.asm anymore. I tend to clean the list as i go, since last time i did a major cleanup of reordering and relabeling everything, half of the game stopped working and i had to roll to a backup from a week ago, so i decided to just clean it up when we're done with it

for the sake of continuing the topic's conversation though, here's a picture of Dimension Shift's source code in it's working enviroment (nesmaker's built-in script editor) on the left are "tabs" of included .asm files, and on the right is a list of defined macros (the bottom part of the screen displays the content of the macro when selected.) why does writing a game in this enviroment classifies it differently than if you use notepad to write an .asm file ? pictured code is indeed written from scratch by yours truly, instead of somehow magically generated by nesmaker. you're looking at the weapon metasprite draw array of the weapons in the game.

there is not ? i was under the assumption that all programmer kinds serve the same masterbrain in a glass-jar.... ah, another childhood illusion broken jokes aside, it's just extremely disheartening to get treated like that, if even just one member of the community.

well, maybe I do. still doesnt change the fact he's double standarded in his whole crusade over labeling people using nesmaker as a tool as opposed to using anything else as a tool.

i've repeatedly been saying here that it should not just be labeled as this and that due to the fact that it has actually been programmed mostly from the ground up. (as i said, it's built over the tech demo i submitted to byte off, which was made on nesmaker) hence after, scrolling, screen loading, physics, sprite draw routines, graphics loading routines input routines and practically everything else aside the object handling system has been collectively removed and/or rewritten. the reason the game never displays enemies is because nesmaker's object routine is still used in the engine, and as it's not compatible with our own routines, it is not working at the moment. i find it especially insulting from him that he keeps insisting this, while dodging the repeated request of categorizing his own work based on tools, nor providing any insight on his opinions aside the stone hard insistment of forcing everyone else to categorize their work in certain ways, and now he even compares our project to a making of a romhack, which honestly feels really insulting to me. i started from absolute scratch with assembly when i made my nesmaker demo, and now that i've finally after almost a year of non-stop working gotten a fairly functional game engine running with my friend, he still insists that it has to be labeled as something that was somehow less work and tool assisted.? are all my future homebrews "nesmaker productiosn too" if i happen to reuse code from my current project in them too ? how do i become a "real" homebrewer then ? or is it that i can't become one now that i've learned how to write assembly code from looking at the sourcecode of nesmaker's engine?

he just doesnt want to create such a list because his own creations use just as many tools as everyone else's so it "takes off from his work" OMG SoleGoose used a tool. No, it just has to be stated for other people because it makes him look better when people think that he wrote nametables by hand while other people used screen tool. i will hop off this discussion now though. It' has become obvious to me that new people are not welcomed to "nes homebrew development" so i will go back to play with legos. thanks for everyone so far on the kind words towards the not a real homebrew game we're making. I appreciate it.