/vr/ - Retro Games

First step you have to turn 18.

Literally impossible.

>get NESMaker
>watch some jewtube tutorials
>...
>profit

>>8055709
I'm going to make millions!!! Thanks anon

>>8055671
Learn ASM

>>8055717
ASM isn't a language to learn, assembly is essentially speaking directly to the hardware with 1's and 0's

>>8055717
>>8055748
the implication being that one would have to understand the target hardware to write assembly code for it

thus it is generally better to just write your NES games in C, which we can do now

>>8055748
*woosh*

>>8055754
fuck off

>>8055758
After you.

>>8055754
reddit

>>8055748
Wrong.

>>8055770
explain nigger

>>8055782
What is there to explain? Assembly is classified as a low-level programming language with platform specific differences.

>>8055783
tell me what directly sending instructions to the hardware is called if not "assembly"

>>8055787
>nitpicking

>>8055671
Much easier for both newcomers and experienced people, I guess, there is instant emulation and debugging available. Making cartridges the old way would not be cheap, but there are compatible hardware solutions.

>>8055987
How many NES games have you written so far?

>>8055993
14

>>8055671
As far as programming and the other overhead skills you'd need much easier, gameplay design and bringing the art assets together into something that doesn't look like shit will still be incredibly hard.

>>8055996
link?

>>8055782
>>8055787

Speaking directly to the hardware with 1's and 0's is machine code. That's what programmers wrote before Assembly languages. ASM (6502 assembly specifically for the NES, C64, Apple II etc.) is a language that needs to be assembled to machine code.

>>8056012

>>8055753
it's a 1Mhz 8-bit CPU with 42k total memory space. you can't code on that thing in C, silly.

You read the docs which are all online and lrn2 6502 assembly language. start with a small NROM game where there's no banking or other bullshit

>>8056002
>and bringing the art assets together into something that doesn't look like shit will still be incredibly hard

That never stopped Micronics.

>>8057081
An assembly lanaguage literally just replaces the binary commands with keywords one for one, for ease of use. It's a direct translation to machine code.

>>8057263
What you're describing is called "machine instructions", which have a one to one correspondence with the binary commands, but most assemblers also have more complex "assembler instructions". Also most assemblers have symbolic labels, where the assembler handles the addresses of those labels automatically.

>As someone with zero video game making knowledge.
I always lol. Hope you at least learned a few things about computer science your first week of googling before inevitably giving up like everybody else.

>>8057116
Not unless you use some hyper-optimized compiler.

>>8057116
6502s don't really work well with C anyway

>>8058380
Any reason for that? I can't off the top of my head see what would prevent a compiler from working with it, unless there just isn't a compiler that exists. Or is it just so finicky that even C code produces dreadfully unoptimized output?

>>8055671
>How hard would it be to make a NES game today?
not very difficult at all.
>>8055671
>As someone with zero video game making knowledge.
just need assembly knowledge. programming the nes is straight foward and well documented.
>>8055709
>>get NESMaker
that's ok for beginners but you'll find yourself raging at it when you want to be more creative with the display.

>>8055671
You will never do it. Don't kid yourself. It will never happen. Never. Never.

You will never make that dream game.
Hell, you will probably also achieve nothing of significance in life in general.

You are just another NPC, that no one will notice, not remember. I bet your family won't remember you one or two generations down the road.

And I'm not just talking to this poster.

I'm talking to the one reading this. Yes, you. Nothing.

>>8055671
there is a tool to make your own nes games you can even use the assets included to make a game in a similar fashion to pixelgame maker

>>8055671
You'll have to learn 6502 ASM, the architecture of the NES, and the graphics / sound formats.
Start here:
https://skilldrick.github.io/easy6502/
With this:
https://www.masswerk.at/6502/6502_instruction_set.html
Then here:
https://nerdy-nights.nes.science/
https://wiki.nesdev.com/w/index.php?title=NES_reference_guide
That should keep you busy for a while. Ask questions in /hbg/ when you get stuck. Good luck.

>>8058652
> not very difficult at all.
Don't listen to idiots like this. They have never written a line of code in their life. It will take a while so celebrate completing each small step to keep yourself sane. Good luck.

>>8058656
I hold up a mirror for you to self reflect
I look at my works and I smile; I smile because I see that I have much to learn; But you, you have no works. You grow old fast; you neglect to consider that your cynicism steals life from you

>>8058656
gotta try harder than that to make me stop enjoying life and developing myself

>>8058884
> enjoying life
> developing
pick one ;)

>>8058656
Yeah. I know.

>>8058656
damn bro we do be livin in a society

>>8055671
I made a master system game when I was still at school, programming an old console in assembly isn't "easy" per se but it's a fun challenge and isn't as hard as you might think. That project actually got me my job today, so it paid off. If you're totally new to programming you might want to become familiar with the basics before you try to make a game with assembly, but I wasn't that experienced with programming myself when I did it.

Really the hard part for me is game design in general, I have never had an original thought and the game I made was a straight rip-off of another game. These days I've been working on a game boy game but it's been going really slowly because it's hard to motivate myself to make another rip-off but I can't think of any ideas that would differentiate it. (The "plan" is to make a rip-off of Nuts & Milk)

>>8058619
The instruction and register set is very unfriendly to C, but more importantly compiled languages are simply too slow for action games on a pre 32-bit machine. A few 8/16-bit games used scripting engines and some later period SNES and MD RPGs were written in C but those are all genres that don't have much stuff moving around.

