Aren't you afraid that NES Maker would just bring lazy noobs

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

pwnskar
Posts: 119
Joined: Tue Oct 16, 2018 5:46 am
Location: Gothenburg, Sweden

Re: Aren't you afraid that NES Maker would just bring lazy noobs

Post by pwnskar » Thu Apr 23, 2020 6:12 am

Controllerhead wrote:
Tue Apr 21, 2020 3:06 am
If only there were a tool that offered point and click game creating / editing with the flexibility of modifying the engine under the hood. Nothing like that exists currently to my knowledge. ...Well, that "thing" may soon exist. That is all i can say about it, for now =)
You got me thinking of Maniac Mansion and the SCUMM engine. Does anyone know if it would be possible to derive SCUMM from a disassembled rom of Maniac Mansion? I don't know how SCUMM works, but what I'm wondering is if you could actually find scripts and parsers for those in the rom. Or maybe SCUMM compiles all that into assembly and leaves no trace of itself in the rom?

Anyways, your insinuation sounds interesting. Good luck! :)

User avatar
gauauu
Posts: 706
Joined: Sat Jan 09, 2016 9:21 pm
Location: Central Illinois, USA
Contact:

Re: Aren't you afraid that NES Maker would just bring lazy noobs

Post by gauauu » Thu Apr 23, 2020 7:05 am

Controllerhead wrote:
Tue Apr 21, 2020 3:06 am
If only there were a tool that offered point and click game creating / editing with the flexibility of modifying the engine under the hood. Nothing like that exists currently to my knowledge. ...Well, that "thing" may soon exist. That is all i can say about it, for now =)
Um, pretty sure that's what NESMaker actually _does_. I mean, I've heard reports that it isn't actually very GOOD at that, but at face value, you just described NESMaker.

lidnariq
Posts: 9782
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Aren't you afraid that NES Maker would just bring lazy noobs

Post by lidnariq » Thu Apr 23, 2020 10:47 am

pwnskar wrote:
Thu Apr 23, 2020 6:12 am
You got me thinking of Maniac Mansion and the SCUMM engine. Does anyone know if it would be possible to derive SCUMM from a disassembled rom of Maniac Mansion? I don't know how SCUMM works, but what I'm wondering is if you could actually find scripts and parsers for those in the rom. Or maybe SCUMM compiles all that into assembly and leaves no trace of itself in the rom?
Yes, you can extract the SCUMM data from the NES release of Maniac Mansion. SCUMMVM can run it. See this very old thread.

User avatar
poorstudenthobbyist
Posts: 134
Joined: Fri Jun 24, 2016 4:20 pm

Re: Aren't you afraid that NES Maker would just bring lazy noobs

Post by poorstudenthobbyist » Sat May 02, 2020 11:40 am

I've been interested in trying out making my own NES games. Now that it's been out for a while, is NES Maker considered a good tool? I do know how to code assembly, so that is an option, but I've never attempted programming a game with it.

User avatar
dougeff
Posts: 2763
Joined: Fri May 08, 2015 7:17 pm
Location: DIGDUG
Contact:

Re: Aren't you afraid that NES Maker would just bring lazy noobs

Post by dougeff » Sat May 02, 2020 12:42 pm

I would say the reviews have been mixed. I've seen a few people who HATED it. And there are over a dozen people who have made complete games, who seem to love it.

If you don't know assembly, and you don't really want to dive into that, then NESmaker is pretty much your only option. Well, there is coding in C. Which I have done. That option is more for very small games.
nesdoug.com -- blog/tutorial on programming for the NES

Bananmos
Posts: 532
Joined: Wed Mar 09, 2005 9:08 am
Contact:

Re: Aren't you afraid that NES Maker would just bring lazy noobs

Post by Bananmos » Sat May 02, 2020 12:54 pm

poorstudenthobbyist wrote:
Sat May 02, 2020 11:40 am
I've been interested in trying out making my own NES games. Now that it's been out for a while, is NES Maker considered a good tool? I do know how to code assembly, so that is an option, but I've never attempted programming a game with it.
Well, the people using it have managed to make some very playable and fun games - checkout last year's byteoff competition. They prove that with patience, creative people with no background in nesdev can whip up some really cool stuff.

Personally, I gave up / put any learning on ice for the time being. As a tech-inclined dude who's been on-and-off with the NES for donkeys years it just wasn't all that fun beta testing a work-in-progress... and running into very arbitrary engine limitations / UI quirks I personally wouldn't have put in place, had I had the time and motivation to make something of that scope myself.

But I'm not really the target audience for the tool... I backed it primarily because I figured it would introduce more people to this quirky nes development hobby of ours. And from that point of view, it's "mission accomplished" :)
And I still really dig the idea, and hope that when the "Strategy Guide" reward will finally be delivered, the tool will have matured enough to be more fun and easy to use, at which point I'll probably re-visit it.

