Imagine having to program for this little bitch. All hail high level languages and compilers

He's right though. Even if you could code in C for these little 8-bit CPUs you wouldn't need to. They were so simple.

I wrote an emulator this a while ago.

It was pretty easy to understand, some of the harder parts actually involved having to radically simplify my thinking. Writing 2MB games like Pokemon in straight assembly for it was probably a pain in the ass though

They probably wrote their own tools to write assembly for it though.

Too bad YouTube didn't work out for them. Could've at least tried setting up Patreon.

Why do you say that? Because they stopped posting?

maybe they just suddenly died

>why did they stop posting
that's the question

The channel has decent traction and thousands of views on a very narrow niche. Why aren't there new videos? Did the author get a real job? Or what said?

C compiles to assembly

I'm programming for something worse in some aspects.
At least the GB have a virtual screen for the scrolling that don't require some sort of double buffer thing and don't have a fucky and weird sprite system.
But the lack of block copy instructions on the """Z80""" of the gameboy is quite annoying.

Attached: penbelt.webm (320x240, 1.34M)

Unsurprisingly, they wrote simpler applications for simpler platforms.
Is this the MSX 2?

Yes it is.

Cool. Why did you choose it as your platform?

Had an MSX (1) as a kid and also its a "easy target", as most people use the pretty but choppy as fuck screen 5 for platformers etc, and the end result is that there aren't very good platformers on the system in general.

Looks like you have the scrolling down. Are you using mode 4? I was a Spectrum owner growing up, but later came to appreciate the MSX. I wish you luck.

Yep.
The sprites are quite a weird stuff.
You have 8 sprites per scanline, but the sprites normally only have one color, but you can fuse the sprites with an or flag thing that allows you to have a third color (selected by oring the color numbers of the two sprites), but they still count as two sprites, so you can only have 4 of those per scanline, but again MSX don't actually care if its 8 8x8 sprites or 8 16x16 sprites (you can only choose one for the WHOLE screen).
This "technically speaking" gives me the same number of sprite pixels per scanline as the NES, but i can't do smaller sprites, so i will have to use single color* 16x16 sprites as the shots.
*(the MSX 2 sprites actually have this 16 color table per sprite that allows you to pick an independent color per scanline)

This does sound weird, but not actually bad. Though it's a bummer to not have 4-color sprites, being able to change the colors per scanline should compensate for that. Since you mention shooting and the movement looks similar, are you making a Mega Man clone?

Yep.
Gravity, movement speed etc all the same.

Nice.

Attached: I'd buy that for a dollar.jpg (1280x720, 60K)

I even want to do stuff such as giant background bosses etc..
It's a quite fun but hard project.

Do you have a blog I can follow or something? I'd probably enjoy reading about your progress.

Not really.
But i will see when i get further into it.

There is something oddly appealing to this things minimalistic and sturdy design isn't it?

Then see you on Jow Forums (or /vr/ if they have home computer or dev threads again). If I were you, though, I'd register a Neocities website right now and drop the link here. Just saying.

the GB's easy as shit
dramatically easier than the NES

the typical GB game is a platformer, RPG, or puzzle game and the latter two don't need performance at all
kinda wondering if momotarou dengeki was written in C though, because that shit chugs sometimes, and it's a super simple platformer

biggest issue with C on the GB is that it's made for flat memory models
the GB's memory model is technically flat, but if you want a game of any actual size or if you want to add save RAM to the cart, you need bank switching on the cart, and dealing with that is a pain in the ass in C

even if it's simple, it's still a pain and things that are oneliners in C, without even doing a function call, can be up to 20 instructions or so if done manually in asm
better to have the compiler deal with that shit

b-but ASM is a high level language...

>transistor was invented in the 1950s
>microprocessor was invented in the 1970s
>we were making dies of integrated circuits in the fucking 70s, where it feels crazy to know that we were ahead of our time then
>programming vidya during the days of atari and then to the NES days still seems like an amazing feet to me despite it being probably extremely easy compared to now
Am I just easily amazed?

>feet
feat

Was the problem not just that compilers sucked balls back then?

C does require higher than 8bit integers?
That would be quite an issue.

The biggest problem with gameboy etc and C is some critical timing shit.
You NEED to perform all your video updating code during the Vblank period or shit fucks up, so at least the video code need to be asm.

i dont know, what'd the PDP machines have?

16/32 with extensions.

>256 kbs of ram

how the fuck did a game even fit on there

By not having to load the game on the memory, if it's the Atari 2600 VCS you're talking about.
Until the nintendo 64 or so, the cartridges were fast enough to pass as system memory, so when you plugged the atari cartridge in, its content was directly accessible by the CPU.
So, its technically speaking "up to 4KB of memory you can't change + 256 bytes you can".

it has 8k of work ram and 8k of video ram
also, you don't need to load much into ram, unlike more modern cd/hdd games, games are stores on ROM, which is physically attached to cpu's address space, that is, it's no harder for the cpu to read from the game cart as it is to read from ram, so there's no need to copy read-only assets into work ram

The hardware was simple so assembly wasn't too bad

you can use C on 8-bit machines
you'll probably be using unsigned char absofuckinglutely everywhere in your code because it's loads faster, but that's it

There is an C compiler for the gameboy if i'm not mistaken, but it's still not a good idea to make the sprite/tile update code on it.
But i bet it has a library for that.

