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
@cll1out4 ай бұрын
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.
@martinevans89654 ай бұрын
So professionally scripted and edited. All killer no filler!
@NesHacker4 ай бұрын
That's the idea: no fluff just the good stuff :)
@uchusky084 ай бұрын
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.
@NesHacker4 ай бұрын
I'm glad you've been enjoying them, and please look forward to more in the new year 🎉
@Robomandude4 ай бұрын
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.
@NesHacker4 ай бұрын
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 🤔
@m4r_art4 ай бұрын
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.
@kwigbo6 күн бұрын
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.
@MattHughson4 ай бұрын
Your best video yet, and maybe the best homebrew primer ive ever seen! I cant imagine how long this took to capture and edit! 😮
@NesHacker4 ай бұрын
Thanks Matt! Yeah it took me about two months from concept, through script, to finished 😅
@sirincandescence69404 ай бұрын
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_4 ай бұрын
This is the best and most understandable coverage on the topic I've seen so far, really great video!
@kirby0louise4 ай бұрын
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.
@NesHacker4 ай бұрын
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!
@kirby0louise4 ай бұрын
@@NesHacker Thanks! I'll email you when I have a spare minute tonight!
@OlofNaessen4 ай бұрын
Wow. A lot of work must have been put into this video and the result is awesome. Keep up the good work!
@ppp_ppp_ppp_ppp_ppp_ppp4 ай бұрын
wow the editing and motion graphics on this video were so good, this was awesome
@schlangengrube1574 ай бұрын
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.
@coomtothebroom7784 ай бұрын
Another good video. Your vids are always worth the wait. Great job!
@NesHacker4 ай бұрын
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...
@durona4 ай бұрын
This is fascinating! So glad I found this channel!
@kwigbo4 ай бұрын
I love your GameBoy videos. Keep them coming! 👏🏻
@NesHacker4 ай бұрын
Thanks! I definitely have more planned for the new year!
@vervalkon4 ай бұрын
Excellent video. Informative and straight to the point!
@SilverGreen934 ай бұрын
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_III4 ай бұрын
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_space4 ай бұрын
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_III4 ай бұрын
@@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."
@NesHacker4 ай бұрын
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. 🤔
@kirby0louise4 ай бұрын
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.
@brandnewman98704 ай бұрын
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!
@Kawaiilolrofl4 ай бұрын
Awesome. Very well made. Here's a sub.
@joelybean9373 ай бұрын
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
@inceptional3 ай бұрын
Simple and informative.
@springogeek4 ай бұрын
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 :)
@NesHacker4 ай бұрын
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!
@springogeek4 ай бұрын
@@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!
@aweawd4 ай бұрын
Great video! I learned a lot of cool stuff. Still need help with snes though... Still excited to learn how to do that. Thanks!
@user-cy2lc7vm7m4 ай бұрын
great video from start to finnish!
@Rob_III4 ай бұрын
Helvetti joo
@laroldsjubilantjunkyard4 ай бұрын
Very High-Quality Video. Good stuff.
@NesHacker4 ай бұрын
Thanks 😊
@nauikunart4 ай бұрын
this video is underrated, it should have a million views by now. amazing!
@NesHacker4 ай бұрын
Maybe someday :)
@DylanBradRamsey4 ай бұрын
Fantastic content, bravo mate
@NesHacker4 ай бұрын
Cheers 🍻
@alieander4 ай бұрын
Love the animations!
@NesHacker4 ай бұрын
Thank you!
@finnya47204 ай бұрын
This is very deep game boy knowledge 🙏
@e.v.a.l.s4 ай бұрын
awesome awesome. i found your 6502 crash course a few days ago. glad you're still making videos
@khatharrmalkavian33064 ай бұрын
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).
@NesHacker4 ай бұрын
Very similar, I think the register interface is better on the GB and I like having the fixed window.
@khatharrmalkavian33064 ай бұрын
@@NesHackerYeah, the window seems cool. I'd like to play with that.
@kboyhat4 ай бұрын
Thanks ขอบคุณมาก อยากรู้มานานแล้ว
@kirby0louise4 ай бұрын
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
@dcocz39084 ай бұрын
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?
@NesHacker4 ай бұрын
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!
@jonweinraub3 ай бұрын
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?
@zach61014 ай бұрын
This channel is so underrated
@NesHacker4 ай бұрын
I aspire to be "rated" someday, and hopefully never "overrated" 😆
@akko82104 ай бұрын
another amazing vid!
@NesHacker4 ай бұрын
😊
@RootsterAnon4 ай бұрын
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!
@NesHacker4 ай бұрын
I’d have to learn Rust first 😂
@RootsterAnon4 ай бұрын
@@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.
@informersinc3 ай бұрын
love this video!!!
@shvc-py4 ай бұрын
I love these videos!
@NesHacker4 ай бұрын
😊
@AlexanderShelestov4 ай бұрын
Ok, now it's clear, thanks.
@jacoblister4 ай бұрын
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_4 ай бұрын
Hi, I couldn't find your project when searching Emu Boy.
@tolstoj_4 ай бұрын
Oh wait NVM, I found it using emuboy and your handle. How can I get in touch with you?
@NesHacker4 ай бұрын
Oh interesting, that makes more sense. Thanks for sharing! 😊
@AFourEyedGeek4 ай бұрын
Can a modified emulator remove the flickering by modifying the second OAM register to be larger?
@Tigrou77774 ай бұрын
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.
@NesHacker4 ай бұрын
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).
@samzeyel82203 ай бұрын
still fascinating
@terriblecoughing47674 ай бұрын
Awesome. Thank you
@NesHacker4 ай бұрын
You're welcome!
@aimademerich4 ай бұрын
Phenomenal
@NesHacker4 ай бұрын
I’m glad you like it!
@CosmosProvider3 ай бұрын
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?
@princepandeynyc2 ай бұрын
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)?
@Tashiro644 ай бұрын
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..
@NeoShameMan4 ай бұрын
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
@NesHacker4 ай бұрын
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 :)
@bitronicc18874 ай бұрын
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!
@pacomatic98333 ай бұрын
They have to go through Nintendo, so they probably told the devs about any screen killers and didn't let them publish.
@fluffycritter4 ай бұрын
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.
@NesHacker4 ай бұрын
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).
@Dukefazon4 ай бұрын
The fact you can damage your LCD is super scary!
@NesHacker4 ай бұрын
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.
@onederdude4 ай бұрын
Does this only happen on the original Gameboy screens or on modern panels as well?@@NesHacker
@NesHacker4 ай бұрын
Seems to only happen on the monochrome versions, unclear if it’s an issue on the GBC
@EffySalcedo4 ай бұрын
What is the gameboy game with the most sophisticated mapper? Could it be the Game de Heklen Tamagochi ; that unique lookin skyblue cart 🤔
@lt71144 ай бұрын
Ohhhhh... I get it now.
@Koettnylle4 ай бұрын
What game does the map with the castle and islands come from?
@NesHacker4 ай бұрын
That was just a demo I made, you can play with it in the screen scroll demo in the GitHub repo.
@Koettnylle4 ай бұрын
@@NesHacker OK nice. Good job!
@NesHacker4 ай бұрын
Thanks :)
@acos213 ай бұрын
1:47 From what game is this?
@jordancobb5094 ай бұрын
I wonder what the logic was behind building a display that can be damaged by software.
@kazimir80864 ай бұрын
Why is it burning that line in?
@CreamusG3 ай бұрын
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.
the programmers must of had fun with making these games....
@ChaonicMew3 ай бұрын
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?
@matthewrease23763 ай бұрын
Damage the screen?????
@retropalooza4 ай бұрын
This took a month, wow
@phorchybug32864 ай бұрын
Yeah, I'm just gonna visual script, thank you.
@rcarrascc4 ай бұрын
Gawd dayum good video
@thedkm-48943 ай бұрын
-Gawd dayum-
@cakestealer59834 ай бұрын
So what you’re telling me is... thank god I don’t have to code for this thing
@NesHacker4 ай бұрын
Nah, it’s fun 🤩
@mikaelsza3 ай бұрын
My curiosity is how hackers can turn GB games into color game!
@williamdrum98994 ай бұрын
0:02 Seeing an extra sprite that's mostly empty makes me cringe
@NesHacker4 ай бұрын
Haha, it's how they did it...
@matzeherd13434 ай бұрын
Too much hall effect on your audio 😅 Pls dont do that 😬
@NesHacker4 ай бұрын
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 :(