Otherwise a good 90% of 4th gen and earlier console games were coded in assembly language. There's simply no other way to do it with the limited amount of memory and CPU cycles.

>>8058989
>programming an old console in assembly isn't "easy" per se but it's a fun challenge and isn't as hard as you might think

The bigger problem is more about creating the art assets. After the Atari era those start requiring a dedicated graphics guy. Also you'll probably need a dedicated guy to code the sound engine and enemy AI. Yes, Atari 2600 games could be made by one person but the typical Mega Drive game was more like 4-6 people.

you need to think of it more as basically an indeterminate hobby instead of a fixed goal you'll achieve. study programming, start on blender and art fundamentals, listen to podcasts or whatever in the background to push through the tedium. Eventually if you put enough hours in and follow some guidelines that are out there you'll probably get to a point where you can put something together. If you think of it as a countdown where you really need to push yourself you'll never make it.

>>8055671
Very difficult. Probably 3 years of work for a shitty game. It would be much easier to make a genesis game as they run on C.

>>8060436
Unless it's an RPG you're not coding a Genesis game in C.

get into making short films, writing or art if you need a creative outlet, vidya is a massive timesink where at best you might be able to create something recognizable as a game after multiple years.

>>8055709
$38
nigger I'm fucking broke until the 1st

>>8058656
Nah, my mum told me I'm special and smart and really handsome. Don't be jell.

