nesdev.org

Movax12 wrote:Oh, I never use those. That could be a problem.

Ha. Give them a try. You might learn why I prefer asm6...

It's probably not as difficult as you think to switch to ca65, between using a text editor's search-replace and using the .define feature to support asm6 directives, etc. no, it probably is. the lack of +/- labels that work the same as asm6 in particular stands out. also i've written just a lot of ...

I want this feature too (it's too late for me to go back to ca65 now). I'm having a look over the asm6 source. It doesn't seem too bad to me. I may attempt adding the feature.

What I've learned: the next time I announce something of this sort, I will be sure to lock the thread immediately once created. Hey, koitsu, sorry I started off with criticism and only that - I really am fascinated by the production and love this news showing that commercial homebrew is alive. Read...

It doesn't use MMC5 but MMC4. > The music with the vocals that played at the end of the video demo was cool Thanks! I composed the song :) Nice work, it's super catchy. Do you have a soundcloud or some link with more of your music? I feel like since you speak English (assuming you're Japanese?? no ...

Seems familiar. There is a whole space of alternate implementations, each trading different things off, and each more appropriate for some use. If you go full-speed down one, you might see another nearby one that was better for your uses. Or you want to take two or more approaches as far as they go...

Yeesh, the gameplay looks so monotonous (you just collect stars...?) can't believe such a simple game was wasted on an MMC5. Going to guess that it was used just for the extra sound channels. The music with the vocals that played at the end of the video demo was cool ... it would be awesome if that ...

Banged out a brand new compiler supporting DTC and several useful bonus features. Converted the player's script, and got it working fairly quickly: \ these aren't even used here ... just an example of adding asm routines code{ uplus tsx clc adc $102,x sta $102,x vmnext_pla } code{ twostore tax pla s...

Nice, thanks for posting this. My game may or may not use a lot of text but if it does this might be a life saver

tepples wrote:The character looks rawther big for the apparent map scale, even given the scale distortion common in 8-bit overhead games.

It's just a test map.

I've been working on this thing almost non-stop. Upgraded to UNROM (128KB ROM) + 8KB PRG RAM + CHR RAM, great to have some legroom! I'm using tokumaru's graphics compression now too. Even so if I'd stayed with NROM I would have hit the ceiling already. I made a small overworld and put it in. There's...

The speed increase, as I thought, wasn't as dramatic as I originally hoped. Debugging the DTC version was a BITCH due to the instruction pointer being pre-incrementing now. But the savings in the test program after everything was about 4 scanlines. I tried to get literals down as much as I could, bu...

Well the desire for speed and more efficient nesting has led to yet another "rehaul" (though not as big as the last one) and I am thinking of moving to 16-bit "opcodes" (really 16-bit direct threaded code, classic Forth) Right now I'm not sure if it'll be worth the effort to imp...

Then make "separate files for each character, item, font, and so on" like tokumaru recommended, and load multiple files into CHR RAM before the level starts. Yeah that's how I would do it - I guess I was just confused, for some reason I got the idea that the compressor expected 256 tiles ...

Well, I don't know how other people usually handle their graphics, but I usually don't have a single CHR file. I have separate files for each character, item, font, and so on. Depending on which tiles will be used at the same time I merge the files to create blocks of tiles that I can compress. I d...