Objects - Super Nintendo Entertainment System Features Pt. 02

[@bluecar5556]

Outstanding! This is like getting your first car and knowing anything about it other than you push the gas and it moves forward. Don't really think about how it works, it just does. Then one day you pop the hood and start poking around, out of curiosity, taking random things apart to figure out how they work and put them back together. To think back on all those childhood memories playing nintendo just a few years old. How we just get sucked out of reality as we know it and enter an exciting narrow path we must follow with impeccable timing. The NES processes what we see and the analog CRT electron gun fires energy at phosphor pigment from top to bottom 60 times a second, at the speed of light, leaving it up to us to nail the small window of success by the millisecond without excuse. To have someone open the hood on my childhood and explain exactly how it works is so awesome i'm getting goose bumps! You have a gift man, don't ever let anyone else tell you otherwise.

[@Nitro_0999]

Or 50 times a second but we don't talk about that

[@Madsy9]

Very nice work :) Lots of the earliest online "documentation" and reverse-engineering of the SNES is very outdated and full of mistakes and errors. It's nice to have your videos as a thorough high overview.

[@chriskaprys]

Now I really wanna see a TV modded to display "off-screen" images that are in the buffer but ordinarily out of bounds.

[@jackwastakenx2]

So boundary break for older games

[@travia21]

My favorite part of this and the last video, is the visual way you present very abstract, technical information. To visual thinkers like myself, this video is clear and easy to follow. gg

[@solodas6490]

Steven Peterson gg?

[@DaVince21]

I agree; this stuff is very easy to grasp and really makes me want to mess around with ROM data.

[@RussellTeapot]

+SoLoDas "gg" is short for "good game": is used to make compliments to another person

[@solodas6490]

Russell Teapot yah I know that's why I put a ? Why use gg there

[@joelkuhn9880]

I love these videos. Thanks for making these.

[@Coaster42]

Joel Kuhn Nice name.

[@KairuHakubi]

There's nothing like finding out after so many years why graphics did certain weird things they did.. I never thought very hard about it, but seeing some of those was incredibly familiar.

[@LordEvrey]

Finally I understand those glitches. Now I have to figure out how the "more sprites" patch from SMWC worked. Long time no visit.

[@AndrevusWhitetail]

I'm not exactly sure, so this is just a guess, but maybe the patch adds assembly code for the ROM file to think that there are extra RAM storage and a secondary video chip added to the cartridge for increased sprite layer counts? Since emulators can cut many corners with their programming, it's not exactly farfetched to think they aren't 100% conforming to the set technical specifications of the console

[@KuraIthys]

@@AndrevusWhitetail If it's something that only works in an emulator you can just get your emulator to ignor the regular limit. But from my experience Super Mario world is typically only showing about 40 sprites anyway. So you could just add more sprites, and at that point it's probably the CPU that can't keep up, so you'd have to mess with that. Finally in terms of graphical variety/capabilities (though not really related to sprites directly), the SNES supports 128 kilobytes of VRAM, but only has 64 installed. In an emulator you can trivially change this with a few lines of code, and even in real hardware you could wire up extra memory if you felt like it. But... That wouldn't benefit sprites that much. It's main benefit (if you were to write games that took advantage of it) would be that Mode 3 and mode 5 would be more viable. Mode 3 is '256 colour background' mode, which doesn't sound so problematic, but 1024 background tiles in the usual 15 colours per tile mode is 32 bytes per tile, meaning you use up 32 kilobytes for a full tileset. (since each background layer can have it's own tileset though, you could use more). Now... In 256 colour mode you use 64 kilobytes for a tileset... Mode 6 is high resolution mode, which means operating at 512x224 or 512x448. While individual tiles don't take up any more memory, you're now showing 2-4 times as many tiles onscreen at once, and need to use 64x64 tilemaps just to fill the screen, much less allow for scrolling. So the tilemaps take up 8kb instead of 2, and repetitive patterns are going to be more obvious, so again you benefit from having more VRAM available... I bet if the system had the full 128 kb installed you'd see a lot more games using these higher end graphics modes than you do right now...

[@greatspaceadventure]

I'm not very smart, so I keep having to pause and rewind the video (with captions on already) to make sure the concepts make it into my itty bitty little brain. Still, I'm amazed and totally wonderstruck at the sheer production quality of all these videos. I'm so excited to see more!