>>8058656
shut up :(

>>8060445
I heard Sonic Spinball was written with C, at least partially, which explains why it runs like ass

NES coding is simple until you move past NROM then it can get sticky.

>>8060756
Good thing that compilers have progressed significantly since then.

>>8060837
Compilers have progressed, yes, but when resources are at a premium, in performance-critical functions a human can still always optimise better than a compiler.

you can definitely make an NES game today, but releasing it out on the market would be almost impossible, at least officially

>>8060903
>you can definitely make an NES game today, but releasing it out on the market would be almost impossible

>offer ROM on Steam
>charge $30 or whatever for it
Easy as.

>>8060932
>charge $30 or whatever for it
Every time I see devs with huge egos because they released some video game on an older console I can't help but laugh. Almost no homebrew passes the Steam test: is your game good enough that it wouldn't be ignored as a $5 PC release on Steam? If $5 is already hopeless for virtually all homebrew, imagine $30. Lmao.

>>8060421
that was true until probably the 7th gen consoles at which point like 40 people and $10 million game budgets became the norm

>>8060943
>thinking a game being on Steam automatically means it's good
You are not very bright, do you know that?

>>8060932
I agree but there are too many autists who insist on a physical cartridge release so they can exploit coomlectors for money.

>>8060950
You did not get it. Would you care for <insert homebrew here> if it wasn't on a plastic cartridge, running on an 80s/90s console?

>>8060982
i assume he's not a retarded coomlector

>>8060976
With NES games that's bad because they're forced to make either an NROM game or use those stupid UNROM-512 boards from Ali Express.

yeah just release it as a ROM so you can play it on emulation or put it on a Flash cart if you want to use a real console

>As someone with zero video game making knowledge.

You have the advantage of having more access to development tools and documentation than the average NES dev did back in the day so there's that, but you're in for a rough time if you don't know code at all. If it takes making a game for NES to motivate you to learn though then you might as well get started by learning how to make a NES game.

>>8058656
>I bet your family won't remember you one or two generations down the road.
>implying I'll manage to reproduce myself
jokes on you

>>8061105
and any memory size/mapper configuration you like

>>8058656
This is the guy who makes life worse for other people and themselves for no reason. Don't be this guy.

The Master System is easier. Better CPU, less janky hardware, and fewer/simpler banking options.

>>8061020
There are clone MMC3s now but it's much harder to make any money selling your game if you use one.

>>8061442
that's why I say fuck physical cartridges, it's better to offer the ROM as a download and the relatively small amount of people who want to play it on real hardware will likely have a Flash cart.

>>8061020
Just make it NROM, then. All the best NES games are NROM anyway.

>>8061251
All you have to do to prove him wrong is succeed.

I bought nes maker. Don't do it man. Even if you get it you STILL have to learn assembly. The devs kind of abandon it. Make some shit on NROM basic ass shit. Even try the C program thing. Join the NES Maker discord and check out the forum and read through some of the code examples and shit even the videos before you decide to get it.

>>8060857
Modern computers are too complex for that, it's true for /vr/ stuff though.

>>8055709
probably the worst place to ask but is that like rpgmaker or can you keep working from stuff made on that without it?

>>8055671
SNES is an easier system to program and develop for.
you can download the dev manual and read it.
you can also download a book on the 65816.
of course, you should know some C before learning assembly, but it's not hard

>As someone with zero video game making knowledge
You're not going to make a nes game then.

>>8063701
This. If you know nothing about making games, and especially know nothing about programming, you're going to glance at the 6502 instruction set, and quit before you can make a 16 bit adder.

>>8062498
>All the best NES games are NROM anyway

what did he mean by this?

>>8062569
nah its like rpg maker you have to use the NES maker engine and build off that. you can't import your pre existing nes shit... you can import your graphics though

>>8062572
>SNES is an easier system to program and develop for.
What? No it's not. The SNES is a complicated spaghetti mess which is why nobody makes any homebrew for it.

>>8064592
>>All the best NES games are NROM anyway
>what did he mean by this?

different nes games use different mappers. mapper 0 is "nrom" type games. they like these ones best i guess
https://nesdir.github.io/mapper0.html

>>8064331
>you're going to glance at the 6502 instruction set, and quit
Most do i'd imagine, but, that's why i linked the 6502 tutorial and instruction set first. That's where i started: If you have patience and the will to do it then you can. >>8058854

>>8064616
the SNES is like an NES without quirks

>>8058619
C code generally requires a reasonably functional stack for function arguments and local variables. The 6502 stack is useless for this purpose as there are no memory addressing modes that can access the stack, only fixed locations in memory can be easily used. To make normal C code usable compilers have to implement a software stack, the 6502 does support 16bit pointers stored in zero page, but they are very slow to use. Basically C code on the 6502 is slow on a fundamental level. The only possible way to make C run at an acceptable speed would be to completely avoid all local variables and function arguments, or otherwise would require whole program optimization to statically allocate fixed locations in memory to stack variables, but this would basically ban recursion. Also due to other limitations of the cpu you could not write normal C, you would have to heavily contort your code to be compatible with the limitations of the cpu.

>>8065304
Adendum, there are not many C compilers to choose from for the 6502 and none of them perform the required whole program optimization to make C actually usable. But this thing exists which apparently does.
http://cowlark.com/cowgol/index.html

>>8065304
The Z80 is a little friendlier to HLLs because it has proper 16-bit registers and a movable stack that can span the whole memory space. But still you really need a 16-bit CPU for them. IBM compatible software was commonly written in HLLs from the earliest days of the IBM PC.

>>8057116
people have written code for the C64 in C with cc65, and there were even contemporary on-machine compilers (that are absolute hell, but your programs were sure as fuck a ton faster than BASIC)
the 6502 isn't particularly well suited for C, but people can and do manage to get by with it

you can totally beat out a compiler with hand-written asm, even a modern one given that people haven't spent decades heavily optimizing C compilation on 6502, but it's not like it'll be impossibly slow or chew up all your ROM space with overhead

sure, you couldn't afford to get away with it writing NES software in C back in the 80s, losing several kB of your cartridge was a big deal when you wanted to use as small ROMs as possible and write tiny code to fit on them
but in modern times, fuck it, your only limitation is the mapper you use, and a small project, even with the overhead of C, isn't going to burn your whole 32k of PRG if you take it easy and just use plain NROM
you'll have trouble with more advanced mappers though, because they actually well, map, and C as a language expects a nice flat memory map instead of bankswitched nonsense, but even then it's still doable

>>8066287
> C as a language expects a nice flat memory map instead of bankswitched nonsense
That's a yuuuge hurdle to C right there. Only 32KB is visible at one time, and bankswitched regions can be chunks of 8, 16, or the entire 32KB depending on the mapper. At least with raw ASM you have direct control of the program counter and can keep track of exactly where you're going and switching around to.
Granted, C development time might still be faster in the longrun than raw ASM, but you can't just fire up GCC and expect good (or even functional) results.

>>8064592
All my favourite Famicom games are the early ones from 1983 to early 1986. Nuts & Milk, Pinball, Ice Climber, Balloon Fight, Golf, Battle City etc. If I ever get round to attempting to make a Famicom game, I would want to go for that early style.

>>8066287
>people have written code for the C64 in C with cc65,
Almost certainly these would be text programs or stuff with little animation. I mean, yeah, Maniac Mansion used a scripting engine and not asm but it didn't exactly need to move much stuff around. Some other adventure or RPG titles might have also used some form of HLL. Action games however? Fucking impossible to write those in an HLL.

>>8066337
It's impressive the lengths some lazy fucks will go to to try and get out of coding in assembly language.

is there any other resources you guys recommend I should read? all I really found was this: https://nesdoug.com/ seems good to me tho so far.

>>8058656
Based. No one ever succeeded by being coddled and told they're gonna make it.

>>8058854
Any programming knowledge required before learning this?

>>8066620
Nope! Working w/ Assembly Language and classic hardware is wayyy different than modern development. Programming knowledge certainly wouldn't hurt though.
The most important thing you need is patience, and arguably it's the only thing you need.

>>8058656
I have a son that does great in school.
But you are right about that game, I'm never gonna make it.

>>8055709
>>8060521
Imagine some anime posting tranny calling you a nigger...

>>8055671
My advice: learn Game maker and use a clone Nintendo pad to play your creations. It won't be quite the same but a million times easier to do and the games you make WILL work better, much faster. And you can get tutorials and support easier.

>>8058656
KHV 20-something NEETs in the thread be like

>>8066683
Also understanding math...or else good luck.

>>8066729
If you're posting this on a site built on anime culture what does that make you?

>>8055671

>>8066337
C can accommodate to more architectures that you can imagine. The famous undefined behavior cases are there because the standard did not define details that were compiler's and hardware's business. Even on x86 people used to be familiar with far and near pointers, code overlays, and EMS/XMS.

It's not an advice to write in C for NES. However, a library or a toolkit that acts as a middleware and allows the user to extend it with C code is possible.

>>8058656
>Being this much of a jew.
Yikes.

>>8067223
He's right goy, go kill yourself if you can't cope with it

Not that hard but hard by modern standards.

>>8067218
Implementation defined behaviour is stuff that's left to the compiler and/or hardware to decide. Undefined behaviour is never ok, it just isn't required to cause a compiler error because it wouldn't be straightforward to detect while parsing the code and forcing a check at runtime could hurt performance. Implementation defined =/= undefined.

>>8067047
> understanding math
not as important as you would think: there's no math a middle school kid couldn't do for a 2d game. the only thing assembly language can do is add / subtract anyway. you will have to learn how to read and manipulate bits and bytes, which isn't really taught anywhere anymore.
what is important is being able to design and implement data structures and how they work with the architecture of the console and the rest of your program as a whole. i see that as a creativity and enginnering exercise personally; not really a "math" one.

>>8068268
> submarine that collects money
Is that some Freudian slip?

>>8068275
heh i don't know. this is a source NES port from an Atari 400 game. i think it was one of the default text icons heh.

>>8068268
I figure the math requirements are overstated, but wouldn't you be doing a lot of algebra?

>>8068289
No. It's just basic adding and subtracting of integer numbers.

>>8068289
i guess; but i don't really think about it that way. you load memory values into the accumulator, perform operations on them, and store them back in memory: these values represent something in the game be it graphics, logic, movement, music, etc. i suppose that's "algebra" but that's not how i see it personally.

>>8068289
assembly language is much different than working with any number of the C-like higher level languages. i see it like guiding a hyper fast sewing needle to make 60 tapestries per second. you have to tell it everything in tediously specific terms or else bye bye program.

>>8055671
If it was on a real cart could nintendo sue for bypassing it's lockout chip?
Would you need to get the lockout chip in order for it to work on period hardware?

>>8068332
The patent on the lockout chip expired years ago.

>>8068332
it's been reverse engineered completely and a replacement has been produced. 100% legal.
funny story is that the Tengen (Atari) clone chip had some debug functions that allowed the algorithm to be dissected.
https://wiki.nesdev.com/w/index.php/CIC_lockout_chip

>>8068332
In Sega v. Accolade the court ruled that reverse engineering to learn about a console's security system and release unlicensed games comes under fair use.

If one were to design and program their NES game, how feasible would it be to manufacture one's own cartridge? What kind of electrical, mechanical, and chemical engineering are required, and would it be attainable to engineer a home factory for less than $5,000 (keeping in mind a limited print run of, say, a few hundred cartridges)?

>>8068832
Homebrewfags generally just buy a bunch of premade chink NROM or UNROM-512 PCBs and have a batch of cartridges made in China. But that's a complete waste of effort when you could just offer the ROM as a Steam download.

>>8068832
yes you can do it easily, and there is no need to own the manufacturing equipment
1) source parts from china
2) design a PCB in kicad
3) have a board house make a run for you
4) have a company 3d print a nice shell
5) have a company print a nice glossy label for you
6) assemble the circuit, close it up in the shell, and apply the label
use a licensed cart as a template if you don't understand how to efficiently design one. also, you may need to source a lockout chip from a sacrifical cart, or otherwise modify your console to disable the lockout. also also, most NES games need a mapper, and if you want one, you'll either have to source one from a real cart or put in an FPGA (relatively expensive and makes the circuit much more complicated)

