How hard is it to program a SNES game?
 Thalidomide Vintage Ad Shirt $22.14 |
 Ape Out Shirt $21.68 |
Thalidomide Vintage Ad Shirt $22.14 |
How hard is it to program a SNES game?
How hard is it to program a SNES game?
Thalidomide Vintage Ad Shirt $22.14 |
Ape Out Shirt $21.68 |
Thalidomide Vintage Ad Shirt $22.14 |
I think they're written C
assembly.
On an actual SNES? HARD! It would be much easier to make a SNES-like game on PC or phone.
Modern compilers could absolutely make C or even C++ work, but ASM was used back in the day because it was the only thing that could squeeze enough performance from the consoles
OP, listen to
, SNES is more capable but Genesis is easier to program for since the CPU is moronicly fast and VRAM is unified as well as DMA being simpler
>Modern compilers could absolutely make C or even C++ work
yes. compilers for 6502 based systems have advanced a long way, no longer generating epic amounts of bloated code, but still not recommended to use for any routines requiring cycle accurate timing or performance.
>How hard is it to program a SNES game?
surprisingly easy in assembly. has dma so you can copy large amounts of data around using very few instructions. audio system is probably the hardest part to learn.
>On an actual SNES? HARD!
if you already know 6502, you could learn the basics of snes hardware programming in a weekend. you'll have graphics and sprites going in no time. hardest part is the audio system, but thankfully there's publicly available SPC drivers.
>I think they're written C
some were, most were not and were programmed in pure 65816 assembly. some musicians also used assembly to construct their audio tracks. no fancy midi sequencers or trackers, just typing in notes, rests and effects by hand either in pure assembly language or MML.
>some musicians also used assembly to construct their audio tracks
You literally had to. Both the SNES and Genesis had a second CPU for handling audio so musicians had to know how to write code for these coprocessors
the musicians didn't need to know how to code for it. for megadrive, sega's drivers used a custom variant of MML language, some snes drivers did too. musician didn't need to know how to read the code, just the music data and an ability to know how to compile it. the expectations for musicians was low, anon. very few were writing their own drivers or they got a lot of help.
doubt it, probably machine lang
C was rarely used for that generation
C on an 8-bit CPU? Are you daft? C is barely usable with 16-bit hardware.
>on an 8-bit CPU?
Anon, snes was 16-bit
>Anon, snes was 16-bit
8/16-bit microprocessor. 65816.
Pretty fricking hard, there's a shitload of graphics modes that don't seem to have any use by virtue of being completely inferior to other graphics modes.
Honestly just make a Genesis game unless you REALLY need something the SNES offers for some reason, like Mode 7 or the better palette. Genesis has SGDK, which is a VERY good library for writing Genesis games in C. Best used on Windows but a few people have gotten in working on Linux and Mac.
really?
Sega genesis games were kind off shitty compared to the super nintendo except for sonic. I'd figure if they were easier to make they should have been better.
>Sega genesis games were kind off shitty compared to the super nintendo except for sonic
profoundly ignorant take
They're both done in assembly on a 65c or 6800 chips etc. You don't use C and it wasn't really until ps2 dreamcast era that console games used C.Maybe some custom stuff for psx
https://github.com/Stephane-D/SGDK
Maybe back in the day, but it is very possible to use C to develop Genesis games now.
Shit's rather performant too, you'll want to use ASM if you want to do anything cutting-edge but that won't matter unless you're a pro or an idiot.
Wouldn't C (with inline/file separated) macro assembly be the ideal?
I think you can do that with SGDK, don't quote me on that though.
Super Nintendo and earlier games were likely written in assembly but the modern dev tools use C
PSX and N64 era games were written in C on SGI workstations. Nobody used assembly for that generation of consoles.
SEGA told devs to use assembly that gen and made everyone hate them
Sega should've just not made the Saturn lol
Probably made sense to tell devs to use assembly back then
now of the many chips in the Saturn. a few were sane. There's a 68k and 2xSH2's Those actually likely had solid C Compiler support, if not officially - there was likely something unofficially
The VDP chips on the other hand were a custom design, with VLIW instruction processing. C Compilers and back ends were largely not optimized to deal with that and so assembly was better. (This would remain largely unimproved, as lack of good enough tooling destroyed the whole Itanium project by the more funded and connected Intel)
>Nobody used assembly for that generation of consoles.
they did. inline assembly in c was a thing, homosexual. and it was used. c is just not that great for everything. and those sdks for both systems were notoriously bad.
here's a poor devBlack person programming pure assembly for saturn's shitty dsp
he has more videos on that channel of him programming assembler for that "era"
> PSX and N64 era games were written in C on SGI workstations
> Nobody used assembly for that generation of consoles.
shut the frick up.
N64 had microcode that required assembly programming. Some games used a whole lot of it and consequently are a lot harder to emulate correctly, like Rogue Squadron. Or even Majora's Mask uses microcode for the audio.
Most N64 games didn't bother with custom RSP microcode which is why HLE worked so well for so long. But some games used it a whole bunch which is why certain games fricked up spectacularly on those titles.
as difficult as the game you're trying to make. want to build an atari 2600 on a snes? cake walk.
probably these, making a simple nes-tier game would probably not be difficult, but making a AAA snes game will require a bunch of skills and good knowledge of the system's limitations and quirks
Easy to learn, hard to master.
just write a NES game and use Project Nested to generate a SNES rom
https://github.com/Myself086/Project-Nested
Dunno about SNES but there's an open source NES game if you want to get an idea of the code
https://github.com/Vector35/PwnAdventureZ
pokemon red and blue were 512kb
A single letter character is 1 byte
How the heck did they do it?
programmers were of a different breed then
I'm tired of people having this stupid perception that games used to be harder to program because there were more limitations
The simplicity of things made things easier not harder, it's ten times harder to program a game today
I really want a game console with dead simple graphics rendering like the consoles before the ps3
The tight coupling of software and hardware made it faster and easier to program
I cant think of a harder programming task than making a modern game engine from scratch.
Gtards talk about making a game from scratch as if it were equivalent to using html+css vs wordpress or something.
Still pokemon red was made in assembly. Imagine just push and mov bytes and making a whole game that way. But yeah my main question is how did they make it so small. Hell a pixel is one byte.
making simple stuff in assembly is simple
as for how they make it so small, an assembly op for Gameboy is probably only a single byte. A pixel certainly isn't one byte, Gameboy only had four colors, it's 2 bits
Oh maybe thats why
If its 16x16 pixels and each pixel is 2 bits that'd be.... small
Iwata had to come and start whooping ass when the coders back then couldn't handle it
don't you have some paste to finish eating
compression was huge in this.
for a slight example of what's going on
here's how Pokemon sprites were compressed for the battle scenes
and while not Pokemon, this Is an example of some solid era relative space saving techniques
?t=171
pokemon is a very simple game
If pokemon is a simple game whats a complex game?
World of Warcraft
nethack
That's actually an interesting question.
Ignoring graphics, what is the largest game?
Some sort of flight sim or maybe a city builder?
>Some sort of flight sim or maybe a city builder?
Not even close
an MMORPG or some other big online game
I'm not so sure.
I know a lot of them have full fledged economies and stuff, but the gameplay is usually fairly simple.
The complexity of the gameplay doesn't determine how big the codebase is
Best judge of how much code a game has is how much content it has, how long it's been supported
So no single-player single release game is going to have a large codebase, although the engine behind it could be large
Live service games that have content added and developed over years, decades even like WoW is probably going to have quite a large codebase
a driving simulator that uses google maps data to accurately simulate driving around your city like its gtav
Dwarf Fortress
Actually a good point.
Its only 700,000 lines of code though
How my C string implementation is, I handle words like tokens, which I store in a dictionary. I guess they use that in the game. When a character talks, every word can actually be a reference to the word in the dictionary. Assume a 16 bit dictionary, a 15 word long saying is now only 30 bytes, if it were encoded as characters it would probably be 60 or more. In fact it would be trivial to expand that out and find common word patterns and put those in the dictionary. Easy compression
you're so smart 🙂
Imagine a game world 100GB big. No patches, no nothing.
Xbox/PS2 Graphics.
Everything filled to the brim, guaranteeing hours upon hours of new content waiting to be explored.
Is that what you want?
512KB is not even impressive for a game like Pokemon which has repeating sprites all over the place.
Look at what they can fit nowadays in a standard 64KB Windows .exe
https://invidious.snopyta.org/watch?v=6INL_pxX8L4
it's not really fair to compare a game on an 8bit machine to a scene demo on modern hardware
try comparing it to modern games written for old platforms
here's a 40k NES game;
http://iteroni.com/watch?v=ZWQ0591PAxM
Thanks for introducing me to that world
maybe not using frameworks and having sovl
>not using frameworks
a retro console is somewhat like having a framework except the framework is built into the hardware and can't be changed if it has issues
>thing i did as a child == soul
>thing i didn't do as a child == soulless
yeah we know
cope and seethe frametards, you will never be optimized and performant, you will never run true transparent effects on 1GB ram again
isn't the z80/8080 really good at crunching numbers?
It's a 40 year old 8-bit processor that doesn't even have divide instructions. Are you stupid?
Hecking impossible!
Thst screenshot is NES, not SNES, you fricking zoomster.
NES is 65C02, technically a Ricoh clone. SNES is 65C816. The best bet for targetting those today would be to use a macro assembler, also termed "high level assembly", but not as high level as C.
Im undecided on which was probably harder to program.
World of warcraft or the original age of empires.
World of warcraft didnt use terribly complex lighting i think and age of empires did a lot despite of tge limitations at the time.
world of warcraft
WoW's net code alone eats the entirety of complexity of AoE by a mile
not too bad. you have to make your own tools when they don't exist, though.
this is something i was putting together on /vr/ years ago before i got into grad school. i need to pick it back up now that i have more free time.
https://github.com/gewballs/graviton
Probably very hard, especially considering you often had to hack the console to get the desired results. And since games were largely on cartridges back then, they had to be released as bug-free as possible since you couldn't download fixes.
Link is a game dev who worked on several older titles, including Sonic, Castle of Illusions, and Toy Story.
>https://www.youtube.com/c/GameHut/featured
>you can inline assembly with SGDK
- anon
I spoke with the developer awhile back, there were two ways of mixing ASM with C, one recommended and one not recommended, I don't remember what they were.
Making games for retro game consoles is fricking pointless. A Raspberry Pi is 4000 times faster, and easier to program for, and is actually cheaper than buying the used console now
old hardware has a lot more character than modern stuff
>more character
what is this moronic shit?
no actually all of it was designed by nerds sitting in a room laying out circuits
Eh, dunno, 6502 is an extremely elegant architecture, 65816 less so but still good. It's amazing what is capable with limited hardware with some forethought and careful design.
I agree
you both are moronic. 65816 is a superset of 6502. it's 6502 with more features.
65816 has a 6502 mode but the 16-bit mode is rather clunky with the page boundaries.
>the 16-bit mode is rather clunky with the page boundaries
a page is 256 bytes in this context. you are probably thinking of the memory segmentation mechanism to extend the 16-bit address space of banks to 24-bits. however this mechanism spans segment boundaries when indexing data, it's just code wraps back around in the same bank. the 6502 on the other hand has only a 16-bit address space, and the indirect jump instruction is bugged when crossing page boundaries
Or you can not do that, and write whatever you want on a Raspberry Pi using whatever language you want and whatever tools you want, and never worry about taxing the cpu or ram or graphics because even a gimp mobile GPU is way more than enough to run any 2d game
Ok, but if I was going for ARM dev I'd target the ARM7TDMI for Game Boy Advance development.
A new Raspberry Pi is at least 350 times more powerful than a game boy advance and is actually cheaper than a used game boy advance
>actually cheaper than a used game boy advance
Lmao not anymore Black person
Uhh no it's still cheaper, like a lot cheaper
6502 and 65816 only have 3 general purpose registers. They also have weird addressing modes. Even the gameboy had more registers and was easier to write for.
>65xx, the chad 3 LTR opcodes
>Zgaiety, the virgin unconfident variablelength opcodes
I mean the simplicity of 6502 is very elegant, but you have to use the stack for literally everything with only A, X, and Y to work with.
By the stack do you mean the zero page?
stack is on page 1
zero page is on... page 0
That simplifies it. Part of the difficulty of writing assembly for modern archs is deciding what variables to keep in registers and what in memory to optimize performance. No such dilemma when you don't have an option.
There is a genius named Randy Linden who made programming SNES games look easy. He created a custom engine in Assembly to port Doom to the SNES, all by himself, in less than a year.
Randy Linden also build a custom assembly engine to poet Quake to the GBA. But id didn’t pick this one up so he only converted the first level as a tech demo.
https://www.retrorgb.com/impossible-port-of-quake-found-for-gba-playable-now.html
homie be looking like a tomato
Have some respect
okay, i'm sorry
he do be lookin like dat doe
I doubt you will easily find manuals/tutorials to write a game using the SNES sdk. There's a small chance there's no SDK and everything was done bare metal.
There was an SDK. Anyhow it's been thoroughly reverse engineered since the 00s.
Extremely easy - it's based (and redpilled) on a 6502 variant.
Basically, if you can't build a game for a SNES, you should consider that great comedy duo, Rafter 'n' Rope.
That's NES game.
these guys made a 4 player co-op NES game
but the other anons ITT are right. developing on the genesis would be a whole lot easier. or you could do some low level C for an n64 homebrew. they reverse engineered SM64 and OoT already.
A pain in the ass due to awkward graphics hardware, segmented memory, and a really shitty ISA.
Just program genesis games instead.
Pretty simple in TempleOS.
Frick off, you annoying little shit. You have never attempted to write a SNES game in TempleOS.
Your aggressiveness is proof enough that TempleOS is the best development environment for it.
Prove it then. Write a SNES game in TempleOS right now.
Genesis is soooo much easier. There are barely any good tools for snes. Nes is easier but still requires very in depth PPU, APU, and overall nes internals knowledge. Snes? Fricking forget about it. The 65C816 is an absolute fricking monstrosity that was used in barely anything.
from what i understand, part of the jankiness of the snes architecture was because it was originally meant to be backwards compatible with the nes
I agree. I've made games for both NES and Genesis. SNES programming just isn't fun.
>posts a nes game
This a good game tho
I've been programming for 20 years and just got into homebrew. I'm not a shit developer by any means but It's actually pretty fricking hard if you're used to modern development toolchains. We get babied a lot today. The bar of entry used to be MUCH higher.