TylerBarnes

There is always Bankswitching for multiple different non-bankswitching NSFs. UNROM is cheap and has 7 switchable bank and a fixed bank at $C000. I have never used famitracker and thus have never looked at the text exporting, the difference between 0CC vs vanilla, nor the documentation for Famitone2. However, intercepting values to be displayed as sprites may require a solid understanding of how famitone operates. The binary file that the famitone converter spits out may or may not be in a useful format to also dip into as for a visualizer. I think something can certainly be made that is a cool animation or visual aspect to keep things interesting on screen. I wish more people used ppMCK though . You can poke values directly into RAM with the y command at any point during the song. Those could be used to very easily sync the timing of a track to any subroutine in the main code.

Writing sprites is easy. Can you elaborate what you mean by 'read the output of the famitone tracks'? What data are you trying to target and turn into a sprite?

I know it's early stages, but any thought into the UI design and all that, Identity of the cart, Animation/visualization, Mapper, etc? And if you are allowing samples, it may also be wise to set a specific sample set that the cart uses so they can be left at $C000 (the start of the fixed bank) for all the tracks to use. This can save space if we all use the same samples. There has got to be a good kick, snare, etc combination that would be good for multiple tracks. Could help meld the tunes together a bit and make the release more cohesive. (Though, I have no idea how Fami takes care of samples. I assume it's the same as ppMCK since for bankswapping they would have to be in the fixed bank.)

Hmmmm, I will have to learn Fami if this is the case. I use MML/ppMCK for all my NSF tunes. The multiNSF exporting and |:loops:| I can create to save space are really nice Any chance you could point me to the version of Fami one should be using these days? Just the latest release or some fork out there?

I am in. Been working a lot on my assembly chops lately too.

If you need another artist and assembly coder, I am 100% down.

Ep13 - Door Sprites (Adding door graphics) https://youtu.be/f1tPyVKJvik Ep14 - Door States pt1 (making a system to choose what door to draw depending on the room your in and what states the door is in) https://youtu.be/u4jAeOOaq3g Ep15 - DoorStates pt2 (Continuation of adding the doors unique to each room, dealing with branch out or range errors) https://youtu.be/KDxOK8I3WUA Source (Ep15) https://app.box.com/s/js1eqp8pdq53c37swr8otnrdeqq6aq6c

It was a pretty killer tune. Many differing sections, good energy in all of them.

CRT is preferred since the system I use output an analog RGB signal. So I run them on Sony PVM monitors.

I don't think anyone does. lol. So your thread isn't useless. Your use of the triangle was really nice. I like when people try and get the most out of it. Don't mind if I do: https://app.box.com/s/jnmi32x8acg6llhdyv1tt6o8exafaz8s (drums are recorded, not chip)

You have a store? Anything online? I'm always looking for grimey and cheap carts to deflower for boards ^_^

Feel free to join the Chiptune Club. Us chippy tuners are always welcoming ^_^ For those us of us that don't use Fami for NES music (I know, it's like sasquach, but we exist) do you have an NSF of your post song?

This is certainly a difficult thing. In many cases I have found an elegant small pixel pattern to convey some graphical aspect or feature and looks super in emulator when all the pixels are seen, then once the CRT or composite on LCD come into play it gets obscured away. Also on the flip side I have had things look great on CRT composite while being only terrible on LCD composite.

This is my feeling from the start. This was never posed at any point. RGB is demonstrably better in every technical aspect compared to composite. The point was in spite of the low quality and limitations, this is the platform in which games where very often made for and expected to be run on. Thus some of the quirks are going to be lost on higher quality platforms that do not have the flaws that devs are exploiting. So effects that they intended you to be seeing are not present. You seem to be arguing to a straw man since the beginning. and I don't understand the amendment vigor at which you feel you need to step in and debunk what people are saying, when it in fact is not what they are trying to convey. Sorry Mugi for the derail. While about composite video, this was not really relevant your inquiry.

I guess I just don't understand the evaluating peoples statements on the matter as simply equating what they have to say as 'making blanket generalizations that don't hold true'. All while at the same time asserting what you believe to be true, even posing this belief on behalf of the original developers. Per your statement "I don't believe dithering was ever intended to abuse composite video at any point" The graphics history behind composite video is rich and while not every dev in history took any mind to it and it's affects, a very large number of them have took very careful and calculated approaches to maximizing composite and, yes, designing their graphics for it. CGA for example makes incredible use from exploiting composite video for rich and colorful games that are otherwise impossible for the technology to produce. I implore you to do some supplemental research on the subject before imposing your personal opinions on the intent of certain technologies/techniques on the entire community. Also before speaking on behalf of another dev. CGA Artifacting through Composite: https://int10h.org/blog/2015/04/cga-in-1024-colors-new-mode-illustrated/ https://bytecellar.com/2019/01/06/my-first-taste-of-cga-composite-color/ https://www.youtube.com/watch?v=niKblgZupOc I'll leave any dithering research to you since you seem to have made up your mind on the matter.

^^ Found one!!! In all seriousness I prefer RGB and anti aliasing off on everything. But conflating my words into semantics in which I was not proposing, when you understand my intent and meaning, is a disingenuous way to discount an entire point. Devs expected their games to be played on composite for the most part. Like 95% of users for the most part. And many affects like dithering depend on it. You are not required to still use composite, but it was the platform in which they expected their consumers to play on. Thusly, the composite tricks and differing, etc on a composit monitor are 'how they intended the game to look' to the consumer.