>>8068908
>and if you want one, you'll either have to source one from a real cart or put in an FPGA (relatively expensive and makes the circuit much more complicated)
For discreet mappers this is true. For stuff like UNROM, CNROM, etc no since they just use a simple TTL circuit to bank switch the ROMs.

>>8068908
>and if you want one, you'll either have to source one from a real cart or put in an FPGA (relatively expensive and makes the circuit much more complicated)
For ASIC mappers this is true. For stuff like UNROM, CNROM, etc no since they just use a simple TTL circuit to bank switch the ROMs.

>>8068872
>>8068908
Hmm. Would this process produce a period-accurate cartridge that could undoubtedly pass the inspection of autists? Are there schematics for the original cartridges and their engineering that I could pass on to hired companies? Would the cost of a globalized, modular cartridge assembly process be less or more than simply accumulating the capital myself? Why do I need a scavenged lockout chip? Is it possible to manufacture my own lockout chip that, again, would pass as perfectly legal and Nintendo-approved? My goals are:
>design period-accurate NES game programmed and designed with graphical, audio, and code paradigms of the 80s
>produce at least one (1) cartridge that passes with 99.9% certainty as an authentic NES games, created at some point in the 80s
>artifically age the cartridge in a realistic way with UV rays, dust, and dirt to make it appear upon inspection that the cartridge has been in plausible storage for the last 35 years
>forge documents and business license archives to create a paper trail leading backwards in time to a small independent game company that folded when some sort of negotiations with Nintendo went awry
>forge documents for employee identities, creating fake yearbook photographs of boomers who graduated between 1957 and 69, previous employment records, etc all sourced from census records that currently have no digital traces

>>8069143
>After building hype for this “lost game” I will put it up for auction and cash these idiots’ checks

>>8069005
I know the SNES better, and even there you see TTL chips to implement the memory map for the cart, but i don't consider those mappers.
mappers to me have state that is accessed via memory mapped I/O to do things like swap banks into the address space at bare minimum

>>8069143
if you want to fake autists out you'd have to injection mold the shell, and that would be outrageously expensive to produce the dies

>>8069143
polybius is already a thing and they never had to actually make anything