[@maxis2k]

This video explains objects so much better than your typical tutorial for actual game development software. ESPECIALLY Game Maker Studio.

[@idkis_thename4438]

Your editing skills are emaculate, and you're creative.

[@Caspicum]

This is a fantastic video. It always baffled me as to how developers achieved so much on such constraints, and now I have a brief insight. Cheers, lad.

[@johnarmstrong5474]

These are great videos, well produced and fantastic detail. Very enjoyable, keep it up!

[@vaendryl]

this is some real god-tier editing work. I've no idea how you make these and a vid on how you make your vids would be no less interesting to your regular stuff.

[@Vykori]

duuuuuuuuude the amount of editing in these is insane.

[@akme7779]

This is such a great series! Super informative, and great production value - keep it up!

[@MattyStoked]

Absolutely excellent. Your video editing is fantastic, and the knowledge is moreso. I love watching these. Please make more.

[@jabelsjabels]

Jeeeeeez you clearly spend a lot of time on these animations, and it shows! Very well done!

[@seanc.5310]

This channel is fantastic! I grew up on these games and systems and so awesome to finally understand the underlying technology and concepts. Very, very well done sir!

[@danmanx2]

Thank you! That extra X coordinate makes perfect sense now in scrolling beat 'em ups! Great video!

[@TheV360]

This series is awesome!

[@sunnohh]

Yeah, I am going to need to say thanks! Love these videos.

[@TheRandomshite123]

I have never studied computing properly beyond the bounds of pre 16 education nor can i code beyond editing or fixing pre-existing game code, but these videos are so well done i can follow them fairly easily

[@KazeshiniGamer]

I love these videos and to learn how old consoles work,since they are relatively simple

[@LeodSMW]

Dots noooooo!!! The pp priority bits actually don't have any influence on object priority at all! They're exclusively for priority with background layers! The only thing that determines the order objects are drawn in is their position in the OAM!

[@IsoFrieze]

rip

[@EebstertheGreat]

What happens if object A is supposed to be behind the background layer, object B is supposed to be in front of the background layer, and object A is supposed to be in front of object B?

[@genstarmkg5321]

@@EebstertheGreat You get F. Fun fact: One of the NES Dizzy games uses this trick to work around backgrounds not having a priority bit by putting earlier sprites behind the background and shaped like the background but latter sprites on front of the background, so when the latter sprite touches the earlier one, it gets clipped despite the earlier sprite not being shown and it gives the illusion of the background obscuring the player.

[@ge97aa]

@@EebstertheGreat The background layer wins. This is because object-object priorities are resolved before object-background priorities. So, first, on the object layer, object A will be chosen over object B. Second, when combining layers, the background will be chosen over object A.

[@DeadwingDork]

man I can barely do basic math but I get this and it's very interesting good shit dude

[@bjman2567]

Y: same

[@Dargonhuman]

As much as I love these vids for what I'm learning from them, I have a buddy who loves them even more as he used to dabble in various types of programming when he was younger (and thus has a much better understanding than I).

[@103213able]

wow really good explanations and illustrations! Keep it up!

[@sammclaren3511]

Thanks, dude. I can use these information in my games

[@sagiksp4979]

These are incredible

[@jordydelange8853]

Awesome video, I'd love to see the SNES series continue!!!

[@johneygd]

I can only hope for more video's like this.

[@shukterhousejive]

So in games that have sprite flicker when they exceed the limit, is that something the hardware handles or do you have to write your own routine? Great work, keep making these vids!

[@IsoFrieze]

Generally, yes. When too many sprites are on the same horizontal (it happened a lot more with the NES), the priority determines which ones show up. This can be done by rotating the objects' priority bits, or, if that isn't applicable, rotate the objects' position in OAM. Both of which are software things. There does exist that OBJ rotation feature that does a similar thing but hardware-based, but it's not very good at doing that sort of thing.

[@Scripture-Man]

Fascinating. Thanks for making this!

[@hawtpotato90210]

these are great. I hope you finish the series.

[@konstero]

Absolutely brilliant, thank you!

[@sparrowthesissy2186]