There is a big divide actually from campers in your position vs the high definition peoples. Consoles like the Genesis have games that use dithering to simulate transparency (i.e. famous sonic waterfalls) that do not looks as the developer intended if using RGB or high definition options. Same with the heavy dithering algorithms on the PS1, it is much more natural looking through composite a lot of the time and actually counteracts heavy banding of colors/shades. So using composite for many cases is actually a very genuine way to play games and you are looking at them how the developer intended them to look. Obviously, on the other end you have your RGB, S-Video and PVM enthusiast that want to count every pixel on screen.

I'll sure miss this mystical one armed old timer.

To ask such a question you would have to define your terms more explicitly. Saying 'Nintendo Game' to just about 80% of people merely implies a game that is playable on, and runs on a Nintendo Console. By that definition homebrews and unlicensed games fit that category. If you are instead defining your term of 'Nintendo Game' as 'A game that can be attributed to Official Nintendo releases and games greenlit by Nintendo themselves' than a license is explicitly a requisite for that, and if that is your definition your question does not make sense to ask, since the parameters for defining a 'Nintendo Game' became a tautology. For these reasons I will assume the heart of your question is really meant to ask where people fall on that line between the literal and legal defining of the term. My answer is both are valid definitions because in our language 'Nintendo' is both a company and a console. Depending on how your are using the term , the answer to your question will differ.

Added Episode 11 and 12 Ep11 - Room Management https://youtu.be/QbBbDVAQAHA Ep12 - More Rooms/LoadingZones ( Adding rooms into a 2D grid configuration and indexing address tables with X+Y*Width )https://youtu.be/u-40NkTkpcY

What keywords are you using? I don't see anything while using the 'Konsolation' keyword..

This looks great. It is just announced? I don't see where to purchase it EDIT. Nevermind I see it was a bundle. Sad day.

This looks really really cool. I would like one if you do physicals. What mapper is it using? Thinking if that might be getting in the way of making physicals easily

Well, I would love to make a little homebrew NES game sometime. I enjoyed making Moonfall, but this was mostly centered around the music, and the rom was basically a glorified title screen (Which was great for me as a first project since I was not biting off more than I could chew). So, I would love to continue learning more, and making a simple little game.

Ok, so rather than creating a bunch of threads I'm going to just make this one to share and link to the videos I am making, coding some assembly. They are in a weird order so some simple stuff may not necessarily be at the beginning. Hopefully someone can be entertained and learn something along the way. Disclaimer: I am still learning myself, so I am not an expert. (join me as I make mistakes and fix them, lol) I also just like talking about this stuff to get my own thoughts in order and understand better. Plus, hopefully someone more experienced can correct me if I'm doing things really wrong. RLE Decoding: Ep 1 - RLE Decoding: https://youtu.be/gP6T8XILdLE Ep2 - Setting up NROM: ( and testing RLE decoder) (ERROR in this video: RTS after the interrupts should be RTI; Fixed in Ep5) https://youtu.be/VK7G_FwdBU0 Ep3 - Adding Directives to the Decoder: (Reading uncompressed strings and doubles) https://youtu.be/lRGhBAKAZl4 Ep4 - Adding More to Decoder: (Reading repeating strings) https://youtu.be/c-gybd0lSM4 NROM Game Building: Ep5 - Displaying Sprites: (and Debugging a Stack OverFlow :P ) https://youtu.be/SkIAcy_ziBc Ep6 - Reading Controllers: (And moving the Sprites) https://youtu.be/GSyLQWfC76Y Ep7 - Background Collision Detection (using a 120 byte bitmap) https://youtu.be/RdFoYswNOpI Ep8 - Sprite Collision Offsets https://youtu.be/I0GxTQl8zog Ep9 - Managing Nametables (and moving the RLE decoder to a subroutine) https://youtu.be/RAkT5ANjKX0 Ep10 -Adding a Loading Zone (to load another room) https://youtu.be/HR6PRMHZkvM Ep11 - Room Management https://youtu.be/QbBbDVAQAHA Ep12 - More Rooms/LoadingZones ( Adding rooms into a 2D grid configuration and indexing address tables with X+Y*Width ) https://youtu.be/u-40NkTkpcY Ep13 - Door Sprites (Adding door graphics) https://youtu.be/f1tPyVKJvik Ep14 - Door States pt1 (making a system to choose what door to draw depending on the room your in and what states the door is in) https://youtu.be/u4jAeOOaq3g Ep15 - Door States pt2 (Continuation of adding the doors unique to each room, dealing with branch out or range errors) https://youtu.be/KDxOK8I3WUA *Source Available in video description Ep16 - Door Collision https://youtu.be/5GD2qksFAdI Ep17 - Eureka!! (Refactoring a dumb method into a smarter one ) https://youtu.be/k1eHkUCrXb4 *Source Available in video description Ep18 - Player Graphics (Adding some player graphic sprites to replace the test doughnut) https://youtu.be/kSKiXkRO2XA *Source Available in video description Ep19 - Walking Cycle Animation (Adding a walking cycle animation https://youtu.be/USWtX9A6ebk *Source Available in video description