In this episode I explain Game Boy graphics and fly through some of the code behind those graphics... Support the channel: / neshacker Game Boy Graphics Project - github.com/NesHacker/GameBoyG...
Пікірлер: 135
@martinevans89655 ай бұрын
So professionally scripted and edited. All killer no filler!
@NesHacker5 ай бұрын
That's the idea: no fluff just the good stuff :)
@cll1out5 ай бұрын
For those who don’t know, the concept of VBLANK stems from consoles connected to CRT TVs where the beam draws the picture from the top down, but the beam needs time to be brought back to the top and is turned off for this period. This happens 60x/sec (USA) and is even designed for in the NTSC/PAL standards. It conveniently gives time for the CPU to do some extra offscreen tasks such as screen movement tile refreshes etc. they carried this over to the Gameboy not because an LCD would need time to go from bottom to top, but it defines a target frame rate and also gives some off-screen CPU time.
@uchusky085 ай бұрын
I'm not a programmer, just someone who loves video games, and your videos have been great at explaining to a layman how the code is working under the covers.
@NesHacker5 ай бұрын
I'm glad you've been enjoying them, and please look forward to more in the new year 🎉
@m4r_art5 ай бұрын
You are an online rarity my friend. If Nintendo has any vision they should support you in teaching these things to people. You are effectively preserving a chunk of history through technical knowledge. Your videos will be a key asset when people decide it's time to make retro graphics again. And I'm pretty sure when people are through with the new systems and their eternal quest for realism, people will notice true art and design lies in doing more with very little.
@Robomandude5 ай бұрын
Good old H-ram. The reason it doesn't cause any bus conflicts is because those 256 bytes are in the cpu die itself, the bus isn't used at all.
@NesHacker5 ай бұрын
Oh interesting, that would make sense given the DMG-CPU is a system on a chip. Now I'm interested and will have to look into it more deeply 🤔
@kwigboАй бұрын
More please. It's so hard to find good videos on Gameboy Assembly and I am working on my own game currently. Great video, I learned a lot.
@MattHughson5 ай бұрын
Your best video yet, and maybe the best homebrew primer ive ever seen! I cant imagine how long this took to capture and edit! 😮
@NesHacker5 ай бұрын
Thanks Matt! Yeah it took me about two months from concept, through script, to finished 😅
@sirincandescence69405 ай бұрын
Im loving the gameboy development videos, you actually got me to start a project i've always wanted to do! Keep em coming.. I would love to learn common gb coding practices.
@tolstoj_5 ай бұрын
This is the best and most understandable coverage on the topic I've seen so far, really great video!
@OlofNaessen5 ай бұрын
Wow. A lot of work must have been put into this video and the result is awesome. Keep up the good work!
@kirby0louise5 ай бұрын
The bus conflict issue is interesting. HRAM ($FF80-$FFFE) and OAM are on their own internal busses to the SoC while WRAM/VRAM are external, so the CPU can safely access HRAM during the transfer. The thing is, the GB's DMA unit is supposed to block CPU access while it is working, so I'm not sure how you could have the conflict appear in the first place. But reading up on a number of high-end GB documentations and they all warn against bus conflicts, though none go into detail about why it happens when on paper the DMA unit should prevent it.
@NesHacker5 ай бұрын
Kirby, you never disappoint. If you’re interested in doing technical editing on scripts, let’s talk. E-mail my NesHacker account. I’d be very happy to hear from you!
@kirby0louise5 ай бұрын
@@NesHacker Thanks! I'll email you when I have a spare minute tonight!
@kwigbo5 ай бұрын
I love your GameBoy videos. Keep them coming! 👏🏻
@NesHacker5 ай бұрын
Thanks! I definitely have more planned for the new year!
@ppp_ppp_ppp_ppp_ppp_ppp5 ай бұрын
wow the editing and motion graphics on this video were so good, this was awesome
@SilverGreen935 ай бұрын
I don't understand, how can the display get physically broken by burning a line? You either set it or not to the tiles you want. How can that harm it?
@Rob_III5 ай бұрын
I was wondering the same thing. I'm having a real hard time believing this and in my (albeit short) round around the web I haven't found any evidence to support this claim (yet). I'm not sure if what is shown @1:35 is actually a (permanently) damaged LCD from software or just a hardware failure.
@regular_space5 ай бұрын
Quoting the pan docs: “Stopping LCD operation (Bit 7 from 1 to 0) may be performed during VBlank ONLY, disabling the display outside of the VBlank period may damage the hardware by burning in a black horizontal line similar to that which appears when the GB is turned off. This appears to be a serious issue. Nintendo is reported to reject any games not following this rule.”
@Rob_III5 ай бұрын
@@regular_spaceYes, but from NESDev: "However, in leaked official Nintendo Game Boy Programming Manual (version 1.0, released 11/09/1999) it's not mentioned that it can cause any hardware damage, only that "a black horizontal line appears on the screen" if LCD turned off outside of VBlank interval (except on Game Boy Color, where it's safe). Also it says that it's 'recommended', not 'required'." From what I've been able to find so far, you'd have to keep doing it pretty extremely and for long periods to have any real lasting effect (if at all). Edit: The actual text from the manual: "Setting the LCDC to OFF (Recommended) Covers: DMG and CGB In early DMGs, a black horizontal line appears on the screen if the LCDC is stopped (LCDC register bit 7 ← 0) at any time other than during vertical blanking. Therefore, the LCDC should be set to OFF during V-blanking. If the occurrence of V-blanking cannot be confirmed, the LCDC should be set to OFF when the value of the LY register is 145 (91h) or greater. These restrictions do not apply in CGB. Thus, when creating software for use on CGB only, the timing of setting the LCDC to OFF need not be considered."
@NesHacker5 ай бұрын
I too am confused by why this might happen. I debated leaving it out, but having seen the line on one of my Game Boys and seeing the GIANT SCARY RED section about it on pandocs made me reconsider. 🤔
@kirby0louise5 ай бұрын
I imagine it's a similar case to how the Commodore Pet has the killer poke. The LCD isn't a CRT (even if it behaves like one for the PPU), I don't think you can burn it in. There might be some temporary odd behavior, but no serious permanent damage.
@schlangengrube1575 ай бұрын
That was a really exciting look at the Game Boy. As I am currently working on my own homebrew project for the NES, a lot of the mentioned concepts sound pleasantly familiar.
@coomtothebroom7785 ай бұрын
Another good video. Your vids are always worth the wait. Great job!
@NesHacker5 ай бұрын
Thanks so much!
@BlakeIzayoi3 ай бұрын
This is a splendid video! You explained everything very well. It also got me a bit interested in looking into Game Boy homebrew...
@vervalkon5 ай бұрын
Excellent video. Informative and straight to the point!
@durona5 ай бұрын
This is fascinating! So glad I found this channel!
@user-cy2lc7vm7m5 ай бұрын
great video from start to finnish!
@Rob_III5 ай бұрын
Helvetti joo
@brandnewman98705 ай бұрын
This is certainly a great and very explanatory video for whoever wanna start messing with Game Boy graphics, but it doesn't mean it won't catch the interest of "simple" video games fans! That's a lot to say about such a technical topic ! thank you very much for both the information and presentation featured in your video!
@Kawaiilolrofl5 ай бұрын
Awesome. Very well made. Here's a sub.
@aweawd5 ай бұрын
Great video! I learned a lot of cool stuff. Still need help with snes though... Still excited to learn how to do that. Thanks!
@alieander5 ай бұрын
Love the animations!
@NesHacker5 ай бұрын
Thank you!
@nauikunart5 ай бұрын
this video is underrated, it should have a million views by now. amazing!
@NesHacker5 ай бұрын
Maybe someday :)
@laroldsjubilantjunkyard5 ай бұрын
Very High-Quality Video. Good stuff.
@NesHacker5 ай бұрын
Thanks 😊
@j0elyb3an4 ай бұрын
Oh this video is great, I already knew a little bit about this stuff from SNES hacking but i never realized what PPU or OAM actually stood for until this video It was also neat to see the similarities and differences between SNES and GB
@DylanBradRamsey5 ай бұрын
Fantastic content, bravo mate
@NesHacker5 ай бұрын
Cheers 🍻
@springogeek5 ай бұрын
This is a great overview for gameboy graphics. I suppose the only thing missing is that you can use interrupts to wait for VBlank instead, which lets you save some battery by halting the CPU in the interrim. It's so cool to see you working on Game Boy stuff at the same time that it's been on my mind. I'm creating a programming language specifically targetted for GB and NES so its nice to have the additional resources to enjoy. I hope you do a video on GB audio in the future :)
@NesHacker5 ай бұрын
I really want to do a dedicated video on interrupt techniques for things like V/HBLANKS in the future. It was hard to fit into the script because I feel the need to explain interrupts in general at that point and it would have felt somewhat off topic for how focused I was keeping things. Good luck on your language, that sounds like a really fun project 🙂. And I'm hoping to do an NES Audio video/project in the new year... one on GB audio is definitely a good idea too!
@springogeek5 ай бұрын
@@NesHacker ah true, it definitely qualifies for its own topic. The language-work is fun, although a lot of effort, will have to keep you posted, if you're interested!
@inceptional4 ай бұрын
Simple and informative.
@shvc-py5 ай бұрын
I love these videos!
@NesHacker5 ай бұрын
😊
@zach61015 ай бұрын
This channel is so underrated
@NesHacker5 ай бұрын
I aspire to be "rated" someday, and hopefully never "overrated" 😆
@akko82105 ай бұрын
another amazing vid!
@NesHacker5 ай бұрын
😊
@dcocz39085 ай бұрын
I think this channel is very neat and you're certainly a clever chap. Now I do have a question as since I found your videos I looked on ebay for a game boy. I have to admit I know nothing about the hw but there were lots of choices - are you referring specifically to the first large grey game boy or will one of those pocket versions work?
@NesHacker5 ай бұрын
The Game Boy Pocket is functionally the same as the original "gray brick" Game Boy. So it will work for all the stuff I cover in the video just fine, and it's probably a better choice unless you want the original as a collectors item. Thanks for watching!
@informersinc4 ай бұрын
love this video!!!
@e.v.a.l.s5 ай бұрын
awesome awesome. i found your 6502 crash course a few days ago. glad you're still making videos
@jonweinraub4 ай бұрын
I always wondered how sprite maps worked. Do you have small examples showing the map, code, and expected output for just learning rather than the expectation of implementing it?
@kirby0louise5 ай бұрын
After seeing Roger Copetti's updated article on the GB's architecture I decided to revisit the bus conflict mystery and I think I've solved it. It seems to be down to two things: 1 - OAM corruption without bus conflict The GB's PPU is kinda buggy, and even if you avoid a bus conflict you can still get OAM corruption if OAM is written to at the wrong time, generally when the PPU is in mode 2 or 3 (these are internal modes, not programmer accessible ala Mode 7). Most emulators won't care and a write to OAM is a write to OAM, but hardware and cycle accurate emulators do care. Since both of these are "live" rendering modes you can avoid this by only ever doing OAM DMA during VBlank. 2 - Actual cause of the bus conflict While most consoles will pause the CPU during a DMA transfer (PS3/Xbox One family are exceptions, though they have multiple HW threads and more advanced bus arbitration so they are a bit out of scope), that doesn't seem to be the case with the GB. Rather, CPU memory access is _invalidated_ which can result in a lot of strange behavior if you're not prepared for it. By making sure CPU access always succeeds by starting DMA while the CPU is running in HRAM this is avoided. I think that makes sense. I could still be wrong (not an electrical engineer) but this does seem to explain everything I had questions with
@terriblecoughing47675 ай бұрын
Awesome. Thank you
@NesHacker5 ай бұрын
You're welcome!
@finnya47205 ай бұрын
This is very deep game boy knowledge 🙏
@RootsterAnon5 ай бұрын
I love this so much. Could you do some content on Rust AGB and how to work with it? that would be awesome! great video!
@NesHacker5 ай бұрын
I’d have to learn Rust first 😂
@RootsterAnon5 ай бұрын
@@NesHacker I know how to run demo "No Game" but that's where my adventure ends. Currently learning bevy but agb really took my attention. I'm using mGBA and it works great, i have successfully output some logs from my app. now i need to understand gba completely in order to make any progress.
@AlexanderShelestov5 ай бұрын
Ok, now it's clear, thanks.
@kboyhat5 ай бұрын
Thanks ขอบคุณมาก อยากรู้มานานแล้ว
@Jim_965043 ай бұрын
How did they update & store multiple instances of the same entities(les say goomba)? How was additional entity data (like speed and other 'unique' attributes) other than the ones in the sprite attribute tables were stored for these entities (goomba)?
@jacoblister5 ай бұрын
Love it - I wrote a Game Boy emulator this year (Emu Boy on github). Can truely say I know what makes it 'tick' now :) per scanline sprite limits are due to secondary OAM. This is a fixed sized hardware register which loads and queues up sprite data per scanline, hence the limit. Also, spirite prioirty weirdness got significantly tidied up on Game Boy Color
@tolstoj_5 ай бұрын
Hi, I couldn't find your project when searching Emu Boy.
@tolstoj_5 ай бұрын
Oh wait NVM, I found it using emuboy and your handle. How can I get in touch with you?
@NesHacker5 ай бұрын
Oh interesting, that makes more sense. Thanks for sharing! 😊
@AFourEyedGeek5 ай бұрын
Can a modified emulator remove the flickering by modifying the second OAM register to be larger?
@Tigrou77775 ай бұрын
It's possible to update the tiles during the horizontal interrupts (a few pixels each time, since there is many HBLANK in a single frame). A lot of games does that to animate the overworld map.
@NesHacker5 ай бұрын
Indeed, wanted to cover it but didn't want to get into the complexity of HBLANK in this video (especially since I haven't really covered interrupts or timing on the channel).
@khatharrmalkavian33065 ай бұрын
More or less the same as the NES/SNES strategy, except that those had more resources (more palette colors, larger tables, more sprites per scanline, etc).
@NesHacker5 ай бұрын
Very similar, I think the register interface is better on the GB and I like having the fixed window.
@khatharrmalkavian33065 ай бұрын
@@NesHackerYeah, the window seems cool. I'd like to play with that.
@samzeyel82204 ай бұрын
still fascinating
@aimademerich5 ай бұрын
Phenomenal
@NesHacker5 ай бұрын
I’m glad you like it!
@CosmosProvider4 ай бұрын
This video gave me the motivation to learn coding and do a custom gameboy Zelda game as a first project. Mostly because i would be bored to create entirely new tilesets but also because we didn't have an original 2D Zelda in past a decade and i can't wait any longer 🤣 Question : i imagine the logic of the game code on gameboy color is identical but instead of 1,2,3 for color value there's a lot more, or is it more complex than that?
@NeoShameMan5 ай бұрын
There is a video called the ultimate game boy talk, they have some word about compute done in hblank necessary for racing game road curves
@NesHacker5 ай бұрын
HBLANK stuff is pretty fun, and I tried to fit it in, but the script seemed to balloon up too much when I did, so I decided to set it aside and handle it in a future video :)
@Tashiro645 ай бұрын
That's freaking incredible! ....... i didnt get anything!! .. but i'm sure it's freaking incredible! nah seriously that captivates me to see how everything worked back then... I have so much respect for these programmers.. all these precise manip of assembly with the limitations etc...... now all they have to do is click click click click..
@lt71145 ай бұрын
Ohhhhh... I get it now.
@acos214 ай бұрын
1:47 From what game is this?
@Koettnylle5 ай бұрын
What game does the map with the castle and islands come from?
@NesHacker5 ай бұрын
That was just a demo I made, you can play with it in the screen scroll demo in the GitHub repo.
@Koettnylle5 ай бұрын
@@NesHacker OK nice. Good job!
@NesHacker5 ай бұрын
Thanks :)
@bitronicc18875 ай бұрын
I'm honestly curious if any of the 1046 production GB games ever contained a bug that unintentionally turned off the screen in the middle of drawing. If there were, then theoretically games would exist that could damage your screen!
@pacomatic98334 ай бұрын
They have to go through Nintendo, so they probably told the devs about any screen killers and didn't let them publish.
@fluffycritter5 ай бұрын
How does writing graphics data during retrace physically damage the screen? That's got to be one heck of a flimsy LCDC design to make that possible. I'm also not finding anything online about this phenomenon.
@NesHacker5 ай бұрын
It’s more changing the display enabled state outside a VBLANK. Pandocs warns against this explicitly, but afaik it’s not been definitively confined that this does happen (see the very long thread in the comments to this video).
@Dukefazon5 ай бұрын
The fact you can damage your LCD is super scary!
@NesHacker5 ай бұрын
It's super weird too, and hard to find concrete information on exactly how it happens. But it's in the pandocs, so I decided it was probably best to point it out to anyone making and playing their own home brew games.
@onederdude5 ай бұрын
Does this only happen on the original Gameboy screens or on modern panels as well?@@NesHacker
@NesHacker5 ай бұрын
Seems to only happen on the monochrome versions, unclear if it’s an issue on the GBC
I love these videos. I keep mistaking you for displaced gamers. Doesn't help that you both talk a lot about the nes and 6502 assembly.
@EffySalcedo5 ай бұрын
What is the gameboy game with the most sophisticated mapper? Could it be the Game de Heklen Tamagochi ; that unique lookin skyblue cart 🤔
@retropalooza5 ай бұрын
This took a month, wow
@ChaonicMew4 ай бұрын
I feel like you look a lot like the Honest Guide here on youtube, who does informative videos for people visiting the Czech Republic. Is that a weird thing to say?
@rcarrascc5 ай бұрын
Gawd dayum good video
@thedkm-48944 ай бұрын
-Gawd dayum-
@DazzlingAction5 ай бұрын
the programmers must of had fun with making these games....
@matthewrease23764 ай бұрын
Damage the screen?????
@jordancobb5094 ай бұрын
I wonder what the logic was behind building a display that can be damaged by software.
@mikaelsza4 ай бұрын
My curiosity is how hackers can turn GB games into color game!
@williamdrum98995 ай бұрын
0:02 Seeing an extra sprite that's mostly empty makes me cringe
@NesHacker5 ай бұрын
Haha, it's how they did it...
@phorchybug32865 ай бұрын
Yeah, I'm just gonna visual script, thank you.
@matzeherd13435 ай бұрын
Too much hall effect on your audio 😅 Pls dont do that 😬
@NesHacker5 ай бұрын
Yeah it was a mistake. I didn’t test the Final Cut on headphones and I didn’t hear it on my monitors or my mobile devices :(
@cakestealer59835 ай бұрын
So what you’re telling me is... thank god I don’t have to code for this thing