I kind of wish the SNES hadn't built in the 32-object-per-scanline limit, and had just left that as a default or as a recommendation to developers. If they had worried it would slow things down, I understand, but there was plenty of slow-down in those days anyways, and one more cause of it would have been acceptable in a lot of circumstances if it didn't mean the sprites strobing and going nuts. In a cut-scene especially it makes sense to throw as much as you can on screen, even if things only get half or a quarter of the framerate of regular gameplay. I'm glad a lot of modern emulators just let you disable that limit, even though sprite-flicker is still kind of coded into a lot of games. After this video (and the correction in the description) it makes sense to me now that the way you would "flicker" the sprites is by just swapping them around in the OAM to change which ones have the highest priority in any given frame. That's pretty efficient, but I imagine it's still kind of a pain in the ass when you're just trying to build a town or make a bullet hell.

[@RGMechEx]

The 32-object-per-scanline limit is a hardware limit. The PPU can only "look up" 32 objects at once during a line. It can also only "look up" 34 8x8 object tiles per line as well. Better hardware would be necessary to extend this limit. If there are more objects on screen than the limit, the PPU doesn't slow down or lag, it just drops those objects completely. The sprite flickering built in to some games is a way to ensure objects will at least show up every other frame instead of being completely non-existent.

[@avi8aviate]

My favorite parts are when the Maxim Tomato appeared and when the KGL3 Kirbies appeared. And when a full screen of the game appeared. And when the sprite sheet for the game appeared.

[@kurosurintomasu]

This guy needs more subs.

[@ocng]

Well made! Can't wait for more!

[@SkylorBeck]

Please continue this series

[@eyezuel5307]

Boi, these are amazing, you do good work. Im like,"wheres part three"

[@HoobriBoobri]

That is soooo coool. BIG thanks! Ohh how whould I be happy to see this video 20 years ago)) Can you do the same for sega md? Or even ps1??

[@MrAIProgrammer]

Thanks, now i understand why some of the objects/sprites flickered on some games. I initially thought i bought a defective SNES !

[@LaskyLabs]

Great video. Take a shot every time he says the word object or some variant of the word.

[@lextatertotsfromhell7673]

This video is very object oriented

[@fidel_soto]

This is amazing!!! So interesting!!! Thank you for this explanation!!!!!!!!!

[@-dash]

5:12 I see this happen a lot in Super Metroid after "moonfalling" down the Climb at the beginning of the game. When moonfall is used, Samus' fall speed becomes uncapped- when you enter the door at the bottom of the shaft, part of the door tiles are missing. I suspect the devs never accounted for those objects being drawn so quickly. I'm not sure how SM handles door transitions... perhaps it has something to do with the background layer and the OAM's misprioritizing tiles? I'm now really curious how door transitions and room-loading is handled graphically in SM. I'm not sure if the door itself is swapped to different layer when loading a room

[@BrunoValads]

really nice video!

[@JoshuaEfron]

These are great videos. Thanks.

[@rafaelsoares8282]

Thanks don't stop doing this

[@inceptional]

4:23: If objects with the lowest priority bits dropout before objects with the highest priority bits and objects earlier in OAM are prioritised over later objects with the same priority bits on SNES, is it possible for the programmer to arrange everything in advance so the sprites are effectively always drawn to the screen in the same relative order next to all other sprites, thus allowing predetermination of which ones will be dropped out first in the case of too many sprites per scanline? I hope what I'm asking there makes sense.

[@inceptional]

4:34 When using the sprite priority rotation method of cycling through multiple sprites to slightly mitigate obvious visible dropout, will it only show sprites visibly flickering on-screen when they go over the sprites/slivers per scan line limit, or will any sprites just normally passing in front of each other be constantly flickering due to using the sprite priority rotation feature even when there's not any cases of too many sprites/slivers on any scanlines? I hope what I'm asking there makes sense.

[@fshiruba]

you should do a crossover with David Murray (The 8bit Guy), I think you two would have a lot of things to share and contrast! :D

[@RengokuGS]

Absolutely amazing please don't stop. You sound like dotsarecool?

[@malik87breaker]

I don't know why i am watching this. I guess his voice is soothing :D

[@gr6723]

Really intresting !!! Thanks!

[@KuraIthys]

