Most Common Problems for Beginners

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

User avatar
2fadfe
Posts: 17
Joined: Thu Feb 24, 2022 7:55 pm
Location: Earth

Most Common Problems for Beginners

Post by 2fadfe »

I know that the subject seems a little cliche, but I think it would be nice to discuss the most common holdups/problems that beginners in this scene have and what the more experienced users have done in order to overcome those problems.
Known as Duncan Idaho #0087 on the Discord Server.
User avatar
Individualised
Posts: 310
Joined: Mon Sep 05, 2022 6:46 am

Re: Most Common Problems for Beginners

Post by Individualised »

I think a major barrier to entry, especially to those who don't have prior experience with any sort of Assembly programming, is that the most popular beginner's tutorials for getting into NES development are all based on old/obsolete assemblers and other tools that aren't recommended anymore. This is part of the reason why I haven't started my NES development journey yet.
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Most Common Problems for Beginners

Post by Pokun »

I suppose you are thinking about Nesasm and tutorials like Nerdy Nights?
I don't really think Neasm is obsolete, and it's not old enough for its age to be a problem considering it works on modern hardware just fine. I learned Nes programming using Nerdy Nights and Nesasm, and nothing relevant has really changed since then. Asm6 and CA65 are more popular than Nesasm, but the Nerdy Nights examples are available for those assemblers as well, the files are found somewhere here on this forum.
It can be nice to be familiar with more simpler assemblers like Nesasm and Asm6 as well though, not only advanced ones like CA65 and 64tass (I'm familiar with all 4 and think they all have their good points).


I think one common barrier is that beginner-friendly documents are less common than more technical ones, but lately there are quite a lot beginner tutorials like Famicom Party (uses CA65).
User avatar
Individualised
Posts: 310
Joined: Mon Sep 05, 2022 6:46 am

Re: Most Common Problems for Beginners

Post by Individualised »

I thought I've heard people here call NESASM obsolete but I guess not. Maybe limited is more accurate. So still not appealing to me.

I don't really like fiddling with development environments and tools and such and having to migrate to/re-learn different tools which is probably why I think that way. It's my least favourite part of anything programming related and I even find myself getting a headache or feeling nauseous when I have to do mundane things like that. Maybe I just don't have the attention span or something.

So even if NESASM is suitable for any beginner projects I might do, I don't want to have to fiddle with everything again when I decide to move on to bigger projects. I'd rather just set up something one time that will for the most part suit me and learn that, I know it's not possible to fully escape that though, as I have experienced quite a few times with Java development.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Most Common Problems for Beginners

Post by lidnariq »

NESASM has the problem—and as far as I know no-one's fixed it—that it produces incorrect output instead of warnings or errors.

Everything else is more a matter of taste, but that's a serious problem for the ability to use it for larger projects.
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Most Common Problems for Beginners

Post by Pokun »

I'm pretty sure Elmer fixed those problems long ago in his fork (grab "nesasm.exe" from the "bin" directory and documents from the "doc/nes" directory) which is probably the best version nowadays. The version that Nerdy Nights links to (called "NESASM3") is a buggy version, avoid that one.

Nesasm isn't really any more limited than Asm6, it actually has more features, but it's also pretty Nes-specific while Asm6 is a more generic 6502 assembler. Both are perfectly fine for creating larger projects with, while being simple to use not requiring to setup an advanced development environment (that's what I like about them myself).
Converting a project to another assembly is not a small task, but the examples used in Nerdy Nights are very small and converting them only takes minutes, plus the job is already done for you.
User avatar
gauauu
Posts: 779
Joined: Sat Jan 09, 2016 9:21 pm
Location: Central Illinois, USA
Contact:

Re: Most Common Problems for Beginners

Post by gauauu »

2fadfe wrote: Fri Sep 30, 2022 3:12 pm I know that the subject seems a little cliche, but I think it would be nice to discuss the most common holdups/problems that beginners in this scene have and what the more experienced users have done in order to overcome those problems.
To get back to some common problems, instead of just discussing assemblers:

- Not understanding nmi and vblank. You can sort of blunder along without really understanding what's happening, but you'll eventually run into something that doesn't work, and not be able to figure out why. It's worth reading and re-reading the sections of the wiki about this until you understand.

- Coupling game state to NES display hardware. Some people will tie their game entities directly to a particular hardware sprite(s). Or draw a background on the screen, and then try to read it back to figure out collisions. You CAN make a game this way, but eventually you'll get frustrated. Instead it's _usually_ better to have the game modeled in memory (ram or rom), and then have the game "draw itself" to NES graphics hardware as a separate step.

- Fixed point math. Most beginners will just have a one-byte X position (or two bytes if it's a scrolling game) for an entity. Which works fine, but becomes a real pain when you try to move things more slowly than one pixel per frame. Instead, use fixed-point math, which is just a fancy way of adding another byte of precision to the position, "sub-pixels". Use that precision when you add or subtract from an entity's position, but ignore it when drawing the entity.

That's all from the top of my head, but I'll try to think of others.
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Most Common Problems for Beginners

Post by Pokun »

Yeah those are good ones.
I think dedicating sprites for each entity is a natural first step and makes sense in your first Pong and other simpler games, then you have to figure out how to dynamically allocate it as a next step.
Scrolling may have similar challenges.

Likewise, using a discrete movement speed is a natural first step and works fine for Space Invaders or a simple mouse-style cursor, but almost any other game benefits from a simple fixed point math system. Just hearing "fixed point math" might scare many beginners as that almost sounds like the much more complicated "floating point math" which thankfully is hardly needed for most games.


I can think of another one:
- Edge-triggered button actions
In your first game you probably only learn how to read held buttons and how to act upon that, but you probably don't understand edge-triggers (0-1 and 1-0 transmissions). Held buttons works fine for movement but things like shooting, jumping or moving a menu cursor may require reading edge-triggers or other more advanced techniques. For menu cursors you may also want to learn to do delayed auto-shift so that the player can hold the d-pad/SELECT button and the cursor keeps moving, first with longer delays and after a while, shorter delays.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Most Common Problems for Beginners

Post by tokumaru »

I see lots of mentions of things like sprite usage, input handling, VRAM updates, and so on, but in my experience, the time spent on those things is a tiny insignificant fraction of a game's development period.

As one of the first steps of developing a game, you'll often create a handful of functions that take care of interfacing with the hardware, and for the rest of the development period you'll hardly ever have to think of these things again, besides calling those functions here and there.

Hardware-agnostic game concepts will give you much more trouble in the long run, I'm afraid. Simpler games (e.g. single screen with basic enemy/object interactions) aren't so bad in this regard, but once you need to manage a camera, solid objects, moving platforms, sloped surfaces, enemy A.I., 2 or more simultaneous players, etc., things can get insanely hard. Due to the limited resources of old systems, you can't just use generic solutions for these things, you have to carefully limit the complexity of each element to trim away anything that's not necessary for the game's design, and constantly make sure that all of these things are playing nice with each other.

Getting to know the hardware and feel comfortable with it is a good first step, but this barely scratches the surface of the complexity that is writing an authentic 8 or 16-bit game.
User avatar
gauauu
Posts: 779
Joined: Sat Jan 09, 2016 9:21 pm
Location: Central Illinois, USA
Contact:

Re: Most Common Problems for Beginners

Post by gauauu »

tokumaru wrote: Fri Oct 07, 2022 4:42 pm I see lots of mentions of things like sprite usage, input handling, VRAM updates, and so on, but in my experience, the time spent on those things is a tiny insignificant fraction of a game's development period.
While that's true, if you understand them poorly, and thus design them poorly, then they really explode out and become a lot more of a headache throughout your game's development. I made a lot of these mistakes in an early game of mine. While it still wasn't the bulk of my game development effort (the bulk was CONTENT), a lot of features took a lot longer than necessary because of modeling them poorly at the beginning.

E.G if you set up an entity system that doesn't use fixed-point, then every enemy or projectile that needs to move at an interesting diagonal becomes a development headache later when you're scripting enemies.
User avatar
donato-zits-
Posts: 47
Joined: Fri Jun 03, 2022 11:14 am
Contact:

Re: Most Common Problems for Beginners

Post by donato-zits- »

gauauu wrote: Fri Oct 07, 2022 7:22 am
2fadfe wrote: Fri Sep 30, 2022 3:12 pm I know that the subject seems a little cliche, but I think it would be nice to discuss the most common holdups/problems that beginners in this scene have and what the more experienced users have done in order to overcome those problems.
- Fixed point math. Most beginners will just have a one-byte X position (or two bytes if it's a scrolling game) for an entity. Which works fine, but becomes a real pain when you try to move things more slowly than one pixel per frame. Instead, use fixed-point math, which is just a fancy way of adding another byte of precision to the position, "sub-pixels". Use that precision when you add or subtract from an entity's position, but ignore it when drawing the entity.
YES! for sure this is my worst one, make a gradual aceleration of the pixel I got to do, but I trying to do the player jump and can't do it yet, I know tha fixed point is about 8-8 bits to one variable, but cant understand this well to make things works, I will try more experimentes whits this but until now I can't do a simple "go and back" of a enemy sprite, to make then move the code have to be in the NMI, and this broke the back movement, but well, I gotting to make good progress in another things anda will go back to make fixed point experiments
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Most Common Problems for Beginners

Post by Pokun »

Fixed point math works pretty much the same as 16-bit math, just that you treat the high byte as the integer part of the value and the low byte as the fraction part of the value. The integer represents real pixels while the fraction is for "sub-pixels", the integer byte is therefore the pixel position and the sprite will only actually move when the integer byte changes, not when the fraction byte alone changes (because there is no such thing as "sub-pixels" on the screen).

tokumaru wrote: Fri Oct 07, 2022 4:42 pm I see lots of mentions of things like sprite usage, input handling, VRAM updates, and so on, but in my experience, the time spent on those things is a tiny insignificant fraction of a game's development period.
Even if it's not something you spend a lot of time with after doing them, if you can't do them in the first place you can't do them and that may be a trip-up for a newbie.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Most Common Problems for Beginners

Post by tokumaru »

Pokun wrote: Mon Oct 10, 2022 1:38 pmEven if it's not something you spend a lot of time with after doing them, if you can't do them in the first place you can't do them and that may be a trip-up for a newbie.
I agree, these hardware interactions are indeed the first few barriers that newbies have to break through. I was just pointing out that there's so much to do after that, but those topics are not brought up as frequently.
User avatar
gauauu
Posts: 779
Joined: Sat Jan 09, 2016 9:21 pm
Location: Central Illinois, USA
Contact:

Re: Most Common Problems for Beginners

Post by gauauu »

tokumaru wrote: Mon Oct 10, 2022 6:24 pm I was just pointing out that there's so much to do after that, but those topics are not brought up as frequently.
Ah, I see. I thought you were saying that these areas weren't important. Yes, I agree, there are other things further "up the stack" that are important and give folks trouble. I'm not sure what all you're thinking of, but these are the types of things that are the next level of problems that new NES developers have to solve:

- What are appropriate strategies for sprite flicker management based on the type of game being made?
- How do you handle metasprite definitions, and how do you handle scrolling them in smoothly instead of having them "pop" on the screen or wrap around
- How do you build your data model for levels and maps and collisions
- If you're scrolling vertically, what does the 240-pixel-tall screen mean for how you track maps and camera movement
- How do you handle your asset pipeline in a way that's easy to maintain and edit?
coto
Posts: 102
Joined: Wed Mar 06, 2019 6:00 pm
Location: Chile

Re: Most Common Problems for Beginners

Post by coto »

donato-zits- wrote: Mon Oct 10, 2022 1:12 pm
gauauu wrote: Fri Oct 07, 2022 7:22 am
2fadfe wrote: Fri Sep 30, 2022 3:12 pm I know that the subject seems a little cliche, but I think it would be nice to discuss the most common holdups/problems that beginners in this scene have and what the more experienced users have done in order to overcome those problems.
- Fixed point math. Most beginners will just have a one-byte X position (or two bytes if it's a scrolling game) for an entity. Which works fine, but becomes a real pain when you try to move things more slowly than one pixel per frame. Instead, use fixed-point math, which is just a fancy way of adding another byte of precision to the position, "sub-pixels". Use that precision when you add or subtract from an entity's position, but ignore it when drawing the entity.
YES! for sure this is my worst one, make a gradual aceleration of the pixel I got to do, but I trying to do the player jump and can't do it yet, I know tha fixed point is about 8-8 bits to one variable, but cant understand this well to make things works, I will try more experimentes whits this but until now I can't do a simple "go and back" of a enemy sprite, to make then move the code have to be in the NMI, and this broke the back movement, but well, I gotting to make good progress in another things anda will go back to make fixed point experiments
Here's some advice I never forgot:

Treat everything as models, and no, not 3D models, lol, but simply a model as whole. So when you want to implement a feature, first, the behavior you want to implement has to fit the model you already have, like a computer, where opcodes and memory banks are executed through an addressing map. In the same way different hardware glued to that computer is addressed through read/write ports and must be seen from the CPU to make everything work.

By that principle, NES games are running on baremetal hardware, rather than being hidden away from an API, like usual desktop applications, or modern games, but the game design pattern is the same:

game state->game events->game physics->rendering->sound->input -> (repeat)

and all of that runs in a main loop. That's why it's necessary to read about both Computer architecture and game design principles before building games.... or you could just design games and forget about hardware but you'd need an SDK, and the game design principle.
Post Reply