great stuff! not a programmer or anything, was just very curious to know how collision and simple physics worked in these old 8-bit games. and this video explained it perfectly.
This is awesome! I have really missed the tech articles from Lizards Kickstarter. Lizard is a great accomplishment but unfortunately it is not my favorite type of game. The update articles that was released during the development on the other hand are absolutely brilliant. Thanks!
Pinball is one of my favorite NES games and another (albiet less advanced) physics simulation. Game looks amazing and your videos are clean and to the point. Best Nesdev content on youtube
Well, I'd love to see a video the goes into depth about those games. I did consider mentioning Pinball, but I don't think I'd seen any of the Famicom Pachinko games yet when I made this video. There's a lot of tangents to think about when writing something like this, but it's always hard to decide which ones to give time to, and how much.
11:35 the numbers being binary actually makes a pretty big difference compared to base-10, because "multiply by 1 and add" simplifies to "add", and "multiply by 0 and add" simplifies to "don't add anything". You don't need anything like the "multiplication table" that you learned in school, because the one for binary is so simple - in fact, it's exactly the same as the truth table for the "AND" operator. 0 * 0 = 0; 0 * 1 = 0; 1 * 0 = 0; 1 * 1 = 1.
Great job, and cool tricks! This may not be the most appropriate place to ask this question (though it is related to the nes restrictions), but... Do you think there is or that there could be a better way to deal with sprite flickering when you go over 8 sprites per line? Say, for instance in Castlevania when the whip is overextended and there is one or more enemies on the same line, so everything there flickers... Or even in TMNT with the life meter when you're in the "overworld" screen (i.e., when the life meter is composed of sprites). Would there be a way to make them less flickery?
Well, the default thing to happen is just sprites disappear. The flickering is already a programming technique to try and cope with it by distributing which ones disappear over several frames. You can't really do much better than that, except very careful planning about where things appear on the screen.
@@elrond_hubbard The hardware makes all sprites past the 8th disappear. The software mitigates this by switching their order. Thus, there's still more than 8 sprites on the line, but the software is changing their priorities to make sure they each get some share of the time. So... augmenting the hardware to allow more sprites doesn't affect the software, the order of sprites is still changing, but the hardware effect of them dropping out has been removed. However, some games use the 8 sprite limit intentionally to hide sprites, especially for things like cutting off characters as they enter water. In those cases, adding extra hardware sprites will work against the goals of the software. There's an incomplete list here: wiki.nesdev.com/w/index.php/Sprite_overflow_games#Use_of_excess_sprites_for_masking_effects
A nice trick for multiplying which I've not had occasion to use personally on the 6502 but have read about is to exploit the fact that x*y = ((x+y)^2)/2-((x-y)^2)/2, using a suitable table of squares, and exploiting (zp),y mode for the lookups. If one starts with the operands in A and Y, a 16-bit multiply would be something like: sta lookup1 / sta lookup2 / eor #$FF / sta lookup3 / sta lookup4 / clc / adc (lookup1),y / sbc (lookup3),y / sta loResult / lda (lookup2),y / sbc (lookup4),y / sta hiResult. Have you seen or read of that trick?
I've heard about it. There are many viable techniques. What I described in this video is not actually what I used, but I wanted to explain the concept of a synthetic multiplication and thought it was best to use an example that would be familiar. You can look at the source code to see how I did implement it. One thing about this game is that it needs a 16x16 multiply and not 8x8, which most generic 6502 "multiply" code snippets will give you. Similarly the squares technique is only 8x8. To use larger operands you're back to combining 8x8 results with long multiplication techniques.
Very nice game! It'd be great to see this ported to the Uzebox so I posted it to the Uzebox forums earlier in the hope that someone takes the bait. Are you Uzebox aware? Might you be interested in bulding your own console?
Uzebox does not seem like my kind of thing. The game is probably somewhat portable. Most of the logic is in C, but the stuff that generates the backgrounds would require something platform-specific.
@@Sakanakao I must say I'm surprised that a NES developer would say the Uzebox isn't their sort of thing as its the nearest there is to a open source NES. What don't you like about it, if you don't mind me asking?
@@danboid I'm interested in retro consoles that were mass produced. Uzebox is modern console that is DIY. For me this is apples to oranges. I think that's the simplest way I can explain.
@@Sakanakao All of the components (inc the MCU) of the Uzebox are still being mass produced 15 years after its introduction. One of the best aspects of the Uzebox is that an electronics beginner can build it themselves. People are still wrting new software for the Uzebox, so its pretty unique amongst non-mass produced and open source platforms.