I would consider the Sprite handling hardware the SNES's biggest weakness compared to the Mega Drive. And in particular, that SNES objects can only be 'big' or 'small'. (only being allowed to be power of two squares is also a problem, but not to the same extent.) - I note you stated that there is unofficial support for 16x32 and 32x64 sprites - I assume these come about due to there being a handful of 'illegal' sprite sizes? It's actually useful to know these exist, because those are useful sizes for many purposes. So, what's wrong with SNES sprites compared to Mega Drive ones? Lack of flexibility. The main reason this is a problem is because it makes optimisation difficult. You often end up either wasting VRAM, wasting CPU cycles (by mimicking larger objects using multiple smaller ones), or both. Compare: SNES: Active display can contain any two sprite sizes out of 8x8,16x16,32x32 and 64x64 (unofficial modes aside). Mega Drive: Active display can contain any arbitrary combination of sprite sizes out of 8x8, 8x16,8x24, 8x32, 16x8, 16x16, 16x24, 16x32, 24x8, 24x16, 24x24, 24x32, 32x8, 32x16,32x24 and 32x32 I think you can see the issue here. SNES supports just 4 sprite sizes, vs 16 sizes on the Mega drive. Worse, any given screen can only have 2 of those 4 sizes in use at any one time, while the Mega Drive can just cram all 16 sizes onscreen at once if it feels like it. That makes optimisation SO much easier...

[@debrucey]

How does it know which size tiles to use for “big” and “small” objects?

[@MaxwelThuThu]

The programmer does that. Small ones are more used for round edges of characters or particles. Bigger ones for near fully graphical sprites (not too many blank spaces). You can still use just one of them if you want, but being aware that too much small ones can exceed the total of 128 sprites easily and too much bigger ones can exceed the maximum of sprites in a horizontal line.

[@javierarzaga8485]

Great videos! you should add ambiance noise/music. Keep the good work.

[@LucasJaluL]

Nice video man! thx

[@saturnjr9136]

You should make a video explaining what the “pseudo-graphics” in Kirby’s Dreamland 3 are

[@melissali1571]

Hey, I love your videos... Where is part 3 ?

[@Lambby]

great vid bub

[@pleasedontwatchthese9593]

if you flip a 16x16 OAM object, does it also flip the the tile placement in addition of flipping the 8x8 section?

[@rodneylives]

You do good work!

[@rodneylives]

Also, you have exactly the right amount of intro and branding, which is, not much. I hate it when a video spends upwards of a minute on an intro movie and narrator introduction and channel description and by that point I've usually clicked away. Keep it up!

[@KedViper]

3:00 Wait a second. Is that a similar reason as to why mouse cursors on Windows can't go off the top or left side of the screen but can go off the right and bottom or is that something totally different?

[@jedel1043]

Yeah, pretty much. Drivers are still weird even in 2020

[@jefflinahan5853]

Cursor hotspots can't go off the screen, but the cursor image can. This is not a bug, it's a feature. It allows you to focus on the Start Menu by slamming your mouse into the bottom left corner without carefully aiming for the corner.

[@Yugisokubodai]

I see a wrong information at 0:33, where JSL InitSprite should return with RTL, not RTS.

[@SebastianEPH]

Muy bien explicado.. he interactivo..

[@yiris10001]

Explain how the minus world works in SMB

[@sophilebali5945]

excellent

[@Kane0441]

Why characters in fighting games(sf2 for example)ore small ?

[@inceptional]

It's mostly about how many sprite tiles you can update per frame, which is not unlimited. So most fighting games on SNES keep the fighters to a manageable size, as well as use some forced blanking at the top of the screen to aid further there too (that those horizontal black bars you see in most SNES fighting games). But Maxel/Maxwel recently showed a demo of two huge Earthquake characters from Samurai Shodown on-screen at once on SNES, with very little forced blanking too, so there was definitely a lot more potential there than most developers really took advantage of. Games like Mortal Kombat 1 and Killer Instinct on SNES at least managed to avoid any forced blanking altogether though. I think the system could definitely do larger sprites in fighting games than likely most people realise.

[@Super_Mario128]

mind blown.

[@Trege_Valerian]

These are pretty cool, do you plan to do any videos on N64 and PS1 eventually? Just curious is all. I always love hearing about how these older consoles worked.

[@UChS4Dq15wHu8vkvWsaLzvPg]

2:23 Who's leod?

[@Michafrar]

Did you use that Bowser 64x64 image on a forum ages ago? I haven't seen that graphic in forever.

