It is currently Sun Nov 18, 2018 2:17 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 19 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Sun May 13, 2018 11:09 am 
Offline

Joined: Tue Jun 28, 2011 2:39 pm
Posts: 192
Opcodes are easy. They really are. I have no problem making some numbers move and increase in an "artificial" environment where all I have are 6502, some RAM and memory monitor. Found something like that online (though I for sure know it wasn't easy6502 and last time I've checked the site became one of those SEDO ad pages), so I know that much.

What really gets me is that I can't wrap my head around about NES memory map, how to interact with PPU and make sounds play (I really want to make my own sound engine because AFAIK there is not a single one that is fully compatible with Famitracker's output given all effects and so on are used), how to write code that would run on a real hardware and so on. That and more advanced things specific to assemblers such as macros. I've read the docs, read the specification, but it really doesn't get to me. No tutorial so far had helped me to do any real game. And mappers. They're the wrost really.

I really want to make nes games, but I'm simply unable to. Any help?


Top
 Profile  
 
PostPosted: Sun May 13, 2018 11:42 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10974
Location: Rio de Janeiro - Brazil
You're right, opcodes are easy. 6502 assembly is just a language for manipulating numbers, but if you don't know WHAT to say in a language, which numbers to manipulate and what to do with the results, the language is useless.

The most important thing for game programming is the understanding of concepts like movement in two-dimensional space, physics, collision detection, object management, and so on. These things won't magically pop up in your head as you code, you have to plan these things in advance, before trying to describe them in assembly language.

Play a bunch of games similar to the one you want to make, and try to look at them differently. Stop playing to win and start analyzing the hell out of them, trying to think of the various rules that that could result in the behavior you're seeing. Create your own theories of how the world is modified each frame in response to your actions and the internal game state.

Then you can expand your theories on paper, checking if there rules you thought of actually make sense. Do the math to find out what the boundaries are, to find the values that could be used to implement the rules, so you have something to work with when the time to code comes.

As for interesting with the hardware (PPU, APU, etc.), try to keep it simple at first. There's no shame in starting out with a static background and gameplay based entirely on sprites, so you don't have to worry about scrolling, incremental VRAM updates, or anything of the sort. There's plenty of example code on how to draw backgrounds and move sprites, so try starting with that and then implement some sort of game behavior using the sprites.

One key concept that many people getting started with game development don't understand is that everything happens frame by frame. Each frame, the game engine has to give everything in the game world the opportunity to update itself. Everything in the game world has to be updated just a little bit each time, taking into consideration things like input, gravity, collisions, timers, and any other game state that may be relevant, and the end result is that everything will appear to be happening simultaneously to the player.


Top
 Profile  
 
PostPosted: Sun May 13, 2018 12:01 pm 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1783
Location: Gothenburg, Sweden
Some thoughts:
-if mappers are the worst, make a game with no mapper (nrom).
-if a music engine is hard (it is), make simple beeps and boops for effects for your first game. think pong.
-the ppu behaviour is a lot to take in, but you can control its registers that are way more legible than writing idk %00110010 to some control register.

So if i set up PPCTRL to be interfaceable like this:

Code:
;PPUCTRL ($2000)
NMIENABLE = %10000000 ;should be off during initialization, should be on when game is running
MODE8X16 = %00100000 ;remember - 8x16 sprites may make use of both CHR tables.
BGCHRSEL = %00010000 ;which CHR table is used for background - 0 for $0000, 1 for $1000
SPRCHRSEL = %00001000 ;which CHR table is used for 8x8 sprites - 0 for $0000, 1 for $1000
INCADDR32 = %00000100 ;if set, VRAM r/w increments by 32 (a whole row) instead of 1, thus going vertical

;least significant 2 bits, ie. %000000xx, are used to set base nametable addresses.
XSCROLL256 = %00000001 ;use this to scroll across 2 nametables
YSCROLL240 = %00000010 ;use this to scroll across 2 nametables


I can take whatever value i want written to PPCTRL and add in individual bits like this:

SomeValue | YSCROLL240

Maybe these names doesn't make sense to anybody except me, but the point is to come up with names that make sense to you.

Or for sprites, i use:
Code:
;sprite attributes
VFLIP = %10000000
HFLIP = %01000000
BEHIND = %00100000


So an OAM entry could be written like this:

someYposition-1, someTileID, somePaletteID | One or several of the above equated constants, someXposition

And so on.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Sun May 13, 2018 12:28 pm 
Offline