It really boils down to what your motivations are. If you've always wanted to make a NES game but aren't sure where to start - and you aren't the "control freak type" who really wants to write and optimise every byte of your code by yourself - then I think NESMaker is a good tool to start out with. It might not be perfect or suit everyone's game idea, but there's not really that many alternatives which offer as easy a path to creating your first semi-large game. So I'd say give it a go.

User avatar
DRW
Posts: 1984
Joined: Sat Sep 07, 2013 2:59 pm

Re: Aren't you afraid that NES Maker would just bring lazy noobs

Post by DRW » Sat May 02, 2020 7:30 pm

dougeff wrote:
Sat May 02, 2020 12:42 pm
Well, there is coding in C. Which I have done. That option is more for very small games.
Why would coding in C only be for very small games?
My game "City Trouble": www.denny-r-walter.de/city.htm

User avatar
Banshaku
Posts: 2393
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

Re: Aren't you afraid that NES Maker would just bring lazy noobs

Post by Banshaku » Sat May 02, 2020 11:09 pm

DRW wrote:
Sat May 02, 2020 7:30 pm
Why would coding in C only be for very small games?
I think the reason he said but he can correct me later is if you use only C and something like neslib you will be limited after a while compared to someone who can add some code in asm to improve performance. Seen that way, it make sense.

Bananmos
Posts: 532
Joined: Wed Mar 09, 2005 9:08 am
Contact:

Re: Aren't you afraid that NES Maker would just bring lazy noobs

Post by Bananmos » Sun May 03, 2020 5:15 am

I don't think performance is the key issue here.

As you try to scale up a one-screen minigame to something larger on the NES, you inevitably run into more problems of asset management, tackling issues of having to choose compression formats for levels, how to carefully partition your banks, etc. With all the subtle bugs you can get by jumping to the wrong bank. My guess is that this is actually what a lot of newcomers get stuck on.

NESMaker does a lot of that for you - mainly because those design choices have already been made for you, for better or worse. It might not do it in the most clever/optimal manner. But using somebody else's design flow that at least works avoids you getting stuck on the most tedious bits of developing for a system that was so reliant on bank-switching. The fact that the tool also serves as a visual asset manager also helps here.

And using C is of little help here. In fact, it often hides the core problem: That you should first and foremost think about how to store your data, and do as little processing of your data in code as possible, doing that data processing offline whenever possible. You could even argue that writing assembly from the start is a good whip to make you more inclined to avoid complicated logic in game code that shouldn't be there in the first place...
Last edited by Bananmos on Sun May 03, 2020 7:39 am, edited 1 time in total.

User avatar
dougeff
Posts: 2763
Joined: Fri May 08, 2015 7:17 pm
Location: DIGDUG
Contact:

Re: Aren't you afraid that NES Maker would just bring lazy noobs

Post by dougeff » Sun May 03, 2020 7:15 am

Why C has smaller games?

Most of the neslib example code is for NROM sized and runs less efficiently than asm, so the scope of the games in C tend to be smaller.
nesdoug.com -- blog/tutorial on programming for the NES

User avatar
aa-dav
Posts: 106
Joined: Tue Apr 14, 2020 9:45 pm
Location: Russia

Re: Aren't you afraid that NES Maker would just bring lazy noobs

Post by aa-dav » Sun May 03, 2020 7:57 am

In my opinion/experience 8-bit systems of NES era comply with rule: assemblers produce code with max speed, compilers (like C) are slower by ten times and interpreters (like Basic) are slower than compilers by ten times again.
For NES where we have to fit in vdraw/vblank narrow limits it can be serious issue.
However, for example, I know that Shiru makes demos with C code as 'control center' and assembler inlines for critical code and these demos are great.
Also, there is great possibility to speed up C code in 8-bit processors by removing high-level constructs: local variables, parameters and some other stuff. I remember 8-bit Basic at this point: absence of real functions/procedures, GO SUB / GO TO and bunch of global variables. So, if we'll write in C in this way I think we could speed up resulting code. I never try it and do not want to generate such C code, but I wonder how fast it could be in comparison to assembler.

User avatar
DRW
Posts: 1984
Joined: Sat Sep 07, 2013 2:59 pm

Re: Aren't you afraid that NES Maker would just bring lazy noobs

Post by DRW » Sun May 03, 2020 11:35 am

dougeff wrote:
Sun May 03, 2020 7:15 am
Why C has smaller games?

Most of the neslib example code is for NROM sized and runs less efficiently than asm, so the scope of the games in C tend to be smaller.
What does C programming necessarily have to do with neslib? I do my games in C and I have never used neslib.

O.k., now the question is: Are you only talking about games that are purely written in C and where every Assembly stuff is from an external library? In this case, yeah, it could be pretty bothersome.

Of course, my games have at least some basic functions in Assembly: NMI, sprite updates etc.
And in my current game, I have a bunch of inline Assembly functions, mostly for accessing arrays through a pointer because cc65 isn't clever enough to omit copying your pointer to ptr1 every time you use it, even though your own pointer is also in zeropage.

But other than that, most of the stuff is pure C. And my current game is far from being small.

