NESmaker update
Page 2 of 2

Author:  Bananmos [ Tue Feb 27, 2018 9:58 am ]
Post subject:  Re: NESmaker update

Forgive me for being dense on this point...I admit, I completely am not sure the benefit, still.

If there is an
.include "Routines\NMIroutines\NMIcode.asm"
, and that NMIcode.asm is exposed in the tool...what functional benefit would be gained from determining its address or making that address changeable again? If the question is about including custom NMI could just put that in that code, no? I'm not sure variable NMI address makes that any easier.

Maybe I'm completely missing the use here. Sorry for being dense on this point! haha

The benefits would be that the NMI address solution gives me complete freedom to define my own NMI/IRQ during a cut-scene/screen transition without messing around with your source code (which may change from version to version). And I really don't want to re-write your source code to get my code to do it's thing, or have to maintain a changing source patch set for your code generation. It's an extra hurdle to go through, and gets even worse if I have to explain a source-hacking process to one of your future users, who may not be tech-savvy at all.

Again, you seem to be coming from the viewpoint that there would be one type of user of your tool who would start out with no programming knowledge and use your tool to gain confidence, hack around and gain more programming experience by slowly extending the code produced by your tool. And that's a great use-case, as you've said.

But another use-case I would like to see is collaboration between the users who use the NESmaker tool and users who write their own asm from scratch, in the assembler of their choice. And that's why I'd like to see this process be smooth both parties. And frankly I'm a bit surprised that you don't seem to be at all keen on this?

Interesting. Yeah, I can see that.

I mean, you'd lose a few NMI cycles, but you could likely do a quick table read in custom NMI code to achieve the same results, no? Rather than variable NMIs, variable places to jump within an NMI?

Yes, a jump table with an index could do most of the same trick to trade CPU cycles for RAM usage. Though I am curious why those 2*2 bytes of RAM are suddenly so vital not to waste, given that you previously said storing the object's direction was an unnecessary optimisation? ;)

Also, the thing I like less about the jump table idea is that combined with mapper30's limitations, it means that any "plugin" code I'd write would be more sensitive to changes in your NMI code. An NMI/IRQ that always starts with a "JMP (addr)" means I know exactly how many cycles the NMI/IRQ has already spent, and code that is sensitive to timing won't have to be re-written if you choose to re-structure your NMI code.

So yeah, if you can give us guarantees that the jump table you envision will be pretty much set in stone and not move around, but always be the first part in the code *and will take a constant number of cycles*, then it would be functionally the same as the indirect jump. But otherwise I still feel it's making extending NESmaker a lot harder than it needs to be.

Author:  JoeGtake2 [ Tue Feb 27, 2018 10:08 am ]
Post subject:  Re: NESmaker update

All these are great things to keep in mind. By the way, I'm not trying to be confrontational at all - just trying to clarify and see if there are other particular reasons for the need. It's a great hope that people start bending and breaking this tool to do all sorts of things we didn't anticipate!

As for why not do it that way - well...that's just not the way it's currently set up, and using table reads is much more in line with how the tool handles most variable things of this nature. I'm not adverse to any solutions, but I think first order of business is to punch through the working beta on course, and get some feedback to see if what's there can meet these needs. So let's absolutely, 100% put a pin in that idea and see if it makes sense once people are using this in ways we didn't anticipate. :-)

Author:  Bananmos [ Tue Feb 27, 2018 11:14 am ]
Post subject:  Re: NESmaker update

As for why not do it that way - well...that's just not the way it's currently set up, and using table reads is much more in line with how the tool handles most variable things of this nature

Well, of course it's not how it's currently setup. If you're only making one type of game (Mystic Searches), then an easier-integration-with-other-code-feature is not high on the priority list to get your game shipped. ;)

But when you're now making a gamemaker for 2.5k users, it suddenly makes sense to spend a bit time of yours, to make the users spend less time repeating the same hacks around your solution. Simple economies of scale. :)

Table reads could work, but would be a bit slower. And you still haven't said whether this would guarantee that the NMI/IRQ would be a fixed and constant amount of cycles between versions?

And how would this solution deal with bank-switching? Also by reading from a table that is indexed by the game-state? And you'd do the same for the IRQ?
That could work I guess... not a terrible solution by any means. Even if I'd prefer the variable address for the reasons I've mentioned. (mainly that I can always trust your code to do nothing but that indirect jump instruction, and won't have to count all the cycles your code takes to do the table lookup and indirect jump)

Author:  caramelpuffpuff [ Tue Mar 06, 2018 1:25 pm ]
Post subject:  Re: NESmaker update

I know my comments would be discarded or unlistened, but NESMaker needs to get a communites, even from big-brain people's, helps if the software wished to recieved love and attentions. There may need to be people who should've helped out with the coding to make NESMaker bigger than we all think of, like Shiru's C coding adaptations, and DahrkDaiz's special programs that pushed Super Mario Bros. 3 hack over the limits. The idea / opportunities for NESMaker is really big to be made just by small people.

Page 2 of 2 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group