Joined: Tue Jun 28, 2011 2:39 pm
Posts: 192
The thing is, I don't have problems with making physics and so on, made couple of games in regular engines and fantasy consoles (mainly TIC-80 and PICO-8, though I'm considering creating in others as well). The main problem for me is interfacing with the hardware as there seems to be no tutorial that describes it in a way I can understand. The best I could achieve was to once make in a NESICIDE a crude title screen that slowly scrolled in (and it was really crude, Atari2600 level of graphical fidelity as I've took an "ascii art" approach to making it), then stopped. The New 8 bit heroes did an kinda good NES dev tutorial few years ago using ASM6 (Joe, in particular), but then he got distracted by other things such as NES maker and the tutorial never got past implementing a reset routine ;).

As for NROM suggestion, thanks but no thanks, sorry. Original SMB did use it and had to make a lot of sacrifices, such as one-way scrolling and levels that had to be assembled from huge chunks of tiles/objects instead of single tiles. Not to mention a small graphical variance. The better way would be to suggest one good mapper that is easy to work with and provides good features that I could then learn and stick to it, like mapper 30 which seems to be a choice for NES Maker so it should be good one.

Anyway, does anyone have any ASM file with just label declaration for NES memory map? I think this would greatly help learning it as I wouldn't need to look up addresses constantly.


Top
 Profile  
 
PostPosted: Sun May 13, 2018 12:32 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7719
Location: Seattle
darkhog wrote:
As for NROM suggestion, thanks but no thanks, sorry. Original SMB did use it and had to make a lot of sacrifices, such as one-way scrolling and levels that had to be assembled from huge chunks of tiles/objects instead of single tiles. Not to mention a small graphical variance. The better way would be to suggest one good mapper that is easy to work with and provides good features that I could then learn and stick to it, like mapper 30 which seems to be a choice for NES Maker so it should be good one.
Your assumptions are fatally flawed.

If you cannot handle a specific level of complexity, set your sights lower. Anything else is defining yourself into failure.

You have to learn to crawl before you can run.


Top
 Profile  
 
PostPosted: Sun May 13, 2018 12:37 pm 
Offline

Joined: Tue Jun 28, 2011 2:39 pm
Posts: 192
Crawling is boring. And I've always learned the most when I've set my sights high and had a proper guidance regarding HOW not IF I SHOULD.


Top
 Profile  
 
PostPosted: Sun May 13, 2018 12:39 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7719
Location: Seattle
Have fun failing, then.


Top
 Profile  
 
PostPosted: Sun May 13, 2018 1:00 pm 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1783
Location: Gothenburg, Sweden
If you brace yourself through learning how to bankswitch, i suggest UNROM, CNROM, GTROM (by memblers) or mapper 30. These will not have the problem you'd have with NROM (that is, needing to take space into consideration), but still allow you to make your first game without adding mandatory complexity. For hardware reproduction, these are among the most sensibly priced as well.

CNROM is the straight logical step from NROM, which will afford you more graphical variance.
UNROM, the mapper 30 variant, and GTROM will require you to learn how to load assets from PRG ROM to CHR RAM, but it sounds like you can manage that already. They do in turn offer more storage for levels, program, graphics, music, etc.

Quote:
Anyway, does anyone have any ASM file with just label declaration for NES memory map? I think this would greatly help learning it as I wouldn't need to look up addresses constantly.


There is (somewhere on the nesdev wiki iirc), but i'd warn that personally, i learned nothing from copypasteing a list of equated constants. Better to write each by hand and make a comment + questions on each. What i did then was i went and bought a notepad, looked up this wikibooks page, copied it by hand to the first couple of pages as a "table of contents", then gave each item a page to write down my own personal research notes on. These notes were derived from the nesdev wiki, nerdy nights, the old classic .txt documents floating around, and minute little experiments.

I still haven't filled everything out (particularly the APU which is kind of scary and because i'm happy with the outlook of using others' music engines), but it gave me the confidence to start interfacing with the PPU.

Edit:
I actually think it is good advice to throw more PRG ROM at some problems. For example, that way you don't need to learn how to come up with a space-efficient level codec; you can simply store levels as raw uncompressed nametable data and be done with it, to some extent. That'd afford you to focus on more pressing problems for your first/second/third attempt. Your game will be short (1 screen is roughly worth 1kB if completely uncomressed - a little less if you're not using the full height in favour of a status bar), but it will work.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Sun May 13, 2018 1:19 pm 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1783
Location: Gothenburg, Sweden
One last tip on my mind. If the written documents, tutorials and wiki articles aren't suitable to your learning style, maybe this guy is just right for you. Take your time and follow him along his videos, and it should clear quite a lot of concepts regarding the hardware, its registers, and how to interface with them. I think he's going through things in a very sensible order and he's helped me quite a bit with his videos.

https://www.youtube.com/watch?v=XwGj1ciSAtw

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Sun May 13, 2018 2:03 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10974
Location: Rio de Janeiro - Brazil
darkhog wrote:
As for NROM suggestion, thanks but no thanks, sorry. Original SMB did use it and had to make a lot of sacrifices, such as one-way scrolling and levels that had to be assembled from huge chunks of tiles/objects instead of single tiles.

You can start with NROM for simplicity's sake... It's not like you'll run out of space coding an engine with a couple of test levels... 32KB may not be enough for the full game you have in mind, but it's plenty for creating the basic framework of what your game will be. Hopefully, by the time your engine is mostly ready, you'll be more familiarized with the hardware to the point where adding a mapper and implementing bankswitching will be easier.

You do have to control your expectations, though. If you can barely make a title screen, you should not be thinking about multidirectional scrolling and mapper features, you should be focusing on the basics. Nobody makes a masterpiece as their first project, specially if you're struggling with the basics.


Top
 Profile  
 
PostPosted: Sun May 13, 2018 2:21 pm 
Offline
User avatar

Joined: Thu Jul 23, 2015 7:54 pm
Posts: 181
Location: USA
1.) It’s important to learn game design concepts in a general sense, not just limited to nesdev. Things like a main loop, states, processing objects and then drawing them were all unintuitive to me at first.

2.) I found it easier to implement things in chunks, and think of them as systems and keep them separate from the rest of your games’s systems. You start out by building a skeleton - a state machine. Indirect jumps help nicely. Do something simple in each state like set a specific address to a specific value, and test it in an emulator’s hex editor to see if it works. I’d recommend adding controller code (which is on the wiki) right after that; somethinf simple like pressing the A button to change states. Then start adding a basic object system. Somehing simple like X and Y coordinates, state, and ID. Building a metasprite system on top of that is a bit tricky, but people can help with that if you ask them. For the game I’m currently working on, I started out with the message box / HUD display system first, laying down code in a similar manner to what I described above. Then I slowly added more states, objects, and eventually metasprites. You have to start out small, and really think and make sure what you’re doing in the beginning won’t come back to screw you later