aa-dav wrote:
Sun May 03, 2020 7:57 am
In my opinion/experience 8-bit systems of NES era comply with rule: assemblers produce code with max speed, compilers (like C) are slower by ten times and interpreters (like Basic) are slower than compilers by ten times again.
Yeah, sorry, but that's absolute bullshit. "Super Mario Bros.", a highly-optimized game, gets down to its knees when it has, what, six flying fish on the screen? Or less? And those don't even have any interaction with the background, only with Mario himself.

According to the logic that high level compilers are 10 times slower, I wouldn't even be able to implement a single character in a game mostly written in C. Feel free to download "City Trouble" and tell me whether you encounter any lag anywhere with four active characters and a taser weapon on screen at once.
And this game doesn't even have the above mentioned pointer optimizations.

aa-dav wrote:
Sun May 03, 2020 7:57 am
Also, there is great possibility to speed up C code in 8-bit processors by removing high-level constructs: local variables, parameters and some other stuff. I remember 8-bit Basic at this point: absence of real functions/procedures, GO SUB / GO TO and bunch of global variables. So, if we'll write in C in this way I think we could speed up resulting code. I never try it and do not want to generate such C code, but I wonder how fast it could be in comparison to assembler.
Generating this kind of code is half as bad. The end result still looks pretty clean.
For example regarding local variables: I have a bunch of global zeropage variables that are then renamed via #define within functions.
And function parameters can be simulated with macros.

So, it's not like fast C code for the NES looks like a total mess.
My game "City Trouble": www.denny-r-walter.de/city.htm

User avatar
gauauu
Posts: 706
Joined: Sat Jan 09, 2016 9:21 pm
Location: Central Illinois, USA
Contact:

Re: Aren't you afraid that NES Maker would just bring lazy noobs

Post by gauauu » Sun May 03, 2020 7:56 pm

Yeah, I don't really get the statement that you wouldn't write big games in C.

C can be a lot slower than assembly (although yours have to write pretty bad C for it to be 10 times slower), so you'd have trouble with cpu-bound things. (Either complex tricky code or just number of entities you can deal with efficiently). But that's tangential to the size of your game.

User avatar
aa-dav
Posts: 106
Joined: Tue Apr 14, 2020 9:45 pm
Location: Russia

Re: Aren't you afraid that NES Maker would just bring lazy noobs

Post by aa-dav » Sun May 03, 2020 9:16 pm

gauauu wrote:
Sun May 03, 2020 7:56 pm
although yours have to write pretty bad C for it to be 10 times slower
I would say opposite: you have to write pretty bad C code to speed up things.
Let's get this typical C code (which is really spirit of C language):

Code: Select all

void str_cpy( char *dst, char *src )
{
	while ( *dst++ = *src++ );
}
And compile it with CC65 with -Oirs flags (full optimizations).
We'll get next assembler output:

Code: Select all

.proc	_str_cpy: near

.segment	"CODE"

	jsr     pushax
L0002:	ldy     #$03
	lda     (sp),y
	tax
	dey
	lda     (sp),y
	sta     regsave
	stx     regsave+1
	clc
	adc     #$01
	bcc     L0006
	inx
L0006:	jsr     staxysp
	lda     regsave
	ldx     regsave+1
	jsr     pushax
	ldy     #$03
	lda     (sp),y
	tax
	dey
	lda     (sp),y
	sta     regsave
	stx     regsave+1
	clc
	adc     #$01
	bcc     L0008
	inx
L0008:	jsr     staxysp
	ldy     #$00
	lda     (regsave),y
	jsr     staspidx
	tax
	bne     L0002
	jmp     incsp4

.endproc
Well... It's really even optimized, but 'ten times slower' looks like underestimation here. This code struggles with loading/saving values from/to C-stack and just look at the procedute staspidx:

Code: Select all

.proc   staspidx
        pha
        sty     tmp1            ; Save Index
        ldy     #1
        lda     (sp),y
        sta     ptr1+1
        dey
        lda     (sp),y
        sta     ptr1            ; Pointer now in ptr1
        ldy     tmp1            ; Restore offset
        pla                     ; Restore value
        sta     (ptr1),y        ; Store
        jmp     incsp2          ; Drop address
.endproc
Well, this regular, normal and clean C code is bad for for 6502.
If we need speed we must rewrite it at least to pass pointers as zero-page global vars which are ready for dereferencing and inplace incrementing. As we do it in asm. This will eliminate 9/10 of code above.
But I would say such new code is "bad C code" because nobody who is sane will write such code on modern systems.

User avatar
gauauu
Posts: 706
Joined: Sat Jan 09, 2016 9:21 pm
Location: Central Illinois, USA
Contact:

Re: Aren't you afraid that NES Maker would just bring lazy noobs

Post by gauauu » Sun May 03, 2020 9:18 pm

Ok, agreed if you mean "bad" by modern C practices.

I mean bad as in "poorly written with the NES constraints and performance and characteristics in mind"

Post Reply