[@teapartycthulu]

If I remember correctly it's from Mario's Early Years: Fun With Letters

[@maxis2k]

Looks like the design of one of the Software Toolworks mario games. Mario is Missing, Mario in Time and etc.

[@snoopweed4208]

yo those Videos are Kreygasm how long does it take you to create a Video? :O

[@IsoFrieze]

Script is usually a day or two, and editing can be a week or two depending on how complex it is.

[@conradorodriguez6216]

Hey i really hope you're still making these!

[@cybernitemusic]

Good.

[@bitwize]

Funny you use the term "sprite" the way you do. In its graphical sense it was coined by the designers of the TMS9918 chip used in the TI-99/4A, to refer to what are called OBJs on Nintendo's systems. The term caught on, especially since it was better than some of the alternatives ("player missile graphics"?) and could easily and unambiguously be used as a BASIC command or keyword (as on the TI-99/4A and Commodore 128), and eventually seeped over into the casual realm of nonprogramming gamers who used it to refer to animated game entities or pixel artwork.

[@CommodoreKulor]

"Player missile graphics" actually goes back to the way graphics were handled on the Atari 2600, where you had a total of 5 sprite-like objects to work with: 2 "players" which could have any pattern of 8 pixels per scanline, 2 "missiles" which were single dots of variable thickness that could be turned on/off per scanline, and an additional "ball" that was pretty similar to the missiles. They were named that because the thinking was that each player's on-screen character would be represented with a "player", and the shots fired by that player would be represented with a "missile". It makes sense in the context of the 2600, but of course once you get to newer systems with more generalized sprite hardware, the term doesn't really apply anymore.

[@bitwize]

@@CommodoreKulor I know whence the term came. But PMGs were being put to wider use even during the 2600's lifespan, so the name sounded awkward, dated, and quite a mouthful compared to the punchier "sprites".

[@NetracFreeman]

Love the videos just one question ¿Where do the constraints on sprite number for scan lines come from?

[@Yoshimaster96smwc]

From my understanding, that is a complex question that requires a bit of explanation on both the hardware side, as well as on how NTSC video works. Someone correct me if I'm wrong.

[@IsoFrieze]

It's hardware. Nintendo decided 32 objects would be enough to have on the same horizontal before having to deal with flickering. This is a big step up from the NES which only allowed 8.

[@KuraIthys]

Yes, it's something entirely internal to the hardware (I believe it largely has to do with how quickly you can read from VRAM), but you have to draw a line somewhere. The SNES can do 128 sprites total, 32 on a line. The Mega Drive had 80 total, with 20 on a line.... And the Neo Geo could do so many it could get away with drawing nearly 4 complete layers of 512x16 sprites. (The Neo Geo actually has no background drawing capabilities at all like the Snes and Mega Drive do. Rather the backgrounds are also sprites.) Given the 320x240 screens the Neo Geo used, that means it could draw at least 64-80 sprites per line. You get what you pay for. XD

[@NetracFreeman]

Thanks this is really interesting.

[@orngjce223]

Would you happen to be able to cover, or at least point me towards a good explanation of, the capabilities of the SNES sound chip? I tried looking it up on Google and got a bunch of stuff about other sound chips instead, so maybe I'm not using the right keywords.

[@RGMechEx]

Yes, a video about the sound processor is planned for this series!

[@branaa09]

Elaine Wang Your looking at A Sony DSP chip, 8 channels and each holds a sample, no synthisizing.

[@KuraIthys]

@@branaa09 That's otherwise known as a sample based synthesizer. ;p Given it takes those samples and adds ADSR envelopes, pitch shifting, echo, volume and panning, reverb and a few other things, it very much IS a synth. It can also perform additive synthesis between adjacent audio channels. (modulating one channel with the output of another.) But it isn't an FM synth, or some other type that is based around manipulating pure tones of course. Still a synth though. ;p

[@hangonsnoop]

Hi Super Famicom Chalmers!

[@asmallbabby4205]

Do "offscreen" sprites factor into the sprites-per-scanline and tiles-per-scanline limitations?

[@IsoFrieze]

If even one pixel of the object is inside of the display area, it counts toward the limit. If it is entirely off screen, it is ignored. The exception is when the x-position is exactly 0x100 (256 unsigned, -256 signed); it still counts as being drawn for some reason.

