Making a Game Boy game in 2017

[Linux-SWAT]

https://www.gamasutra.com/blogs/Doc..._A_quotSheep_It_Upquot_PostMortem_part_12.php

 

[Eight Bit]

Nice! I took a quick look to see if the assembly is like the C64 6510 assembly but it looks a bit different

Who knows, some day....

 

[PowerGod]

Interesting

 

[rygD]

I got exited, thinking you were making us a GB game.

 

[Hellfleck]

I love reading those Post Mortems, thanks for sharing.

 

[FBnil]

"8 bits integer variable: -127 to 128 (or 0 to 255 if not using sign)"
Weird... I learned that you have 0..127 and -1..-128 ...
(quickly reading http://marc.rawer.de/Gameboy/Docs/GBCPUman.pdf )
Yeah, I was right, as a Z80 derivative (just like the Intels and AMD's) the article has a typo (but is still awesome to read).

 

[levi]

I love reading those Post Mortems, thanks for sharing.

I'm pretty sure me writing such a postmortem and editing it and fiddling with those animated gifs and so on would take me longer than actually writing the game. It's similar to how it was writing games for old 8-bit machines like the Amstrad, BBC or spectrum (although with the spectrum you also had the fun of colour clashing to deal with). Those systems did have a full framebuffer, so for full-screen title screens you could just stream the data off tape and into the framebuffer, but they didn't have sprite engines, so to move a character you had to write to the framebuffer directly.

That's complicated by the framebuffer on old machines (at least like the Spectrum and BBC - not sure about Amstrad or C64) didn't use a straightforward x by y layout where the memory goes all the way across the screen (or down if you fancy) then goes down one line (or across one) and does the next line, instead they use a layout that makes writing monospaced text quicker and easier, whereby the data goes across then down each character cell then on to the next one. To make a character move between cells cleanly you needed to manipulate two cells at the same time. A lot of early games just didn't bother with that and had you hurtling across the screen on character space every frame, which at 50fps (as was common in PAL territories) means you're across the screen in under 2 seconds in high-res modes, or less in any mode with actual colours. The C64 had hardware sprites like game consoles of the time, so could dynamically place a multicolour sprite in a different place on screen not adhering to character boundaries every frame.

That made knocking up a clone of Super Mario Bros in the form of the Great Giana Sisters possible. The other systems did get games that broke out of the character boundaries fairly quickly, but once the developers had gone to the effort of implementing that I guess they felt more like making something of their own design. Plus something like SMB means you need to be able to cross the not just the horizontal or the vertical character boundaries (like a game like Chuckie Egg does much of the time) but both at the same time often for multiple character and projectiles. Hardware sprites make all the difference (or these days on modern systems, software libraries can do the job most of the time).

 

[Eight Bit]

The C64 has a register that moves the current raster line (or the entire screen) one to 8 pixels offset. To move graphics data from one char to the next, the screen offset is moved 8 pixels over time, and then quickly set back to 0 while copying the char to the next one, giving the illusion of a smooth scroll. No chars need to be animated at all.

 

[levi]

Yeah, the BBC micro also had that sort of hardware scrolling, but because it had no hardware sprites, it spend all of its vsync time moving the player character and animating any enemies and often ran out of time before the beam started racing down the screen to paint the background over the bad bit that's appeared over the other side of the screen. It was surprisingly common to see a little dirt on the opposite side of any scrolling game on the BBC micro.

Thinking on it, I'm not sure why that's the case; if they haven't got time from a vsynced start to paint the background before the raster starts flying, they won't have time next time round, and given they didn't get to do it before beam start that time, they're starting later, so it'll get worse and worse until the character starts to flicker, and then it'll all reset. They didn't do that. Perhaps they actually only repainted the backdrop every other frame, which would explain why it was so visible.

You can see here the game styker's run where they seem to have taken the decision to paint the player character last which leads to his flashing quite a lot, as do enemy sprites and even occasionally bits of the background. It also seems to be taking two or even more frames to move, which makes it feel a little sluggish.

(warning: turn down your speakers before playing any of these; the BBC micro tended to be a loud computer)


Repton 2 on the other hand maintains a rock steady rendering of characters, but had noise actually on the leading edge of the screen, which is not how I remember it. It seems to me moving in two frames per movement; one frame to scroll the screen and move the player/enemy sprites and one to repaint the noise copied over from the other side of the screen.


To be fair to stryker's run it's also running in a 16-colour mode (where only 8 colours were actually steady and therefore usable in game), while Repton uses a 4 colour mode, so Stryker's Run had a lot more data to write out when moving sprites or rendering the background.
[doublepost=1513101947,1513100571][/doublepost]Gah, double post caused by boards general slowness. Seems to ping okay - is it a server misconfiguration or are we being DoSed?

 

[TeDaDeS]

That was a nice read.

Reminded me of the time I tried to make a graphical game in 14KB (written in BASIC) and it was only a single map with one screen with a fighting mode.