>>8069161
Honestly, anon, if one managed to go through all that effort, to the point where not even the FBI could figure out if the game was created in 1986 or 2021, then money likely isn't important. It's the game, as in, not the video game itself, but the literal art of counterfeiting. It's like recreating antiques for the black market. Sure, one might make a few bucks selling to shady guys who resell it, but the point is to create perfection, to live and breathe a lie that no one else knows the truth of. What greater pleasure is there? What better honor for a video game console?

>>8069143
There was a Japanese guy copying from online photos of dev cartridges and selling his clones as genuine prototypes to unwitting dummies. For a while there were people showing up every month or so in different places asking for analysis of a prototype dev cart they'd bought. After a while the first response was "yeah it's a fake, you bought it from that Japanese guy, didn't you?".

>>8069167
Not really. ASIC mappers in the NES perform a couple different tasks like banking, extra address decoding to enable cartridge RAM, and soft switching of the mirroring direction. Some also provide scanline IRQs or expansion sound (not on 72-pin cartridges). A discreet mapper like UNROM just switches the ROM banks around and provides no other features.

>>8069185
Any links to this, anon? Whether I bother to follow through, it would be interesting to see what mistakes he made. How did people see through his scam? If he worked through photos, that can only produce superficial results. If one were doing this to make fuckloads of cash, it would be a great idea. Scam people, make money, get caught, disappear for a few years, re-appear under a new identity, etc. But I want more.
>>8069168
What sort of costs are we talking about, anon? I only mentioned $5,000 as a starting point; merely a guesstimate.
>>8069172
Polybius is fascinating to think about. Word of mouth and urban legends, broadened to a wider audience by modern social media and videos, does almost exactly what I seek to produce. The problem is, is for many such as anons on /vr/, Polybius is likely a hoax. It can neither be proven nor disproven but there is always doubt. In the court of law, one must be proven guilty beyond a reasonable doubt. There is reasonable doubt regarding the existence of Polybius.
I want more. I want all the normalfags, autists, anons, and more to believe my game existed and was cancelled for [insert X reason here] with total certainty. In the beginning there will be great doubt but within 6 months to a year, I want anyone who question its authenticity to be the equivalent of a flat-earther.

>>8069201
>UNROM
just a quick search says switching banks requires a write to $8000-$FFFF
that's the memory mapped IO part, and there must be a register that's part of the mapper that remembers what swappable bank is currently mapped

>>8069208
>What sort of costs
i have no idea how much dies cost because i don't have that kind of cash to throw around on a side project. probably as much as a car

>>8069227
There isn't. You just write to select which bank is active in $8000-$BFFF ($C000-$FFFF is fixed). Just some simple switching logic is all it is.

>>8066404
how much overhead do you expect lmao
you're mainly just going to be doing a bunch of arithmetic and occasionally calling some functions (which will likely get inlined by the compiler anyway), often things that aren't hard for the compiler to optimize
even in the absolute literal worst case, you can just take another vblank to do whatever you're doing, it's not like you're going to enter slideshow territory

yeah, you'll have some functions that'll need to be in asm, but most of those can (and will) just be library calls, stuff cc65 actually does for you
like, fuck, this isn't some theoretical thing, and cc65 isn't some shitty 80s compiler either
https://shiru.untergrund.net/articles/programming_nes_games_in_c.htm

people massively overestimate the overhead of high-level languages, and commercial NES software isn't even hyper-efficient (because the devs had a deadline to hit)
fuck, there are high level languages available for the fucking 2600, and that's a system where you have to count cycles to draw anything at all

>>8066337
It is a hurdle, but it's not insurmountable. It's just annoying to deal with, and you'll need to remember to use the volatile keyword a lot so the compiler doesn't optimize certain things out.
In the literal worst case scenario, the compiler is entirely unaware of the bankswitching method and your code has to fit in the non-bankswitched area of ROM. But, you can easily still just throw in some tables and level data and whatever there post-build and you can trigger the bankswitching in C, and it matters even less if you're bankswitching CHR instead of parts of PRG.

you were doing some awful dance like that in asm anyway

LOL at kids born in 1999 think they can code in asm

C is not viable on pre-5th gen consoles except possibly for an RPG. Too slow and memory is too limited. Pretty much all of the classic games you love were written in assembly language.

Redpill me on making gba games

>>8069979
One of the easier ones to get into..
>HLLs like C supported readily
>ARM assembly is particularly readable and writable
>flat memory map
>fast & simple CPU & GPU
>lots of debugging tools
>lots of documentation
>decent amount of libraries
>cheap and easy to test on hardware
can't go wrong

If I were young with free time what I'd do a little demo rhythm game like Rhythm Heaven

Like this
https://www.youtube.com/watch?v=g4SwBepgmuo
https://www.youtube.com/watch?v=LcT1XIrklhQ
If you want to design levels get SMW Lunar Magic or ZDoom

>>8069934
It's totally reasonable on 4th gen systems.
C is entirely viable on the Genesis in present day (look at SGDK -- someone ported Cave Story with it), and several games from back in the day were written in C on the machine. The 68k is a really good fit for the language, too.
It's less viable by far on the SNES, I don't think anyone ever actually did back in the day. Still, you can use pvsneslib if you want.

As for 3rd-gen machines... you can totally write Master System games in C, there's a bunch of SMS homebrew using devkitSMS.
You can do it for the NES too, it's not like cc65 isn't a thing.
https://www.youtube.com/watch?v=jvgz5sY5xUw
look at how much shit you can move around at full framerate