3.) Start out with NROM. Start out with a simple game. Mine was one of those 15-slider puzzles. State transitions were messy, and it directly manipulated hardware sprites, but I learned a lot and it was cool seeing all those bits and pieces finally working together to make something resembling a game. After that I finally moved onto a bigger project I’d had in mind for a while; and used MMC1. I also deleted everything and started over completely one time, FWIW, as I still wasn’t experienced enough to make a project this big in scope at the time.

Point is, like everything, you start out small. Super Mario Bros is honestly a bit of an outlier in my opinion as far as code complexity in first gen NES games go. Look at any other launch title - they all use NROM (a lot of them are only 16k of PRG too), and they’re all pretty simple games too.


Top
 Profile  
 
PostPosted: Sun May 13, 2018 2:36 pm 
Offline
User avatar

Joined: Thu Jul 23, 2015 7:54 pm
Posts: 181
Location: USA
darkhog wrote:
The main problem for me is interfacing with the hardware as there seems to be no tutorial that describes it in a way I can understand.
What exactly isn’t making sense to you?


Top
 Profile  
 
PostPosted: Sun May 13, 2018 5:19 pm 
Offline
User avatar

Joined: Thu Aug 13, 2015 4:40 pm
Posts: 310
Location: Rio de Janeiro - Brazil
I think nim & nom is a masterpiece and it is mapper 0 and doesn't even have scrolling, so...

_________________
https://twitter.com/bitinkstudios <- Follow me on twitter! Thanks!


Top
 Profile  
 
PostPosted: Sun May 13, 2018 5:59 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10974
Location: Rio de Janeiro - Brazil
True. There are a few good examples of impressive games that use the hardware resources very conservatively but have great art, music and gameplay that really stands out.

There are also examples of more ambitious projects that end up glitchy due to bad timing of raster effects and various forms of non-standard PPU use, lack of polish in presentation, bad controls, and so on.


Top
 Profile  
 
PostPosted: Sun May 13, 2018 8:43 pm 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 2333
Location: DIGDUG
I think you will get a basic understanding by reading every link in the wiki on the PPU.

http://wiki.nesdev.com/w/index.php/PPU

And by using all the debugging tools, like PPU viewer and Nametable viewer in an emulator like FCEUX. Also, hex editor, with view set to PPU....while you look at an actual game.

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 19 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: DRW, Google [Bot] and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group