[@KuraIthys]

For the super Nintendo, no they don't. But indeed, if even a single pixel is onscreen, it counts. There's also a bug with it for some specific value that should be offscreen. An important thing to remember that's easy to overlook is that transparent pixels still count as being onscreen even though by definition of being transparent that isn't visible. So if you had say a 28x28 sprite on a 32x32 hardware sprite, it behaves as a 32 by 32 object for the purposes of these limits, even if only, say, the right two columns of pixels are onscreen, which would all be transparent in this case. A side note here is you may notice that Mega Drive sprites glitch out more than SNES ones. The primary reason for this is the equivalent limit on the Mega Drive (20 sprites per line, and 320 pixels drawn per line) DOES include things which are offscreen. This means if you were to program a a Mega Drive game and foolishly set all the offscreen sprites to be on the same line, every visible sprite on that line would glitch out. But if you did the same on an SNES (leaving aside the bug it has), everything would work fine. Subtle differences are sometimes the most interesting. XD

[@Davimikyl]

How many registers are in the snes total?

[@jefflinahan5853]

Hundreds

[@johneymute]

Now for a loooong time i tout that the snes also could do sprite scaling, it would,ve been sooo obvious for 1990 since memory was so expansive at the time but also since many arcade systems had such features , but it turns out that the snes had no sprite scaling , WHO NOT, was it too GPU intensivr in combination with other features??? Also why did nintendo not bother to use sprite scaling in software for games such as f zero & mario kart? Would it had harm the cpu to a crowd or would it only slowdow the snes to an acceptible 30fps??? My point being is,the GBA could do sprite & BG scaling & rotation as well,but by that time memory was already much cheaper,so at the time it wasn’t perse all that necessary to try to save on memory space on the GBA, it just defys everything from what you would expect in terms of sparing as much cartride memory,mmmm Nintendo should,ve atleast 1 valid reason to not have added sprite scaling on the snes, because i really don’t understand that because it already existed back then!!!

[@IronLotus15]

How do we know what Bit Depth the objects use?

[@IronLotus15]

Also, in CGRAM, it looked like there were multiple palates on one line. How does the system know what palate on that line to use then?

[@randomcatdude]

I think the objects are fixed to 4 bpp. And the whole thing about multiple palettes on each line? That is a 2 bpp background layer, I think...

[@KuraIthys]

4 bits. hence 16 colours. (15 + transparent.) This is fixed for sprites. For background tiles you can have 2 bits, giving 4 (3+ transparent) colours, 4 bits eg 16 colours (15 + transparent) in a format identical to sprites, and 8 bits eg 256 colours (or 255 + transparent)

[@sabriath]

I stumbled on this annnnnnd I feel like the definitions you used for sprite and object are wrong, but I'm an old guy who came from the PET/CBM days of commodore......sprites are just pieces of graphics that can be defined and moved on the screen, an object is just the code that does the moving of the sprite. Maybe this is just an SNES quirk or something, but that's how it's been done for as long as I've lived.

[@RGMechEx]