>memory is too limited
increased code size doesn't matter too much because it's in ROM anyway and is still only going to be a few kB more than hand-written ASM
you might have issues with the stack, but like, you can just avoid stack use
>too slow
it's still a compiled language, and anything but an actively bad compiler will still be in the ballpark of 70% or better vs hand-written ASM regarding reasonably written C, and that's an extreme low-ball estimate where the compiler is missing a bunch of easy optimizations

>>8065304
you're writing heavily platform specific code, you aren't going to be writing C normally anyway
loads of unsigned char everywhere, loads of global variables, etc
still better than needing to manually churn out a dozen lines of asm to do a handful of arithmetic operations when the compiler is going to emit similar code

>>8070008
Or this pedophile garbage
https://www.youtube.com/watch?v=lsOushx9_NU
https://www.youtube.com/watch?v=Jzb1oKLFLH0
good presentation with simple gameplay that doesn't overstay its welcome

>>8069368
I was born in 1996 and have a job where I write asm professionally

>>8070039
For real? What do you work on? little ARM chips? device drivers? legacy maintenance?

>>8070050
Device drivers and firmware for embedded systems. A lot of it is C, but working with assembly isn't uncommon either. I got the job because I made a master system game at school. At the interview they had me draw a block diagram of the master system on the whiteboard and explain how it works and stuff, they figured if I learned z80 assembly in my free time I can learn whatever they need me to.

>>8070072
Based. I'm so sick of webshit and need to find something like this. I'm glad jobs like this exist. also i think i saw you on HN heh

>>8070008
https://www.youtube.com/watch?v=3y73AufFZSM

>>8070018
>anything but an actively bad compiler will still be in the ballpark of 70% or better vs hand-written ASM
Have you ever actually looked at the assembly generated by a C compiler
Even for the 68000 the results are pretty bad, I have used SGDK before, gcc produces horrific code that is enormously slower than hand coded assembly.

>>8070030
>https://www.youtube.com/watch?v=lsOushx9_NU
the backgrounds are way too busy

>>8069208
I worked in the plastic industry for awhile and injection mold dies are incredibly expensive. Even for small simple things you are probably looking at $10,000-$15,000+. I’ve seen molds that are many times that though depending on size and complexity. More expensive if it’s made domestically as well. The actual cost of the cart once the die is made will be cheap (though you will need to order many at a time for anywhere to consider doing a run for you. Hundreds at least maybe thousands or more). But you will need to amortize the cost of that die to ever make your money back.

>>8070018
>It's totally reasonable on 4th gen systems.
...for RPGs, not action games

>>8055748
False. 1s and 0s only is machine code. Assembly is architecture-specific language.

>>8071694
No 1s and 0s is binary. Binary's just a way to represent numbers and generally, if you're looking at machine code directly, it'll be in Hex, not binary, because we aren't using 1-bit machines.

Machine code is a set of operation instructions and it's very much architecture-specific. Assembly is not quite machine code, but it tends to be very close to a 1-1 relationship between assembly and machine code. It's basically a lightweight human-readable layer on top of machine code.

>>8055671
Surprisingly easy to make a basic moving ball type of thing with the tutorials and tools available today. It would help a lot if you were already into programming though.

For a proper game it's going to be hard and take a long time, and for an actual GOOD game that people will play and return to it would be like a full time job.

>>8071724
Just remember Sea Chase anon has spent a couple months just making a port, a game that's already designed. Making a completely original game from scratch is something much bigger than that.

>>8071724
I think the work in making a good game can depend on whether you can come up with a really solid idea that wouldn't be difficult to implement. Tetris is relatively easy to program, but ideas as brilliant yet simple as Tetris are really hard to come by. A lot of arcade games from the 70s and early 80s also are basic enough to implement without being a full time job, but again, they started with solid game designs that could stand on their own without needing 50 levels designed with a dozen graphics sets, a plot, a variety of power ups, enemy types etc.

>>8071780
>I think the work in making a good game can depend on whether you can come up with a really solid idea that wouldn't be difficult to implement.

you have to build things around the limitations of the target platform. obviously an Atari 2600 can't do Final Fantasy IV no matter how badly you might want it to.

>>8071687
anon, are you willfully, deliberately retarded

people have written fucking gameboy games in C
https://github.com/SimonLarsen/tobutobugirl-dx
someone wrote a Genesis port of Cave Story in C
https://github.com/andwn/cave-story-md
this is an action game for the Sega SG-1000 (a system that is inferior to the NES in quite nearly every way) written in C, with graphics better than damn near all the commercial releases on the system
https://www.youtube.com/watch?v=DAFzbL9AOGs
too lazy to find more, but pretty much any site with homebrew for old systems will have quite a bit of software written in C because it's easier than asm
these are all action games, and it's not like they just call a bunch of pure asm functions

people who can't program for shit will talk about how C is too slow despite it being a language made for a machine that operated at an effective 1.25MHz (technically, the machine didn't really have clock cycles like modern computers, but the machine was ultimately limited by the speed at which the memory could operate at)
https://retrocomputing.stackexchange.com/questions/6960/what-was-the-clock-speed-and-ips-for-the-original-pdp-11