sdcc supports gameboy
sdcc.sourceforge.net/

there's also the ancient gbdk, but that's only a c subset called small-c
gbdk.sourceforge.net/
en.wikipedia.org/wiki/Small-C

Quite interesting as frak.
Of course, you might want to know how to not use multiply and divide or floating point types for realtime code on those.

literally fucking nobody

gbdk kinda blows
spent ages wondering why a piece of code to access a table was reading garbage, turns out I was getting bit by weird number promotion issues since >255 array offsets broke and the code it generated went reading way into the abyss

IIRC multidimensional arrays broke too because of the >255 issue affecting the result or something, I can't remember, I should go test it now
ended up having a piece of garbage like this, and it really is garbage
UINT8 getmap(UINT16 x, UINT16 y) {
static UINT8 res;
res=(map+(x+y*MAP_WIDTH))[0];
return res;
}

every fucking bit of that was necessary and if I wrote it like a sane human being, it'd break
map was a global array with the current map data copied from ROM into RAM (since it'd change)

gbdk supports actual C
it uses sdcc anyway, but it's old as shit

Using multidimensional arrays on the gameboy is not exactly a good idea, as unless your array size is a power of two number, you need a multiply.

>Using multidimensional arrays on the gameboy is not exactly a good idea, as unless your array size is a power of two number, you need a multiply.
yeah, but that's pretty much the only way you're accessing a tile position in your stages, period

and anyway as long as you don't need to read from the map often (so, just on like the player and a few enemy objects), you're okay
it was an almost entirely grid based game too, and I had something like 8 actual frames to do my shit between updates too, wouldn't do this in a shoot-em-up, but I also probably wouldn't need to either beyond player->ground collision, if I even bothered with that
for anything that involved the whole map, it'd just cycle through in order from 0..MAP_SIZE and increment an x/y pos counter to avoid the multiply for when I needed to do something with where what I was reading was (gbdk sucks, so IIRC it doesn't optimize this itself)

I think it would be comfy actually

I see.
But you was pointing out that the gbdk cheats with multidim, right?

Imagine having to program for this big bitch.
Can only use C on two of the CPUs, 4 or 5 different CPU types (which means 4 or 5 different machine code languages), all the chips are weird and quirky and on the end of the day, the playstation GTE still rapes it.

Attached: the simple and elegant sega saturn design.jpg (531x561, 85K)

Programming in assembly is manageable and actually kind of fun for simple chips like the z80 and early x86 because a human programmer can get the theoretical maximum out of the processor for the critical loops. All of the clever little assembly tricks are actually impactful. Plus, if you have a macro assembler, you can write your own macros to simplify boring if/else game logic that doesn't need to perform optimally.

Why char? Aren't the sizes of integral types set per-system? So int would be defined as int8_t for compiling to the GB.

i don't think you really understand a lot about computers.

chrisantonellis.com/files/gameboy/gb-programming-manual.pdf

meseec.ce.rit.edu/551-projects/spring2014/4-1.pdf

marc.rawer.de/Gameboy/Docs/GBCPUman.pdf

github.com/avivace/awesome-gbdev

Pokemon ASM
github.com/pret/pokered

You forgot the no$gmb doc:
problemkaputt.de/pandocs.htm

This guy is quite good at damn good at documenting hardware, at a point it is more precise than his own emulators. (no$msx shits the bed with my thing, but i programmed it pretty much following the docs)

wtf that's so cool.
Metrovania esque?
I love that it's a pengu too.
MEGA TUX :}

No metroidvania whatsoever.
The idea is to make a NES megaman game, but not on NES.

I still like.
Is the penguin intentionally referencing tux or just coincidental?

Everything on the MSX references penguins.
From the games, to stuff like fm-pac, to manuals to everything.
Mostly konami weird influence.
Would be a sin to make anything else.

Yes, but back then compiler optimization was pretty bad, manually written assembly always was slimmer and faster.

Normies prefer to watch clickbaits videos and listen to crap music.

There's people for everything on the internet, but fishing em is a bit hard.

So can I make GB games in C? That seems pretty fun

Yep.
Obviously watch your step, use libraries if they're available, and try to keep yourself on 8/16bit values as everything over 8bit is probably emulated.
And it go without saying but get a good tile editor.

>better to have the compiler deal with that shit
Remember, we're talking about proprietary compilers from the 90's, not open projects that have seen decades of improvements from the entire world.

In the context of today, yeah maybe.

Imagine having to program for this little bitch. All hail high level languages and compilers.

Attached: _____.jpg (800x500, 82K)

>I'm too stupid to even understand C. Here, allow me to shit up a web page with 100MB of CurryScript.
That's you.

Attached: 3glqlh-ekbP56A.jpg (334x391, 26K)

int actually has to be at least 16 bits (be warned: compilers exist that do use 8 bit by default, but don't make any assumptions about it being ANSI C compliant then)
char has to be at least 8 bits (there are machines with like 16 bit char, but IIRC they can't address individual bytes anyway, char's also supposed to be the smallest addressable unit of memory, as long as that's >8 bits)

long has to be at least 32 bits
it's entirely compiler dependent on the specifics (int is 32 bit on modern machines, long is 64 bit maybe), but there are guaranteed minimum sizes, and this isn't C99, so there are no fixed-size names
that being said, GBDK does provide defines for types like UINT8 and INT16 and the lot anyway, so use those

all hail machines that don't fucking suck