This is what I tried to clear up at the start of the video. Nintendo officially named the graphical entities that move across the screen as objects. All registers and memory that relate to them refer to them as objects as well (e.g. the register that determines object size is "OBJSEL" and the memory that holds object positions and attributes is "Object Attribute Memory (OAM)."

[@KuraIthys]

That's a matter of terminology, and terminology is arbitrary. Commodore calls them Sprites. Atari called them 'player missile graphics' Exact same concept, different names. PC developers working with DirectX had a habit of calling them BOB's (which stands for Blitter Object) Nintendo calls them Objects, and states that the 8x8 pieces they are composed of are called 'characters'. (Characters are also the term used to describe background tiles) Sega calls them sprites and calls the 8x8 tiles they consists of 'cells'. (it also calls backgrounds 'playfields' - a habit it shares with Atari) None of these terms are wrong, or right. It's ALL correct, just not a standardised thing. I mean, if you want to talk precedence, then clearly the Atari terms are the 'correct' ones, even though that's extremely clunky. (player-missile graphics? Really?) I mean, between 5 different hardware platforms/manufacturers we have 4 different terms for sprites (Sprite, Object, BOB, Player missile graphics), at least 2 for backgrounds (background, playfield), and a minimum of 3 for the small blocks of graphics that backgrounds and/or sprites are composed of. (Tiles, Characters, Cells) We can see the derivation of these too, in some cases. -'player-missile graphics' is very literal, given that the earliest games had exactly this. Think about something like asteroids or missile command. (the Atari 2600 even explicitly has a 'ball' graphic - so Pong is explicitly coded into the naming of the hardware sprite functions.) -BOB is also very literal, even if it is an Acronym of sorts. (Blitter Object) - Object is the most generic term you could think of. - Sprite has the least obvious derivation in fact. The other terms are obvious enough too: - Background. (speaks for itself - it's what's seen in the background) - Playfield (a similar term with a more game specific connotation.) - Tile (given a set of small repeating graphics in a regular grid, the resemblance to physical tiles is obvious.) - cell (again, fairly obvious. A small object in a grid; Spreadsheets also use 'cell' in this way) - Character ( here we see the history of this kind of graphics mode. In effect this is a text mode with the letters replaced with customisable graphics. Functionally a tilemap based graphics mode IS a text mode - the way they work is nearly identical. Thus calling the individual graphics 'characters' is an obvious derivation of text mode displays that formed the technological foundation for this kind of technique) Terminology takes a long time to standardise sometimes. There's also cultural differences to Consider. (Nintendo and Sega are japanese. Their English developer documentation is translated from Japanese originals - companies like Commodore and Atari are American.)

[@SerBallister]

@@KuraIthys BOB was coined on the Amiga first I think. That machine also had traditional video hardware generated sprites, so both terms were used on that platform. The PS1 also had a "Sprite" drawing primitive that worked just like a BOB. Yup, terminology is all over the place.

[@CommodoreKulor]

@@KuraIthys I don't think you could really say the Atari terms are "correct" in a general sense. "Player missile graphics" actually goes back to the way graphics were handled on the Atari 2600, where you had a total of 5 sprite-like objects to work with: 2 "players" which could have any pattern of 8 pixels per scanline, 2 "missiles" which were single dots of variable thickness that could be turned on/off per scanline, and an additional "ball" that was pretty similar to the missiles. They were named that because the thinking was that each player's on-screen character would be represented with a "player", and the shots fired by that player would be represented with a "missile". It makes sense in the context of the 2600, but of course once you get to newer systems with more generalized sprite hardware, the term doesn't really apply anymore.

[@XaneMyers]

How are these videos animated so nicely?

[@IsoFrieze]

I use Adobe After Effects, and render the video at 60fps. I also boost the influence on all the tweens, which makes movement more snappy.

[@XaneMyers]

***** Ah, After Effects...I've never used it, the closest being Adobe's Premiere Elements/Pro...I bet animating this would be a pain in Premiere...but your videos look like they require a lot of work to animate...what does After Effects do?

[@IsoFrieze]

I used to use Premiere and it works, but it was clearly meant to be for video editing instead of animation creating. (Even After Effects is supposed to be for video compositing instead of video creation.) The cool thing about After Effects though are expressions, which allow you to control object attributes via Javascript and external files, so I can write lua scripts for emulators that dump memory values every frame, and use those values as inputs to my expression scripts.

[@XaneMyers]

Ah, yeah, I guess Premiere is more made for just video editing...but wow, After Effects sounds cool if it can do things like that!

[@Aikisbest]

"Exposition" X Position. Hehe.

[@master3243]

nice

[@NaitorStudios]

Could you please make a video about OBJ files and how it deals with multi part objects that can move freely (like in Yoshi's Island)? I find it interesting that it doesn't need to be stuck on a grid, the parts can be offset by any amount of pixels... I would like to understand this better Another thing that I'm curious is how Yoshi's Island deals with enemies that can deform like the Potted Ghost, which doesn't look baked... I also found this and got curious about the texture, if it's baked and how this would look in game twitter.com/_UTF8_/status/1287413033828929539

[@belgar8887]

Which Snes game uses sprites with 64x64 pixels ?

[@belgar8887]

This bowser is background, not sprites. I didn't find 1 game that uses sprites 64x64.

[@MaxwelThuThu]

Generaly are used just for static images. In Chrono Trigger was used in the portal cutcene, to have a mode 7 layer and a blue translucent affect at same time. In Eek The Cat was used for some cutcenes also with mode 7. Big sprites are really great for fake backgrounds.

[@fedup7496]

Awesome video. So... what people normally call sprites, to the SNES are sprites, made up of what the SNES calls objects?. I usually call these "tiles", because that's what emulators call them. For example, "Mega Man's sprite is made up of 5 objects, also known as tiles". Is this correct?

[@KuraIthys]

That's a reasonable way of putting it, but not officially correct Terminology can get a bit arbitrary at some point. For instance, the Atari 2600 and later the 8 bit home computers called the hardware moveable objects 'player-missile graphics' 'Sprite' seems to have been a term first used with the C64... Nintendo calls the entire thing an 'object' (hence OAM - Object Attribute Memory - the listings in OAM are for an entire sprite, eg something that may be 32x32 in size) In fact if you look through official SNES developer documentation, you find they call them 'Object' or 'OBJ' for short. They call the background layers, unsurprisingly 'Background' or 'BG' and, and call the 8x8 (or 16x16) blocks the backgrounds are made a 'character' (sometimes 'character unit') So what are the parts that make up an 'object' called? Well, unsurprisingly given they have the same size, format in memory and colour depth as the most common background tiles, they also get called 'character's The actual data that tells you how the background is laid out (the tilemap) is a 'screen', and the area in which the tiles are stored is the 'BG character data area' or 'name base address' - the equivalent for sprites is 'OBJ Name Base Address' Also not a surprise since the actual 8x8 blocks are in the same format as they are for backgrounds. (unless you use 3 or 256 colour background tile) So in short: Backgrounds are referred to as Backgrounds Tilemaps are 'screens' Sprites are 'Objects' and tiles are 'characters' A background is composed of a bunch of characters, but so is a sprite. a background would typically have say 32x32 characters (1024, but because of 'screen' data you can re-use any character in an arbitrary location), while an object with an overall size of 32x32 pixels is composed of 16 characters. (but because of how Objects work, these 16 characters have a fixed relationship in memory that you cannot adjust) A sprite IS an Object, and is composed of Characters. (tiles and sprites are not terms that come into it at any point.)

[@merthsoft]

What font are you using? I really like it.

[@IsoFrieze]

It's called ModeNine.

[@dynastylobster8957]

when people realise that it is possible to make snes homebrews ,

[@l9m241]

So how does Super Metroid allow larger sprites? A prime example is Kraid, he's *vastly* larger than 64x64, and how does the SNES work with Metroid?

[@IsoFrieze]

My guess without looking into it would be that he is made up of more than one object. In fact, a lot of sprites are made up of multiple objects, especially if they aren't square-ish in shape.

[@KuraIthys]

@@KieferSkunk Ridley also exploits scaling and rotation, and that alone is a dead giveaway that the 'sprite' is actually a mode 7 background layer. Actually that probably means the 'background' in these scenes is composed of sprites. Just shows you that it's a bit misleading thinking of 'backgrounds' and 'sprites' in such rigid terms. A background is simply a very large moveable object that the system only draws a few of, and a sprite is simply a much smaller object that many more of can be drawn. The extreme case of this can be seen in the Neo Geo - Which only draws sprites, and nothing else. So how do the backgrounds work on a Sprite only system? Two simple additions. First the system can draw 512x16 sprites (eg long, thin columns). Secondly it has a function to make a sprite 'stick' to the sprite on it's left. This might seem a bit weird, but the advantage of this is that if you put multiple sprites in a line and enable this feature on all of them, you can move the whole block of sprites just by manipulating the position of the first sprite. (so the CPU only has to do the calculations to move a single sprite, and the others move automatically.) Besides that, it just has a much higher sprite limit. Something like 256 sprites in a single scanline, if not more. (which is why multiple background layers can still be used, since there's a lot more sprites available than you need to fill the screen with.)

[@MaxwelThuThu]

@@KieferSkunk Yes, he is a background layer. But being behind everything isn't a clue. BG 2 can be placed above BG 1, 3 and 4 too.

[@1024x2]

You got (ubyte)(0xFF + 0x02) sub!

[@SteveMacSticky]

Tubírta!

[@Sean.Vosler]

Bro is this your job..? It should be.

[@linkng7665]

"First, [...] needs to be cleared out..." "There are three parts to these things..." Sounds familiar :-/