>>8071926
to be fair, few things are as limited as the 2600, a machine designed to avoid having RAM as much as possible to the point of having only 128 bytes on board
the high-level Batari Basic language for the 2600 does all the heavy lifting of being able to draw things on screen at all without you going insane while counting cycles, but this comes at an incredibly steep cost -- you have 26 bytes of free RAM (which is a lot more than you'd think, especially if you treat that as having 208 bits of RAM instead, but it's still way less than you'd hope)

there are cartridges that have RAM on board, and that would help a lot, but doing anything vaguely resembling nice RPG graphics would be hell on the 2600, and doing anything text heavy is a nightmare

>>8055671
hard,the nes had very limited abilities so getting it to do even half the shit you want requres very complex programming tricks

also the coding process was much different back then,its gonna be hard despite the games being simple by modern standards

>>8072445
>too lazy to find more, but pretty much any site with homebrew for old systems will have quite a bit of software written in C because it's easier than asm

LOL back in the day thousands of people coded in asm just fine. I grant you that zoomers born in 2002 can't code, but that's not my fault, is it?

https://www.youtube.com/watch?v=TaiaL7zXZGE
https://www.youtube.com/watch?v=7cehaqXFCGE

Uggh, C on retro machines. And this is on DOSBox where you can increase the cycles. Imagine playing this shit on an actual 8086 or 286 PC back then and enjoying your 13 fps (both games written in Turbo C IIRC).

>>8072445
>this is an action game for the Sega SG-1000 (a system that is inferior to the NES in quite nearly every way) written in C, with graphics better than damn near all the commercial releases on the system
in all fairness Z80 is a bit more friendly to HLLs than 6502 is

>>8072445
>https://www.youtube.com/watch?v=DAFzbL9AOGs

well this looks pretty good actually one of the few believable homebrews i've seen that looks like it could have come out back in the 80s as opposed to some bullshit like Micro Mages. if i had to change one thing it would be those bouncing arrows. those things annoy me for some reason. i'd just make them sit there and blink instead.

>>8066372
I think its the simple premise that sells it. All the later games try to do and be something much more complicated, while they sometimes nail it a lot fail.

>>8072893
it is, but the difference isn't some hyper-insurmountable wall
the actual worst thing is the stack, and for most early systems, you want to use global variables heavily anyway and avoid passing things to functions if you can, regardless of the specific problems with the stack on the 6502 because it's faster in general

>>8072884
>pre-Keen side-scrolling PC game runs like shit
like, what else do you expect lol
could it have been smoother? probably a lot vs what's here, but in general, the trick to getting faster smooth scrolling on EGA wasn't widely known

There's a lot of debate here over whether it's feasible to write games for old consoles in C and I feel like it's missing the point. You may not be able to squeeze out 100% top performance for an intensive game using C but making a game in C can totally be done, but why? When making homebrew games for retro consoles, learning the assembly is half the fun, I feel like if you're gonna use a high level language you may as well just download Game Maker, you'll have an easier time and can focus more on the actual game rather than technical details. When I make games for old consoles I go for assembly because the assembly programming is the whole point for me.

>>8071712
If you want to be pedantic it helps to be correct. The machine code is typically represented as hex on screen because it is conveniently a power of 2 and large enough that you can actually fit 32 or 64 bits of information in a small enough space on screen to be useful. However, the actual machine code itself *is* in binary because that is the number of states the transistors, logic gates, and memory cells represent. When computers used magnetic core memory people could reprogram them by selectively magnetizing or demagnetizing individual bits of memory. Nowadays you can do the same thing by targeting individual bits of ram with a laser. It's called laser fault injection.

>because we aren't using 1-bit machines
That isn't even wrong and I'll tell you why. A bit literally means a "binary digit". We almost always call them bits because all of our computers are binary lol. A base three digit is called a "trit". I can't exactly tell what you mean by a "1-bit machine" because there are an almost infinite number of ways to be wrong and only a few ways to be right.

You might be thinking of when people call computers 8bit, 16bit, 32bit, 64bit, etc, etc, but this refers to the address space and sometimes the width of registers. Not the actual underlying mechanics of how information is stored and operated on in the computer. 8bit, 16bit, 32bit, 64bit computers are all "1-bit machines".

>>8073034
HLLs on 8/16-bit machines were far from unknown, it was not at all unusual to use them for RPGs or adventure games as it made adding and removing game assets easier and you didn't have to move much stuff around in Wizardry. Action games however need all the speed they can get and HLLs just don't get the job done.

>>8072445
> this is an action game for the Sega SG-1000 (a system that is inferior to the NES in quite nearly every way) written in C, with graphics better than damn near all the commercial releases on the system
1. The graphics are completely irrelevant, the VDP draws those the code has absolutely nothing to do with it whatsoever.
2. That game pretty much does nothing, there is no scrolling, no complex physics, no slopes, no animations, hardly any game objects. You could probably run this game on interpreted basic.

>>8073801
yeah try doing SMB3 (which has all of that stuff) in C on a 1Mhz CPU

Rather than ruining your life turning into a lolcow to make manchild toys why not learn a practical skill you can actually turn into a marketable carreer instead?
Byuu/Near was one of the most talented 9612 ASM programmer ever and look at the way the internet treated the guy. No good deed goes unpunished.

>>8073957
>look at the way the internet treated the guy
I don't understand, what am I looking at?

>>8073801
>no scrolling
that would be done on the video chip anyway (full disclosure: this is on a machine that doesn't have hardware scrolling at all), and you aren't so starved for frame time that the addition of the camera offset to positions would tank your performance
>no physics
the player has pretty standard delta movement like any other 80s console game, most NES-era games don't have any real physics, anything more complex is usually just a lookup table
>no animations
are you stupid? most shit is animated, and adding more frames is more a question of VRAM because you can just tie everything to a global counter that does more than flip between 1 and 0
>no game objects
it has a pretty normal amount of shit on screen, and some of the limitation is actually hardware -- the VDP can draw 32 sprites on screen at once, but only 4 on the same line at once, and the game uses two stacked sprites for objects because sprites are monochrome
>no slopes
fixed angle slopes like you see in Super Contra and SMB3 aren't computationally complex, and how often do you see those in single-screen platformers
literally just moving up/down based on what tile you're standing on and where you are along it -- you're already checking what tile type you're colliding with, so it's not some massive addition that will chew up more frame time than this
>The graphics are completely irrelevant
it's moving at full framerate instead of dropping to 30fps and most game objects are animated.

>>8073034
Focusing on the technical details is fun, and having a specific set of limits helps define the scope of what to make.

>>8073957
writing C is a marketable career (I kid, I kid, if only a little)

>>8074002
This is my point, focusing on technical details is fun, so if I'm making a game on an old console, I'm doing it in assembly, because that's the fun. If I wanted to make the process of making a game simpler, I would just do it on a modern computer with modern game making tools.

>>8074002
I am well aware this machine has a primitive VDP that lacks scrolling and has significant sprite limitations. But that does not change the fact that the game is not doing those things, things which require significant cpu time. What the game is actually doing requires pretty much no CPU, so its not a good example of the capability of C.

> scrolling
Scrolling is actually quite a significant expense. All game coordinates must be 16bit. Some kind of complex level data structure is required. The pattern table needs to be updated as the level scrolls. Game object coordinates need to be converted from level space to screen space. Its a lot of work.

> Slopes
Slopes might not be expensive to implement, but they are still more expensive than not having slopes.

>>8074102
That's fair.
Not having to deal with more than one hardware configuration is immensely freeing (like, yeah, I can just write my game around a fixed 60hz timer on PC, but people will bitch because their machine is too slow or their monitor refreshes faster than that, etc, etc).
Plus, the system imposes specific aesthetic and playability constraints on the result, meaning that I'm guided towards making certain things depending on what machine I pick. Could just use some fake console thing like TIC-80, but that takes out a lot of the fun.

>>8074121
>scrolling
updating the pattern table is definitely going to be the biggest thing
you could get away with not using 16-bit values -- if you're updating every single object in the level, you're retarded, throw that into an array of on-screen items, moving around 4 things+the player isn't going to kill you

>What the game is actually doing requires pretty much no CPU
and yet, it's still more than an RPG

yeah, you aren't going to be making Gradius and having a dozen enemy bullets and five options trailing behind you and having a bunch of other shit going on, not without just taking the framerate hit and updating the final result every other vblank (giving you a fuckton more time to be inefficient lol)
but there are hundreds of NES games that aren't RPGs that could easily be implemented in C with no real issue and run at full framerate

>>8071780
And what percentage of those 70s and 80s games are played today by more than 20 people?

>>8074485
I'll just pre-emptively point out that I said "percentage", not what amount. We are on 4chan you understand.

>>8074491
Who cares what percentage? The ones that do have a legacy and are still played today still had simple concepts. If you're gonna go by percentages nothing is of value since 99+% of anything ever made goes beneath anyone's notice.

>>8060410
Makes sense. That was pretty common back then anyway. Particularly with a machine like the NES that is (probably?) without an OS and any given cart is just running on the metal. I do not know much of the architecture, and everything back then seemed to be reasonably distinct.

>>8058656
happy bros... weve been defeated

>>8074193
>Plus, the system imposes specific aesthetic and playability constraints on the result, meaning that I'm guided towards making certain things depending on what machine I pick.

That's why the SNES Boogerman isn't that good. It's a game built around the Mega Drive's particular aesthetics. That is to say the Mega Drive lends itself to edgy, gross games like that while the SNES is not built for those, it's built for cutesy games like Magical Pop'N.

>>8072983
The DOS port of Double Dragon actually runs surprisingly well, the dev team were definitely more skilled than the people who did Robocop.

>>8074193
>but there are hundreds of NES games that aren't RPGs that could easily be implemented in C with no real issue and run at full framerate
I mean, Pac-man is no real challenge but LOL at trying to do Kirby's Adventure.

>>8074193
>Plus, the system imposes specific aesthetic and playability constraints on the result, meaning that I'm guided towards making certain things depending on what machine I pick.
>Atari 2600
>ZX Spectrum
Surrealistic drug trips
>C64
80s cyberpunk -core
>NES
Can be cute and Saturday Morning Cartoon-tier or gritty depending on your tastes
>Genesis
Gritty 90s edgecore
>SNES
Fischer-Price-core, beginning of the Nintenyearold meme starting

physics only get complicated when you try 3D stuff like Stunt Car Racer

What kind of game you want to make, OP?

>>8055671
hi eric

RPGs aren't very hard because they have little animation and are mostly just adding up a column of numbers. Platformers are among the harder game formats to program.

>>8072924
>All the later games try to do and be something much more complicated, while they sometimes nail it a lot fail.

The later Mega Mans are like this. They sort of run up against the wall of what you can get out of a NES.

>>8076135
the last three were just reskins of the same game